同一请求被反复发送，可能让接口不断验签、查库或执行耗时操作。处理恶意请求重放导致接口过载的缓解措施，不能只靠封禁来源地址：请求可能来自多个地址，误拦正常用户也会影响业务。更稳妥的做法是按“识别重复、限制频率、保护后端”的顺序组合防护。
先判断重放发生在哪一层
先查看访问日志和链路追踪：相同账户、请求路径、参数摘要或业务操作是否在短时间内反复出现；再确认压力集中在网关、应用处理还是数据库等依赖服务。不要仅凭相同来源地址下结论，移动网络、代理和企业出口都可能让多个正常用户共用地址。
记录请求时间、认证主体、接口、响应状态和处理耗时。涉及凭证或个人信息时，不要把完整令牌、签名密钥或敏感请求体写入日志。确认重复模式后，再选择以下措施。
五种措施分别适合什么情况
1. 时间戳、签名与一次性 nonce
适用于有签名机制的 API，尤其是请求可触发资金、配置或数据变更时。客户端对请求方法、路径、参数摘要和时间戳签名；服务端校验签名，并拒绝超出允许时间范围的请求。再为每次请求加入一次性 nonce，用带过期时间的共享存储记录已用值，重复出现即拒绝。
- 先约定签名字段、编码方式和时钟误差范围。
- 验签通过后，原子地检查并写入 nonce；已存在则拒绝。
- 按允许的重放窗口设置记录有效期，并监控时钟偏差造成的误拒。
它能识别被原样复制的有效请求，但不能阻止攻击者不断生成新请求；共享存储不可用时，也需明确是拒绝敏感操作还是采用受限降级。
2. 幂等键与业务去重
适用于创建订单、提交任务等可能因重试而重复执行的操作。客户端为一次业务意图提供幂等键，服务端将键与用户、接口和处理结果关联；相同键再次到达时返回已有结果，不重复执行。可以在数据库建立唯一约束，避免并发请求同时通过应用层检查。
幂等键不等于防重放：攻击者换一个键，仍可能制造大量新任务；而重复请求即使不重复写入，也可能持续消耗验签和查询资源。因此要设置保存期限，并避免仅凭键值跨账户复用。
3. 分层限流与并发上限
适用于需要快速控制突发流量的接口。可在 API 网关按认证账户、接口和来源地址组合限流，并设置全局并发上限。令牌桶允许短时突发，固定窗口规则实现简单但可能在窗口交界处放大流量；具体阈值应依据正常流量基线、接口成本和容量测试调整，不宜套用统一数值。
- 先为高成本写操作设置较低额度，普通查询单独配置。
- 为单账户和全局分别设限，避免分散来源绕过单一维度。
- 达到上限时返回明确的限流响应，并提供适当的重试提示；对持续超限请求记录指标。
限流见效快，但规则过紧会影响流量突增时的正常用户，且不能替代请求验真。
4. 缓存结果、隔离耗时任务
如果相同请求会重复读取昂贵数据，可缓存可复用结果，并为缓存设置合适的过期与失效规则。对于报表生成、批量导出等长任务，改为提交任务后异步处理；队列必须有长度上限、消费者并发上限和过期任务清理，满载时快速拒绝或提示稍后重试。
这能降低单次请求占用后端资源的时间，但缓存不适合结果随权限或实时数据变化的接口；异步队列若无上限，只会把过载从应用转移到队列和存储。
5. 风险规则、熔断与人工复核
适用于前四项仍无法覆盖的异常模式。结合单位时间请求数、失败比例、账户行为和接口成本提高风险等级，对高风险请求增加验证、暂缓处理或拒绝。依赖服务持续超时或错误时启用熔断，短暂停止向故障依赖发送新请求，避免请求堆积扩大故障。
规则要有观察期和回滚方案，重点检查误拦率及正常请求成功率。验证码等交互验证不适合所有机器对机器接口；熔断保护的是依赖服务，不能单独识别恶意请求。
如何组合与上线
多数场景可从“签名或身份校验＋限流＋关键操作幂等”开始；耗时任务再加有界队列，异常升高时启用风险规则和熔断。灰度发布时先记录命中情况，再逐步启用拒绝策略。比较请求量、重复率、错误率、处理耗时和队列长度，确认防护有效且未明显误伤后再扩展。
选择恶意请求重放导致接口过载的缓解措施时，优先处理最贵、最易重复执行的接口：一次性 nonce 防旧请求照搬，幂等键防业务重复，限流控总量，资源隔离保后端，风险规则补充应对。各措施职责不同，组合比单独依赖某一种更可靠。
常见问题
只用 IP 限流够不够？
通常不够。多个用户可能共用出口地址，攻击请求也可能分散来源；应结合账户、接口和全局额度。
幂等键能彻底阻止重放吗？
不能。它主要避免同一业务操作重复执行，仍需配合验签、限流或资源保护。
时间戳窗口应该设多长？
取决于客户端时钟误差、网络延迟和业务风险。窗口越短越难重放，但越容易误拒延迟请求，应通过实际运行观察调整。
五种措施必须全部部署吗？
不必。先按接口风险和资源成本选择；高风险写操作优先验真和幂等，持续突发则先限流，长任务再做队列隔离。