登录高峰或促销开场时，请求量上升不一定意味着机器人攻击：真实用户也可能集中刷新、重试登录或提交订单。有效的Web应用层机器人流量识别和限速方法，不是单纯封禁访问最多的IP，而是结合请求行为、账号状态和业务路径分层处理。以下五种做法可按风险逐步启用。
1. 从请求行为识别自动化模式
观察请求间隔、访问顺序和操作结果，比只看单次访问速度更有用。例如，用户可能先打开登录页，再提交凭据；自动化程序则可能在短时间内重复提交、跳过页面流程，或对大量账号执行相似操作。可用行为分析汇总短时间窗口内的失败次数、页面切换和重复请求。
- 按登录、搜索、领券、结算等路径分别记录请求时间、状态码和会话标识。
- 比较正常时段与活动时段的基线，找出失败请求集中、间隔高度规律或路径异常的群体。
- 先对可疑请求增加验证或降低频率，再观察误拦和业务完成情况，避免仅凭一个特征封禁。
优点是能发现轮换IP的自动化行为；缺点是需要积累基线，活动期间的正常用户行为变化也可能触发告警。
2. 在高风险操作前加入人机验证
人机验证适合放在登录失败次数异常、批量注册或领取权益等敏感步骤，而非一进入网站就要求所有人验证。可选择交互式验证码，也可使用风险评估型验证服务；前者拦截直观，但增加操作负担，后者体验通常更顺畅，却需要结合自身隐私、集成和服务可用性要求评估。
- 选定触发条件，例如单个账号在短窗口内连续登录失败，或同一会话重复请求敏感操作。
- 验证通过后再放行当前操作；未通过时提示重试或暂缓请求，不泄露账号是否存在。
- 记录验证触发率和后续成功率，定期调整条件，避免弱网、辅助技术用户被不必要地拦截。
人机验证应与速率限制配合：验证可以提高自动化成本，但不能替代后端对请求频率的控制。
3. 按账号、会话和操作分别限速
只按IP限速容易误伤共享网络中的真实用户，也挡不住分散来源的请求。更稳妥的做法是对账号、会话、来源地址和具体操作分别设置限制，并对登录、发验证码、提交订单等高成本接口采用不同规则。
- 先区分读取页面与写入操作，优先保护会消耗短信、库存或计算资源的接口。
- 以观测到的正常峰值为依据设初始阈值。例如，可先评估同一账号在约5至10分钟内连续失败5次左右后要求额外验证；具体数值须按登录方式、用户群和误拦情况调整。
- 超过阈值时依次采用延迟响应、要求验证、短时限制等措施，并提供明确的恢复路径。
限速窗口和阈值没有通用答案：阈值过低会影响真实用户，过高则可能无法及时减轻压力。活动开始前应在实际业务环境中验证规则。
4. 组合请求特征，避免依赖单一指纹
请求头、会话变化、访问路径和设备特征可以辅助判断自动化流量，但单个特征都可能被正常用户或机器人共享、改变。设备指纹还涉及隐私与合规要求，应遵循适用规则，减少不必要的数据收集，并设定保存期限。
实施时可将特征用于风险分级，而非直接作为封禁依据：多个信号同时异常时提高风险级别；特征不完整或可信度较低时，改用人机验证或较温和的限速。Cloudflare Turnstile、Google reCAPTCHA 等是可评估的人机验证产品；接入前应核对各自当前的功能、数据处理方式和适用条件，不假定产品配置能代替应用侧规则。
5. 设置渐进处置与活动期监控
识别规则上线后，处置力度应与风险相匹配。可先记录并观察，再对高风险请求加验证；确认影响和效果后，才对持续异常的会话或账号实施短时限制。相比直接封禁，渐进处置更容易发现规则误判，也便于在促销期间快速回退。
- 活动前确认登录、结算和权益接口的负责人、告警渠道及规则回退方式。
- 活动中查看请求量、失败率、验证触发量和业务完成情况，按接口拆分，避免总流量掩盖局部异常。
- 每次调整记录触发条件、影响范围与观察结果；若正常操作受阻，先收窄规则，再分析原因。
将Web应用层机器人流量识别和限速方法组合使用，重点是按业务风险分层，而不是追求拦截所有自动化请求。先监测、再验证、后限速，并持续核对对真实用户的影响，通常比一次性启用严格封禁更稳妥。
常见问题
高峰期请求突然增加，能直接判定为机器人吗？
不能。应结合失败率、请求路径、账号分布和操作结果判断，并与以往业务基线比较。
只按IP限速可以吗？
不建议作为唯一规则。共享网络可能让多个真实用户共用出口地址，分布式自动化请求也可能来自多个地址。
人机验证应该放在哪些位置？
优先放在登录失败异常、批量注册或权益领取等高风险操作前，并为无法顺利完成验证的用户提供合理的重试方式。
多久调整一次限速阈值？
活动前后都应检查；若用户结构、登录流程或接口成本变化，也应重新评估。阈值以实际监测和误拦情况为准。