codex 中转站 如何使用

很多人买了中转站的额度，卡在最后一步：codex 里到底该填什么。中转站给的是 OpenAI 兼容的 base_url 和 key，但 codex 的配置文件写法、走 Responses 还是 Chat Completions、环境变量怎么设，网上的说法五花八门。这篇不评价哪家站好，只把配置这一件事拆开：先确认站点支持什么，再改哪个文件，最后怎么验证真的通了、怎么按顺序排查报错。

很多人买了中转站的额度，最后卡在配置这一步：codex 里到底该填什么。站点给你的是一个 OpenAI 兼容的 base_url 加一把 key，但 codex 读的是自己的配置文件，地址写根路径还是带版本号、走 Responses 还是 Chat Completions、key 是塞进文件还是环境变量，网上说法各不相同。

这篇不评价哪家站好用，只把「配置」这一件事拆开：动手前先跟站点确认三件事，再决定改哪个文件，接着验证是不是真接通了，最后给一套报错出现时的排查顺序。照着走，基本能把大部分「填了但用不了」的情况定位到具体一步。

动手前先跟站点确认三件事

不要拿到 base_url 就往配置里贴。中转站之间的路径习惯不一样，有的给根地址，有的带一段版本路径，写错的一端通常直接 404，而不是给你一个明确的提示。先问清楚，再动手，能省掉一半的来回。

• 确认 base_url 该以哪个路径结尾，codex 里填的是根地址还是带版本号的地址，两者混用必报 404
• 确认站点走的是 Responses 协议还是 Chat Completions 协议，codex 两类都能接，但配置字段不一样
• 确认这把 key 能不能调用 codex 实际会用到的那档模型，有些站点的低价分组并不包含它

第三点最容易被忽略。先去 按量计费的接口目录（/ai-nav/category/ai-api） 看站点标注的接口形态，再去 中转站目录（/sites） 对照它写的支持范围，两处说法不一致就以站点后台的实际分组为准，后台没写的就当不支持。

配置怎么写：把 key 和地址放对位置

配置的核心只有两件事：鉴权信息放哪、模型名写什么。鉴权信息建议走环境变量，配置文件里只引用变量名。这样换站时只改变量，配置文件不用动，也就不会出现「改了一半回滚不了」的情况。

模型名要逐字照抄后台列出的写法，大小写和连字符都不要自己猜。它填错时的表现很典型：报的是「模型不存在」，而不是鉴权失败。分清这两类报错，能立刻确定该改哪一项。

怎么确认真的接通了，而不是被静默换掉

能返回内容不等于链路正常。有些站点会在你指定的模型之外偷偷降级，或者把请求转给别的上游，表现是「能用但结果明显不对」。所以验证要分两步：先看接口层通不通，再看结果对不对得上。

1. 发一条最短的请求看返回里有没有正常的模型标识和 token 统计。没有统计字段或标识与请求不符，先别往下跑真实任务。
2. 用一个有明确答案的小任务做基线比如让它改一段有语法错误的代码。拿这条结果跟官方直连的结果对比，差异明显就要怀疑链路被换了。
3. 量一遍延迟基线去 接口测速（/tools/speed-test） 把当前响应时间记下来，作为之后判断「是不是变慢了」的参照。
4. 跑一遍真假实测用 中转站真假在线实测（/tools/verify） 验证模型是不是真的，别只靠体感判断。

这四步不需要每次用都跑，第一次接入时做一遍，之后只在结果明显异常或换了站点时重跑。把基线的数字留着，比事后凭印象争论有用得多。

跑不通时的排查顺序

报错不要一上来就怀疑站点。按状态码从前往后看，基本能对上具体是哪一环出了问题。顺序错了会白折腾：明明该改模型名，却一直在换 key。

• 报错里出现站点自己的域名，说明请求已经到了中转站，问题在它的上游或分组权限，可以直接拿报错找客服
• 把失败请求的时间、模型名、报错原文记下来再问，比只说「用不了」能省一轮来回
• 同一把 key 换个模型能通，基本就是该模型那档分组的问题，不是地址或 key 错

什么情况下不适用：如果你用的是官方直连，或者订阅制客户端，根本不涉及 base_url 这类配置，这套排查顺序帮不上忙，别硬套。另外，站点偶尔的抖动不在这套逻辑内，隔一段时间重试一次再判断更准。

配置报错里，状态码本身就是答案的一部分，先看它，再猜原因。