本地代码没改，昨天还跑通的请求今天成片返回 503，日志里只有一行 Service Unavailable。这篇不解释概念，直接给一条从「先确认是不是自己」到「要不要联系站方/换源」的排查顺序，顺带说明哪些 503 其实不该重试，避免你把重试次数打满反而更糟。
本地代码一行没改，昨天还跑通的请求今天成片返回 503，日志里只有一行 Service Unavailable。遇到这种情况先别急着翻代码，503 的语义是「对方这一刻接不了活」，不是「你请求传错了」，所以排查方向要整个换掉：从「我哪里写错了」转到「链路上哪一层在拒绝」。
下面给一条从「先确认是不是自己」到「要不要联系站方、要不要换源」的排查顺序，顺带说清哪些 503 其实不该重试。重试次数打满反而更糟，尤其你后面还排着队等结果的场景。
先搞清 503 是谁返回的
503 和 4xx 要分开看。4xx 是你传错了参数或鉴权掉了，改代码能解决；503 是请求本身没毛病、对方暂时接不了。所以排查重点不在请求体，而在链路上哪一段在拒绝你。分清来源，处置方式差得很远。
| 来源 | 典型表现 | 处置方向 |
|---|---|---|
| 上游模型厂商限流或过载 | 只有某个模型报 503，别的模型正常 | 换模型或等窗口，别改代码 |
| 中转站网关或调度层故障 | 多模型同时 503，可能整站不通 | 看站方状态，考虑换源 |
| 你到中转站之间这一跳 | 换网络或换机器就好了，报错常是 HTML 页 | 查 DNS、代理、区域网络 |
一个便宜又有效的判据：用同一个 Key 发一个最简单的最小请求，还报 503，基本不是你请求体的问题；如果只有某个模型报 503、其他模型正常，多半指向该模型通道或上游。这一步花不了两分钟，但能砍掉一大半无效排查。
按顺序排查：从最便宜的检查做起
- 先读响应头和响应体网关层的 503 往往带 Retry-After 或站方自定义错误码，先读它再决定等多久；返回纯 HTML 的 503 页通常意味着打到了代理或 CDN，而不是 API 本身
- 横向对比三组变量同一 Key 打另一个模型、同一端点换网络环境、同一请求换一台机器，三者交叉就能判断问题出在「Key/账号」「模型通道」还是「本地网络」哪一环
- 看时间分布用一小段脚本连续打若干次，统计失败率，区分偶发零星和持续性全挂；肉眼盯单次报错容易被误导
- 再决定动作偶发且有 Retry-After 就退避重试；持续全挂先换源或换站，别在已经死掉的通道上耗时间；需要延迟基线时到 /tools/speed-test 先量一下作对照
顺序有讲究：越便宜的检查越靠前。读响应头几乎零成本，换网络要动手，换源成本最高。很多人一上来就换站，结果发现只是自己代理挂了，白折腾一圈。
503 的重试该怎么做、什么情况不该重试
只对 503/502/504 这类服务端暂时性错误重试，4xx 重试是纯浪费。重试必须带指数退避加随机抖动，固定间隔重试在拥塞时只会火上浇油——对方已经过载，你还按秒表敲，只会让情况更糟。
- 给重试设双重上限：次数上限加总时长上限，超过就抛错交给上层
- 流式请求注意：已吐了一半的响应不要重发整个请求，否则可能重复计费
- 查询类请求放心重试；有副作用的写操作（下单、扣费、写库）先确认下游是否已执行，可参考 /guides/agent-api-idempotency
- 明确过载且 Retry-After 给得很长时不该硬等，应降级到备用模型或直接告诉用户稍后再试
最后一条最容易被忽略：重试规则在「上游明确过载、给了很长的等待时间」时不适用。这时候正确做法是降级或换路，而不是把重试次数耗光。你得先判断这是不是你该等的那种 503。
判断是站方问题，然后怎么有效地报
什么证据能说明是站方问题：多个模型同时 503、健康检查端点也不通、站内监控页显示异常。先到 /ai-status 对一下当前状态，比自己在本地猜快得多。确认是站方问题，就别再改自己的代码了。
报障要给可复现的最小信息：时间点、请求端点与模型名、响应头原文、失败率。只说「你们接口挂了」等于没说，对方还得回来问你一堆问题，白白多耗一轮。
长期策略是做多源冗余：主备两个通道，按失败率自动切换。这类降级的落地做法在 /guides/multi-model-routing-fallback 里；如果只靠一家，503 就是你的可用性上限。挑备选站时可以到 /sites 看各家中转的实测情况。
下一步：把可用性做厚一点这次排查完，顺手给主通道配一个备用源，并用失败率决定切换，别等下一次 503 再临时找。到 /sites 看当前各家状态，再按 /guides/multi-model-routing-fallback 的做法配降级。→常见问题
503 和 502、504 到底差在哪，处理方式一样吗？
三者都属网关侧问题，但含义不同：503 是服务方主动表示暂时接不了（常带 Retry-After），502 是网关从上游拿到无效响应，504 是等上游超时。处置上都可以退避重试，但 504 更该先怀疑自己的超时设太短，503 更该先看对方是否在维护。
加了重试还是 503，是不是站方在坑我？
不一定。先确认重试是否带退避、是否超了并发上限——高频硬重试可能被当成攻击进一步限流。再对照站内状态页与测速页，如果同一时间多个模型全挂、延迟也异常，才更像站方通道问题。
生产环境要不要因为 503 就换中转站？
偶发零星 503 换站成本大于收益，靠退避重试就能消化；如果失败率持续偏高、恢复时间不可预期，且你已经影响业务，才值得换。换之前先按 /guides/relay-switch-api-verification 验证新站通不通，别从一个坑跳进另一个。
