1. FckSignups到底在治什么病如果你运营过任何带注册功能的网站或App大概率经历过大半夜被短信轰炸、第二天醒来后台用户表多出几千个昵称乱码账号的崩溃时刻。这些账号不会给你带来任何活跃只会吃掉短信费用、污染数据报表甚至批量发广告把社区生态带坏。FckSignups字面意思不客气但情绪相当真实——它就是一个专门跟注册垃圾死磕的反滥用系统代号核心目标只有一个在注册入口把非真人、不怀好意的请求拦下来。这个项目本质是一套轻量级风控系统由前端行为采集、后端评分引擎、处置策略三部分组成。它适合被垃圾注册困扰但暂时上不起企业级风控平台的团队也适合刚接触风控方向、想了解整套防注册体系是怎么运转的开发、产品和运维。读完这篇你能搞明白三件事垃圾注册具体有哪些形态、为什么验证码已经挡不住它们、一套可落地的防注册系统应该怎么分层设计并一步步搭出来。1.1 垃圾注册的真实成本很多团队一开始觉得垃圾注册就是“脏数据多了点”删库跑路不至于忍忍算了。但把账细算下来它造成的损失远比表面看起来严重。通道成本短信验证码按条计费。脚本刷注册每分钟能烧掉几百上千条短信一个月下来通道费能翻好几倍。数据污染注册量虚高活跃度却原地不动。市场部拿这份数据复盘投放效果ROI算出来全是错的决策跟着跑偏。内容生态恶化批量注册的账号会用来自动签到、刷积分、发广告帖、私信引流把正常用户赶跑。营销预算被撸新人礼金、注册送券、邀请奖励全都会变成黑灰产的提款机。我见过一个电商项目上线首月注册量突然暴涨到正常的十倍运维以为是被攻击了结果查日志发现70%注册来自同一批IDC机房IP段的自动脚本短信费用直接爆表。所以做FckSignups这类系统动手写代码之前要先算一笔账你的注册入口被滥用一天具体损失是多少。这笔账决定了你后面愿意投入多少成本去做防护。1.2 四类最常见的注册攻击形态要防守先得知道对手长什么样。注册滥用的常见形态大致可以归成四类攻击形态行为特征常见目的纯脚本注册请求间隔固定、无浏览器特征、提交速度快批量刷号、薅短信半自动注册模拟浏览器、请求有随机化、能过简单验证码批量养号、占资源人肉/众包注册真人操作、IP分散、速度慢但行为无破绽绕过设备/IP风控撞库/凭证填充用泄露的账号密码批量尝试试登录、盗号表格里前两类是传统技术手段能拦截的后两类是真正的难点。人肉注册用真实用户去操作行为上和正常用户几乎没有差别撞库则是拿外面泄露的密码库往你接口里灌跟注册行为重叠度不高但同样会消耗资源。FckSignups这类系统在设计时不会试图“一键封死”而是把识别率抬高、把攻击成本拉大让攻击者觉得继续搞你不划算。1.3 传统防线的局限与FckSignups的思路图形验证码、滑块、行为验证码本质上都是在增加机器的破解成本。但发展到现在打码平台和各类验证码绕过服务已经很成熟单纯靠验证码已经很难扛住有组织、有技术的批量攻击。FckSignups的思路是“组合判断”不再让验证码当唯一防线而是把注册请求的多种信号——前端行为特征、设备指纹、IP历史、注册频率、表单填写节奏——全部收集起来算一个风险分。分数高就要求二次验证或者直接拒绝。用大白话说普通的注册流程只是一次密码验证FckSignups是把注册变成一次“证据链审查”攻击者每多伪装一个维度成本就要往上翻几倍。这套组合判断的思路是理解整个项目后续所有设计的基础。下面我把三层过滤架构拆开讲清楚。2. 防注册系统的核心设计三层过滤架构FckSignups的工程形态可以拆成三层每层拦截不同颗粒度的问题三层串起来形成一条完整的防线。2.1 第一层前端行为采集前端行为采集是整套系统的第一道信号源。真人注册时从打开表单到点击提交背后有大量不规律鼠标移动会有停顿、有折返键盘输入速度有快有慢从姓名填到密码之间会有思考间隔。脚本注册正好相反行为序列极短、交互事件极少、鼠标轨迹几乎是一条直线。这一段放一个轻量采集示例展示怎么把用户在注册页的交互事件记录下来后续随注册请求提交到后端风控引擎// 轻量行为采集记录注册页的关键交互事件 const events []; const MAX_EVENTS 200; const formStart Date.now(); function record(type, detail) { if (events.length MAX_EVENTS) return; events.push({ t: Date.now() - formStart, type, detail }); } document.addEventListener(mousemove, (e) { record(mm, ${e.clientX},${e.clientY}); }); document.addEventListener(keydown, (e) { record(kd, e.key); }); document.addEventListener(click, (e) { record(cl, ${e.clientX},${e.clientY}); }); document.getElementById(signup-form).addEventListener(submit, async (ev) { ev.preventDefault(); const behavior { duration: Date.now() - formStart, events }; const formData Object.fromEntries(new FormData(ev.target)); // 将行为数据和表单数据一起提交给后端 await fetch(/api/signup, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ ...formData, behavior }) }); });后端拿到行为数据后可以计算几个统计量事件总数、鼠标轨迹点数、交互间隔标准差、页面停留总时长。真人停留时间通常在几十秒到几分钟事件数在几十到几百之间脚本往往两三秒就提交事件寥寥。这些信号单独看都不绝对但组合在一起后判断可靠性会明显提升。这里有个新手容易踩的坑把前端采集的数据当成唯一裁决依据。前端数据是可以被伪造的攻击者完全可以先观察你采集的字段再写脚本模拟一份合理的行为序列。所以行为采集只能作为第一层信号后面必须叠加服务端信号一起评估。2.2 第二层后端规则引擎与评分后端拿到行为数据和注册基础信息后会做一套综合评估。这一层才是FckSignups的核心。以常用的 Node.js/Express Redis 技术栈为例我的做法是给每个注册请求计算一个 0 到 100 的风险分分数越高越可疑再根据分数区间执行不同动作。核心伪代码如下// 风控评分每个维度加权计算分数越高越可疑 function riskScore(ctx) { let score 0; // 行为信号停留时长、事件数、事件熵 score behaviorScore(ctx.behavior); // 频率信号IP、设备指纹、手机号段在单位时间内的注册次数 score frequencyScore(ctx); // 设备信号无痕模式、canvas指纹缺失、异常UA score deviceScore(ctx); // IP信号IDC机房、代理、秒拨IP池 score ipScore(ctx.ip, ctx.ipInfo); // 业务信号注册后是否立刻请求敏感接口、是否命中历史黑名单 score businessScore(ctx); return Math.min(100, score); }算完风险分后处置动作按阈值分段0到30分正常注册走标准流程。30到70分要求二次验证比如滑块、行为验证码或短信验证码。70到90分限制注册进入人工审核队列。90到100分直接拒绝IP和设备指纹进封禁名单。权重怎么定先用历史真实数据离线跑一遍看每个指标的分布再结合实际误杀率调整。轻量系统不建议一上来就用机器学习模型规则引擎解释性强出问题能快速定位是哪个信号触发的比黑盒模型好维护得多。等积累足够多标注样本后再考虑模型提升准确率。2.3 第三层验证码、封禁与人工复核评分之后不是结束而是执行处置。这层有一个关键原则能拦在注册前就不要等注册完再清理。二次验证对中等风险用户出验证码。验证码选型上滑块和行为验证码体验比传统图形验证码好但都要清醒认识到它不是万能的。它只是一个“提高攻击成本”的手段不是终极解决方案。频率封禁同一个IP、设备指纹、手机号段在短时间内多次注册直接进黑名单。封禁策略用阶梯式第一次封1小时第二次24小时第三次一周避免一刀切永久封误伤正常用户。人工复核高分用户进入等待队列运营或客服后台审核通过后手动放行。虽然这里人工成本高但对真实用户的保护作用很强。三层架构串起来核心是“有拦有放”。只做验证码挡不住绕过只做IP黑名单误杀和绕过都严重。三层联动才能在不牺牲正常用户体验的前提下把绝大多数注册垃圾挡在门外。3. 手把手搭一个轻量版FckSignups讲完设计下面落到代码。我不会贴一份能直接复制上生产的完整工程但会给出最小可运行骨架以及每一步关键决策的说明。3.1 最小架构设计轻量版只需要三个组件前端页面注册表单 行为采集脚本。后端服务接收注册请求调用风控评分函数。Redis或数据库存放IP黑名单、频率计数、封禁记录。技术栈不强绑定。我用 Node.js Express 写规则引擎比较多因为异步IO处理并发注册很顺畅JSON处理也方便用 Python 的 Flask 或 FastAPI 也完全可以。关键在于规则设计语言只是工具。3.2 前端采集的细节补充前面2.1的基础版能跑但有几个细节容易忽略采集字段不用贪多。mousemove 事件如果每帧都记录一个用户停留五分钟就能积累几千条数据既拖慢前端又浪费网络传输。加个事件上限比如200条超出就丢弃只保留前200条就够了。提交时给行为数据加时间窗校验。后端要检查 behavior.duration 是否在合理范围内小于2秒直接判可疑大于2小时也判可疑正常用户不可能在注册页停留2小时才提交。移动端要单独处理。手机上鼠标事件不存在光标移动事件也不触发需要兼容 touchstart、touchmove 事件或者干脆在移动端降低行为信号权重改用短信验证码等其它信号。3.3 后端评分引擎代码示例以 Node.js 为例核心函数是评分和频率控制。频率控制这里重点讲实现const redis require(redis); const client redis.createClient(); // 频率检查在窗口期内统计计数是否超限 async function checkFrequency(key, windowSeconds, maxTimes) { const count await client.incr(key); if (count 1) { await client.expire(key, windowSeconds); } const blocked count maxTimes; if (blocked) { // 记录触发频率限制的完整key方便后续排查 console.warn(frequency blocked: ${key}, count${count}); } return blocked; } // 示例同一个IP在10分钟内最多允许3次注册 const ipKey signup:ip:${ip}; const ipBlocked await checkFrequency(ipKey, 600, 3); // 示例同一个设备指纹在1小时内最多注册2次 const devKey signup:dev:${deviceId}; const devBlocked await checkFrequency(devKey, 3600, 2);为什么用Redis而不是直接查数据库因为注册接口并发往往很高Redis 的 INCR EXPIRE 是原子操作性能好还能自动过期清理。如果用数据库 count update高并发下会产生大量锁竞争和慢查询接口延迟很快就上去了。评分函数里我强烈建议每个维度都输出独立的日志字段。比如记录行为总时长、事件数、频率计数、IP归属类型。这样后续排查误杀时能精确看到是哪个信号把分数拉高的而不是只有一个干巴巴的总分。3.4 阈值设定与线上灰度阈值不能拍脑袋。上线前最好拉历史真实注册数据做离线回放统计每个指标的分布。一个实际做法取过去30天正常注册用户的行为数据画停留时长的分布图。如果90%正常用户停留时间在15秒到10分钟之间那把3秒以内提交的请求打上一个较高的可疑分是合理的。类似地IP注册次数也能做分布统计。正常家庭宽带的IP下一个月注册1次占绝大多数企业出口IP可能多一些。先设定一个经验值上线后用误杀率来调整。我的切身体会是初次上线的阈值宁可松一点也不要紧。宁可漏掉10%的垃圾请求也不要误伤1%的真实用户。漏掉垃圾请求顶多脏数据多一些误杀真实用户直接损失业务转化率这个代价完全不同。上线分四步走日志模式只记录风险分不拦截跑3到7天积累真实数据。调整阈值用日志数据校准确认高风险请求占比在预期范围。低风险拦截先只拦截90分以上的请求观察误杀情况。逐步放开把中等风险用户的二次验证加进来观察转化率变化。这四步看着慢但能帮你安全地把规则跑起来。很多团队一上来就全量拦截第二天业务方就收到一堆用户反馈说注册不了最后只能紧急回滚。3.5 前端伪造的对抗措施前面已经提过前端数据可伪造这里给几个实用的对抗手段行为数据做 HMAC 签名前端在采集结束后把行为数据和时间戳拼起来用预共享密钥做一次 HMAC后端验证签名合法才继续评分防止攻击者直接改数据包。校验事件序列的合理性真人交互的事件类型一般是 focus、keydown、blur、click 交替出现纯脚本生成的序列往往非常规律。可以对事件类型序列计算熵值熵过低说明太规律需要打可疑分。行为采集脚本做轻量混淆增加攻击者逆向的成本不需要多复杂能挡住大部分半自动脚本就够了。需要清醒的是跟攻击者拼前端混淆是没有终点的军备竞赛。所以不管前端做多少后端信号始终要保持独立IP、设备指纹、频率、业务行为都要并行不能把宝押在单一维度上。4. 常见问题与排查技巧实录这套系统真正跑起来之后会遇到一些预想不到的情况。我把常见问题整理成速查表和排查思路方便你对照。4.1 误杀真实用户怎么办误杀是所有风控系统绕不开的问题。我最常见到的场景有三个公司或校园网出口是同一个公网IP几十上百人共享一个出口频率限制很容易把后面注册的人误伤。用户开了无痕模式设备指纹不完整指纹评分被拉高。用户用了浏览器的自动填充标记判定很快行为事件特别少看数据像脚本。排查误杀时一定要把日志里的原始事件和最终分数保留下来最好把触发信号也打出来。比如日志记成score:72, reasons:{frequency:30, behavior:42}一看就知道是哪个环节出了问题。定位之后再针对性调整权重不要盲目把全局阈值调低。注意频率限制里的IP判断要处理NAT场景。只对单个IP做“x分钟内允许n次注册”会把办公室、校园网这种共享出口误伤。实际中可以把频率限制拆成两级行为分不高时放宽频率限制只有行为分也偏高时才应用严格频率限制。4.2 换IP、改指纹的绕过怎么防攻击者用代理、秒拨IP池可以轻松换IP用指纹修改插件可以伪造大部分设备指纹。这时候单点信号全部失效只能靠多维交叉验证。我常用的组合拳是IP性质识别把IDC机房IP、代理IP、家庭宽带IP做分类。同一个家庭宽带IP短期内大量注册逻辑上不太合理IDC机房IP天然可疑分更高。设备指纹关联分析IP能换但攻击工具的指纹生成算法往往有特征比如canvas结果总是缺某几位、WebGL渲染内容异常。把这些异常特征加入指纹评分体系。业务链路约束注册成功后的动作也要风控。比如新账号注册后5分钟内就发帖、申请优惠券触发业务流风控直接限制。IP库现在有不少商业化服务也可以自己维护一份“高危IP段”名单。预算有限的情况下可以先人工拉取主流云厂商的IP段凡是这些IP段来的注册请求要求做更严格的验证。4.3 日志与复盘别只封号不看数据很多团队做风控只看今天封了多少号不分析攻击者是怎么进来的。这样会导致规则越来越僵化某天攻击手法一变规则就全部失效了。建议每周做一次复盘动作很简单拉出被拦截请求的样本人工翻看前20条看有没有误杀。统计每类信号命中的比例。如果某个信号命中率异常高说明攻击者可能正针对这个弱点批量操作。根据复盘结果更新规则权重和黑名单形成滚动迭代。日志字段尽量结构化至少包含时间、IP、设备指纹、风险分、触发信号、处置结果、用户ID。这套日志未来做模型训练也用得上值得一开始就设计好。4.4 常见问题速查表现象原因处理建议真实用户注册被拒NAT共享IP触发频率限制频率限制和行为分组合判断垃圾注册仍然很多只做了IP限制对方用秒拨增加设备指纹与业务链路验证验证码被绕过打码平台识别换行为验证码并叠加评分接口被直接刷前端校验被绕过后端必须做签名与完整校验误杀率居高不下阈值太紧调松阈值先跑日志模式规则突然全部失效攻击手法升级复盘日志更新规则与指纹库4.5 一个容易被忽略的细节静默处理再分享一个很少被人提到的实战技巧不是所有可疑请求都要直接拒绝。对一些风险分中等的请求可以给一个“看起来很正常的假成功”——注册流程走完但账号进入观察期不能发帖、不能领券、不能评论。这样做的原因是攻击者不容易感知到规则被触发也就不会立刻调整策略来对抗你。如果每次都明确报错攻击者很快就能测试出你的边界针对性绕过。这个方法尤其适合内容社区和电商。因为黑灰产的批量注册目标往往是领补贴、发广告观察期直接掐住这两个核心动作他们的ROI就撑不住了。5. 维护一年后的几条心得把FckSignups这类系统从零搭起来并维护一段时间后我沉淀了几条经验不一定高深但确实帮我解决过不少实际问题。风控规则的版本管理要做扎实。改权重、改阈值必须留版本记录每次改动后跑一遍已有样本集做回归。有一次我们调了一个小权重第二天注册成功率掉了5%因为没有版本记录排查了很久才定位到是这次改动引起的。从那以后每个规则版本都绑定一份标注好的样本集上线前先对样本集跑一遍指标正常才发布。另一个体会是不要追求完美拦截。风控本质上是跟攻击者比成本你的系统能让对方注册100个账号所需时间从5分钟变成2小时他大概率就会换个目标。所以你可以一直追问自己一个问题新加的这个规则是让真实用户变麻烦了还是让攻击者变贵了如果主要作用是后者哪怕拦截率只提升几个百分点也值得做。做FckSignups不用一开始就搞得很重。一套行为采集、一个评分函数、一组合理阈值、一堆结构化的好日志就能挡掉绝大多数注册滥用。先把这些基础做扎实后面再谈模型、再谈深度学习。攻防博弈永远在变但你只要比攻击者多走一步就能省下大量实打实的损失。
