网站注册被机器人刷了怎么办？5 个止损办法和滑动验证码接入指南
注册、短信、登录接口被脚本批量刷，最直接有效的办法是在入口加一道人机验证。本文给出 5 个止损办法，以及滑动验证码前端 + 服务端的完整接入步骤。
最快的止损办法是在注册、登录、发短信这几个入口加一道人机验证：真人滑一下就过，脚本被挡在外面。再配合按 IP / 手机号限频和服务端二次校验，绝大多数批量注册、短信轰炸和撞库都能拦住。下面分别说清楚怎么做。
先判断：是不是真的被机器刷了
出现下面任意两条，基本可以确定：
- 短信费用突然暴涨，但新增用户没有对应增长；
- 新注册账号的手机号或邮箱集中在某个号段、某个域名，昵称是规律字符串；
- 注册请求在凌晨集中出现，间隔整齐，几乎没有页面浏览；
- 同一个 IP 或同一批 IP 在短时间内发起大量注册 / 登录请求。
其中短信接口被刷最常见也最烧钱：攻击者拿你的「获取验证码」接口去轰炸别人的手机，每条短信的钱都是你付。
5 个止损办法（按见效速度排序）
1. 关键入口加人机验证
在「获取短信验证码」「注册」「登录」按钮前加滑动验证，是见效最快的一步。脚本要通过验证，必须模拟真人的拖动轨迹，成本立刻上一个台阶。
2. 按 IP、手机号、设备限频
同一手机号 60 秒内只能发 1 条、一天不超过 5 条；同一 IP 每分钟注册请求超过阈值直接拒绝。限频是兜底，不能单独依赖：攻击者换代理 IP 的成本很低。
3. 服务端二次校验，别只信前端
前端弹了验证码，但服务端接口没校验验证结果，等于没加——脚本会绕过页面直接调接口。所有敏感接口都必须在服务端校验验证凭证，这是最常见的接入漏洞。
4. 清理已经混进来的垃圾账号
按注册时间、号段、行为特征（注册后零活跃）批量筛出来封禁，避免它们后续被用来薅羊毛或发垃圾内容。
5. 开监控，异常早发现
给短信发送量、注册量设阈值告警，比月底看账单才发现要好得多。
为什么推荐滑动验证码，而不是字符验证码
传统字符验证码要用户辨认扭曲的文字，体验差，而且现在的 OCR 和多模态模型识别率很高，基本挡不住机器。
行为式验证码换了个思路：不考用户眼力，而是分析拖动滑块时的轨迹、速度、停顿等行为特征来判断是不是真人。真人一两秒就能通过，脚本却很难伪造自然的操作轨迹。
接入滑动验证码：3 步完成
以 不墨DEV 行为式验证码 为例，整个接入通常几分钟就能完成：
第一步：开通服务，拿到产品 ID。 登录不墨DEV，在验证码产品页开通免费试用，控制台会给出产品 ID。
第二步：前端接入。 按文档在网页或移动端 H5 引入验证码组件，配置产品 ID，在用户点击「获取验证码」「注册」时先唤起滑动验证，验证通过后拿到一个凭证。
第三步：服务端校验。 前端把凭证随业务请求一起提交，你的服务端调用校验接口确认凭证有效，校验通过才执行发短信、注册、登录等业务逻辑。
完整代码示例见 接入文档，也可以先在 在线 DEMO 里体验效果。
常见问题
加了验证码会不会影响转化？ 滑动验证一两秒完成，比输入字符验证码轻得多。建议只在高风险动作（发短信、注册、登录失败多次后）触发，而不是每个页面都弹。
小网站有必要吗？ 有。攻击者扫接口不看网站大小，短信接口一旦暴露，一晚上就能刷掉几千条短信费。
费用怎么算？ 不墨DEV 验证码提供免费试用额度，测试满意后按需购买，控制台可以实时查看当月用量。
总结
被机器刷注册，先在入口加滑动验证 + 服务端校验，再补限频和监控。其中「服务端必须校验」最容易被漏掉，务必检查。
免费试用不墨DEV 行为式验证码，几分钟接入，先止住损失。
