企业官网建设流程全解析

先说个真实的场景：你高高兴兴把 DeepSeek 接进 Codex，跑了半天发现效果不错，然后某一天想切回 OpenAI 官方模型，结果codex启动之后模型列表里只剩 DeepSeek，或者直接给你抛一个unexpected status 401 unauthorized，再看一眼配置发现model_provider不知道什么时候被改掉了。这时候绝大多数人的第一反应是重装 Codex，其实不用，问题基本都出在 CC Switch 对本地配置的接管方式上。

这篇文章我按自己排障的完整思路来写，从原理、体检、恢复到各种报错怎么查，一套流程走完，保证你能把官方模型找回来，顺便把这个工具的用法彻底搞明白。

1. 官方模型"消失"的真正原因：CC Switch 的代理机制与 Codex 的模型发现逻辑

很多人以为 CC Switch 是"给 Codex 装了一个新模型"，其实不是。它的工作方式更像是一个本地代理和配置文件改写器：你选中某个 Provider 之后，它会去修改 Codex 的配置文件，把请求的出口指向本地代理，再由本地代理把请求转发给真正的服务商。问题就出在这一步——它改的是配置，不是 Codex 的模型库，一旦配置被覆盖成 DeepSeek 的 Provider，官方模型自然就"不在视线里"了。

1.1 CC Switch 到底改了你的什么文件

Codex CLI 在 macOS 上的配置集中在两个文件：

• ~/.codex/config.toml：主配置，里面定义了模型、Provider、API 地址等。
• ~/.codex/auth.json：认证信息，存放登录 token。

CC Switch 切换 Provider 时，核心动作是改写config.toml里的model_provider字段，把它的值从openai改成类似deepseek这样的自定义 Provider 名称，同时会往[model_providers.deepseek]段里写入base_url和env_key。

听起来没什么问题，但风险在于：它写入的不只是新增一段，有时会直接改写默认选择。等你再手动改回model_provider = "openai"时，如果对应的[model_providers.openai]段已经被删掉、或者配置残留了base_url指向本地代理，Codex 启动时仍然会把你的请求送到 CC Switch 的本地端口，而 CC Switch 当前激活的 Provider 如果还是 DeepSeek，那结果就是：你嘴上说要用官方模型，实际请求还是进了 DeepSeek，表现自然就是"官方模型不见了"。

1.2 Codex 是如何决定"用哪个模型"的

Codex 启动时会做这几件事：

1. 读config.toml，拿到model_provider的值。
2. 根据这个值去找[model_providers.xxx]段，取出base_url和env_key。
3. 向base_url发起鉴权和模型列表请求，拿到可用的模型列表。
4. 从[[models]]定义里匹配你指定的model，如果匹配不到就报类似model: gpt-6-astra; cause: 配置错误的错误。

所以最核心的一点是：只要model_provider被指向了非官方地址，Codex 眼中的世界就完全变了，它会认为世界上只有 DeepSeek 或者当前代理才能提供的模型，OpenAI 官方模型自然不在列表里。

这个机制很像电视机的输入源切换：屏幕还是那块屏幕，但信号源变了，频道列表就全变了。CC Switch 做的就是把 HDMI 输入从"官方信号"切换到了"第三方信号"，而你的遥控器（模型列表）显示的当然是第三方频道的节目。

2. 动手恢复前，先给当前配置做一次"体检"

我不建议你上来就直接删配置或者重装 Codex，那样容易把还能救的登录态弄丢。正确顺序是：先搞清楚当前配置坏在哪，再决定用哪种方式恢复。

2.1 配置文件在哪、怎么快速定位问题

打开终端，按顺序执行这几条命令：

# 查看当前主配置 cat ~/.codex/config.toml # 查看认证状态 ls -l ~/.codex/auth.json cat ~/.codex/auth.json | head -c 200

第一眼要确认几个关键位置：

• model_provider当前值是什么。
• 是不是存在[model_providers.deepseek]或类似的自定义 Provider 段。
• [model_providers.openai]段还在不在，base_url有没有被改成localhost或127.0.0.1之类的本地地址。
• [[models]]列表里是否还能看到gpt-6-astra这样的官方模型条目。

我看过不少翻车案例，最常见的是这三种状态：

2.2 一个判断原则：先看官方配置还剩多少

"恢复默认配置"这个说法很容易让人误解为把 CC Switch 删干净就行，其实不对。CC Switch 只是一个外部工具，真正决定 Codex 怎么工作的还是config.toml。只要这个文件里的官方 Provider 配置完整，哪怕没有 CC Switch，你也可以正常使用官方模型。

所以我在体检时会做一个简单评估：config.toml里的官方配置还剩多少？

