网关转发原理

调中转站接口时报错，最难的地方是不知道错在哪一段：是自己的代码、网关、上游厂商，还是中间的鉴权与限流。这篇按请求经过的顺序把网关转发拆成几段讲，每段给出你能自己验证的动作，让你在排错时能先定位到跳，而不是靠猜。

调中转站接口报错，最难的地方是不知道错在哪一段：是自己的代码、网关、上游厂商，还是中间的鉴权与限流。这篇按请求经过的顺序，把网关转发拆成几段讲，每段给出你能自己验证的动作，让你排错时能先定位到跳，而不是靠猜。

先给一个整体印象：网关本质上是一个「会改目标地址的中间人」。它收到你的请求，做几件固定的事，再把请求丢给上游厂商，拿到响应后再回给你。中间任何一跳出问题，表现都会不一样，所以定位的关键是分清「这一段谁负责」。

网关转发到底转了什么

网关不改语义，只做三件事：换目标地址、补鉴权头、按需改写请求体里的个别字段（最常见的就是 model 名映射）。请求体和响应体基本原样透传，字段兼容性问题往往出在上游厂商那边，而不是网关自己写错了什么。

还有一件容易被忽略的事：流式响应能不能转发，取决于网关是否按块转发，而不是先把整包缓冲下来。如果是先缓冲再吐，你会看到「等很久，然后一次性全出来」，而不是逐字往外冒。这一点自己发一次流式请求就能感受到，不用猜。

• 换个角度看，网关只是中转，不会帮你把上游不支持的参数变出来；上游不认，网关也大概率不认
• 写请求前先确认你要的字段上游到底认不认，别把锅先甩给网关
• 流式和非流式是两条不同的处理路径，排查时要分开试

一次请求的完整链路，从头数到尾

把链路摊开看：客户端 → 你的域名或网关入口 → 鉴权与额度校验 → 渠道选择（路由）→ 上游厂商接口 → 响应回传。每一跳都可能加延迟，比如 DNS 与 TLS 握手、鉴权查询、路由匹配、上游首字等待。你要做的不是背下这条链，而是出问题时知道该往哪一跳查。

1. 量自己的基线延迟先到 /tools/speed-test 打一次，把网关和直连的数字放一起比。差得不多说明网关这一跳开销小，差得多就要往中间环节想。
2. 确认鉴权在哪一跳被拦把返回体的格式拿出来看。网关自己的错误格式通常带 code 和 message 字段，上游原样透传的多半是厂商那边的格式。
3. 分离渠道问题和代码问题同一个 Key 换另一条线路试一次，能通就说明是渠道，不是你的代码。

几个必须知道的转发机制

这一段说的是几个你迟早会碰到的机制。知道它们怎么运作，报错时你才有判断依据，而不是只能看到一句「请求失败」。

鉴权替换

客户端拿的是网关 Key，网关换成上游 Key 再发出去，所以你的 Key 泄露和上游 Key 泄露是两件事，处理方式也不一样

模型名映射

客户端写的名字和实际调用的模型可以不是同一个，对不上时报错多半卡在这一层

超时与重试

网关有自己的超时阈值，超过了就返回 502 或 504；重试该由客户端做还是网关做，要提前约定清楚

流式透传

SSE 场景下网关如果不逐块转发，你会看到「等很久然后一次性出来」，而不是边生成边出来

按链路定位问题：一份排查顺序

下面这份顺序是从「看一眼就能判断」到「需要动手试」排的。照着走，大部分问题在第一步或第二步就能缩小范围。每条都给了验证动作，不是让你凭感觉猜。

• 先看返回体：网关自己的错误格式通常带 code 和 message，上游原样透传的多半是厂商格式，先分清是谁在报错
• 再换直连或换渠道试一次：同一 Key 换另一条线路，能通就说明是渠道问题而不是你的代码
• 然后查请求头：鉴权头字段名写错、多包了一层 Bearer，都会在鉴权这一跳被拦下来
• 最后看超时设置：客户端 timeout 比网关短，就会出现你这边超时、服务端其实已经成功的情况

如果你手上有多个中转站要对比，与其一个个手动试，不如先到 /sites 看各家的说明和当前状态，再到 /rankings 核对当时的数字，把范围缩小到两三家再动手调。

什么情况下这套机制不适用

转发这套机制不是万能的，有些场景它天然帮不上忙。提前知道边界，比出了问题再找原因省事。

• 需要厂商私有能力时，比如某些没有对外暴露的参数，网关透传会直接丢掉，这种情况得走官方通道
• 对延迟极敏感的场景，多一跳就多一段开销，能不能接受要先测再定，别默认网关一定够快
• 有数据合规要求时，请求经过第三方网关意味着多一个处理方，选型要看合规口径，而不是只看价格

价格和线路这类会变的数字，别凭记忆判断。到 /price-watch 看当时的记录，再到 /sites 对照各家的条款，两条信息放一起再决定。