企业官网建设流程全解析

我的 Codex CLI 在 Windows 上用起来最大的问题不是不会装，而是装好之后不知道把请求往哪里发。后来在 CC Switch 里把 DeepSeek API 接进去，顺便解决了切换模型和保存 API Key 的麻烦。这篇文章不是为了复述官方 README，而是把我实际在 Windows 11 上把 Codex CLI、CC Switch 和 DeepSeek API 串联起来，并且稳定跑了半个月的配置过程、踩坑经历和排查方法整理出来。如果你也想在 Windows 终端里用 Codex CLI 驱动 DeepSeek，这篇文章应该能帮你省掉至少一个晚上的 debug 时间。

1. 把三样东西串起来之前，先搞懂它们的分工

1.1 Codex CLI 的模型来源并不只有官方

Codex CLI 是 OpenAI 开源的终端编程助手，很多人默认它只能连 OpenAI 官方模型，其实并不对。它从设计上就留了自定义模型提供方的入口，你可以通过model_providers字段注册任意兼容接口，然后指定model和model_provider，让它把请求发到第三方服务上。官方文档管这个叫 bring your own model，本质上就是允许你在~/.codex/config.toml里配置一个 base URL、一个鉴权方式、一个请求协议，然后按你自己的模型名去跑。

这个机制给国内用户最直接的用途，就是把 Codex CLI 接到 DeepSeek API 上。DeepSeek 的接口和 OpenAI 高度兼容，只需要注意协议差异，后面我会重点讲。就算你没有 CC Switch，手动改config.toml也能接上，但问题是日常使用中你不可能只用一个模型。今天想用 DeepSeek 写代码，明天想切回官方账号，每次手动改文件、改环境变量，不仅容易出错，还会把官方登录状态搞乱。这才是我觉得 CC Switch 有价值的原因：它把“切换供应商”这件事做成了界面上的一个按钮或一次点击。

1.2 CC Switch 到底管了什么

CC Switch 是一个第三方配置切换工具，最早很多人在 Claude Code 场景下用它切换不同的服务商，后面也支持了 Codex CLI。它在 Windows 上主要有两种工作方式。

第一种是直接改写配置文件，也就是替你编辑~/.codex/config.toml，把当前选中的模型提供方写进去。这种方式简单直观，缺点是你每切一次，配置文件就变一次，如果中途又手工改过配置，容易互相覆盖。第二种是“本地网关”模式，也就是你在错误日志里常看到的那句 local proxy。CC Switch 会在本机启动一个监听端口的服务，比如127.0.0.1:15739，然后固定把这个地址写成 Codex CLI 的 base URL。Codex CLI 发出的所有请求先到本地网关，再由网关按照你当前选中的供应商配置转发到 DeepSeek 或其它目标。

我推荐理解第二种方式，因为你在 windows 上遇到的所谓 unexpected status 401、404、502、503，绝大多数都是在本地网关这一环出的问题。比如 CC Switch 进程没起来、端口被占用、网关拿到的 API Key 是空的，或者网关把请求转发到了不对的路径。理解了本地网关的位置，排查范围一下就缩小了。另外，网关模式下切换模型不需要反复改 Codex 的配置文件，Codex 一直在和本地网关说话，网关再去背后调不同的上游。

1.3 DeepSeek API 的兼容层与两个必须记牢的端点差异

DeepSeek API 提供的是 OpenAI 兼容接口，这一点意味着很大的便利：你不需要给 Codex CLI 装额外的 SDK，只要把 base URL 指过去，再用一个 Bearer Token 做鉴权，它就能认出请求结构。但兼容不等于 100% 相同，最大的差异在端点上。

OpenAI 官方的 Codex CLI 默认走的是 Responses API，也就是请求会发到/responses。而 DeepSeek 公开的兼容接口走的是 Chat Completions，也就是/chat/completions。这两个端点虽然都能实现多轮对话，但请求体格式存在差异。如果没有在 Codex 配置里指定wire_api，它默认会按 Responses 协议去发，DeepSeek 那边自然返回 404 或者直接让本地网关报 local proxy failed。

