接口调用返回503怎么解决，常见问题和做法（先搞清楚 503 是谁发出来的）

调用中转接口时突然一片 503，看着像自己代码写错了，其实多数时候问题不在请求本身。这篇按「先分锅、再收拾」的顺序给一套排查动作：怎么区分是渠道过载、网关抖动还是自己并发打太猛，每一步该看什么、该做什么，什么情况下忍一忍就会好，什么情况下要果断切走。

调中转接口突然一片 503，看着像自己代码写错了，其实多数时候问题不在请求本身。503 的意思是「服务端现在接不了」，不是「你请求写错了」，所以先别急着翻 body 和参数。这篇按「先分锅、再收拾」的顺序给一套动作：怎么区分是渠道过载、网关抖动还是自己并发打太猛，每步看什么、做什么。

判断的核心是固定变量、逐步往外撤。把你自己的代码当成一个黑盒，先确认请求没错，再确认是不是单条渠道饱和，最后才怀疑站点整体。顺序反了会浪费时间，比如你一边改参数一边重试，永远不知道到底是哪一层的问题。

先搞清楚 503 是谁发出来的

503 通常不是参数错误。同样的 Key 换个最简单的请求（非流式、小 prompt）再打一次，如果还是 503，基本能排除你 body 写错。如果换模型还 503，说明是通道层面没容量，不是单条模型的事。

• 上游模型方过载：表现为某个特定模型长期 503，换模型就好
• 中转站网关或渠道池无容量：表现为同站多个模型一起 503，或响应很慢后超时
• 本地入口被挡：Base URL 多斜杠、走了本地代理、证书问题，会伪装成服务端报错
• 请求本身有问题：通常是 4xx，不是 503，别混为一谈

五步排查顺序：从你的代码往外走

1. 固定变量重放同一请求连发三次，看是否稳定复现。偶发一次就好的别大动干戈，记下来观察即可。
2. 换模型换通道拿渠道里另一个能用的模型打一次，通了说明是单条渠道饱和，不是你的问题。
3. 降并发把批量任务临时降到串行，看是否立刻恢复。这一步能识别是不是自己把配额打满了。
4. 看响应头和报错体多数中转会带渠道信息或请求 id，对上你日志里的时间点，能定位到具体渠道。
5. 再去问中转站把请求时间、模型名、响应头一起给，比只发一句「报 503 了」有效得多。

这五步的价值在于顺序：越靠前的步骤成本越低、越能排除自己。很多人在第三步就发现问题，根本不用去问客服。反过来，一上来就怀疑站点，往往折腾半天才发现是自己并发打太猛。

重试怎么写才不添乱

重试不是越多越好。只对 503、超时这类可重试状态重试，4xx 重投只会浪费配额。用指数退避加随机抖动，次数封顶，别写死 while 循环硬怼，那只会让渠道更堵。

import time, random

def call_with_retry(fn, max_tries=4):
    for i in range(max_tries):
        try:
            return fn()
        except RetryableError:
            if i == max_tries - 1:
                raise
            time.sleep((2 ** i) + random.random())

• 流式请求重试要小心：已经吐了一半的内容别整条重发，从失败点记录
• 幂等性提前设计好，重试才不会造成重复计费或重复写入
• 重试次数和间隔要能配置，别硬编码在业务代码里
• 把每次重试记进日志，攒几天就能看出渠道的抖动规律

什么时候等、什么时候切

短时抖动适合等，单条渠道饱和一般几分钟到十几分钟，重试加排队就能过去。但持续很久、或同站多个模型一起 503，基本是站点侧问题，这时候切备用渠道比继续等划算。判断标准看持续时间和影响面，别看单次报错。

降级路径要提前排好：大模型挂时用小模型顶，流式挂时切非流式，保证功能不断。长期规避靠分散，别把全部流量押一个站，用多模型路由把请求分到两三条线上。哪些站值得放备用，可以到 /sites 看当时的中转站情况，价格和线路到 /price-watch 核对。

上线前的防 503 清单

503 很难完全避免，但可以把影响压到最小。下面这几条建议在上线前过一遍，尤其是要跑批量任务的项目。别等出事再补，补的时候往往已经影响用户了。

• 客户端要有状态码分类处理，503 和 429 走不同策略，不要一锅端
• 批量任务做分批加并发上限，别把瞬时峰值打出去
• 关键链路配一条备用线路，并定期演练切换，没演练过的切换等于没有
• 日志记下每次 503 的时间、模型、渠道，攒几天就能看出规律
• 上线前用 /tools/speed-test 测一下线路延迟和稳定性，心里有底