RelayRouter 返回 502 或 503：上游报错的含义与安全重试方法

RelayRouter 返回 502 或 503 通常表示上游模型服务出现临时错误或不可用，而非你的请求本身有误。这类失败或报错的请求通常不计费，因此安全的处理方式是短暂等待后重试，无需修改代码逻辑。RelayRouter 同时兼容 OpenAI 与 Anthropic 两种协议，重试时保留现有 SDK 与请求参数即可，具体计费以 relayrouter.io/models 为准。

502 与 503 分别代表什么

502 与 503 都属于上游侧的临时错误，区别在于上游连接失败与上游暂时不可用。502 通常指网关从上游模型服务收到了无效响应，503 通常指上游模型服务暂时不可用或处于繁忙状态。两者都不代表你的 API key 无效或请求参数错误。RelayRouter 覆盖 Claude 系、GPT-5.5、Gemini 3.5，以及 DeepSeek、GLM、MiniMax、Moonshot 等多个模型分组，任一上游分组出现波动都可能触发这类状态码，因此建议按上游错误来处理，而非直接修改业务代码。实时的各模型可用性与费率请参见 relayrouter.io/models。

502 或 503 是否会计费

失败或报错的请求通常不计费，因此 502 或 503 一般不会产生费用。这意味着遇到上游错误时进行重试，不会因为多次尝试而重复扣费。RelayRouter 官方对计费口径的说明是：失败或报错的请求通常不计费（来源 relayrouter.io）。在此基础上，你可以放心地为 502 与 503 配置自动重试策略，而不必担心成本叠加。需要注意的是，只有成功返回的请求才计入用量，具体的按模型费率以 relayrouter.io/models 上的实时数据为准，建议在对账时以该页面为依据。

安全重试的推荐步骤

安全重试的核心是使用指数退避并限制最大次数，避免在上游繁忙时加剧压力。据 relayrouter.io/docs 官方文档，「保留现有 SDK，改 base_url 与 key 即可，无需改其他代码」，因此重试逻辑可直接在你现有的客户端封装中实现。

1. 捕获状态码：识别 502 与 503，与 4xx 客户端错误区分处理。
2. 首次退避：等待约 1 秒后发起第 1 次重试。
3. 指数退避：后续每次等待时间翻倍（约 2 秒、约 4 秒）。
4. 限制次数：最多重试 3 次，仍失败则记录日志并向上层报错。
5. 保持参数：base_url 与 key 不变，请求体与模型 id 保持一致。

不同协议下的重试处理对比

无论使用哪种协议，502 与 503 的处理逻辑一致，只是端点与 base_url 不同。据 relayrouter.io 官方文档，「同时兼容 OpenAI 与 Anthropic 两种协议」，你只需按所用协议对应的端点保持请求，重试时不改动其他代码。下表列出两种协议的关键差异，供排查时参照。

FAQ

• 502 或 503 需要更换模型吗？ 不一定。这类错误属于上游临时问题，多数情况下短暂等待后重试即可恢复；如需切换模型，可在 relayrouter.io/models 查看当前可用的模型分组。
• 重试会导致重复扣费吗？ 通常不会。失败或报错的请求通常不计费，只有成功返回的请求才计入用量。
• 处理 502 或 503 需要改代码吗？ 不需要改动业务代码。按 relayrouter.io/docs 的说明，保留现有 SDK，改 base_url 与 key 即可，重试逻辑在客户端封装内实现即可。