所以在配置里的关键动作，就是把wire_api设为chat，并确保 base URL 拼接出来的最终路径能正确打到 DeepSeek 的/chat/completions上。这一点记住之后，后面所有报错都会好理解很多。DeepSeek 平台目前主推的模型名是deepseek-chat和deepseek-reasoner，前者适合日常代码生成，后者适合复杂推理。两者都走同一个兼容端点，只是模型名不同。

2. Windows 端的安装与准备

2.1 安装 Node.js 与 Codex CLI

Codex CLI 官方以 npm 包分发，Windows 上第一步是先装 Node.js。我建议装 LTS 版本，不要追最新，因为一些 npm 原生模块的预编译二进制在最新版 Node 上可能还没跟上。安装时选默认设置，记得确认Add to PATH被打勾。装完后打开新的 PowerShell，执行node -v和npm -v，能正常输出版本号就说明环境没问题。

然后全局安装 Codex CLI，命令很简单：

npm install -g @openai/codex

装完后执行codex --version。如果提示找不到命令，先执行npm config get prefix，返回的目录就是 npm 全局可执行文件的安装目录。一般 Windows 下是C:\Users\你的用户名\AppData\Roaming\npm，你需要把它加到当前用户的环境变量 PATH 里。这步绕过去，就会出现搜索热词里那个unable to locate the codex cli binary or required runtime components。这不是 Codex 本身坏了，通常是系统没有找到codex.exe的位置。加完 PATH 后重新开一个终端窗口再试。

如果你所在网络环境拉 npm 包很慢，可以先把 npm 源切到国内镜像：

npm config set registry https://registry.npmmirror.com

这只是让下载更快，不影响后续 Codex CLI 登录或请求路径，因为这个镜像只干预 npm 包下载，和 Codex 运行时请求无关。

2.2 装 CC Switch：安装版还是便携版

CC Switch 在 Windows 上有安装版和便携版两种。安装版会写入系统级的配置，可能在启动时弹 UAC，适合希望开机自启的人。便携版是解压后直接运行.exe，不写注册表，升级时直接替换文件夹，适合像我这种喜欢保留一份绿色工具的人。第一次尝试建议用便携版，因为遇到问题要回退版本，直接删文件夹就行，不会留残余。

我自己的习惯是放到D:\Tools\CCSwitch，不让它躺在系统盘里。运行后会有一个主界面，左侧列出支持的应用，比如 Codex、Claude Code 等。第一次打开时 Windows Defender 有概率弹出风险提示。原因很简单，这类工具要读写用户目录下的配置文件，运行行为容易被安全软件误判。只要你是从 GitHub Releases 官方渠道下载的，校验过大小时就可以放心用。实在不放心可以单独做一次杀毒扫描，或者加白名单，不建议跑到不知名下载站找所谓“绿色版”。

2.3 准备 DeepSeek API Key 并用 curl 验证上游

在 DeepSeek 开放平台创建 API Key，复制以sk-开头的那串字符串。第一次使用 DeepSeek 的 API 一般需要先在账户里充值，因为 API 调用是按 token 计费的。虽然代码生成量不大时费用很低，但余额为零的时候调用会直接失败，这也是一会儿排查报错时要先确认的项。

拿到 Key 后，最好先绕过 Codex CLI 和 CC Switch，直接验证 DeepSeek 上游是否正常。在 PowerShell 里执行：

curl.exe -X POST https://api.deepseek.com/chat/completions ` -H "Content-Type: application/json" ` -H "Authorization: Bearer sk-你的APIKey" ` -d '{\"model\":\"deepseek-chat\",\"messages\":[{\"role\":\"user\",\"content\":\"hi\"}],\"max_tokens\":20}'

注意这里要用curl.exe而不是 PowerShell 里默认的curl别名，否则参数解析方式不一样。如果上游正常，会返回一段 JSON，里面有choices、usage这些字段。万一这里就报 401，说明 Key 本身有问题或者账户状态异常，赶紧先去控制台核对，不要继续折腾后面的配置。这一步非常重要，它能帮你把问题牢牢锁定在“上游”还是“本地配置”，后面排查 401 时可以节省非常多时间。

3. 配置阶段：让 Codex CLI 的请求真正抵达 DeepSeek

3.1 在 CC Switch 里添加 DeepSeek 并开启本地网关

