代码跑着跑着突然开始刷 503，日志里只有一行 Service Unavailable，看不出是自己写错了还是上游塌了。这篇不讲大道理，就给你一套排查顺序：先判断响应头是谁盖的章，再决定是等、是重试、还是改配置。看完至少能少走两轮瞎改客户端参数的弯路。
代码跑着跑着突然开始刷 503，日志里只有一行 Service Unavailable，看不出是自己写错了还是上游塌了。这时候最容易犯的错，是直接去改客户端参数、重装依赖、换 SDK，折腾一圈发现跟这些都没关系。
这篇不讲大道理，就给你一套排查顺序：先判断这个 503 是谁发出来的，再决定是等、是重试、还是换通道。看完至少能少走两轮瞎改参数的弯路。
503 不是一种病，是三层不同的故障
同样一个状态码，可能来自三个完全不同的地方：你自己的客户端（比如被本地代理拦了）、中转站的网关、上游官方接口。三层吐出来的 503，处理方式差得很远。判断是谁盖的章，看响应头最直接。
- server / via
- 带 nginx、cloudflare 字样，多半是中转站网关或 CDN 层在拒绝；带官方域名特征的，往上游那边想
- x-request-id
- 有这个字段就记下来，找中转站客服时直接给，比描述半天现象有用
- Retry-After
- 存在即说明对方明确告诉你等多久，照着等，别自己拍脑袋定间隔
判断时尽量别拿业务代码去试。写一个最小的固定请求，参数写死，用 curl 或一段十行的脚本单独跑一次，把变量降到最少。业务代码里可能有重试中间件、代理配置、超时设置，任何一个都会污染你的判断。
body 和 header 里其实写了线索
很多人看到 503 就关掉响应，只看状态码。实际用下来，不少中转网关会在 body 里塞一段 JSON，里面有错误码、维护提示、甚至哪个通道不可用。这些信息比状态码本身有用得多。
- 打印完整响应体和响应头，不要只打 status_code，先看清对方说了什么
- 看 Retry-After 有没有值，有就按它来，没有再自己定退避策略
- 同一秒内连打三次还是 503，基本可以排除偶发抖动，往通道被打满或模型池没实例的方向想
- 如果 503 出现在固定时间点，对照一下自己的并发峰值，看是不是自己把通道压满了
该等还是该换：三种情况分开处理
分清是谁在拒绝之后，动作就三选一：等、重试、换。判断标准看持续时间和影响范围，别靠感觉。
| 现象 | 大概率原因 | 建议动作 |
|---|---|---|
| 短时间集中出现，几分钟内自己恢复 | 上游抖动或瞬时过载 | 退避重试，间隔拉开，别原地狂刷 |
| 持续不恢复，换个通道请求就通 | 单个中转站或某条线路出问题 | 到站内中转站列表换一家交叉验证 |
| 只有某个模型报 503，换个模型就通 | 该模型当前没有可用后端实例 | 换模型，不要换站 |
| 所有模型、所有请求都 503 | 可能是你本地出口或鉴权层被拦 | 先拿 curl 打一个最简请求排除本地因素 |
退避重试要写对：第一次等一两秒，之后每次翻倍，设个上限，总重试次数别超过三四次。原地循环重试最糟，等于自己帮对方把通道再压一遍。重试逻辑里记得区分错误类型，503 可以退避，4xx 这类别跟着重试，只会白烧额度。
换通道验证的时候，用同一个请求体、同一个模型、同一个提示词，只换 base url 和 key。变量控制住了，结论才可信。换过去还是 503，问题多半不在中转站；换过去通了，那这家站当前就不适合继续用。
这几个地方别急着动
503 几乎不会是请求体结构、鉴权方式、base url 拼写引起的。真拼错了，返回的一般是 4xx。所以别在这几处反复改，改一次引入一个新变量的风险，比问题本身还大。
- base url 和鉴权头先别动，确认它们原本是通的，就别碰
- 重试次数别为了绕开 503 调到很大，容易把自己变成压垮通道的那一方
- 超时时间可以适当放宽，但别设成无限等，每次失败的耗时都记下来方便复盘
- 别在故障期间顺手升级 SDK 或换依赖版本，两个问题会混在一起，排查更难
还有一种常见误判：看到 503 就以为是模型版本下线了。其实版本下线一般有明确的错误信息，不会只有一句 Service Unavailable。把响应体打全，先读完再下结论。
恢复之后补两件事
服务恢复不等于事情结束。这次故障的时间点、涉及的模型、错误类型、响应头里的关键字段，都该补进日志结构里。下次同类问题出现，直接对表，几分钟就能定位，不用再从零查一遍。
另一件事是判断这家站还值不值得长期用。到站内的中转站检测页面看它的在线状态和历史检测结论，结合这次故障的表现，决定是继续观察还是准备备用通道。备用通道平时不用，但配置要先写好，别等出事现搭。
下一步想知道你正在用的中转站当前状态和可信度结论，去站内检测页对一下，比凭感觉换站靠谱。→常见问题
503 和 502、504 有什么区别，处理方式一样吗？
不一样。502 是网关拿到上游的坏响应，504 是等上游超时。503 是服务方主动说现在接不了活。502 和 504 优先查网络和超时配置，503 优先看对方是不是在维护或通道打满。三类都先看响应头判断是谁发的。
我加了很多次重试还是 503，是不是代码有问题？
大概率不是代码。重试次数多只会在对方没恢复时制造更多失败请求。先确认是不是所有模型都失败；只有一个模型失败就换模型，全都失败就去站内中转站列表交叉验证，看是不是这个站整体不可用。
中转站返回 503，是不是说明这个站不靠谱？
不能一概而论。偶发 503 在高峰期很常见，关键看恢复速度和是否集中在某个模型。持续几个小时不恢复、或者反复出现在同一通道上，才值得考虑换站。可以去站内的中转站列表和检测页面对照一下当前状态。