• 如果[model_providers.openai]还在，只是model_provider被改了，那恢复成本很低。
• 如果这个段被删了，那就需要手动补全，或者干脆让 Codex 重建默认配置。
• 如果auth.json里的 token 已经失效，那就必须重新codex login，这一步逃不掉。

先去~/.codex目录看一眼有没有自动备份，很多版本在更新配置时会生成.bak或.old后缀的同名文件，如果有，恢复起来最省事。

3. 恢复默认配置的完整操作：从备份还原到重建验证

体检做完，下面直接上恢复流程。我按"有没有备份"分两种路线，第三种情况是给你验证是否恢复成功的方法，三条一起看。

3.1 路线 A：有备份，直接还原

如果你之前在切换前备份过config.toml，或者 CC Switch 在修改配置时留下了备份文件，那恢复是最简单的：

# 先备份当前被改乱的配置，留个后路 cp ~/.codex/config.toml ~/.codex/config.toml.hand-fix.bak # 用备份文件覆盖回去，改成你自己的实际备份文件名 cp ~/.codex/config.toml.bak ~/.codex/config.toml

然后确认一下备份里的关键字段：

grep -n "model_provider" ~/.codex/config.toml grep -n "base_url" ~/.codex/config.toml

model_provider应该等于"openai"，[model_providers.openai]段的base_url要么不存在、要么指向https://api.openai.com/v1。如果这两处都不对，说明备份本身也不是干净的，请直接看路线 B。

3.2 路线 B：没有备份，让 Codex 重建默认配置

没有备份也不用慌。Codex CLI 的默认配置完全可以重新生成，你只需要把被污染的配置文件暂时移走，然后触发一次重新登录：

# 把现有配置移走，不要直接删，方便后面找回自定义内容 mv ~/.codex/config.toml ~/.codex/config.toml.cc-switch-corrupted # 重新登录，这步会重新生成默认配置和刷新 token codex login

执行完登录后，Codex 会在~/.codex下生成一份全新的config.toml和auth.json。这时候你直接运行codex，官方模型就应该回来了。

如果codex login因为认证问题卡住，也可以先手动清掉旧认证：

codex logout rm -f ~/.codex/auth.json codex login

登录成功后再把你之前需要的自定义配置，比如模型温度、model选择，一行一行加回去，千万别整段复制旧的 provider 配置，不然又把错误带回来了。

3.3 验证是否恢复成功的三个检查点

配置恢复完不是看一眼就觉得行了，建议按下面三个步骤验证：

# 1. 查看可用的模型列表，应该能看到官方模型 codex models # 2. 跑一次最简对话，确认请求真正到达 OpenAI codex exec "say hi, just a connectivity test" # 3. 再检查一遍配置里的关键字段 grep -E "model_provider|base_url" ~/.codex/config.toml

如果codex models能看到gpt-6-astra之类的官方条目、codex exec能正常返回内容、base_url不是本地地址，基本就恢复成功了。这时候再打开 CC Switch，你会发现它依然在，但没有真正接管你的 Codex——这是正常状态，说明你把控制权拿回来了。

4. 从 401 到 503，逐个拆解恢复过程中的异常报错

恢复过程中最常见的卡点其实不是配置本身，而是一堆让人摸不着头脑的 HTTP 状态码。我把热词里反复出现的几个报错整理一下，按"看到这个错，先往哪个方向查"的逻辑来讲。

4.1 401 Unauthorized：token 问题还是代理转发问题

这个报错出现频率极高，表现形式通常是：

unexpected status 401 unauthorized: cc switch local proxy failed while handling

第一反应别去怪 CC Switch，先判断请求到底发给了谁。你可以临时改一下base_url指向官方地址，再跑一次请求；如果正常，说明问题出在 CC Switch 的代理层，也就是代理转发时没有携带有效凭证；如果不正常，那说明你的auth.json已经过期，需要重新codex login。

还有一个很容易忽略的点：当你通过 CC Switch 接入 DeepSeek 时，凭证用的是 DeepSeek API Key，而不是 OpenAI token。如果你切回官方模型时 CC Switch 还挂在激活状态，本地代理会把 OpenAI 官方请求也转发到 DeepSeek 的鉴权逻辑里，自然就 401 了。恢复时记得在 CC Switch 里把 Provider 切到 OpenAI 官方，或者退出 CC Switch 的本地代理进程。

4.2 404、502、503：本地代理状态和转发目标不匹配

这三个状态码放在一起看，因为它们多半是一家人：

unexpected status 404 not found: cc switch local proxy failed while handling unexpected status 502 bad gateway: cc switch local proxy failed while handling unexpected status 503 service unavailable: cc switch local proxy failed while handling

• 404：本地代理活着，但把请求转发给了一个不认这个接口的服务。比如 DeepSeek 某些接口不支持/responses这个 endpoint，代理解析不了就回 404。
• 502：本地代理活着，但它背后要转发的上游服务连不上，通常是 API Key 配错或网络不通。
• 503：本地代理本身没起来，或者 Caddy 服务没监听端口，请求直接无处可去。