打开 CC Switch 主界面，找到 Codex 应用相关的设置项，进入供应商或模型管理。新建一个供应商配置，名称可以叫 DeepSeek，Base URL 填https://api.deepseek.com，API Key 填刚才复制的密钥。有些版本里还需要你填一个默认模型名，这里填deepseek-chat就好。

接下来是重点：把当前 Codex 使用的供应商切到 DeepSeek，并开启本地网关模式。不同版本的 CC Switch 按钮位置不太一样，有的叫“开启本地代理”，有的叫“使用 Local Proxy”，但核心表现是一致的：CC Switch 会告诉你一个本地监听地址，通常是127.0.0.1:15739。开启后，CC Switch 会在后台启动一个 HTTP 服务，Codex 的请求会先到这个地址。

这里有必要提醒一下 Windows 防火墙。第一次网关启动时，防火墙通常弹窗问要不要允许node.exe或 CC Switch 进程对外监听。如果你点了取消，后面本地网关端口处于半死不活的状态，请求就会失败。保险起见，可以先去防火墙里把 TCP 入站规则中对应端口或程序放行。这一步做完，再继续下面的配置文件修正。

3.2 config.toml 手工修正：model_provider、base_url、wire_api 的含义

虽然 CC Switch 会尝试自动改写 Codex 配置，但为了排查稳定，我建议手动打开%USERPROFILE%\.codex\config.toml检查一遍。没有这个文件的话可以先创建一个，注意.codex这个目录默认是隐藏的，在资源管理器地址栏直接输入路径最省事。

一个能跑通的配置长这样：

model = "deepseek-chat" model_provider = "deepseek" [model_providers.deepseek] name = "DeepSeek" base_url = "http://127.0.0.1:15739/v1" env_key = "DEEPSEEK_API_KEY" wire_api = "chat"

逐行解释一下。model就是当前会话使用的模型名，deepseek-chat已经够用；如果要用深度推理，可以临时改成deepseek-reasoner。model_provider必须和下方[model_providers.deepseek]里的键名一致，Codex 就是通过这个关联关系知道该去哪找配置。

base_url这一项，最容易被误解。如果你不通过 CC Switch，可以直接写https://api.deepseek.com/v1；但如果你已经在 CC Switch 里开了本地网关，就应该写http://127.0.0.1:15739/v1。注意是/v1，不是裸域名，因为 Codex CLI 会根据wire_api在 base URL 后面拼接路径。当wire_api = "chat"时，最终请求会是http://127.0.0.1:15739/v1/chat/completions。DeepSeek 官方地址兼容这个路径格式。

env_key是告诉 Codex：读取环境变量DEEPSEEK_API_KEY作为鉴权凭证。这样 API Key 不会直接明文写在配置文件里，减少误操作提交到公开仓库的风险。wire_api = "chat"是整条链路上最关键的字段，它把协议切到 Chat Completions，避开 OpenAI Responses API 的不兼容问题。

设置环境变量的方法，在 PowerShell 里执行：

setx DEEPSEEK_API_KEY "sk-你的APIKey"

setx写入的是用户级环境变量，之后新开的终端窗口自动生效。已经打开的 PowerShell 窗口不会自动刷新，要重新打开一个。

3.3 端到端验证与常见检查命令

配置完之后，先不要急着跑 Codex，验证本地网关是否正常。最直接的办法是请求网关的模型列表，看看 CC Switch 有没有把 DeepSeek 的模型暴露出来：

curl.exe http://127.0.0.1:15739/v1/models

如果网关正常，会返回一个包含deepseek-chat的 JSON 列表。如果这里就连接失败，先回到第 2 章检查防火墙和端口监听。如果这里返回列表但 Codex 依然报错，再往后走。

然后运行一次最简单的 Codex 指令：

codex exec "用 Python 写一个快速排序"

第一次调用会读取配置和环境变量，然后向网关发请求。能正常返回结果，说明整条链路已经通了。如果没有，就进入下面的排查章节。

4. 高频报错排查：从 401 到 502，每一条都对应一个真实坑

4.1 本地网关没起来：端口占用与二进制找不到

很多人看到cc switch local proxy failed while handling codex endpoint /responses就直接以为是 Codex 或 CC Switch 的 bug。实际上这个报错的前半段已经告诉我们：消息到本地网关这一步了，但网关注入失败或转发失败。所以先确认网关到底有没有在监听。

