任务跑到一半，屏幕上跳出 503 Service Unavailable——AI 编程里让人最快泄气又最快恢复的报错：泄气，是因为它看起来严重；恢复，是因为它多半不归你管。503 属于服务端状态码，意思是服务此刻不可用：过载、维护、临时降级，都是服务侧的决定，本地改配置基本无解。排障的重点因此不在修，而在判断：是官方的事故、第三方的锅，还是被误读成本地故障的别的毛病。这篇按排障文的惯例给排查顺序，划清等与修的边界；包装成 exceeded retry limit 的情形另见retry limit 分流一篇。
503 的身世：服务端主动降级
先认清这个码的出身。HTTP 状态码里 5xx 段归服务端：请求没错，是服务自己出了状况；503 特指服务暂时不可用——常见原因是过载保护，流量超出承载，服务主动拒掉一部分请求保住整体；也可能是发布、维护或依赖组件故障。与 4xx 段的根本差别在于：429、401 指向你的用量与凭据，你动手有意义；503 指向服务本身，你这边没有任何配置能改变它的判定。理解这一点，排障目标就变了：从修好它，变成确认它是谁的 503——官方的、第三方的，还是名字像 503 实为本地问题的别的故障。目标定对了，后面每一步才不会白走。
排查顺序：先看状态页
按顺序走：
- 第一步，开官方状态页（status.openai.com）看有没有事故公告：有事故且涉及相关服务，就是官方侧的问题，等恢复公告，别做任何本地改动。
- 第二步，状态页正常、走第三方后端或中转的，去查对方的公告与用量面板：503 可能是对方的池子降级，与官方无关。
- 第三步，单次偶发的 503，等几分钟重试即可，过载窗口通常很快过去。
- 第四步，反复出现且两边状态都正常，验证本地因素：换网络或热点再试一次——代理与防火墙把响应掐断时，客户端可能把连接失败误读成服务不可用，本地清单见本地网络排查一篇。
- 第五步，本地因素排除后仍复现，升级 CLI 再试并留存完整报错；跨版本行为差异以官方更新日志为准。
容易认错的两位邻居
503 有两个常被混淆的邻居，分流清楚能少走弯路。一是流式断连：长回答生成到一半连接被掐，报 stream disconnected before completion——那可能是链路问题而非服务降级，排查方向是代理、超时与网络，见流断连一篇；流式输出的机制见流式输出一篇，明白边生成边传输的链路，就知道断点可能落在哪一段。二是 429：限流是「你超了，别来了」，503 是「服务病了，谁都别来」——前者查用量与频率，后者查状态页，判断口诀就这一句，误报分流见429 误报一篇。两个邻居的共同点是都会被重试层再包一层，剥开看原始状态码再定方向。
| 报错 | 指向谁 | 处理方向 |
|---|---|---|
| 503 Service Unavailable | 服务本身：过载保护、发布维护或依赖组件故障 | 看官方状态页与第三方公告，等恢复，本地改动无解 |
| 429 | 你的用量与频率：你超了，别来了 | 查 /usage 余量与请求频率 |
| stream disconnected | 链路：长回答生成到一半连接被掐 | 查代理、超时与网络，不是服务降级 |
等还是修：一句话决策与事故期纪律
决策可以压成一句话：状态页有事就等，状态页没事且只有你坏就查本地，大家都有事就等公告。事故期还有一条纪律：克制重试。服务过载时，所有用户的重试流量叠在一起，等于给挤兑的柜台再添人手，拖长所有人的恢复时间；连环手点除了缓解情绪，对恢复毫无帮助。正确做法是拉开间隔等，或切到手头不依赖服务的别的任务，过载窗口过去再回来。等恢复后有个小动作值得做：把刚才中断的任务重跑一遍并核对结果——事故期的部分写入可能只完成了一半，重放一遍才踏实。想让这套判断练熟，可以让 DeepSeek 把 503 与它两位邻居的差异整理成对照卡，再用豆包模拟三种报错场景，对着排查顺序口头各走一遍。
503 速查
- 503 是服务端主动降级：过载、维护或故障，本地配置改不动它
- 排查第一步永远是官方状态页，其次查第三方后端公告
- 单次偶发等几分钟，反复出现再验本地网络因素
- 与流断连、429 分流：链路问题查代理，限流查用量
- 事故期克制重试，恢复后重放中断任务核对结果
关于 503 报错的常见疑问
- 503 会持续多久？：过载型通常几分钟到几十分钟，事故型看官方公告的恢复进度；状态页的实时状态比任何经验估计都准，盯着它比盯着报错窗口有用。
- 反复 503 但状态页一切正常，说明什么？：先怀疑两处——第三方后端在降级，或本地链路把连接失败误报成服务不可用；分别用对方面板与换网络验证，两条都排除再回官方侧查。
- 事故期间应该做什么？：等公告、克制重试、把手头任务换到不依赖该服务的事上；恢复后重放中断任务并核对结果，别带着半成品往下走。
