用中转站 API 时，地址换了、Key 换了、模型名换了，中间到底谁在干活，多数人说不清。结果一出错就只会怀疑「是不是掺水」，其实链路里每一段都可能卡住。这篇把请求从你的客户端到模型再回来的路线拆成几段，给一份按段排查的顺序，让你遇到超时、报错、答非所问时能先定位再下结论。
用中转站 API 的人，大多说不清一件小事：地址换了、Key 换了、模型名也换了，中间到底是谁在干活。于是每次出错，第一反应都是「是不是掺水了」。其实从你点下发送到答案回来，中间隔着好几层，每层都可能卡住，只是表现不一样。搞清这条链路，你的排查顺序会从「猜」变成「按段定位」。
下面按请求走过的四段来拆：进门、选路、转发、回程。每段给一个判断标准和几个能马上做的动作。哪一段的症状对不上，就先别急着下结论，有可能是上游、网络、甚至你自己客户端配置的问题。
第一段：请求先到中转站的门房
你的客户端其实只认一件事：把 base_url 指向中转站，换上它发给你的 Key，剩下的调用格式一般沿用上游那套，所以代码基本不用改。请求发出去的第一站不是模型，而是中转站的门房。门房干三件事：验 Key、查余额或额度、看模型名在不在它的白名单里。
这一段最典型的症状是「秒回错误」。Key 无效、额度不足、模型名没被收录，请求根本到不了模型就被挡回来，耗时往往很短。所以如果错误是立刻弹出来的，先怀疑门房，不要一上来就说模型质量不行。
- 错误几乎不耗时、格式是标准 4xx：优先查 Key 是否复制全、有没有多余空格、分组对不对；
- 模型名报不存在：去站内 /models 确认这个名称有没有被收录，写法是否一致；
- 想确认站点支持哪种调用格式（OpenAI 兼容还是别的），先看站内 /sites 里该站的说明；
- 只在某个分组下报错、换个模型就好：说明是门房的白名单问题，不是网络。
什么情况下不适用：如果你用的是自建代理或本地 SDK 做了改写，报错可能来自本地那一层，先把本地日志打开再对照上面的判断。
第二段：它决定这一单发给谁
过了门房，中转站要决定这一单走哪条上游通道。它背后通常挂着多条线路，同一个模型名可能对应不同来源，价目表里用分组名区分。具体倍率口径和分组命名，去站内 /markup-group-pricing-columns 这类报价说明页核对当时的数字，别拿官方价直接换算。
路由逻辑一般是可用性优先、成本次之：某条通道超时或报错，就切下一条。所以你两次调用命中不同上游，是正常现象，不代表有人在搞鬼。这也解释了为什么同一个模型名，不同时间段的手感会不一样。
| 现象 | 可能落在哪一段 | 先做什么 |
|---|---|---|
| 报错秒回、几乎不耗时 | 门房（鉴权/白名单） | 核对 Key、分组、模型名是否被收录 |
| 能出字但中途断、答一半 | 转发/流式长连接 | 换模型试一次，看是否只此一个通道 |
| 时快时慢、跨时段差异大 | 路由切换上游 | 用一段时间内的表现判断，别用单次快慢 |
| 答非所问、风格突变 | 回程/上游被换 | 复现三次以上，再用探针交叉比对 |
想判断某家通道的分层情况，站内 /channels 那类科普可以对照着看。判断稳定性要看一段时间的表现，单次快慢说明不了问题。
第三段：转发、流式与超时
转发本身不改变请求内容，它改的是出口 IP、账号池和计费口径。有一点要提前想清楚：数据在中间这一层对中转方是可见的，敏感内容别往里塞。可见性边界和日志留存的口径，去站内 /relay-data-visibility-privacy 这类说明页核对，不同站点做法差别不小。
流式输出靠的是保持长连接逐块回传。中间任何一跳断了，你看到的现象是「答一半停住」，而不是明确的报错，所以流式中断和超时要分开处理。
- 第一步：排除整体如果所有模型都慢或都报错，多半是网络或站点整体问题，不是单个通道。换个网络环境再试一次确认。
- 第二步：换模型对照只换模型名、其他不动。如果换了就正常，问题大概率在原模型对应的通道上。
- 第三步：量一个基线用站内 /tools/speed-test 测一次自己的延迟基线，后面所有对比都拿它当尺子，别凭感觉。
- 第四步：看客户端确认自己有没有设超时、重试、代理。客户端超时设得太短，也会表现成「模型不回」。
第四段：回来的路上发生了什么
上游返回后，中转站通常会把用量字段重新算成自己的计价口径，倍率、输入输出分开算。最终扣多少以它的账单页为准，别拿官方价手算，中间隔着倍率和分组。具体数字到站内 /price-watch 看当时的行情。
返回内容里的模型自称、风格差异，都不能当证据。要验证真伪得靠探针和交叉比对，做法见站内 /tools/verify。遇到答非所问或明显降级，先复现三次以上再判断，单次异常可能只是路由切了通道。
- 门房
- 鉴权、额度、模型白名单，秒回错误多半出在这
- 路由
- 在多个上游通道之间挑选，决定这一单发给谁
- 转发
- 改出口 IP、账号池和计费口径，数据在中间层可见
- 回程
- 把用量换算成站点计价口径，账单以站点为准
什么情况下上面的判断会失效：站点正在故障、你的网络在抖动、或者客户端偷偷重试了好几次。这几种情况下，先看状态页和本地日志，别一上来就归罪模型。
下一步出问题时留好请求时间、模型名和报错原文，再去站内核对当时的通道与价格数据，有了这三样，找客服或换站都不至于空口无凭。→常见问题
中转站的 API 地址和官方的能混用吗？
一般不混用。中转站给的是自己的 base_url 和 Key，路径结构通常照着上游做兼容，所以你把代码里的地址换掉、Key 换掉就能跑。但也有些站点只兼容部分接口，比如只支持对话不支持文件或图片上传，接之前先在站内 /sites 对应的站点说明里确认支持范围，别拿一个能跑的对话接口就默认全都通。
为什么同一个模型名，两家站回答风格不一样？
因为背后的来源可能不同。中转站常见做法是多条通道并存，按分组区分，同一个模型名下面挂的可能是不同上游。风格、语气、甚至速度都会因此有差别。要判断是不是被换了模型，靠单次对比没用，得用固定提示词多次跑并交叉验证，站内 /tools/verify 有现成的检测思路可以参考。
请求卡住不返回，是中转站的问题还是我的问题？
按段排。先换一个模型发同样的请求，如果也卡，多半是站点或你的网络；如果只有某个模型卡，就是那条通道的事。再看是不是流式接口，流式断开常常表现为中途停住。最后用站内 /tools/speed-test 量一下基线，跟正常时段的数字比。三步都排除完，再把请求时间、模型名、报错原文整理给客服，比空口说「你们很慢」有用得多。
