ChatGPT 接 Sub2Api 报错？排查 CLI 拉不到 5.6 版本的真相

最近在折腾 ChatGPT 到 Sub2Api 的转发配置时，遇到一个挺有意思的 Bug：直接用 Codex CLI 调起一切正常，但如果通过 Sub2Api 转发，死活识别不到 5.6 版本。这种情况相信不少搞过自动化或 API 中转的朋友都见过，今天就来拆解一下这个问题背后的原因和解决办法。

现象分析：为什么 CLI 能行，APP 不行？

首先，我们要明确一个核心差异：Codex CLI 和 ChatGPT APP（旧版 Codex 客户端） 在发起请求时携带的“身份信息”是完全不同的。

• CLI 环境：通常运行在终端或服务器上，请求头比较纯净，或者经过了特定版本的代码库签名，直接对接端点时，服务器端放行，自然能拿到最新的 5.6 数据或模型。
• APP 环境：移动端或桌面端应用在请求中往往包含了复杂的设备信息、User-Agent（UA）以及可能被“污染”的 Header。当这些请求经过 Sub2Api 中转时，如果配置不当，某些关键字段可能被过滤或篡改，导致后端无法正确识别客户端版本，从而拒绝提供 5.6 的服务。

排查步骤三步走

如果你也遇到了“CLI 可以，APP/转发不行”的情况，可以按以下步骤逐一排查：

1. 检查 User-Agent (UA) 伪装

很多时候，API 网关为了防止滥用，会校验 UA。

• 问题原因：Sub2Api 默认可能使用了通用的 UA，而官方接口针对特定版本（如 5.6）有专门的 UA 白名单校验。
• 解决办法：在 Sub2Api 的配置文件中（通常在 config.yaml 或环境变量里），找到关于 User-Agent 的设置。尝试将其修改为与 Codex CLI 完全一致的 UA 字符串，或者使用最新的官方客户端 UA 进行伪装。重启服务后再试。

2. 深入检查 Header 转发规则

这是最容易踩坑的地方。

• 问题原因：Sub2Api 在中转请求时，可能会为了清洗数据而丢弃某些 Header。但 5.6 版本可能依赖特定的 Header（比如 OpenAI-Organization 或某些自定义标识）来鉴权或路由。
• 解决办法：开启 Sub2Api 的调试模式（Debug Log），对比 CLI 成功请求的 Headers 和 Sub2Api 转发出去的-Headers。找出哪些关键字段丢失了。在 Sub2Api 的转发配置中，显式添加 Host、Authorization 以及那些可能被过滤的“隐形”字段。

3. 兼容性与节点选择

• 问题原因：某些 Sub2Api 的旧版本实现可能没有适配最新的 API 规范，或者部署的节点网络环境对官方接口有连通性限制。
• 解决办法：检查 Sub2Api 是否为最新版。如果不是，建议更新到支持 GPT-4o 或最新模型的版本。此外，尝试更换 Sub2Api 的部署节点，有时特定地区的 IP 会被官方接口进行差异化限制。

总结与建议

遇到这种“本地直连 OK，中转挂掉”的问题，核心思路就是**“找差异”**。

1. 不要盲目去改代码，先用 Wireshark 或 Burp Suite 抓个包，看看 CLI 发出去的包和 Sub2Api 发出去的包到底差在哪。
2. 重点关照 Header 里的 UA 和 Authorization 字段。
3. 如果 Sub2Api 配置实在搞不定，不妨换一个更轻量级的转发工具试试，或者直接在反向代理层（如 Nginx）做 Header 的透传处理。

有时候，版本号识别不到不一定是你的账号凉了，很有可能是中间那个“搬运工”把证件给弄丢了。希望这篇排查思路能帮大家省点熬夜搞服务器的时间！