本地代码没改,昨天还通的接口今天突然回 503,第一反应往往是「中转站挂了」。其实 503 只是上游说「暂时服务不了」,可能是平台在切渠道,也可能是你的请求打到了没配好的源站,或者并发太高被短暂挡了一下。这篇按「先分清是谁回的 503,再逐层往下收窄」的顺序给一套动作,新手照着走也能定位到自己该改哪一行。
昨天跑通的代码,今天突然回 503,很多人第一反应是「中转站挂了」。其实 503 只是上游在说一句话:现在暂时服务不了。原因可能在平台切渠道,也可能你的请求打到了没配好的源站,或者并发一高被短暂挡住。先别急着改业务逻辑,按顺序收窄范围更省时间。
下面这套流程按「先分清是谁回的 503,再一层层往下缩」来走。不需要你事先懂网络原理,每一步都有具体动作和判断标准,新手照着做也能定位到该改哪一行代码或者该换哪条线路。
第一步:先分清这个 503 是谁回的
拿到一次 503,先别关掉报错窗口,把原始响应完整看一遍。返回体是纯 HTML 或者一句很短的中文提示,多半是网关、CDN 或中转层挡下来的;返回体是带结构的大段内容,往往来自源站或模型厂商。责任方不同,后面查的方向也完全不同。
- 看响应头和报错体:网关层多半回纯 HTML 或短文本,源站或厂商常常有结构化内容,先判断属于哪一类
- 判断信号要一起看:是所有请求都 503,还是只有某个模型、某个渠道、某个时间段出问题;只坏一个模型,基本不是你的代码错
- 排除自身因素:Base URL 有没有多写或漏写版本段、Key 是不是被重新生成过、本地代理有没有偷偷改请求体
- 网关层 503
- 请求还没到模型那一侧就被挡了,重点查地址、代理、平台当前状态
- 源站 503
- 请求到了模型服务那边但对方暂时处理不了,重点查这个渠道和模型是否可用
- 单模型 503
- 其他模型正常、只有某一个不通,一般记下来反馈换备用线路就行
第二步:按层收窄,把范围从「全体」缩到「一处」
范围收窄有个笨但可靠的办法:由外到内分成网络接入、网关转发、渠道模型、请求参数四层,每层只发一个最小请求去验证。不要直接拿业务代码试,业务代码里混着鉴权、流式、工具调用、超长上下文,任何一个都可能把问题盖住。
- 先测最外层连通性用最简单的请求打一次接口,只带 Key 和一句话,确认地址能通、域名能解析,排除本地网络和代理问题
- 再加一个参数进去逐个加回流式、工具调用、长上下文这些能力,加到哪个参数开始 503,问题就锁定在那一处
- 做时间维度对照隔几十秒再试一次;能通说明是短时容量问题,一直不通更像配置或渠道不可用,这两类处理方式完全不同
还有一个容易被忽略的变量是并发。白天多人同时用、夜里没人用,表现会完全不一样。如果你只在自己一个人调试时测过,建议在业务高峰时段按真实并发量再跑一轮,那里暴露的问题和单人测试不是一个性质。
第三步:对应每层给处理动作
定位到哪一层,就只改那一层,别顺手把整段代码重写。下面这张表按层给出该做的动作和判断依据,照着对号入座即可。
| 出问题的那层 | 典型表现 | 该做什么 |
|---|---|---|
| 网络与接入 | 换设备、换网络都 503 | 关掉本地或系统级代理,改用直连地址再试一次 |
| 网关与转发 | 响应是简短提示、没有结构化内容 | 换一家中转站同模型请求,能通说明是上游暂时不可用 |
| 渠道与模型 | 只有某个模型或某个渠道不通 | 记录模型名与时间,切换备用线路,把问题反馈给平台 |
| 请求参数 | 去掉某个参数就恢复正常 | 减小批量与并发,把单次大批量拆成小批,避免瞬时打满 |
代码层面只加一件事:有限次重试。不是所有错误都值得重试,瞬时容量问题重试大概率能过,地址写错、Key 失效这类重试一百次也没用。重试要带退避间隔,次数设上限,失败后走降级或提示,别写成原地死循环。
# 最小请求验证连通性,去掉一切附加参数
curl -s -o /dev/null -w "%{http_code}\n" -H "Authorization: Bearer $KEY" \
-H "Content-Type: application/json" \
-d '{"model":"你的模型名","messages":[{"role":"user","content":"hi"}]}' \
https://你的中转地址/v1/chat/completions第四步:确认修好了,以及什么情况下别硬修
修完别只跑一次就算过。验证要看三件事:连续多次请求都成功、流式和非流式各跑一遍、耗时回到你平时记录的延迟基线附近。这三样都对上,才算真的恢复,只过了一次可能是碰巧赶上渠道恢复。
- 连续多次成功,次数按你平时的调用频率来定,不要只测一次
- 流式与非流式各跑一次,两种模式走的链路可能不一样
- 耗时回到你平时测的基线附近,明显偏慢说明渠道还没完全恢复
- 把请求时间、模型、渠道、返回码和响应体片段记下来,下次同类问题能直接对上
什么情况下别硬修:如果连续多次失败,换模型、换中转站都还是 503,那问题不在你这边,硬改代码只会掩盖故障。这时候正确动作是切到备用线路,记录故障开始时间,把证据发给平台。平台当前状态和线路情况,可以到网页工具测一下连通性,用 /tools/speed-test 看单次链路表现,再对照 /sites 里各家站点的现状判断是不是普遍问题。
下一步排查完还是拿不准是哪家的问题,就去站点列表页看各家当前状态和可信度记录,对着时间点核一遍,比在自己代码里反复试更快找到答案。→常见问题
503 和 502、504 有什么区别,处理方式一样吗?
三者都是「你这边的请求没走通」,但含义不同:502 是网关拿到了无效的上游响应,504 是网关等上游超时。503 偏向「暂时不可服务」,常见于扩容中、渠道下线、容量打满。处理上 502/504 优先查链路与超时设置,503 优先查渠道可用性和并发,别把三者当同一个问题改。站内另有 502 与网关超时的排查路径可对照看。
加自动重试能解决 503 吗?
只能兜底,不能根治。如果 503 是短时容量波动,带退避的有限次重试确实能扛过去;但如果渠道已下线或 Key 被限,重试只会放大请求量,把自己送进限流。做法是限制重试次数、拉开间隔、只对可重试状态码重试,并且重试失败后要能切换到备用线路,而不是一直原地重试。
怎么判断是中转站的问题还是我代码的问题?
做一个最小对照:同一份代码换成官方地址或另一家中转站再请求一次,同时用最简单的一条命令直接打接口。两者都失败偏向环境或代码;只有某一家失败、换一家就通,基本是那家中转站的渠道问题。实在拿不准,可以先到站内用中转站在线实测页跑一次检测,看检测结果再决定方向。