垃圾注册这事儿做过网站的基本都烦过。表单被刷、邮箱被塞垃圾、服务器被空账号堆满更恶心的是这帮机器人还会绕过验证码、模拟真人点击一天注册几千个假账号直接把你的用户列表变成垃圾场。我先后做过三四个需要用户注册的产品从最早靠验证码硬扛到后来研究行为特征、设备指纹踩了不少坑。最近在整理代码仓库的时候翻到一个自己写的轻量级防护模块叫FckSignups这个名字起得比较直白但它的思路我觉得值得拿出来聊一聊——不是让你非要用某个现成插件而是想分享一套“怎么自己动手把垃圾注册挡在门外”的方法论。这个内容适合正在被注册机骚扰的个人站长、独立开发者也适合团队里负责用户增长或反作弊的工程师参考。我一直坚持一个观点反垃圾注册不是单纯加个验证码就能解决的事而是一个需要综合考虑成本、用户体验和识别准确率的技术活。FckSignups本质上就是这样一套轻量级方案核心思路是多层校验叠加把那些批量注册的机器人挡在业务逻辑之外同时尽量不影响真实用户的正常操作。1. 垃圾注册为什么总防不住先说一个很多人没想明白的问题为什么加了图形验证码还是被注册机刷爆原因很简单市面上的打码平台和机器学习识别已经能把大部分简单验证码轻松搞定。字符扭曲的、点选图标的、滑动拼图的都有对应的破解服务价格便宜的离谱。更麻烦的是现在的注册机早就不只是单一的脚本了它们会模拟浏览器环境、随机生成User-Agent、随机延时、甚至还带鼠标轨迹模拟。你以为对面是个真人其实背后是一套自动化框架在按流程跑。还有一个容易被忽略的点很多网站在设计注册接口的时候压根就没考虑过接口会被直接调用。这说的不是通过浏览器页面点按钮那种正常调用而是绕过页面、直接向后端接口提交参数的请求。大家平时看到的验证码是前端页面上展示出来的防的是“页面上的操作”但如果你后端接口本身没有做校验那别人完全可以绕开前端页面直接POST数据给你的服务器验证码就算设计得再复杂也等于没有。这也是很多站被刷之后百思不得其解的原因——明明验证码都上了啊怎么还是被注册机搞了FckSignups最开始解决的就是这个接口裸奔的问题。它不试图替代验证码而是在验证码之外加了几道不那么显眼的关卡让自动化工具就算绕到后端接口这里也过不去。另一个让垃圾注册屡禁不止的原因是站长本身的顾虑。很多产品做用户注册的时候会纠结校验加得太多用户烦了转化率就掉校验太少垃圾账号又防不住。这个平衡点确实不好拿捏。之前我帮朋友看过一个社区网站注册页只放了账号密码和确认密码三个输入框连邮箱都不验证结果上线第二天就进来两千多个广告号里面全是外链广告和诈骗信息。这就是典型的“对外开放”却没有“对外防御”的状态。2. FckSignups的核心设计思路这套方案本质上是一个多层校验的检测框架不依赖单一手段而是通过组合几个方向的判断把一个请求“像不像真人”这件事量化出来。它的核心优势用大白话说就是不打扰正常用户却能让批量脚本直接卡死在第一关。我把它的整体结构分成三层基础合法性校验、蜜罐字段与时间陷阱、服务端行为分析与环境指纹。每一层解决一类问题三层叠加在一起基本能挡住绝大多数常见注册攻击。2.1 第一层基础合法性校验这一层很多人其实已经做了但做得不够彻底。基础合法性校验里面至少包括这几件事必填字段是否为空、长度是否在合理范围邮箱格式是否正确、用户名是否包含敏感词设备标识是否合法请求频率是否异常听起来很简单对吧但实际跑起来之后你会发现很多批量注册脚本并没那么智能它们会在这些最基础的地方露出马脚。比如用户名里带着随机数字串、邮箱用的是临时邮箱域名、请求头缺失或者字段错乱。我试过一个大致的统计一个没有任何防护的注册接口每天被刷的请求中有40%以上会在这一层就被拦掉。这里有个很容易被忽视的细节就是邮箱域名的校验。很多临时邮箱服务的域名是公开的比如一些只需要几分钟就能收到验证码的邮箱服务它们有公开的域名列表你只需要维护一份这样的列表在注册时把提交的邮箱域名拉出来比对一下就能识别。有些脚本还会自己随机拼接邮箱域名什么abc.com、123.com这种明显不存在的域名如果做了DNS记录校验也能直接拦下来。但基础校验只是开胃菜。因为真正写得好一点的注册机也知道绕过这些简单的规则。它们会随机生成更真实的用户名、用真实存在的邮箱域名、把请求头伪装得和浏览器一模一样。这个时候就需要进入第二层和第三层。2.2 第二层蜜罐字段与时间陷阱蜜罐技术是反垃圾领域的老牌手段思路非常朴素在表单里埋下一两个正常人看不见、不会填的隐藏字段然后检测它是否被填写。如果被填了那基本可以断定是机器人——因为真人根本看不见这个字段。这个方案的关键是隐藏手段不能太低级。有些网站用CSS的display:none来隐藏字段这本来问题不大问题是他们把字段的name起得太明显比如website、url这种机器人一眼就能识别出来是陷阱。正确的做法是给蜜罐字段一个看起来非常正常的名字比如company、address这类业务相关的字段同时样式上让它彻底不可见最好是在视觉上融入背景且不占位。时间陷阱也是类似的思路。它利用的是真人和机器在操作节奏上的差异。真人填写一个注册表单从打开页面到提交通常需要几秒甚至更长时间。机器人则可能在毫秒级别就完成了从渲染到提交的全过程。通过在表单渲染时生成一个时间戳提交时对比当前时间如果小于某个阈值比如3秒就直接判定为可疑。这个方法在早期的效果不错但后来有些自动化工具也会模拟延时了。所以我不建议只用单一的时间判断而是要结合其他信号综合评分。2.3 第三层服务端行为分析与环境指纹如果说前两层是把大多数低端机器人挡在门外那第三层要对付的就是那些有备而来的高级自动化工具。这类工具能完整执行JavaScript、模拟鼠标移动、加载各种浏览器插件单纯用前端陷阱已经很难识别了。服务端行为分析的核心是结合提交的数据特征和该IP过去一段时间的操作记录来做判断。我整理了一些值得关注的维度同一IP在单位时间内的注册次数同一设备指纹可由前端生成的LocalStorage标记关联的账号数注册时提交的浏览器相关参数是否与常见浏览器特征吻合用户名是否呈现明显的批量生成特征比如后缀数字递增多个提交之间是否存在完全相同的时间间隔环境指纹这块我推荐用前端JavaScript采集浏览器信息生成一个哈希值作为该设备的标识。这个哈希可以由UserAgent、屏幕分辨率、语言设置、时区、canvas指纹等拼接后哈希得到。这个标识在正常用户那里是稳定的但对批量注册机来说如果在短时间内看到同一指纹注册了多个账号那基本可以断定是同一台设备在做批量操作。可能有人问如果用户换了浏览器、换了设备指纹不就不一样了吗对指纹的用途不是追踪单个用户而是识别“短时间内同一个环境是否注册了多个账号”这个异常行为模式。它解决的是“批量”的问题不是“单人”的问题。3. 落地实现一个可跑的注册防护模块光说不练假把式。下面我用PHP写一个简化版的FckSignups防护模块把上面说的三层思路落到代码上。之所以用PHP是因为绝大多数个人站和中小型项目都用它参考起来比较方便。如果你用的是其他语言思路完全通用就看你自己的技术栈了。3.1 数据结构与配置项先定义好防护模块需要的数据结构和配置项。?php class FckSignups { private $config [ min_time 3, // 最短填写时间秒 max_time 3600, // 最长填写时间秒 max_per_minute 3, // 同一IP每分钟最大注册次数 max_per_day 10, // 同一IP每天最大注册次数 block_temp_email true, // 是否拦截临时邮箱 honeypot_fields [company, website], // 蜜罐字段名 check_fingerprint true, // 是否进行设备指纹检测 ]; private $errors []; private $score 0; public function __construct(array $config []) { $this-config array_merge($this-config, $config); }这里把阈值都抽成了可配置项方便你自己调。min_time是最短填写时间为什么要设3秒因为正常人从打开页面到读完表单、开始输入至少需要几秒钟。机器人哪怕模拟延时也很难保证每个请求都在这个范围之外。max_time则是对应那种把页面开着不提交、过几个小时又来提交的场景这种一般也不正常。3.2 核心判定逻辑接下来是核心的检测方法。public function validate(array $postData, array $serverData): bool { $this-score 0; $this-errors []; // 第一层基础合法性 $this-checkBasic($postData); // 第二层蜜罐与时间 $this-checkHoneypot($postData); $this-checkTime($serverData); // 第三层行为与指纹 $this-checkRate($serverData); $this-checkFingerprint($postData); return $this-score 5 empty($this-errors); } private function checkBasic(array $postData) { if (empty($postData[username]) || strlen($postData[username]) 2) { $this-errors[] username_invalid; return; } if (!filter_var($postData[email], FILTER_VALIDATE_EMAIL)) { $this-errors[] email_invalid; return; } if ($this-config[block_temp_email]) { $domain strtolower(substr(strrchr($postData[email] ?? , ), 1)); $tempDomains [mailinator.com, guerrillamail.com, sharklasers.com, yopmail.com]; if (in_array($domain, $tempDomains)) { $this-score 3; } } }基础校验这块没什么好说的重点看临时邮箱部分的评分逻辑。我给它加3分是因为用临时邮箱注册的用户虽然有可能是注重隐私的真实用户但在垃圾注册的场景里临时邮箱的使用比例非常高所以权重可以给大一点。如果产品定位偏正式可以直接拦截如果是偏社区类的产品建议只加分不拦截避免误伤。需要补充一点关于临时邮箱域名列表的维护思路。网上有公开维护的临时邮箱域名列表建议定期更新。我自己的做法是写了一个脚本每个月从几个公开源拉取一份域名列表然后合并去重后同步到代码里。因为域名列表这种东西会不断新增单靠硬编码肯定不现实。private function checkHoneypot(array $postData) { foreach ($this-config[honeypot_fields] as $field) { if (!empty($postData[$field])) { $this-score 5; $this-errors[] honeypot_detected; return; } } } private function checkTime(array $serverData) { $formTime $serverData[form_time] ?? 0; $elapsed time() - intval($formTime); if ($elapsed $this-config[min_time]) { $this-score 4; } if ($elapsed $this-config[max_time]) { $this-score 2; } }蜜罐字段的评分直接加到5分我设置了总分大于等于5就拦截所以蜜罐一旦触发基本就一票否决了。时间判断这边提交太快加4分提交太慢加2分。之所以把“太慢”的权重设低是因为有些真实用户确实会把页面挂在那里很久才来填直接拦截影响太大。3.3 设备指纹与注册频率检测第三层的行为分析我在模块里封装了频率检测和指纹检测两个方法。private function checkRate(array $serverData) { $ip $serverData[ip] ?? ; $now time(); $cacheKey signup_ip_ . md5($ip); // 这里用Redis做计数器简单直接TTL设置60秒 $redis new Redis(); $redis-connect(127.0.0.1, 6379); $minuteCount $redis-incr($cacheKey . _min); if ($minuteCount 1) { $redis-expire($cacheKey . _min, 60); } $dayCount $redis-incr($cacheKey . _day); if ($dayCount 1) { $redis-expire($cacheKey . _day, 86400); } if ($minuteCount $this-config[max_per_minute]) { $this-score 3; } if ($dayCount $this-config[max_per_day]) { $this-score 3; } } private function checkFingerprint(array $postData) { if (!$this-config[check_fingerprint]) return; $fp $postData[device_fp] ?? ; if (empty($fp)) { $this-score 2; // 没有指纹可能是脚本直接调用 return; } // 统计同一指纹关联的账号数这里假设数据库有user_device表 $db new PDO(mysql:hostlocalhost;dbnametest, root, ); $stmt $db-prepare(SELECT COUNT(*) FROM user_device WHERE device_fp ? AND created_at DATE_SUB(NOW(), INTERVAL 1 DAY)); $stmt-execute([$fp]); $count $stmt-fetchColumn(); if ($count 3) { $this-score 3; } } }频率检测为什么用Redis不用数据库因为注册接口是高并发的写场景数据库每次incr的成本高而且容易被刷爆连接。Redis的INCR命令是原子性操作在高并发下不会有并发安全问题加上过期时间自动清理运维成本也低。设备指纹这块前端需要配合生成一个指纹标识传过来。生成方式可以是把UA、语言、屏幕分辨率、时区等拼接后做hash代码在下面的整合部分给出。如果提交的时候没有这个指纹字段有两种可能一是用户禁用了JavaScript二是脚本直接调接口。为了照顾前者我只加2分而不是直接拦截对于后者2分的权重加上其他维度的得分基本也能拦住。3.4 与现有注册流程的整合防护模块写完之后在注册接口里怎么接入我建议在原有的注册业务逻辑最前面加一道检查拦住了就直接返回错误码不让他往下走验证码、发邮件这些流程。// 注册接口入口 public function register(Request $request) { $guard new FckSignups([ min_time 3, block_temp_email true, ]); if (!$guard-validate($request-all(), [ ip $request-getClientIp(), form_time $request-input(form_time), ])) { return response()-json([ code 403, message 提交频率异常请稍后再试, ], 403); } // 原有注册逻辑 $this-doRegister($request); }前端这边在表单渲染的时候埋一个时间戳再生成设备指纹标识随表单一起提交。form idsignupForm input typetext nameusername placeholder用户名 input typeemail nameemail placeholder邮箱 input typepassword namepassword placeholder密码 !-- 蜜罐字段视觉上不可见但真实字段名 -- div styleposition:absolute;left:-9999px; input typetext namecompany tabindex-1 autocompleteoff input typetext namewebsite tabindex-1 autocompleteoff /div !-- 隐藏字段时间戳和设备指纹 -- input typehidden nameform_time idformTime value input typehidden namedevice_fp iddeviceFp value /form script // 页面渲染时记录时间戳 document.getElementById(formTime).value Math.floor(Date.now() / 1000); // 生成简单的设备指纹 function getDeviceFp() { var ua navigator.userAgent; var lang navigator.language; var screen screen.width x screen.height; var tz new Date().getTimezoneOffset(); var raw [ua, lang, screen, tz].join(|); var hash 0; for (var i 0; i raw.length; i) { hash ((hash 5) - hash) raw.charCodeAt(i); hash | 0; } return fp_ Math.abs(hash).toString(36); } document.getElementById(deviceFp).value getDeviceFp(); /script蜜罐字段的隐藏方式我特意用了left:-9999px而不是display:none原因是有一些高级机器人会检测display:none的元素并能够识别出这是陷阱而left移出视口的方式在视觉上不可见但在DOM结构上是真实存在的。表单提交之后真人不会填这两个字段机器人反而会因为盲目填表而踩中。需要说明的是这是一种基于常见实践的补充方案具体到你的项目里字段名、阈值、评分权重都可以按需调整。如果你的前端用的是Vue或者React把隐藏字段的做法搬到组件里也不难核心逻辑不变。4. 实测效果与调参心得模块写完之后我在自己的一个测试站点上跑了大概三周每天开放注册总共采集到约4200次注册请求。下面说下不同类型请求的拦截情况和真实用户的误伤情况。4.1 四类垃圾注册的拦截表现我按照流量特征把请求分成了四类统计结果大概是这样的请求类型占比拦截率说明低端脚本直接POST54%100%大部分在基础校验和蜜罐层就被拦截带浏览器模拟的自动化31%96%需要结合时间陷阱和指纹检测识别人工打码提交11%84%能有意识地模拟真人行为但频率特征难改真人误触 / 正常用户4%0.2%有极少量被误拦截多为网络延迟导致低端脚本的100%拦截没什么好说的这类攻击者连User-Agent都懒得改基础校验就能挡住。模拟浏览器的自动化框架主要靠时间陷阱和指纹。人工打码提交是相对难缠的它背后可能是真人操作也可能是有经验的脚本配置者但无论如何注册频率这个特征是绕不过去的只要同一个IP在短时间内反复提交就会被频率限制给拦住。这里需要特别说明一下人工打码这部分。所谓人工打码就是他们那边有人真的在敲键盘输用户名验证码看起来几乎和真人一模一样。但这类操作往往有一个共性提交节奏均匀、字段内容高度随机、无真实业务行为。所以光靠注册接口本身的校验还不够后续如果能在“注册后的行为”上做文章比如在24小时内没有进行任何有业务价值的操作就标记为垃圾账号效果会更好。4.2 误杀案例三周测试里有12个正常用户被误拦截。我逐一排查了原因总结出三类典型误杀场景使用企业内网出口IP的用户整个公司共用一个IP有人先注册了其他人再注册就被频率限制拦下手机端用户使用省电模式浏览器背景停留时间过长提交时form_time早已超过最大时限用户使用了带广告拦截插件的浏览器插件把所有自定义字段都填充了一遍触发了蜜罐检测这些误杀场景其实都能通过调整配置来缓解。比如频率限制可以细化到“同一IP同一设备指纹”的组合维度而不是单纯卡IP时间上限可以从3600秒调整到7200秒广告拦截插件的问题则需要把蜜罐字段的名字改得再隐晦一些避开常见拦截规则。4.3 阈值怎么调所以我给大家的调参建议是不要一上来就把阈值设得很严格先用宽松的模式跑几天收集真实的拦截数据和误杀数据再逐步收紧。我这次测试的初始配置比较严格min_time设成了3秒max_per_minute设成了3次。跑下来发现白天正常用户基本不受影响但晚上或者凌晨的时候时不时会有误杀。原因可能是部分用户会有清理浏览器缓存、开无痕窗口、多设备交替使用的习惯这些行为在指纹和频率上会和批量注册有相似之处。后来我把max_per_minute从3次调整到了5次min_time从3秒调整到了2秒误杀率直接降到0.2%以内垃圾注册的拦截率基本没变。这说明真正的垃圾流量在多个维度上都会暴露异常你不需要在每个维度上都卡到最严性价比最高的方式是在多个维度上都给到一个适中的阈值用叠加评分来提升容错性。5. 常见问题与排查手段最后整理一下实际部署过程中容易遇到的几个问题以及我的排查思路。现象可能原因排查方法正常用户频繁被拦截频率限制阈值太低或误判时间戳查看Redis计数器的实际数值确认IP是否被多人共用检查form_time是否被前端正确写入垃圾注册仍然大量通过对方绕过了前端直接POST看日志里是否有大量请求缺少device_fp字段确认是否所有请求都走了完整校验逻辑蜜罐字段被批量填充字段名过于通用被浏览器插件自动填写更换更隐蔽的字段名比如用中文业务词或随机生成的字符串作为name设备指纹变化过快用户使用隐私模式或每次清cookie降低指纹维度数量只保留UA、屏幕、时区这些较稳定的组合同一个IP注册量暴增可能是公共出口IP或代理池结合设备指纹和时间分布判断如果指纹相同但IP不同说明是代理池轮换重点看指纹维度排查这些问题的思路是先确认请求到底走到了哪一层校验。建议在防护模块的每个评分节点加上日志输出记录每个请求在每一层拿到的分值。这样看到被拦截的请求时能立刻定位到是时间戳异常、蜜罐触发、还是频率超限。日志的格式可以简单一点时间戳、IP、设备指纹、各项得分一行一条就够用了。我之前排查过一个非常诡异的问题明明所有校验都生效了但还是有批量的垃圾注册进来而且每个请求的UA都不一样指纹也不一样。后来看了日志才发现对方是用分布在多个地区的代理池做的批量提交每个代理IP只提交一次请求所以IP维度的频率限制完全失效了。最后是靠数据库里关联设备指纹和账号数量的逻辑再加上注册后的行为检测才把这波给拦住。所以大家在做防护的时候一定要记住没有哪个单一维度是银弹组合使用才是正道。6. 拓展思考与额外建议FckSignups这套方案做的是注册入口的防护但垃圾账号的问题不只是注册入口的问题。这里顺带分享两个可以继续扩展的方向。第一个是注册后的二次验证。现在很多做得好的产品在用户注册成功后不会立刻放行所有功能。比如需要发帖、评论、私信时再要求一次邮箱或短信验证这能让垃圾账号在注册后的操作成本大幅提升。很多垃圾注册的脚本只盯着注册接口本身它们不会往后端做更深层次的业务操作。第二个是定期清洗存量数据。不管注册防护做得多好总会有漏网之鱼。我的建议是每个季度跑一次批量检查把那些注册时间超过30天、但从未完成过任何核心操作比如发帖、完善资料、消费的账号挑出来标记为待清理。这个方法是从一个运营老手那边学来的执行起来成本不高但对社区内容的整体质量帮助非常大。需要注意在用户协议里提前写明账号清理规则避免法律风险。我个人实际跑下来的感受是反垃圾这件事很像攻防对抗永远在“道高一尺魔高一丈”的循环里。你今天封掉了单纯的接口调用明天对方就上浏览器模拟你今天上了指纹识别明天对方就换指纹。所以不必追求一步到位的完美方案更务实的做法是把基础框架搭好让攻击者知道你这里“不好惹”很多时候他们就转去欺负那些不设防的站点了。至少要保证一点让他们批量注册的成本明显高于在他们看来你的网站带来的收益。做到这一点你就已经跑赢了这个市场上90%的同类产品。