检查端口：

netstat -ano | findstr 15739

如果有输出，说明有进程监听，记录下 PID，然后用：

tasklist | findstr 你的PID

看看是不是 CC Switch 或它调用的 node 进程。如果没有输出，多半是 CC Switch 的本地网关没有成功启动。重新启动 CC Switch，切换到 DeepSeek 供应商一次，再执行netstat看端口有没有起来。

端口被占用的情况我也遇到过。之前电脑上有一个别的工具占用了15739，CC Switch 起不来。解决方法是进入 CC Switch 设置里改一个端口，比如改成15740，然后同步修改config.toml里base_url的端口号。很多人只改了 CC Switch 的设置，忘了改 Codex 配置，结果 Codex 还在往旧端口发请求，报错依然存在。

如果你遇到的是unable to locate the codex cli binary or required runtime components，那和网关无关，是 Codex CLI 自身安装不完整或不在 PATH。重新执行一次npm install -g @openai/codex，然后确认npm config get prefix目录在环境变量里。两个问题别混在一起看，能减少不少弯路。

4.2 401 鉴权失败：密钥注入链路

unexpected status 401 unauthorized看起来是鉴权失败，但你得先分清楚这 401 是从哪里返回的。我见过两种情况。

第一种，上游 DeepSeek 返回 401。这种最好定位，直接用第 2.3 节的 curl 命令测上游，如果也返回 401，就是 Key 不对、账户欠费，或者平台侧的权限异常。去控制台重新创建 Key，确认账户有余额，再测试。

第二种，本地网关返回 401。这种情况直接 curl 上游可能正常，但 CC Switch 网关转发时没有正确注入鉴权头。检查 CC Switch 里的 DeepSeek 配置，看 API Key 字段是否真的保存了，有些版本在切换供应商时会丢失 Key 内容。还要检查config.toml里的env_key是否和你 PowerShell 里设置的环境变量名字完全一致，大小写也要一致。Codex CLI 读取环境变量的逻辑很严格，变量名写错一个字母都会导致空凭证。

之前我遇到一个很隐蔽的问题：我先用setx设置了DEEPSEEK_API_KEY，但环境变量里还残留了一个空的同名变量，优先级把正确值覆盖了。排查时清掉系统里的旧变量，重新打开终端才正常。建议在 PowerShell 里执行echo $env:DEEPSEEK_API_KEY确认当前终端的变量值是否包含sk-前缀。

4.3 404 与 /responses 端点不兼容：wire_api 才是关键

搜索热词里频繁出现cc switch local proxy failed while handling codex endpoint /responses，这基本就是 wire_api 设置不对。默认情况下 Codex CLI 倾向于使用/responses端点，而 DeepSeek 并没有提供这个端点，于是本地网关把请求转给 DeepSeek 时，上游返回 404，网关再把 404 包成自己的错误。

解决方式就是打开config.toml，确认已经写入：

wire_api = "chat"

改完之后，重启 Codex CLI，而不是只关掉对话框。因为 Codex 进程一旦启动，配置可能已经被进程加载到内存，旧请求还是会打到/responses。我建议改完配置后，把终端窗口也一并关闭重开，确保干净。

另一种 404 是模型名写错。比如在model里填了gpt-4o一类 OpenAI 模型名，DeepSeek 平台不认这个模型，也会返回 404。一定要用 DeepSeek 平台实际的模型名，如deepseek-chat或deepseek-reasoner。这个字段在 CC Switch 里配置时也要保持一致，因为本地网关会按模型名做路由。

4.4 502/503 网关报错与对话闪跳的处理

502 Bad Gateway和503 Service Unavailable都是网关层面的错误。502 通常表示本地网关已经收到了 Codex 的请求，但向上游 DeepSeek 请求时失败，比如上游连接超时、返回了不可解析的内容，或者 DeepSeek 接口临时抖动。503 则更像是上游明确拒绝服务，通常是限流或服务过载。

