中转 API 是怎么"掺水"的？揭秘 5 种偷换手法的技术原理

中转的本质：一个可改写请求/响应的中间层

正常调用：你的程序 → 官方 API。走中转后变成：你的程序 → 中转网关 → (某个)上游 → 中转网关 → 你。

关键在于：这个网关能读、能改你来回的每一个字节。它可以只做透明转发（老实中转），也可以在中间动手脚。下面五种就是常见手脚。

手法一：模型路由替换（降级）

请求里写 claude-opus，网关不管你写什么，按自己的"路由表"把请求转给更便宜的模型（Sonnet / Haiku / 甚至开源模型），再把响应里的 model 字段改回 claude-opus 还给你。

• 技术上只是一次「请求改 target + 响应改 model 字段」；
• 你看到的 model 完全正常，但底层算力早被换掉。

所以只看返回的 model 字段永远发现不了降级。

手法二：协议改写（套壳 / 逆向）

上游其实是某个 IDE、某个网页版、或别家平台的接口，网关把它逆向出来，再"翻译"成标准 OpenAI / Anthropic 协议卖给你。

• 请求进来是标准协议 → 网关转成上游私有协议 → 上游返回 → 再转回标准协议；
• 一来一回都经过改写，原生签名、特征头、流式事件顺序都会变形或丢失。

这类"套壳"稳定性和合规性最差，随时可能因上游封禁而集体失效。

手法三：缓存冒充

网关缓存了历史问答，命中相似问题时直接返回旧结果，不真正请求上游。

• 省了上游成本，代价是你的回答可能过时、不联网、甚至答非所问；
• 特征：同一问题多次请求返回一字不差，或响应快得不真实（没有真实推理延迟）。

手法四：参数暗改（偷 token / 砍能力）

网关悄悄修改你的请求参数：调小 max_tokens、截断超长上下文、去掉 tools 字段、把 temperature 归一。

• 你以为发了 3 万字上下文，网关只转了前 4k；
• 你以为开了工具调用，网关把 tools 吞了，模型自然"不会用工具"。

这类改动最隐蔽，因为响应本身"看起来正常"，只是能力悄悄缩水。

手法五：usage 字段美化

响应里的 usage（token 用量）也是网关能改的。它可以把真实用量报小/报大，影响你的计费判断和额度感知。

• 真实消耗和账单对不上时，别排除这一层的可能。

为什么这些手法"肉眼看不出来"

因为上面每一种，网关都能让最终响应在结构上"看起来是对的"：model 字段对、JSON 合法、内容通顺。差别藏在指纹、原生结构、签名、能力表现、用量一致性这些不显眼的地方，需要多维交叉才暴露。

想知道自己有没有中招？

理解了机制就知道：单看一处一定被蒙，得从指纹、结构、签名、能力、用量多个维度一起交叉验。这套手动做门槛不低。

顺带推荐个免费在线工具 CheckToken（Token检测）：**https://www.checktoken.cn/**——填地址 + Key + 模型，它就是按上面这些维度黑盒并发跑十几项检测，替你判断底层到底被动了哪种手脚，并给出「官方直连 / 逆向 / 掺水 / 非目标模型」结论，全程不存 Key。

总结

中转掺水不是玄学，而是网关层的五类具体手法：模型路由替换、协议改写套壳、缓存冒充、参数暗改、usage 美化。它们的共同点是"让响应表面正常、暗地缩水"。知道它们藏在哪，你才知道该验哪里。