Codex 接 DeepSeek-v4 报 404从协议错配到 CC Switch 路由的完整排障Codex 桌面端发起的 Agent 请求默认走/v1/responses协议而 DeepSeek-v4 对外只暴露/v1/chat/completions标准对话接口。两者协议不兼容请求打到上游自然返回 404。本文围绕这个报错把 ccx 协议转换、cc-switch 路由配置、TaoToken 统一通道接入串成一条可复制的排障路径。如果你正在用 Codex DeepSeek-v4 组合并且 cc-switch 里已经填了供应商却仍然 404这篇可以直接对照排查。TaoToken 官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end一、原问题与场景404 到底卡在哪一层先还原一下典型现场。你在 Codex 桌面端配置了自定义 providerwire_api responsesbase_url指向本地 ccx 代理的http://localhost:3000/v1模型写deepseek-v4-pro。重启 Codex 后发一条测试消息ccx 后台能看到请求进来了但很快返回 404Codex 侧提示模型不可用或请求失败。这个 404 不是单一原因造成的它可能出现在三个位置第一层ccx 上游渠道的服务类型没选对。ccx 添加 DeepSeek 渠道时如果 Service type 停留在默认的 Responses 或 OpenAI 原生模式ccx 就不会把 Codex 发来的 Responses 请求翻译成 Chat 请求而是原样转发/v1/responses到 DeepSeekDeepSeek 没有这个端点直接 404。第二层BaseURL 填错。DeepSeek 官方地址是https://api.deepseek.com本地 ccx 代理地址是http://localhost:3000/v1。这两个地址在 ccx 后台和 cc-switch 里各出现一次职责完全不同。ccx 后台的 Base URL 应该填 DeepSeek 官方地址或 TaoToken 通道地址cc-switch 里的 API 基础地址应该填本地 ccx 地址。一旦把 DeepSeek 官方地址填进 cc-switchCodex 就会绕过 ccx 直接请求 DeepSeek 的/v1/responses404 必现。第三层密钥混淆。ccx 的.env里有一个PROXY_ACCESS_KEY这是本地代理的访问密码用于 cc-switch 和 ccx Web 后台登录。DeepSeek 官方有一个sk-开头的 API Key用于 ccx 向上游发起请求。cc-switch 里填的应该是PROXY_ACCESS_KEY不是 DeepSeek 的 sk 密钥。填反了ccx 会拒绝本地请求或者 ccx 拿着错误的密钥去请求上游同样触发 404 或 401。理解了这三层排障就有了方向。本文的做法是把上游通道统一收敛到 TaoTokenccx 只负责协议转换cc-switch 只负责本地路由密钥和地址各归其位。二、TaoToken 前置统一 Base URL 与 Key在开始改配置之前先拿到 TaoToken 的 API Key。打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册后在控制台创建 Key。这个 Key 的作用是替代原来直接填 DeepSeek 官方sk-密钥的位置让 ccx 的上游请求统一走 TaoToken 通道。为什么建议把上游从 DeepSeek 官方地址切到 TaoToken原因有两个。一是地址统一TaoToken 的 API 地址是https://taotoken.net/apiccx 后台的 Base URL 填这一个就行不用在 DeepSeek 官方地址和本地代理地址之间反复切换减少填错概率。二是密钥统一ccx 上游渠道的 API Key 填 TaoToken Keycc-switch 里填本地PROXY_ACCESS_KEY两个密钥职责清晰不会再出现把 DeepSeek sk 密钥填到 cc-switch 的情况。需要明确的是TaoToken 在这里只提供统一的 Base URL 和 Key不负责协议转换。Codex 的 Responses 请求到 Chat 请求的翻译仍然由 ccx 完成。ccx 的角色不变只是上游目标从 DeepSeek 官方换成了 TaoToken 通道。如果你还没有创建 Key可以先去控制台操作https://taotoken.net/console 。创建完成后Key 只在创建时完整显示一次记得保存。三、可复制配置ccx 与 cc-switch 分工填写这一节给出完整的配置步骤按顺序操作即可。3.1 ccx 侧协议转换层ccx 的.env文件保持原样重点是PROXY_ACCESS_KEY和PORTPROXY_ACCESS_KEY123456 PORT3000 ENABLE_WEB_UItrue APP_UI_LANGUAGEen启动 ccx 后浏览器打开http://localhost:3000用PROXY_ACCESS_KEY登录。进入 Codex 分类添加新渠道Channel nameDeepSeek V4 ProService typeOpenAI Chat必须选这个不能选 ResponsesBase URLhttps://taotoken.net/apiAPI key你的 TaoToken Key保存前确认两点服务类型是 OpenAI Chat规范化非常见 Chat role 已开启。这两项决定了 ccx 是否会把 Codex 的 Responses 请求拆解成/v1/chat/completions发给上游。3.2 cc-switch 侧本地路由层打开 CC-Switch切到 Codex 面板新增或修改供应商供应商名称DeepSeekAPI 基础地址http://localhost:3000/v1API Key123456即.env里的PROXY_ACCESS_KEY不是 TaoToken Key也不是 DeepSeek sk 密钥点击获取模型列表选中deepseek-v4-pro作为默认模型保存并启用。3.3 Codex 侧兜底配置如果 cc-switch 自动写入不生效手动改C:\Users\你的用户名\.codex\config.tomlmodel_provider deepseek model deepseek-v4-pro model_reasoning_effort high disable_response_storage true [model_providers.deepseek] name deepseek wire_api responses requires_openai_auth true base_url http://localhost:3000/v1注意wire_api仍然是responses因为 Codex 对 ccx 说话用的是 Responses 协议ccx 再对上游说 Chat 协议。这个转换关系不能颠倒。四、验证请求与成功结果配置完成后重启 Codex 桌面端发一条测试消息。验证要看两个地方。第一ccx 后台的请求记录。成功的情况下你能看到一条新的请求记录目标模型显示deepseek-v4-pro输入和输出 Token 有统计请求状态不是 404。如果 ccx 后台完全没有记录说明 Codex 的请求根本没到 ccx检查 cc-switch 是否启用、base_url是否指向http://localhost:3000/v1。第二Codex 侧的回复。如果模型正常返回内容说明整条链路通了Codex 发 Responses 请求到 ccxccx 转成 Chat 请求发到 TaoToken 通道TaoToken 转发到 DeepSeek-v4返回结果再原路封装回 Responses 格式给 Codex。如果 ccx 后台有记录但状态是 404重点看请求的目标地址。ccx 日志里会显示它向上游请求的完整 URL。如果 URL 里出现https://api.deepseek.com/v1/responses说明 ccx 渠道的服务类型没选 OpenAI Chat协议转换没生效。如果 URL 是https://taotoken.net/api/v1/chat/completions但仍然 404检查 TaoToken Key 是否有效、模型 ID 是否拼写正确。五、本篇常见错排查围绕 Codex 接 DeepSeek-v4 的 404下面这几类错误出现频率最高。服务类型选错。ccx 添加渠道时Service type 必须选 OpenAI Chat。选成 Responses 或 OpenAI 原生ccx 不会做协议降级直接把/v1/responses转发给上游DeepSeek 没有这个端点404。这是最常见的原因改一个下拉框就能解决。BaseURL 混淆。记住两个地址的归属ccx 后台的 Base URL 填上游地址即https://taotoken.net/apicc-switch 里的 API 基础地址填本地代理地址即http://localhost:3000/v1。把 DeepSeek 官方地址https://api.deepseek.com填进 cc-switchCodex 就会绕过 ccx 直连 DeepSeek404 必现。密钥混淆。cc-switch 里填的是PROXY_ACCESS_KEY用于访问本地 ccx。ccx 后台渠道里填的是 TaoToken Key用于访问上游。DeepSeek 官方的sk-密钥在这套配置里不再直接使用。三个密钥各司其职填错位置就会导致 401 或 404。端口占用。ccx 默认监听 3000 端口。如果本机其他程序占用了 3000ccx 启动会失败或监听不到请求。改.env里的PORT参数同时同步修改 cc-switch 里的 API 基础地址端口号。未开启规范化 role。Codex 发出的请求里可能包含自定义 roleDeepSeek 的 Chat 接口对 role 有严格校验。ccx 渠道设置里开启「规范化非常见 Chat role」后ccx 会在转发前把 role 标准化避免上游拒绝。模型 ID 不一致。cc-switch 里选的模型、Codexconfig.toml里的model、ccx 渠道里配置的模型重定向三处要一致。任何一处写成deepseek-v4或deepseek-chat都可能导致上游找不到模型而返回 404。六、语义一致 CTA排障完成后如果你需要管理 TaoToken 的 Key、查看接入文档或调整通道配置可以从这几个入口进入创建和管理 API Keyhttps://taotoken.net/api-keys接入文档与配置说明https://taotoken.net/doc模型对话测试https://taotoken.net/model-chat长期编码与 Agent 场景https://taotoken.net/coding-planCodex 接 DeepSeek-v4 的核心矛盾是协议不兼容ccx 负责翻译cc-switch 负责路由TaoToken 负责提供统一的上游 Base URL 和 Key。三者分工明确404 的排查也就有了清晰的路径先看 ccx 渠道服务类型再看两个 BaseURL 是否填反最后核对密钥归属。按这个顺序走一遍大部分 404 都能定位到具体那一行配置。