促销开始后，请求量变大很常见；真正需要警惕的，是请求是否偏离正常业务路径。做好API接口恶意请求识别与防护，不能只看总量或单个 IP，而要把流量变化与用户操作、接口用途和响应结果一起判断。
先看流量是否符合业务过程
正常访问通常跟随可解释的流程：用户打开页面、查询商品或内容、提交订单，相关接口的调用顺序和数量会同步变化。恶意探测则可能出现大量路径尝试、异常参数组合，或绕开页面流程直接请求后台接口。不过，自动化客户端和网络出口共享也会让正常流量看起来集中，单一指标不能直接定性。
先比较促销前后的同类时段，并按接口分组看请求量，而不是只看全站总数。检查访问日志中的时间、路径、方法、状态码、来源地址及可用的会话标识。若某个查询接口随活动流量平稳上升，且成功响应与页面访问同步，通常更像业务增长；若大量请求分散尝试不存在的路径，且返回 404 或 405，则应提高关注级别。
用行为组合判断，而非单点封禁
| 观察信号 | 更可能的解释 | 建议核实 |
|---|---|---|
| 热门接口请求增加，参数和调用顺序稳定 | 可能是正常活动流量 | 与页面访问、成功率及业务操作趋势对照 |
| 短时间遍历大量路径，频繁出现 404、405 | 可能在枚举接口或探测服务 | 核对路径分布、请求方法和来源变化 |
| 同一接口出现异常字段、超长值或类型不符 | 可能在测试输入边界 | 检查参数校验记录及应用错误 |
| 请求量升高，同时 429、5xx 明显增加 | 可能有过载，也可能是容量不足 | 对照服务延迟、资源使用和限流日志 |
例如，促销页的商品查询量上涨，但调用集中在已公开的查询接口、字段格式正常，不能仅因请求密集就封锁。相反，反复尝试诸如 Spring Boot 应用可能使用的 /actuator 路径，或对不同接口轮番使用不匹配的方法，值得检查；但该路径是否存在取决于具体部署，单次访问并不能证明恶意。
按顺序处置，先减风险再定性
- 建立对照。选取促销前相近时段，比较各接口请求量、成功率、延迟和状态码；注意活动投放、缓存命中等会改变基线。
- 筛出异常群组。按路径、方法、参数特征和来源聚合。观察是否出现路径枚举、重复失败或不合业务逻辑的调用顺序，不要仅凭单个 IP 判断。
- 先做低影响防护。在API网关或边缘层对明确异常的请求设置速率限制、临时挑战或拒绝，并保留日志。限制阈值应结合接口用途和实测峰值调整；读接口与提交类接口不宜套用同一标准。
- 修正接口本身。采用参数校验、权限检查和合理的响应控制；确认调试、管理类接口没有意外暴露。对误拦用户的规则及时回退或缩小范围。
- 持续复核。观察限制后正常成功率、错误率和服务延迟是否改善，并确认异常请求是否转移到其他路径。将已验证的规则纳入后续活动预案。
常见问题
请求量突然翻倍，就代表恶意探测吗？
不代表。应结合业务活动、接口分布、参数与响应结果判断；总量只能作为告警信号。
多个请求来自同一个 IP，是否应该封禁？
先看请求内容和节奏。代理、企业网络或运营商出口可能让多人共用地址，优先按接口行为和会话特征细分。
遇到大量 404，要马上封锁吗？
先确认是否为路径枚举、部署变更或客户端旧版本造成。若伴随连续探测和异常请求模式，再采取针对性限制。
怎样避免把正常促销流量误判？
保留活动基线，分接口设规则，并在启用强拦截前观察告警或限速效果。最终的API接口恶意请求识别与防护应依据多项证据持续校准，而不是依赖一个阈值。
