通过代理调用API时，客户端等到超时，看起来像“请求没成功”，但服务端可能已经收到了请求并完成处理，只是响应在返回途中丢失。此时直接重试创建订单、付款或发放权益，可能产生重复业务。
代理故障处理不能只看网络层，还要让业务接口具备可确认、可去重和可恢复的语义。
一、超时不等于服务端没执行
| 失败阶段 | 服务端可能收到吗 | 处理思路 |
|---|---|---|
| DNS失败 | 通常没有 | 修复解析后有限重试 |
| TCP连接未建立 | 通常没有应用请求 | 确认目标与代理后有限重试 |
| 发送过程中断 | 可能收到部分或完整请求 | 按业务幂等设计判断 |
| 读取响应超时 | 很可能已经处理 | 先查询状态，不盲目重发 |
| 502/504 | 取决于网关与上游阶段 | 结合请求ID和服务端日志确认 |
二、哪些HTTP方法天然安全重试
HTTP规范中的安全与幂等语义提供方向，但业务实现仍需验证。GET、HEAD通常不应改变服务端状态；PUT、DELETE在语义上通常幂等，但重复调用仍可能产生审计、通知等副作用；POST默认不能认为幂等。
不要仅凭方法名称决定重试。读取接口也可能被错误设计成产生副作用，写接口则需要明确的去重机制。
三、幂等键怎样工作
客户端为一次业务意图生成唯一键，例如订单创建请求的业务UUID。首次请求时服务端保存该键、请求摘要和结果；后续收到相同键时：
- 请求内容相同：返回第一次的结果或当前状态；
- 请求内容不同：拒绝并提示幂等键冲突；
- 第一次仍处理中：返回处理中状态或等待策略；
- 键已过期：按接口契约处理，不能由客户端猜测。
只有服务端明确实现并说明幂等键，客户端随便加一个Header才有作用。
四、幂等键和请求ID不是一回事
请求ID主要用于日志追踪，每次重试可以有新的尝试ID；幂等键代表同一次业务意图，重试时保持不变。建议同时记录：
- 业务幂等键；
- 每次网络尝试的请求ID；
- 代理节点ID和连接阶段；
- 服务端业务对象ID；
- 重试次数与最终状态。
这些标识不应包含用户身份证号、手机号或其他个人信息。
五、代理502和504能否自动重试
需要判断接口是否幂等、响应来自哪一层，以及服务端是否可能已处理。对读取请求，可在合理范围内退避重试；对非幂等写请求，应先通过幂等键或状态查询确认。
错误码来源定位可参考代理407、502、503、504排查。
六、重试策略至少包含哪些参数
- 可重试错误清单；
- 连接、读取和总超时；
- 最大尝试次数；
- 指数退避与随机抖动；
- 单次业务的总截止时间；
- 熔断和人工介入条件；
- Retry-After等服务端提示。
无限重试会放大故障，也可能重复占用代理连接和服务容量。
七、切换代理节点时幂等键要变吗
如果仍是同一个业务意图，幂等键不应因网络节点变化而改变。新的代理连接只代表传输尝试不同，不代表要创建第二个订单。
但切换节点前应确认目标API允许备用出口，白名单已配置，且错误不是限流或权限拒绝。不能通过换IP绕过目标控制。
八、读取超时后的安全恢复流程
- 保留幂等键和原请求摘要；
- 调用官方状态查询接口或按业务对象查询；
- 若结果已存在，直接使用第一次结果；
- 若明确未创建，按原幂等键有限重试；
- 状态未知且业务高风险时，进入人工对账；
- 记录最终决定和服务端证据。
没有状态查询接口的高价值写操作，应在上线前补齐确认机制。
九、消息队列和异步任务也会重复
API返回成功只可能表示任务已入队，真正处理在后台。消费者通常要按“至少一次投递可能重复”的假设设计，使用业务唯一键、去重表或状态机。代理重试只是重复来源之一。
十、测试时如何模拟不确定状态
- 请求发出后主动丢弃响应；
- 让服务端处理成功但客户端读取超时；
- 代理在上传完成后返回502；
- 同一幂等键并发提交；
- 相同键携带不同请求内容；
- 服务端处理时间超过客户端超时。
验证系统是否只创建一个业务对象、是否返回一致结果、日志是否能关联全部尝试。
十一、凭据和日志安全
不要为了对账记录完整Authorization、Cookie、代理密码或支付数据。保存请求摘要、脱敏业务ID和必要字段哈希，并限制日志访问和保留期限。
十二、结论
网络层只能告诉你“没有拿到确定响应”，不能证明业务没有执行。代理请求的安全恢复依赖服务端幂等、状态查询、请求追踪和人工对账。只有这些能力齐全，有限重试和节点故障转移才不会把一次网络波动变成重复订单。