排查顺序建议是：先看 CC Switch 的本地代理进程是否在跑，再看它的日志输出，最后确认你当前选中的 Provider 和 Codex 的base_url是否一致。

# 查看本地代理进程是否存在 ps aux | grep -i cc-switch # 查看监听端口，找到 CC Switch 的代理端口 lsof -iTCP -sTCP:LISTEN | grep -iE "cc-switch|caddy"

如果你确认配置已经恢复成官方默认，但 CC Switch 的本地进程还占着端口，直接把它退掉，Codex 就会直连官方 API，不再经过代理。

4.3 配置语义错误：缺少 base_url 和工具调用相关报错

有时候不是 HTTP 状态码的问题，而是配置语义不对，最常见的是：

配置错误: codex provider 缺少 base_url 配置

这句话的意思是：model_provider指定的那个 Provider 名字，在config.toml里找不到对应的[model_providers.xxx]段，或者找到了但里面没有base_url。说白了就是model_provider = "deepseek"，但[model_providers.deepseek]段被你删了，或者名字拼写不一致。

修复方式很简单：要么删掉model_provider这一行让 Codex 用默认值，要么把对应的 Provider 段补齐。二选一，不要两个都做一半。

还有一个和 DeepSeek 模型本身强相关的报错：

deepseek messages tool calls need immediate results

这个不是配置问题，是 DeepSeek 推理模型不支持 Codex 所需的某些工具调用模式。Codex 在运行时会要求某些工具调用立即返回结果，而 DeepSeek 推理模型做不到，就会报这个错。解决方法是换用 DeepSeek 的对话模型，而不是推理模型，或者避免在任务中触发工具调用。换句话说，有些模型能力边界是天生的，不是配置能扭转的。

5. 以后想长期混用 DeepSeek 和官方模型？正确配置姿势在这

走到这一步，你已经把官方模型找回来了。但我知道很多人其实是想要"两个都要用"：日常用 DeepSeek 省成本，需要高难度代码生成时切回官方模型。这个需求很合理，关键是别再让配置乱掉。

5.1 推荐的 config.toml 结构：官方和第三方分开维护

正确的思路是：官方 Provider 配置完全保留，DeepSeek 作为独立追加的 Provider，而不是替代。下面是一个经过了验证的参考结构：

# 主选择：需要官方模型时保持 openai model_provider = "openai" # 官方 Provider 保持默认，不写 base_url，或者显式写官方地址 [model_providers.openai] name = "openai" # DeepSeek 作为独立的第三个 Provider 追加，不影响 openai [model_providers.deepseek] name = "DeepSeek" base_url = "https://api.deepseek.com/v1" env_key = "DEEPSEEK_API_KEY"

切换时只需要改model_provider的值，不需要删任何 Provider。CC Switch 如果动配置，你也知道它动的是哪一行，自己手动改回来就能恢复。

5.2 日常使用 CC Switch 的几个建议

我用 CC Switch 也踩过不少次坑，最后总结了几条习惯，现在分享出来：

• 切换 Provider 前，先备份config.toml。一条命令的事，别偷懒。CC Switch 本身不会帮你备份，真出问题只能靠自己。
• 不要手动删[model_providers.openai]段。无论你多想给 DeepSeek 腾位置，都不要删。官方 Provider 和第三方 Provider 完全可以共存。
• CC Switch 有更新时，先看更新日志再升级。部分旧版本的配置改写逻辑有 bug，会在切换时把其他 Provider 的base_url一并改掉，这种问题升级版本后基本就没了。
• DeepSeek 接入时，优先用 Chat Completions 兼容接口。Codex 对/responses接口的支持和 DeepSeek 的实现存在差异，如果因为接口不兼容导致反复报错，不要试图绕过，换一个模型或者换一种接入方式更省时间。
• 注意模型服务商的使用规范。DeepSeek 这类模型有自己的内容安全策略，不要尝试通过特殊方式突破模型限制或破解安全机制，这不仅违反平台规则，也可能导致 API 被限制，得不偿失。

我个人现在的用法是：config.toml里把openai和deepseek两个 Provider 都写清楚，CC Switch 只负责管理和切换 API Key，不再让它碰核心配置。切模型时就改一行model_provider，切完顺手codex models验证一下，整套流程十分钟之内能跑完，再也没有出现过"官方模型失踪"这种事了。

如果你现在正好卡在某个报错上，按第 4 节的顺序从 401 逐步排查到配置语义错误，基本都能定位到根因。实在还没解决的话，把config.toml恢复到默认再重新登录是永远有效的保底方案——这次别忘了先备份。