碰到这两类问题，我建议先做个快速拆解：直接 curl DeepSeek 的/chat/completions，看上游本身是否可用。如果上游也异常，那就不是你的配置问题，等平台恢复即可。如果上游正常，但通过网关就 502，试着在 CC Switch 里关闭网关再重新开启，有时候是网关内部的长连接缓存坏了，重启能解决。

“切换模型后原对话不停跳闪”这个现象，我在 Windows 上遇到过，很让人烦躁。原因是 Codex CLI 的会话上下文还保留着旧模型的请求记录，而 CC Switch 切换供应商后，旧会话里的消息可能仍在尝试访问旧的 endpoint，导致 Codex 不断重试、状态反复刷新。遇到这种情况，不要继续在旧会话里挣扎，直接退出 Codex，删除对应的会话记录，再开一个全新会话。Codex 的会话文件一般在%USERPROFILE%\.codex\sessions目录下，按时间戳存放。删除前先确认没有重要内容，或者把整个 sessions 目录复制一份备份再操作。

5. 长期使用经验：备份、更新、切换官方账号的注意事项

5.1 CC Switch 与官方账号其实不冲突，但配置会互相覆盖

很多人在用 CC Switch 接第三方 API 时会担心：会不会和官方登录账号冲突？我自己的体验是，它们不直接冲突，但配置文件确实会被互相覆盖。

Codex CLI 的官方账号登录信息存在auth.json，用于和 OpenAI 的服务鉴权；而 CC Switch 主要改的是config.toml，也就是模型提供方的配置。正常情况下两者各管各的。但当你切换回 OpenAI 官方模型时，CC Switch 会改model_provider和model字段，而 Codex 官方登录需要auth.json里有可用的 token。如果你从未登录过官方账号，即使 CC Switch 切到 OpenAI 名称，Codex 依然会提示需要登录，让你误以为冲突了。

我的建议是：在动 CC Switch 之前，先把config.toml和整个.codex目录备份一次。每次切换到新的供应商配置后，如果发现 Codex 行为异常，直接对照备份恢复，而不是在界面上反复猜测。CC Switch 作为一个频繁读写配置的工具，出现覆盖乱序的概率虽然不高，但备份一下心里踏实。

5.2 Codex CLI 更新与 CC Switch 配置刷新

Codex CLI 更新频率不算低。Windows 下更新很简单：

npm update -g @openai/codex

更新之后建议先跑一次codex --version，确认版本号变了。如果更新后之前能用的 DeepSeek 配置突然报错，优先检查~/.codex/config.toml是否被安装脚本重置。npm 全局包的安装脚本一般不会动用户配置文件，但保险起见还是要看一眼。

CC Switch 这边，如果你用的是便携版，更新时直接替换整个程序目录；配置文件如果存在程序目录下，替换前先拷贝出来。如果存在系统用户目录下，通常不受影响。更新后模型配置列表有时候不刷新，可以退出 CC Switch 重新打开，或者点击界面里的刷新按钮。Windows 上偶尔会有“界面已经切换了模型，但config.toml没有同步”的情况，这时候你手动保存一次 provider 配置，再切换到别的 provider 再切回来，基本就能触发重写。

5.3 换模型后清掉旧会话，别让状态残留

最后一个我特别想强调的经验是：在 Windows 上长期使用 Codex CLI 接 DeepSeek，一定要养成换模型后开新会话的习惯。Codex CLI 的会话状态是基于历史消息和当前模型配置的，如果你在同一个终端里切了模型，旧历史里的消息工具调用和 token 统计可能和新模型对不上，轻则重复请求，重则界面闪跳。

我现在的工作模式是：日常代码任务用deepseek-chat，需要深度分析复杂逻辑时写一个简短指令，用codex exec直接执行一次，拿到结果再回到主会话。每次切换模型前先退出当前会话进程，再从 CC Switch 切换供应商，最后重新进入 Codex。这套流程虽然多两个动作，但换来的是稳定不抽风，值得。

API Key 也不要长期直接暴露在环境变量里，尤其当你的终端会记录历史命令时，强烈建议把 Key 只填在 CC Switch 里，由它统一管理。实在需要环境变量，给变量权限设置好，只限定当前用户。总之，工具链越简单越好，CC Switch 和 Codex CLI 的组合现在已经成了我在 Windows 上接 DeepSeek 的标准姿势，希望这份记录能让你一次跑通。