1. 为什么要在 CC-Switch 里接 DeepSeek 跑 Codex
Codex 这类命令行 AI 编程助手，默认走的是 OpenAI 官方通道，国内网络环境下直接调用经常连不上，或者延迟高到没法用。很多人第一反应是找各种绕行方案，但真正稳定的做法，是把请求转发到国内可直连的大模型服务上，DeepSeek 就是目前性价比最高的选择之一。而 CC-Switch 这个工具，恰好就是干这件事的——它本质上是一个本地路由层，把 Codex 发出的请求拦截下来，按你配置的规则转发到 DeepSeek 的 API 端点上。
这套组合解决的核心问题是：让 Codex 在不改变使用习惯的前提下，用上 DeepSeek 的模型能力。你依然在终端里敲 codex 命令，依然用自然语言描述需求，但背后实际执行推理的是 DeepSeek 的模型。对于日常写代码、改 bug、生成测试用例这些场景，DeepSeek 的表现已经足够能打，而且价格比官方通道便宜一大截。
适合看这篇内容的人有三类：一是已经在用 Codex 但被网络问题折磨的开发者；二是想用 DeepSeek 但不想自己写转发脚本的懒人；三是手里有多个 API Key 需要频繁切换的团队用户。CC-Switch 的账号切换功能在这个场景下特别实用，后面会详细讲。
需要提前说明的是，CC-Switch 本身不提供任何模型服务，它只是一个本地代理和配置管理工具。你需要自己准备 DeepSeek 的 API Key，这个在 DeepSeek 开放平台注册后就能拿到。整个链路是：Codex → CC-Switch 本地路由 → DeepSeek API。理解这个数据流向，后面排查问题会轻松很多。
2. 动手前的环境准备与工具选型
2.1 CC-Switch 的下载渠道与版本选择
CC-Switch 的获取方式有几个渠道，但最稳妥的是走它的官方发布页。网上搜"cc-switch下载"会出来一堆第三方站点，有些捆绑了乱七八糟的东西，不建议从那下。官方渠道通常提供 Windows、macOS、Linux 三个平台的安装包，Linux 下还有 AppImage 和 deb 两种格式。
选版本的时候注意两点：一是优先选最近三个月内有更新的版本，太老的版本可能不支持 DeepSeek 的接口格式；二是看更新日志里有没有提到"local proxy"相关的修复，这个功能直接关系到 Codex 能不能正常走通。我实测下来，0.4.x 之后的版本对 Codex 的兼容性明显好于早期版本。
如果你在 CentOS 7.9 这类老系统上部署，可能会遇到 glibc 版本不够的问题。这种情况建议用 AppImage 格式，它把依赖都打包进去了，对系统库的依赖最小。实在跑不起来的话，可以考虑用 Docker 方式跑，虽然多一层但省心。
2.2 DeepSeek API Key 的获取与权限确认
DeepSeek 的 API Key 在开放平台的控制台里创建，路径一般是"API Keys"→"创建新密钥"。创建的时候会让你选权限范围，建议至少勾选 chat completion 相关的权限，否则 Codex 发过去的请求会被拒。
拿到 Key 之后，格式通常是sk-开头的一长串字符。这里有个坑要注意：DeepSeek 的 Key 和 OpenAI 的 Key 格式很像，但绝对不能混用。网上那些unexpected status 401 unauthorized: incorrect api key provided: sk-svcac****的报错，十有八九就是把 OpenAI 的 Key 填到了 DeepSeek 的配置里，或者反过来。
创建完 Key 之后，建议先在命令行里用 curl 测一下能不能通：
curl https://api.deepseek.com/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-你的key" \ -d '{ "model": "deepseek-chat", "messages": [{"role": "user", "content": "test"}] }'能正常返回 JSON 就说明 Key 没问题，再去配 CC-Switch。这一步能帮你排除掉一半的后续问题。
2.3 Codex 的安装与版本核对
Codex 的安装方式取决于你用的具体是哪个 Codex。如果是 OpenAI 官方的 Codex CLI，通常通过 npm 全局安装：
npm install -g @openai/codex装完之后用codex --version确认版本。这里要注意，不同版本的 Codex 对 API 端点的配置方式可能不一样。有些版本支持通过环境变量OPENAI_BASE_URL来改端点，有些版本则需要在配置文件里改。CC-Switch 的工作原理是接管本地端口，所以理论上不管 Codex 怎么配端点，只要它发 HTTP 请求，CC-Switch 就能拦到。
但实际测试中发现，如果 Codex 版本太新，它可能会对返回的响应格式做严格校验，DeepSeek 的返回格式和 OpenAI 有细微差异，可能导致解析失败。遇到这种情况，要么降级 Codex 版本，要么在 CC-Switch 里开启响应格式转换功能（如果有的话）。
3. CC-Switch 的核心配置与 DeepSeek 渠道接入
3.1 本地路由的工作机制与端口规划
CC-Switch 的核心是一个本地 HTTP 服务，默认监听某个端口（常见的是 3456 或 8080，具体看版本）。Codex 发出的请求先到这个本地端口，CC-Switch 根据配置的规则决定转发到哪个上游。这个设计的好处是，你可以在 CC-Switch 里配多个上游渠道，然后按需切换，Codex 那边完全不用改配置。
端口规划上有个经验：不要用 80 或 443 这种需要 root 权限的端口，也不要用系统服务常用的端口（比如 3306、5432），避免冲突。选一个 3000 以上的高位端口，比如 3456、7890 这种。如果这个端口已经被别的程序占了，CC-Switch 启动时会报错，换个端口就行。
配置本地路由的时候，需要填两个关键信息：监听地址和上游地址。监听地址一般填127.0.0.1就行，只允许本机访问，安全。上游地址填 DeepSeek 的 API 端点，通常是https://api.deepseek.com。有些版本还需要你指定路径前缀，比如/v1，这个要看 CC-Switch 的具体要求。
3.2 DeepSeek 渠道的参数填写与验证
在 CC-Switch 的渠道管理界面里新建一个渠道，类型选 DeepSeek 或者 OpenAI Compatible（取决于版本支持情况）。需要填的参数包括：
| 参数项 | 填写内容 | 说明 |
|---|---|---|
| 渠道名称 | DeepSeek-官方 | 随便起，自己能认出来就行 |
| API 端点 | https://api.deepseek.com | 不要带末尾斜杠 |
| API Key | sk-你的DeepSeek密钥 | 从开放平台复制 |
| 模型名称 | deepseek-chat | 或 deepseek-coder |
| 超时时间 | 60秒 | 太短容易断，太长卡界面 |
填完之后一定要点"测试连接"或类似的验证按钮。如果报 401，检查 Key 有没有复制全，有没有多余空格。如果报 404，检查端点地址是不是写错了。如果报超时，检查网络能不能通到 api.deepseek.com。
验证通过后，把这个渠道设为默认，或者在 Codex 的请求里指定用这个渠道。有些版本的 CC-Switch 支持按模型名路由，比如请求里 model 是deepseek-chat就走 DeepSeek 渠道，是gpt-4就走 OpenAI 渠道，这个功能在多模型混用时很方便。
3.3 Codex 端的端点指向与配置同步
Codex 这边需要把 API 端点指向 CC-Switch 的本地地址。如果是通过环境变量配置的，大概是这样：
export OPENAI_BASE_URL=http://127.0.0.1:3456/v1 export OPENAI_API_KEY=随便填一个占位符注意这里的 API Key 填什么都行，因为实际鉴权是 CC-Switch 拿你配的 DeepSeek Key 去做的。但有些 Codex 版本会检查 Key 的格式，那就填一个sk-开头的假 Key。
如果 Codex 是通过配置文件管理的，找到对应的配置文件（通常在~/.codex/config.json或类似路径），把baseURL改成 CC-Switch 的地址。改完之后重启 Codex，让它重新加载配置。
这里有个细节：CC-Switch 必须先启动，Codex 后启动。如果顺序反了，Codex 启动时连不上本地端点，可能会缓存一个失败状态，后面即使 CC-Switch 起来了它也不重试。遇到这种情况，重启 Codex 就行。
4. 完整实操流程与关键环节记录
4.1 从零开始的安装与启动顺序
整个流程按顺序走下来是这样的：
- 下载 CC-Switch 安装包，安装到本地。Windows 下双击 exe，macOS 下拖进 Applications，Linux 下
chmod +x后直接运行。 - 启动 CC-Switch，确认托盘区或进程列表里有它的身影。首次启动可能会让你选配置目录，默认的就行。
- 打开 CC-Switch 的配置界面（通常是浏览器访问
http://127.0.0.1:3456或者它自带的 GUI）。 - 新建 DeepSeek 渠道，填入 API Key 和端点，测试连接通过。
- 把 DeepSeek 渠道设为默认路由。
- 确认 CC-Switch 的监听端口，比如 3456。
- 配置 Codex 的
OPENAI_BASE_URL指向http://127.0.0.1:3456/v1。 - 启动 Codex，发一条测试消息，看能不能正常返回。
这个顺序里最容易出问题的是第 4 步和第 7 步。第 4 步的测试连接如果失败，后面全白搭。第 7 步如果地址写错，Codex 会直接报连不上。
4.2 验证链路是否走通的三种方法
方法一：看 CC-Switch 的日志。正常转发的时候，日志里会有请求记录，包括请求时间、目标渠道、响应状态码。如果日志里空空如也，说明 Codex 的请求根本没到 CC-Switch，检查端点配置。
方法二：在 Codex 里发一条消息，看返回内容。如果返回的是 DeepSeek 风格的回复（比如某些特定的措辞习惯），说明走通了。如果返回的是 OpenAI 的回复，说明路由配错了。
方法三：用 curl 直接打 CC-Switch 的本地端点：
curl http://127.0.0.1:3456/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"deepseek-chat","messages":[{"role":"user","content":"hi"}]}'如果能返回正常 JSON，说明 CC-Switch 到 DeepSeek 这一段是通的，问题在 Codex 到 CC-Switch 这一段。
4.3 多账号切换与上下文保持的实操
CC-Switch 的账号切换功能是它的卖点之一。你可以在里面配多个 DeepSeek 账号（或者多个 API Key），然后一键切换。切换的时候，Codex 那边不用做任何改动，因为端点始终是本地地址。
但这里有个已知问题：切换账号后，之前对话的上下文可能加载不出来。这不是 CC-Switch 的 bug，而是因为不同账号对应的会话存储是隔离的。Codex 的上下文通常存在本地，但有些实现会把会话 ID 和 API Key 绑定，切换 Key 之后旧会话就找不到了。
解决办法有两个：一是切换账号前先导出当前会话，切换后再导入；二是用 CC-Switch 的"会话保持"功能（如果有的话），它会把会话 ID 映射到新的 Key 上。实测下来，第一种方法更可靠，虽然麻烦点但不会丢数据。
5. 常见报错排查与避坑经验
5.1 401 报错的五种可能原因
unexpected status 401 unauthorized: incorrect api key provided这个报错出现频率最高，原因可能有：
- Key 复制的时候带了空格或换行，尤其是从网页复制的时候容易多复制一个换行符。
- Key 已经过期或被撤销，去 DeepSeek 控制台确认一下状态。
- Key 的权限不够，没有 chat completion 权限。
- 把 OpenAI 的 Key 填到了 DeepSeek 渠道里，或者反过来。
- CC-Switch 的配置文件里 Key 字段名写错了，比如写成了
api_key但实际要求apiKey。
排查的时候按这个顺序来：先确认 Key 本身能用（用 curl 测），再确认 CC-Switch 里填对了，最后确认 Codex 发的请求带上了正确的鉴权头。
5.2 本地代理失败的典型场景
cc switch local proxy failed while handling codex endpoint /responses这个报错说明 CC-Switch 收到了请求但处理不了。常见原因：
- Codex 发的请求路径是
/responses，但 CC-Switch 只配了/v1/chat/completions的路由。需要在 CC-Switch 里加一条路径映射规则。 - 请求体格式不兼容，Codex 用的可能是 OpenAI 的新版 API 格式，DeepSeek 不支持。需要在 CC-Switch 里开启格式转换。
- CC-Switch 的版本太老，不认识 Codex 发的某些字段。升级到最新版试试。
这个问题的根源在于 Codex 和 DeepSeek 的 API 规范有差异，CC-Switch 作为中间层需要做适配。如果 CC-Switch 的适配功能不够，可以考虑在它前面再加一层转换工具，但那样链路就太长了，不如直接换个支持更好的工具。
5.3 连接超时与响应缓慢的优化
如果请求能通但特别慢，先确认是不是 DeepSeek 服务端的问题（用 curl 直接测 DeepSeek 的响应时间）。如果 DeepSeek 本身快，但走 CC-Switch 就慢，可能是 CC-Switch 的缓冲或日志拖慢了速度。在设置里把日志级别调到 warn 或 error，减少 IO 开销。
另一个可能是 Codex 的超时设置太短，请求还没返回它就断了。把 Codex 的超时时间调到 120 秒以上，给 DeepSeek 足够的推理时间。DeepSeek 的模型在生成长代码的时候确实需要点时间，尤其是 deepseek-coder 这种专门优化过的模型。
5.4 常见问题速查表
| 报错信息 | 可能原因 | 解决方向 |
|---|---|---|
| 401 unauthorized | Key 错误或权限不足 | 检查 Key 格式和权限 |
| 404 not found | 端点地址写错 | 确认 API 端点路径 |
| local proxy failed | 路径映射缺失 | 添加 /responses 路由 |
| connection timeout | 网络不通或超时太短 | 检查网络，调大超时 |
| model not found | 模型名写错 | 确认 DeepSeek 支持的模型名 |
| context load failed | 切换账号导致会话隔离 | 导出导入会话或保持会话 |
6. 进阶用法与个人实操体会
6.1 多模型混用的路由策略
CC-Switch 支持配多个渠道，然后按规则路由。一个实用的策略是：日常对话用 deepseek-chat（便宜），代码生成用 deepseek-coder（专精），复杂推理用 deepseek-reasoner（如果可用）。在 CC-Switch 里配三条规则，按请求里的 model 字段分流。
这样做的成本优势很明显。deepseek-chat 的价格比官方通道低一个数量级，deepseek-coder 虽然贵一点但比 GPT-4 还是便宜很多。对于每天要跑几百次请求的开发者来说，一个月能省下不少。
6.2 本地部署 DeepSeek 的对接可能
如果你在 Jetson Orin 或者带显卡的机器上本地部署了 DeepSeek（比如用 vLLM 跑的），CC-Switch 也可以对接。把上游地址改成http://localhost:8000/v1（vLLM 的默认端口），模型名改成你部署的模型名，其他配置一样。
本地部署的好处是数据不出内网，适合对隐私要求高的场景。坏处是需要自己维护推理服务，显存不够的时候会 OOM。Jetson Orin 上跑 DeepSeek 的小模型还行，大模型就吃力了。
6.3 我踩过的几个坑
第一个坑是 Key 的复制。DeepSeek 控制台的 Key 显示区域有个"复制"按钮，但有时候复制出来会带一个不可见字符，粘到 CC-Switch 里就报 401。后来我都是手动选中复制，或者复制到记事本里过一遍再粘。
第二个坑是端口冲突。有次 CC-Switch 启动后 Codex 一直连不上，查了半天发现 3456 端口被另一个程序占了。CC-Switch 居然没报错，只是静默地没启动监听。后来养成习惯，启动后先用netstat确认端口在监听。
第三个坑是版本不匹配。CC-Switch 升级到新版后，旧版的配置文件格式变了，导致渠道全部失效。升级前一定要备份配置，或者看清楚更新日志里的 breaking changes。
6.4 关于 CC-Switch 能否用于 Cursor 的说明
有人问 CC-Switch 能不能给 Cursor 用。理论上可以，因为 Cursor 也是发 HTTP 请求到 API 端点。但 Cursor 的配置入口比较深，而且它对返回格式的要求比 Codex 更严格。实测下来，Codex 的兼容性更好，Cursor 需要额外做格式适配。如果主要用 Cursor，建议找专门为 Cursor 设计的转发工具，省得折腾。
这套方案我用了几个月，整体稳定性不错。DeepSeek 的响应速度在可接受范围内，CC-Switch 的切换功能确实省事。唯一需要注意的是，DeepSeek 的 API 偶尔会有波动，遇到 503 的时候等几分钟重试就行，不用改配置。