攻击期间上线限流或人机验证后，拦截数量可能迅速上升，但正常登录、支付或 API 调用也可能同时失败。此时继续叠加规则常常让问题更难解释。第一步应判断业务错误率是否因规则变更而恶化。
先冻结变更并确认时间线
- 最后一条防护规则何时生效。
- 业务错误率从何时开始上升。
- 攻击流量是否同时变化。
- 源站和应用是否出现新的资源瓶颈。
如果错误率在规则上线后同步跳升，应在已知安全范围内撤回最后一批变更。回退的目标是恢复业务，不是关闭全部防护。
按正常用户样本对比
分别观察登录页、静态资源、搜索、支付和 API。比较规则上线前后同一业务的成功率、挑战通过率、403 数量和响应时间。只有拦截数上升、没有业务成功率的对照，不能证明策略有效。
常见误伤来源
| 来源 | 表现 | 检查 |
|---|---|---|
| 共享出口 IP | 某个运营商或办公网大量失败 | 地区、ASN、设备和会话差异 |
| 挑战脚本不兼容 | 页面加载但一直验证失败 | 浏览器、移动 WebView 和第三方客户端 |
| 路径规则过宽 | 正常 API 与攻击请求一起阻断 | 方法、路径、参数和返回结构 |
| Cookie/会话缺失 | 登录后接口仍被挑战 | 域名、SameSite、代理和 Cookie 传递 |
| 限速阈值过低 | 短时间正常突发也触发 | 峰值分布，而不是平均 QPS |
设置可逆的规则发布
规则应带版本、负责人、观察窗口和回滚条件。先以观察模式记录命中，再对小范围路径生效。每次只修改一组条件，避免同时改 IP 频率、会话、UA 和路径。
业务验证优先于拦截数
恢复后检查正常登录、支付回调、搜索和关键 API。只有这些路径恢复且攻击压力下降，才算完成处置。保留下线规则、回退时间和业务指标，用于事故复盘。
回退条件示例：核心登录成功率连续下降、支付错误率超过约定阈值，或正常地区错误分布明显扩大。具体阈值应由业务和防护负责人根据基线确认。
延伸阅读：限流为什么误伤登录 · 攻击日志字段清单 · 事故时间线模板生成器。