1. 404 是怎么复现的Codex 换 Base URL 后的第一份日志先把结论摊开Codex 调 DeepSeek 报 404九成不是 Key 的问题也不是模型没开通而是Base URL 被拼错了路径。我用的是 TaoToken 作为统一入口改地址前先到 TaoToken 官网 拿 Key然后把config.toml里的base_url从官方地址换成https://taotoken.net/api。第一次重试就直接 404日志长这样ERROR codex_core::client: request failed methodPOST urlhttps://taotoken.net/api/v1/chat/completions/v1/chat/completions status404 Not Found body{error:{message:Not Found,type:invalid_request_error}}看到url那一行没有/v1/chat/completions出现了两次。这就是 404 的全部原因Codex 自己会在base_url后面再拼一层 chat completions 的路径而我在填base_url的时候手滑把/v1也写进去了服务端拿到的是一个不存在的双层路径只能返回 404。这个错误特别容易骗人因为 404 在直觉里等于「地址不对」但很多人的第一反应是「Key 没生效」「模型没权限」「账号被限流」。于是开始反复换 Key、换模型名、重启终端折腾半小时其实要改的只有一行。复现步骤我完整记录一下方便你对照自己的情况# 1. 安装 Codex CLInpm 全局装 npm install -g openai/codex # 2. 确认版本 codex --version # 3. 写入配置文件下面这版是错的故意留错复现 404 mkdir -p ~/.codex cat ~/.codex/config.toml EOF model deepseek-chat model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api/v1 env_key TAOTOKEN_API_KEY wire_api chat EOF # 4. 注入 Key export TAOTOKEN_API_KEYYOUR_API_KEY # 5. 发起一次对话观察报错 codex exec 用一句话说明什么是 HTTP 404执行第 5 步之后终端只会给你一句很短的stream error: unexpected status 404 Not Found。真正的 URL 拼接细节藏在日志里所以排查第一步永远是打开详细日志而不是继续猜。# 打开 debug 级别日志再跑一次 RUST_LOGdebug codex exec ping 21 | tee /tmp/codex-404.log # 只看请求相关的行 grep -Ei url|status|provider|base_url /tmp/codex-404.log日志里能同时看到三件事最终请求的完整 URL、Codex 解析到的 provider、以及 HTTP 状态码。只要这三样拿到手404 的定位就完成了 80%。剩下 20% 是把地址改对。这里还有一个容易被忽略的点报错信息里的域名是对的路径是错的。很多人一看域名是taotoken.net就以为接入已经通了问题出在「模型」上转头去查deepseek-chat这个名字对不对。实际上请求根本没走到模型路由那一步服务端在路径匹配阶段就把它挡掉了。日志里的url才是唯一可信的现场证据。2. 地址对照哪一层路径把 /v1 重复了把常见的base_url写法列成一张对照表你可以直接拿自己的配置来比对。判断标准只有一个Codex 拼完之后服务端收到的路径必须是/api/v1/chat/completions这一层不能多也不能少。配置里写的 base_url实际请求路径结果原因https://taotoken.net/api/api/v1/chat/completions200正确写法https://taotoken.net/api/v1/api/v1/v1/chat/completions404/v1被拼了两次https://taotoken.net/api//api//v1/chat/completions404 / 301尾部斜杠造成空路径段https://taotoken.net/v1/v1/v1/chat/completions404漏掉/api前缀https://taotoken.net/v1/chat/completions404根路径没有推理端点https://taotoken.net/api/chat/completions/api/chat/completions/v1/chat/completions404把完整端点当成了 base_urlhttp://taotoken.net/api重定向或连接失败非 200协议头写错这张表的核心信息是base_url是「前缀」不是「完整端点」。这两种东西在其它工具里经常混着叫所以从别的地方复制配置过来时特别容易踩坑。我贴一下真实的重试对比左边是错的右边是对的只改了base_url一行# 错误404 POST https://taotoken.net/api/v1/v1/chat/completions → 404 Not Found # 正确200 POST https://taotoken.net/api/v1/chat/completions → 200 OK → data: {choices:[{delta:{content:404 表示...}}]}注意第二行正确情况下服务端收到的路径里只有一个/v1。这个/v1是 Codex 依据wire_api chat自己拼上去的不需要你在base_url里再写一遍。如果你不确定自己手上的路径该不该带/v1有个不用猜的办法看你的工具在拼 URL 时用的是哪种协议风格。# wire_api chat → 工具会拼 /v1/chat/completions # base_url 只需写到 https://taotoken.net/api [model_providers.taotoken] base_url https://taotoken.net/api wire_api chat# 假设某些版本用 responses 风格 → 工具会拼 /v1/responses # 同样不要把 /v1 写进 base_url [model_providers.taotoken] base_url https://taotoken.net/api wire_api responses规律是一致的base_url只写到域名加/api这一层版本号和资源路径交给工具去补。你写得越完整越容易拼出双层路径。顺便说一个判断技巧如果报错是 404 并且日志里的路径里出现了两个/v1那基本可以 100% 确认是这个问题不用再做其它排查。如果路径看起来正常但还是 404才需要往下一节的方向查。3. 改对 config.tomlCodex 接 DeepSeek 的最小可用配置明确一点Codex 用的是config.tomlTAOTOKEN_API_KEY这套环境变量不要拿 Claude Code 的ANTHROPIC_*往 Codex 上套。这两套东西是不同工具的不同协议混用只会产生一堆看起来像 404、实际是鉴权失败的报错。下面是我现在实际在用的完整配置可以直接复制唯一需要替换的是 Key# ~/.codex/config.toml # 默认使用的模型按你在 TaoToken 上可用的模型名填写 model deepseek-chat # 指定走哪个 provider model_provider taotoken # 给模型一点温度按需改 model_reasoning_effort medium [model_providers.taotoken] name TaoToken # 关键一行只写到 /api不要带 /v1 base_url https://taotoken.net/api # Key 从环境变量读取不要硬编码在文件里 env_key TAOTOKEN_API_KEY # 协议风格决定工具拼哪条路径 wire_api chatKey 的注入方式二选一即可。方案一是写进 shell 配置文件长期生效# ~/.zshrc 或 ~/.bashrc export TAOTOKEN_API_KEYYOUR_API_KEY # 生效 source ~/.zshrc # 验证是否读到 echo ${TAOTOKEN_API_KEY:0:8}...方案二是临时注入只在当前终端会话里有效适合临时测试TAOTOKEN_API_KEYYOUR_API_KEY codex exec 你好如果你在 Windows 上用 PowerShell环境变量的写法不一样别用export# PowerShell 临时注入 $env:TAOTOKEN_API_KEY YOUR_API_KEY codex exec 你好 # 永久写入用户级环境变量 [Environment]::SetEnvironmentVariable(TAOTOKEN_API_KEY, YOUR_API_KEY, User)配置文件写完之后做一次语法自检。TOML 对格式很敏感少一个引号、多一个空格都会导致整份配置解析失败而这种失败有时候也会表现成网络层面的异常# 用 Python 顺手校验 TOML 语法 python3 -c import tomllib,sys; tomllib.load(open($HOME/.codex/config.toml,rb)); print(config.toml OK)输出config.toml OK说明格式没问题。如果报TOMLDecodeError先修格式别急着测请求。还有几个常见的配置层错误一并列出来对比# 错误 1key 直接写死且字段名不对 api_key sk-xxx # 错误 2把 Claude Code 的变量名搬到 Codex env_key ANTHROPIC_API_KEY # 错误 3base_url 带了版本号 base_url https://taotoken.net/api/v1 # 正确 env_key TAOTOKEN_API_KEY base_url https://taotoken.net/api第 2 条特别值得强调。有些教程为了让配置通用会写「把各家的 Key 都塞进ANTHROPIC_API_KEY」这在 Claude Code 里成立在 Codex 里不成立。Codex 读的是你在env_key里指定的那个变量名名字对不上请求发出去就是 401 或者干脆在你本机就被拦下来跟 404 是完全不同的两类问题。排查的时候先分清是「请求没发出去」「发出去了路径错」「发出去了鉴权错」再对症下药。配置改完、Key 注入完别忘了把之前 export 的错误变量清掉否则新旧配置可能互相干扰# 查看当前所有相关变量 env | grep -Ei TAOTOKEN|OPENAI|ANTHROPIC # 清掉可能冲突的旧变量 unset OPENAI_API_KEY unset OPENAI_BASE_URL尤其是OPENAI_BASE_URL这种变量很多工具会自动读取它一读就把你写在config.toml里的base_url覆盖掉了。这类改对了还是 404的情况十有八九是环境变量的优先级在捣乱。改地址前先在 TaoToken 官网 把 Key 准备好可以少走一段弯路。4. 重试与验证从 404 到 200 的完整记录改完base_url之后我做了一轮完整的重试把每一步的输出都记下来方便你对照判断自己卡在哪一步。第一步只验证连通性让请求尽量短减少变量codex exec 只回复 OK 两个字母成功时的输出大致是这样OK [tokens] input23 output2如果这一步就过了说明地址、Key、模型名三者全对可以直接进入真实任务。如果还是 404回到日志里看url那一行比较它和https://taotoken.net/api/v1/chat/completions的差异。第二步用 curl 独立复现一次把 Codex 从链路里摘出去。这一步的价值是分清问题在配置还是在网络curl -sS -o /tmp/resp.json -w HTTP %{http_code}\n \ -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d { model: deepseek-chat, messages: [{role: user, content: 回复 OK}], max_tokens: 16 }如果 curl 返回HTTP 200而 Codex 还是 404那问题 100% 在config.toml的base_url上跟网络、跟服务端都没关系。如果 curl 也 404把你拼的 URL 和上面的对照一下多半还是路径的问题。第三步看返回体的结构确认响应格式和wire_api匹配{ id: chatcmpl-xxxx, object: chat.completion, choices: [ { index: 0, message: { role: assistant, content: OK }, finish_reason: stop } ], usage: { prompt_tokens: 12, completion_tokens: 2, total_tokens: 14 } }看到object字段是chat.completion就说明服务端返回的是标准 chat 格式wire_api chat是对的选择。如果你把wire_api设成了别的值而服务端返回的是这套结构工具解析时会报别的错虽然不一定是 404但一样会让请求看起来失败。第四步跑一个稍长的真实任务确认多轮对话和长上下文都正常codex exec 写一个 Python 函数输入一个路径返回该目录下所有 .log 文件的总大小单位 MB保留两位小数这一步能同时验证三件事流式输出是否正常、多轮上下文是否保持、Token 计量是否在涨。如果中途断流或者返回空内容那就不是 404 范畴了需要去看是不是超时或者并发限制。我的重试结果汇总成一行对照第一次base_urlhttps://taotoken.net/api/v1 → 404 → url 里出现两个 /v1 第二次base_urlhttps://taotoken.net/api → 200 → url 正常返回 OK只有一行配置的差别结果从 404 变成 200。这也是为什么我一直建议遇到 404 先看 URL不要先动 Key。如果重试时遇到了 401 而不是 404那说明地址已经对了问题转移到了 Key 上。常见原因是 Key 没复制完整、含有首尾空格、或者复制的时候把引号也带进去了。这类问题用一个简单命令就能排掉# 检查 Key 长度和首尾字符 python3 - PY import os k os.environ.get(TAOTOKEN_API_KEY, ) print(length:, len(k)) print(head:, repr(k[:4])) print(tail:, repr(k[-4:])) PY长度明显偏短或者首尾出现多余字符那就要回到控制台重新生成一个。生成入口在 API Keys 页面创建后立刻复制避免中间被编辑器插入不可见字符。5. 还会遇到的 404 变体模型名、端点、环境变量路径拼错是最常见的原因但不是唯一。下面这几类 404 我也都遇到过特征各不相同分开说。变体一模型名写错返回 404 而不是 400。有些网关对不存在的模型直接返回 404而不是「模型不存在」这种业务错误。特征是路径完全正常只有model字段有问题POST https://taotoken.net/api/v1/chat/completions → 404 body{error:{message:model not found}}遇到这种把model换成你在模型列表里实际能用的名字即可。别凭记忆写去 模型对话页 确认一下可选的名称然后填进config.toml的model字段。变体二协议风格和端点不匹配。如果你把wire_api设成了responses而实际调用的是 chat 端点工具会去请求/v1/responses这个路径如果不存在同样返回 404# wire_api 与端点不匹配可能触发 404 wire_api responses判断方法很简单把wire_api改回chat重新请求一次。如果 404 消失说明就是这个问题。变体三环境变量把配置覆盖了。这是最隐蔽的一类。你明明把config.toml改对了但 shell 里残留着OPENAI_BASE_URL工具优先读环境变量于是还是走旧地址# 排查覆盖源 env | grep -Ei BASE_URL|API_KEY # 有冲突就清掉 unset OPENAI_BASE_URL这类问题的特征是改了配置没用重启终端也没用但换一台机器就正常了。只要符合这个特征先查环境变量。变体四多层代理插了一手。如果本机设置了HTTP_PROXY/HTTPS_PROXY请求会先经过代理代理不认识这个路径就返回 404# 临时绕过代理测试 curl --noproxy * -sS -o /dev/null -w HTTP %{http_code}\n \ -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d {model:deepseek-chat,messages:[{role:user,content:hi}]}如果加了--noproxy之后返回 200那就说明是代理的锅去检查代理配置或者把域名加进白名单。把这几类整理成一张排查顺序表顺序检查项命中特征处理动作1请求 URL 是否双层/v1日志里路径重复去掉 base_url 里的/v12模型名是否存在路径正常响应提 model换成实际可用名3wire_api 是否匹配请求打到不存在的端点改回chat4环境变量是否覆盖改配置无效、换机正常unset 冲突变量5代理是否拦截加--noproxy后正常调整代理白名单按这个顺序走绝大多数 404 都能在前两步解决。剩下的三步属于「少见但很烦」遇到了知道往哪查就行。6. 把排查流程固化成 checklist上面这些步骤我把它压缩成一份可以贴在显示器旁边的 checklist。下次再遇到 404从上往下过一遍基本不用思考[ ] 1. 打开 debug 日志找到 url 那一行 [ ] 2. 数一下路径里有几个 /v1超过一个就是 base_url 写多了 [ ] 3. 确认 base_url 只写到 https://taotoken.net/api [ ] 4. 确认 env_key 和实际 export 的变量名一致 [ ] 5. 确认没有 OPENAI_BASE_URL 之类的残留变量 [ ] 6. 用 curl 独立复现确认服务端本身可达 [ ] 7. 确认 model 字段是实际可用的模型名 [ ] 8. 确认 wire_api 与端点风格匹配 [ ] 9. 重试一次最短请求观察状态码这套流程的价值在于把「猜」变成「看」。404 这个状态码本身信息量很低但只要你拿到最终请求 URL它立刻就变成一个非常确定的问题。顺手给一个自动化的自检脚本把最关键的检查项跑一遍#!/usr/bin/env bash set -u CONFIG$HOME/.codex/config.toml echo 1. config.toml 是否存在 [ -f $CONFIG ] echo OK: $CONFIG || { echo FAIL: 缺少 $CONFIG; exit 1; } echo 2. base_url 检查 grep -n base_url $CONFIG || echo WARN: 未找到 base_url if grep -q base_url.*taotoken.net/api/v1 $CONFIG; then echo FAIL: base_url 里带了 /v1会导致路径重复 else echo OK: base_url 未重复版本号 fi echo 3. env_key 与实际变量 KEY_NAME$(grep -oP env_key\s*\s*\K[^] $CONFIG 2/dev/null || echo TAOTOKEN_API_KEY) echo 配置声明的变量名: $KEY_NAME if [ -n ${!KEY_NAME:-} ]; then echo OK: 环境变量已设置长度 ${#!KEY_NAME} 2/dev/null || echo OK: 环境变量已设置 else echo FAIL: 环境变量 $KEY_NAME 未设置 fi echo 4. 是否存在覆盖变量 env | grep -Ei OPENAI_BASE_URL|OPENAI_API_KEY echo WARN: 存在可能覆盖的变量 || echo OK: 无冲突变量 echo 5. 连通性测试 code$(curl -sS -o /dev/null -w %{http_code} \ -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer ${!KEY_NAME:-YOUR_API_KEY} \ -H Content-Type: application/json \ -d {model:deepseek-chat,messages:[{role:user,content:ping}],max_tokens:8}) echo HTTP 状态码: $code case $code in 200) echo PASS: 链路正常 ;; 401) echo FAIL: 鉴权失败检查 Key ;; 404) echo FAIL: 路径错误回到第 2 步 ;; *) echo WARN: 未预期状态码 $code ;; esac存成check-codex.shchmod x之后直接跑。输出会明确告诉你卡在哪一环比来回改配置快得多。有一点要提醒这份脚本只做本机检查和一次最简请求不涉及任何数据库连接、不执行任何来自外部输入的 SQL、不读取生产环境凭据。所有命令都是你在本地手动执行的Key 只从你自己设置的环境变量里读。这个边界要保持住排障归排障别顺手把敏感信息写进脚本。如果你的团队多人共用一套配置建议把config.toml里的base_url和wire_api做成注释模板把易错点直接写进文件里[model_providers.taotoken] name TaoToken # 只写到 /api禁止追加 /v1 base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY # 可选值: chat / responses与端点保持一致 wire_api chat注释写清楚比在群里反复解释省事得多。7. 下一步把稳定链路跑起来404 修好之后链路其实才刚刚可用。真正要关注的是稳定性和成本Codex 在这种「对话式改代码」的场景里Token 消耗是持续累积的一次任务里可能发起几十次请求每一次都带着上下文。所以我一般在跑通之后立刻做两件事。第一件是确认计量。跑几个真实任务观察每次请求的usage字段估算一下日常工作量下的消耗区间# 跑一个真实任务把耗量打出来 codex exec 把当前目录下所有 .py 文件的 TODO 注释汇总成一个 Markdown 表格 21 | tail -n 20第二件是选定计费方式。如果只是偶尔跑一跑按量付费就够如果每天都用 Codex 干重活去看一下 Coding Plan比单次按量更容易控制预算。选择的时候主要看两件事你的日均请求量以及单次请求的平均上下文长度。还有一个小建议把config.toml纳入你的 dotfiles 管理但要把 Key 从文件里彻底剥出去。配置可以进 GitKey 只留在环境变量或者系统钥匙串里。这样换机器的时候复制配置 重新注入 Key 两步就能恢复不会出现「配置文件里有明文密钥被推到远端」这种事故。最后留一个速查清单。下次 Codex 报 404按这个顺序做通常三分钟内能定位看日志 url → 数 /v1 个数 → 改 base_url → 清环境变量 → 重试如果重试之后还是 404把完整 URL 和 curl 的结果一起拿出来对照第 2 节的表格路径问题没有藏得住的。地址通了之后Codex 接 DeepSeek 就跑在一条可复现、可验证的链路上后面无论换模型还是加并发都只是在这条链路上做微调。配置细节如果想再看一遍官方说明可以从 Claude Code 文档 里对照参数含义新建或轮换 Key 在 API Keys想先确认模型名和可用性去 模型对话 试一发最快。入口统一在 TaoToken 官网按「模型对话 → Coding Plan → 创建 Key → 文档」这个顺序走一遍基本就把接入链路建立了。