想让 Codex 用上 DeepSeek，绕不开把请求指向中转站这一步。卡人的地方通常是三处：不确定该改配置文件还是环境变量，不知道接口地址和模型名该填哪个，填完跑起来报错也看不出是地址错了还是模型名不认。这篇按「先备料、再落配置、最后跑通验证」的顺序走一遍，顺便说清什么情况下这条路不适合你。
想让 Codex 用上 DeepSeek，绕不开把请求指向中转站这一步。真正卡人的地方通常就三处：不确定该改配置文件还是环境变量，不知道接口地址和模型名该填哪个，填完跑起来报错也看不出是地址错了还是模型名不认。
这篇按「先备料、再落配置、最后跑通验证」的顺序走一遍，顺手说清什么情况下这条路不适合你。全程不写具体数字，涉及价格、速率、额度这类会变的东西，都指向站内页面让你自己去核对当时的数值。
先给个总览：整件事就是一份对照关系，把下面三样东西从官方默认值改成中转站给的值，改完再用三步验证。具体路径的差异在于你的 Codex 从哪儿读配置，这点必须先查清。
| 字段 | 原来指向 | 要改成什么 |
|---|---|---|
| 接口基址 | 官方 API 域名 | 中转站给你的、通常以 /v1 结尾的地址 |
| API Key | 官方控制台签发 | 中转站在后台发给你的那一串 |
| 模型名 | 官方文档里的模型标识 | 该中转站文档里写明的那个字符串 |
动手之前先把四样东西凑齐
所谓四样，就是接口基址、API Key、模型名，外加一个「配置入口在哪」的答案。前三样必须成套，缺一个后面必报错。尤其别拿别家站的模型名去套这一家，名字对不上是最常见的 404 来源，而且报错信息往往只说找不到模型，不告诉你是名字写错了。
- 接口基址：中转站后台或文档里那份，注意是不是带 /v1 后缀；
- API Key：这一家专用的，别把别家的 Key 填进来试；
- 模型名：抄文档原样，别自己拼接版本后缀，也别填展示用的中文名；
- 配置入口：先搞清楚你的 Codex 读配置文件还是认环境变量，改错地方等于没改。
- 确认配置入口在自己机器上把当前生效的配置文件位置和已有环境变量列出来，看清楚哪个字段是真正被读取的。
- 确认协议兼容性到站内中转站列表页翻一下这家有没有标注兼容 OpenAI 协议；不兼容的只能走它自己的 SDK，配置方式完全不同。
- 核对模型名同一家的不同分组可能对应不同模型名，分组和模型名要成对确认，抄下来放进一个临时文本里备用。
配置落哪里：三个字段的填法
把接口基址指向中转站而不是官方域名。这里最容易踩的坑是末尾斜杠和 /v1 后缀，多一层少一层都会 404，而且报错可能看起来像认证失败。改完不要直接进 Codex，先单独用命令行打一次最简单、不带任何工具的请求，能通再往下走。
export OPENAI_BASE_URL="<中转站接口基址>"；export OPENAI_API_KEY="<中转站Key>"；curl -s "$OPENAI_BASE_URL/chat/completions" -H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json" -d '{"model":"<中转站文档里的模型名>","messages":[{"role":"user","content":"你好"}]}'模型名填中转站文档里给出的那一个字符串，不要自己加前缀后缀，也不要填展示用的中文名。Key 建议走环境变量而不是硬写进配置文件，写完重启一次进程，确认新变量真的被读到，再进入验证阶段。
- 接口基址
- 请求发往哪儿，末尾斜杠和 /v1 后缀要和文档完全一致
- 环境变量
- Key 放这里，避免硬编码进配置文件被误提交
- 模型名
- 中转站认的字符串，名字对不上直接报找不到模型
跑通验证：从最小请求到真实任务
验证分三步，顺序别跳。第一步只发一句「你好」，看能不能拿到完整回复；第二步发一个需要流式输出的长请求，看是不是边出边显示，如果卡到最后才一次性吐出全部内容，说明流式没走通；第三步才是拿一个真实的小改动任务跑一遍，观察工具调用——读写文件、执行命令——是否正常触发。
前两步都过、第三步挂掉的话，多半不是配置问题，而是这个模型对工具调用的支持程度问题。这时候先别改配置，换个思路判断：把同样的任务换回官方通道跑，两边行为差异就是你要找的线索。
- 一句问候：验证地址和 Key 是否被认可；
- 长请求：验证流式输出是否正常，不是攒完才吐；
- 小改动任务：验证工具调用能否触发；
- 交叉验证：用站内的实测思路确认返回的确实是你要的模型；
- 异常判断：出现答非所问、上下文明显变短，先怀疑模型被换，再查配置。
什么情况下这条路不适合你
不是所有场景都适合让 Codex 走中转。判断标准有三条，命中任意一条，就优先考虑直连或者换一家。第一条是上下文长度：任务需要一次塞进很长的文件时，中转站可能在中间截断，表现是模型好像没看到你后半段的内容，这时候要么分批传，要么换直连通道。
第二条是工具调用和长会话的稳定性需求。如果这家站的兼容层做得比较薄，实际表现会明显不如直连，具体差多少不好一概而论，建议先跑几天再决定要不要长期用。第三条是数据边界：涉及敏感代码或客户数据的项目，走中转意味着请求经过第三方，这条得在落配置之前就想清楚，别配完才后悔。
| 你的情况 | 建议做法 | 为什么 |
|---|---|---|
| 单次任务、文件不长、对稳定性要求一般 | 可以走中转，先小范围试 | 配置成本低，出问题影响面小 |
| 需要长上下文一次塞大文件 | 优先直连或分批传 | 中途截断时你以为是自己写错了 |
| 依赖稳定工具调用和长会话 | 先跑几天对比再定 | 兼容层薄的话表现会明显掉档 |
| 涉及敏感代码或客户数据 | 先评估数据边界再动手 | 请求经过第三方，这是前提问题 |
最后补一句：具体哪家站在价格、速率上更划算，别信别人截图，直接到站内页面核对当时的数字，各家政策变得比你想象的快。
下一步先按上面的对照表确认你的三个字段填对了，再决定这家站值不值得长期用；主流中转站的支持情况和实测表现，到站内列表页看当期的对比数据。→常见问题
配置改完还是报错，先查哪几个地方？
按这个顺序排：先确认接口基址拼写和 /v1 后缀对不对，再用同一把 Key 单独打一次最小请求。两次都通但 Codex 里报错，问题多半在模型名字符串或配置文件没被读到。查错时一次只改一个变量，改两个以上就分不清是谁的问题了。
同一个 DeepSeek，中转站和官方直连用起来差在哪？
差别主要在路径和数据可见性：直连是你和官方之间一条线，中转多经一手。功能上，兼容层做得好的站体验接近，做得薄的会在工具调用、流式输出、长上下文上露怯。成本和额度口径各家不同，具体数字到站内 /official-api/providers/deepseek 和 /sites 对一遍再决定。
怎么判断返回的是真 DeepSeek 还是被换了模型？
别只看一次回答。挑几个能暴露风格差异的问题交叉问，再用站内 /tools/verify 的实测流程做一轮，看响应特征和文档描述是否一致。如果同一把 Key 换个分组名字就变了风格，说明背后挂的可能不是同一个模型。
