调用 AI 接口时中间突然返回 502，是最让人抓不住的一类报错——它不告诉你谁挂了，只告诉你「我转发的时候没拿到好结果」。这篇不解释协议也不讲客户端怎么配，只给一条能顺着往下查的顺序：先分清是哪一段断的，再判断是偶发还是持续，最后决定重试、换源还是找服务方要日志。
调 AI 接口的时候突然蹦出个 502，是最让人抓不住的一类报错。它不告诉你是谁挂了，只告诉你「我转发的时候没拿到好结果」。很多人第一反应是模型服务挂了，其实 502 更常见的是某一层网关自己发出的信号。这篇不给协议科普，也不讲客户端怎么配，只顺着一条排查顺序往下走：先分清是哪一段断的，再判断是偶发还是持续，最后决定重试、换源还是找服务方要日志。
开始之前先定个心态：502 是中间层的错误码，不是终点的错误码。它代表请求确实到了某个转发节点，但这个节点从它的下一跳没拿到合规响应。所以排查方向永远是「从近到远」——先看自己的出口，再看中转或网关，最后才看模型上游。
先搞清 502 是谁吐给你的
502 是网关类返回码，第一个要问的不是「模型怎么了」，而是「这个 502 的响应头是谁发的」。用 curl -i 或者浏览器开发者工具看响应头，重点看 server、via、x-request-id 这类字段。如果 server 字段带着熟悉的 Nginx 或云厂商网关的名字，说明这层就是发错的节点；如果完全看不到这些痕迹，就往应用层和上游查。
- 看响应体形态：网关自己生成的错误页通常很短，带明显的软件或厂商名；如果是结构化 JSON，说明请求其实已经进到应用层了
- 看响应头里的转发字段：via、server、x-request-id 能帮你确认是哪一层返回的
- 看请求 ID：网关一般会回一个请求 ID，拿它去找服务方查日志才查得动
- 看是否所有接口都这样：只挂一个模型和全站都挂，指向完全不同的层
三段隔离：把故障点缩到最小
把整条链路拆成三段——你的出口（本地网络、代理、公司网关）、中转或第三方网关、模型上游。每一段单独测一次，不要在同一时刻混着改配置，否则你分不清是哪次改动生效了。三段隔离的好处是，不管最后问题在哪，你手里都有一份对照结果。
- 测第一段：你的出口在服务器上直连目标域名，看是否稳定复现。换网络环境再跑一次，比如从公司网切到手机热点，如果换了就正常，问题基本在你这一侧的出口或代理。
- 测第二段：渠道或 Key如果手上有另一个渠道或另一把 Key，用它跑同一条请求。换 Key 就好、不换就坏，指向渠道或账号层面的问题，跟模型本身没关系。
- 测第三段：上游模型只有单模型、单渠道持续 502，而同网关其他模型正常，才优先怀疑上游模型服务本身。
注意不适用的情况：如果 502 是间歇性的，每隔几分钟冒一次，单次测试基本测不出来。这种要连续跑一段时间的探针，靠一段时间窗口里的成功率来判断，而不是靠一次请求的结果。
偶发还是持续：决定你下一步动作
同样是 502，偶发和持续的处置方向完全不同。偶发的（同样请求重发就好）优先按超时和瞬时过载处理，做有限次数的重试加退避；持续的（每次必 502）不要重试，重试只会压着网关，先去确认是不是配置改过、域名或路径写错、证书过期这类确定性问题。一个可落地的判据是：连续发若干次同一条请求，成功率低于一半，而且每次都卡在相近的时间点，按持续故障处理。
| 现象 | 倾向的判断 | 下一步动作 |
|---|---|---|
| 重发一次就好，几小时后偶尔再来 | 偶发、瞬时过载 | 有限重试加退避，观察一段时间 |
| 每次必 502，改了配置之后开始 | 配置或路径问题 | 回滚配置、核对域名和证书 |
| 高峰期集中出、低峰期正常 | 上游容量或网关限流 | 错峰、排队，不是改代码 |
| 一个模型挂、同网关其他模型正常 | 上游模型服务问题 | 换渠道或等上游恢复 |
重试次数、退避档位和超时秒数怎么分档，站内有专门文章给过对照清单，按自己业务的容忍度取一档就行，不要照搬别人的数值。至于具体的成功率、耗时这些数字，去站内速度测试和可用性页面核对当时的情况，别凭记忆下判断。
该记哪些字段、找谁问才问得动
排查到要找人问的时候，能不能问到点子上，取决于你手里记了什么。每次请求至少记这几项：时间戳、请求 ID（有就带上）、目标域名或渠道名、模型名、HTTP 状态码、总耗时、是否流式、重试次数。缺了请求 ID，服务方基本查不到你这一条，沟通成本会翻好几倍。
- 请求 ID
- 服务方定位单条请求的钥匙，没有它只能靠时间范围猜
- 渠道名
- 区分是中转站、云厂商还是官方直连，决定找谁问
- 是否流式
- 流式请求的失败点可能在首包之后，日志要标出来
- 重试次数
- 区分「第一次就挂」和「重试多次才挂」，判断方向不同
整理成一小段文本再去找服务方，比直接问「你们是不是挂了」有效得多。对中转站，先看站内的可信度与在线状态类信息，再决定是自己继续排查还是迁移到别的渠道。注意不适用的情况：如果 502 集中出现在你自己的网关或代理上，而这些日志字段全在你手上，那就别急着找服务方，先自己比对前后配置。
排查完别急着收工，把这次的时间点和现象记下来，下次同渠道再出问题时能直接比对是不是同一个原因。下一步想知道手上渠道当前的可用性和响应情况，直接去速度测试页面跑一轮，比凭感觉判断靠谱。→
常见问题
502 和 504 有什么区别，需要分开处理吗？
502 是网关从下一跳拿到的响应不合规，504 是网关等下一跳等到超时。处理动作经常重叠，都先看是不是网关层断的；区别在于 504 更偏向「对面太慢」，502 更偏向「对面给的东西不对」。实际排查时按同一条链路走，只是侧重点不同。
只有流式请求报 502，非流式正常，说明什么？
通常说明链路本身是通的，问题出在长连接的维持环节：中间某层对连接空闲时间、单次响应时长或分块传输有限制。可以先用非流式确认业务没问题，再回头找那一层的时间限制配置。站内关于流式接入生产的整理可以对照着看。
换了一家中转站还是 502，是不是我代码有问题？
不一定，但概率上升了。两三家都复现，先怀疑自己这一侧：出口代理、DNS、超时设得太短、请求体过大、目标路径拼错。把同一条请求换成最简形式（短提示词、非流式）再测一次，能明显区分是代码问题还是链路问题。
