Codex中转站怎么搞得，具体流程和判断标准（动手之前：先确认这个站值不值得接）

很多人卡在这一步：手里有一个中转站的 key 和地址，却不知道该往 Codex 的哪个位置填，填完跑不通也说不清是站的问题还是配置的问题。这篇按顺序走一遍——先定选站标准，再落到配置文件，最后用最小请求验通并给出排查顺序。不讲原理，只讲怎么动手和怎么判断。

动手之前：先确认这个站值不值得接

接一家中转站之前，先别急着注册充值。把这站当成一个要长期打交道的供应商来看：接口给不给得明白、调用方式对不对得上你的工具、账能不能自己查清楚。这三条只要有一条含糊，后面出问题都是扯皮。

1. 先小额试充最小额度，用你自己的真实任务跑几轮，看返回是否稳定、延迟能不能接受
2. 对账拿站点后台的用量记录和你本地调用次数比一比，差太多就说明统计口径有问题
3. 验真到 跑一遍站点检测，广告页写得再漂亮也不如这一遍结果实在
4. 核规格拿不准的模型版本，到 对一下上下文长度和参数支持，别拿自己的猜测当依据

小额试水这一步别省。哪怕站点看着靠谱，也先把预算压在一家之前跑通一轮。具体充多少，按 的口径来定，别自己拍脑袋。真跑顺了再追加，比一次性压一大笔进去安全得多。

配置四步：地址、key、模型名、跑一次

Codex 类中转站接入失败，九成不是 key 填错，而是四步里某一步没对齐：地址写法、key 放置位置、模型名是否在该站列表里、有没有先跑一个最小请求。这四步按顺序走，每步都能单独验证，出问题时也容易定位。

1. 第一步：拿 base URL，注意版本路径从站内中转站详情页抄 base URL，别自己拼。重点看两件事：结尾是否带版本路径（有的站要求带，有的站要求不带，由它代理的上游决定），以及结尾斜杠是保留还是去掉。多一个斜杠或少一段版本路径，常见表现就是 404，而不是鉴权失败。拿不准时按站内 /guides/relay-base-url-setup 的说明对照一遍。
2. 第二步：填 key，别写进会被提交的文件key 放环境变量或本地配置文件里，不要硬编码进仓库里的代码或配置模板。验证方式：提交前跑一次 git status 或看 .gitignore 是否覆盖了那个配置文件；如果 key 曾经进过提交历史，直接去站内后台轮换一把，别指望删掉文件就没事。
3. 第三步：确认模型名在该站列表里模型名以该站模型列表或 /models 接口的返回为准，不能照抄别家文档里的名字。同名模型在不同站可能大小写、后缀、前缀都不一样，写错通常报模型不存在。不确定就先调一次列表接口，把返回的名字原样复制。
4. 第四步：发一个最小请求，通了再上任务先发一句话的补全或最短对话请求，只看能否返回正常内容，不要一上来就跑长任务。通了之后，用站内 /tools/speed-test 量一次延迟基线，记下来，后面觉得慢有对比依据。

• 地址从站内详情页原样复制，不手动拼
• key 走环境变量或本地配置，并确认被 .gitignore 覆盖
• 模型名以该站列表接口返回为准，原样粘贴
• 先跑最小请求，再做延迟基线，最后才上真实任务
• 任何一步失败，只回退这一步，不要四步一起改

跑不通时的排查顺序

调 Codex 中转站接不通时，最容易犯的错是凭感觉乱改：一会儿换 key，一会儿改地址，最后连哪个改动起作用了都不知道。下面这套顺序是从最常见、最便宜的排查开始，一步步往后走。

1. 第一步：检查 key把 key 复制到纯文本编辑器里，看前后有没有空格、换行、引号，或者从网页复制时带上的多余字符。报鉴权类错误先只怀疑这一项，别急着找站方。
2. 第二步：检查 base URL多数中转站给的地址已经带了版本路径，你自己再拼一次就会变成双份路径，直接 404。先把地址还原成站方给的原样，只改这一个变量重试。
3. 第三步：确认模型名模型名写错也会返回找不到，和地址错误的报错长得很像。去站内模型库核对当时支持的写法，注意大小写和前后缀，别用自己记忆里的名字。
4. 第四步：查额度登录站内后台看余额和套餐档位是否还有效。额度耗尽或套餐到期，表现往往是限流或直接拒绝，不是网络问题。
5. 第五步：查网络前面都排除了再怀疑网络：本地代理、公司防火墙、DNS 都可能拦。换个网络环境或关掉代理重试一次，确认是不是链路问题。

• 每次只改一个变量，改完立刻重试，两个一起改就分不清是谁的问题
• 把请求地址、模型名、时间点和返回内容记下来，对账和找客服都用得上
• 别在没记录的情况下连续换 key，换到后面自己也记不清哪个能用
• 报错原文比截图有用，完整复制返回内容再发出去

什么情况该换站，而不是继续调

调了半天 prompt、换了参数、重启了客户端，结果还是忽好忽坏——这时候先别怀疑自己的写法。问题很可能不在你这边，而在中转站那一段链路。关键是分清「我这边配置/用法有问题」和「对面站侧有问题」，前者值得继续调，后者继续调就是浪费时间。

1. 先做质量交叉验证拿同一模型、同一提示词，到 /tools/quality-check 跑一轮对照，看看输出是普遍不稳定还是只是你这个站不稳。结果差不多的，说明是上游或模型本身的问题；差别明显的，基本能锁定站侧。
2. 再确认是不是配置问题把地址、key、模型名逐项对一遍，换一个客户端重试一次。如果换客户端、换机器还是同一类错误码，配置这条基本可以排除。
3. 问客服，看回答质量把错误码、请求时间、复现步骤一起丢过去。对方能定位到具体环节就继续等；如果只是反复让你重试、或者答非所问，说明这家站自己也没掌握链路状态。
4. 切换到备用站别在原地无限重试。把备用站的地址和 key 换上去，同样的请求跑一遍，能通就先干活，事后再回来复盘。

• 同一提示词连跑几次，输出质量明显不对，且不是偶发一两次
• 错误码持续是同一类，重试次数已经超过你能接受的范围
• 客服答不上来，或者给不出任何可执行的排查方向
• 你的业务停不起，等不起对方慢慢修
• 已经确认不是自己客户端、网络、参数的问题

至于什么时候算「这家站该长期放弃」、什么时候只是短期波动，可以对照 /guides/site-lifespan-diversify 里列的判断信号，结合自己业务的容错能力来定。这里没有一刀切的标准：小团队、非关键任务可以多忍几天；对外服务、有 SLA 压力的，宁可早切换。