表单防刷与接口限流：咨询线索被刷时怎么处理

咨询线索被刷，问题往往不只在表单

运营同事早上打开后台，发现一夜之间多了几百条手机号格式相似、内容雷同的留言，销售跟进成本被拉高。这类情况通常不是单一漏洞，而是前端校验、接口限流、业务风控三层都缺少拦截。对于做网站建设和微信小程序的企业来说，把防刷做成默认能力，比事后人工清理更划算。

先判断：是恶意刷量还是正常波动

先看数据再动手，避免误伤真实客户。

• 时间分布：集中在凌晨、几秒内连续提交，通常不是人工行为。

• 来源特征：同一 IP 段、同一 UA、同一设备指纹占比异常。

• 内容特征：手机号规则化、留言内容高度重复或含推广链接。

• 转化特征：提交量大但电话接通率低、无后续互动。

把日志留全（IP、UA、时间戳、来源页、表单 token），是后续封禁与追溯的基础。

三层防护：前端、接口、业务

1. 前端轻量拦截

• 人机验证：滑块、点选或行为验证码，按风险动态触发，不必每次提交都弹出。

• 一次性 token：页面加载时下发签名 token，提交时校验，提高脚本直接调用接口的难度。

• 蜜罐字段：隐藏输入框被填写即判定为机器提交。

• 提交耗时判断：过短（如小于 2 秒）或过长（页面闲置数小时）都标记为可疑。

前端手段的作用是提高刷量成本，不适合作为唯一防线。

2. 接口层限流

接口限流是核心，建议按维度组合使用：

1. IP 维度：如单 IP 每分钟 5 次、每小时 20 次，Nginx 可用 limit_req 做第一道拦截。

2. 设备与指纹维度：结合 UA、Canvas 指纹或小程序 openid，减少换 IP 绕过的情况。

3. 手机号维度：同一号码短时间内重复提交直接拒绝。

4. 全局维度：给接口设总阈值，异常时保护数据库与短信通道。

算法上，令牌桶适合允许突发的场景，漏桶适合平稳输出，滑动窗口统计更精确但需要 Redis 支撑。常见做法是用 Redis + Lua 脚本实现原子计数，超限返回 HTTP 429 并带上 Retry-After。

3. 业务风控与线索清洗

• 手机号短信验证，验证通过才写入正式线索库。

• 黑名单与灰名单：异常 IP、号码段、设备指纹进入观察名单。

• 内容相似度与敏感词过滤，识别批量群发文案。

• 风控评分：多因子加权，达到阈值进入待审核队列，而非直接推送给销售。

被刷之后怎么应急处理

1. 止血：临时收紧限流阈值、开启强验证，必要时暂停表单接口。

2. 隔离：把可疑线索打标移入独立表，不混入正常销售池。

3. 去重：按手机号、内容指纹、提交时间做批量去重与合并。

4. 通知：告知销售团队线索延迟原因，避免误判渠道效果。

5. 复盘：定位入口是网页表单、H5 还是小程序，补齐对应防护。

网站建设与微信小程序中的典型落点

网站侧

PHP 或其它后端可在中间件统一做限流与签名校验，Nginx 负责粗粒度拦截，CDN 与 WAF 处理明显异常流量。表单页建议加 CSRF token、验证码与蜜罐字段，接口返回统一错误结构，便于前端给出友好提示。

小程序侧

小程序不能完全依赖前端逻辑，服务端要用 wx.login 拿到的 code 换取 openid 并校验，同时保证 code 一次性使用以降低重放风险；云函数或自建服务同样要做单 openid 频率限制。结合订阅消息的授权状态，也能辅助判断请求真实性。

可落地的检查清单

• 表单是否有人机验证或行为校验

• 接口是否按 IP、设备、手机号维度限流

• 是否记录完整请求日志并设置告警

• 线索入库前是否经过验证与去重

• 是否有可疑线索隔离与人工复核流程

• 限流阈值是否随业务活动动态调整

防刷不是一次性开发任务，而是需要随流量变化持续调参的能力。在做网站建设、微信小程序或 API 接口开发时，把限流、验证、日志和告警一起设计，能明显降低后续的运营清理成本。尊云科技在网站、小程序与二次开发项目中，通常会把这几项作为默认可选能力，便于后续按业务节奏调整阈值。