跳转到内容
CC Switch WikiUnofficial Community Wiki

供应商切换后配置不生效 / Codex 请求失败 (cc-switch)

Quick fix

在 cc-switch 里切换 DeepSeek 等供应商后配置不生效：升级 cc-switch，并以 cc-switch 的启用/保存为唯一写入口，不要手改 live 配置文件。

Symptom

Section titled “Symptom”
报错原文
根据操作配置不生效，之前还是有用的，今天重启电脑后就这样了

Cause

Section titled “Cause”

这个聚簇里报告的其实是同一类「配置已切换但没生效」的表象，背后有多种机制，各 issue 指向的原因并不完全一致：

1) 最典型的是配置文件写入范围问题（#2966、#656）：切换供应商/模型时，目标应用的配置文件（hermes agent 的 config.yaml、Claude 的 JSON 配置）没有被完整重写，导致默认模型、provider、base_url 仍是旧值。这类问题在 v3.15.0/v3.16.0 附近被修复——维护者在 #2966 中确认切换时会同步更新 `model.default`、`model.provider`、`model.base_url`（base_url 从新 provider 的 `base_url` / `baseUrl` 读取）。

2) 另一类是运行时链路问题而不是写文件失败（#3591、#6936）：通过「功能增强/接管」本地代理（127.0.0.1:15721）转发时请求失败或 429，日志显示 `上游连接失败: error sending request`，同一进程里 Claude 转发成功而 Codex 失败；其中 #6936 在 macOS 上 3.17～3.20.1 全部复现，且有用户未改任何配置、重启后自行恢复，怀疑与证书有关——这一条没有定论，属于未确认的变体。

3) 还有目标端模型本身的问题（#3255、#3864）：上游模型名不存在（如 `claude-haiku-4-5-20251001` 下架）、或测试模型字段修改后未保存成功，表现为「改了不生效」。

注意：#3591 的 429 与 #6936 的连接失败更像中转商限流/网络栈问题，与 #2966/#656 的写配置 bug 不同；如果按下面的步骤仍复现，需要区分你遇到的是哪一类。

Fix

Section titled “Fix”

  1. 先升级 cc-switch 到最新版（v3.20.0+ / v4.0）：v3.15.0/v3.16.0 已修复切换供应商时同步更新 model.default/provider/base_url 的问题，v4.0 又重做了本地路由和请求转发，只写关键字段，覆盖面更广。

  2. 切换供应商时，在 cc-switch 界面里对目标供应商点一次「启用」或「保存」（不要只改模型 ID 后退出），让 cc-switch 重新生成目标应用的 live 配置；不要手动去改 hermes agent 的 config.yaml 或 Claude 的 JSON 配置文件，否则下一次启用/保存会被整文件覆盖回去。

    以 hermes agent 的 config.yaml 为例：切换后应由 cc-switch 同步写入以下三项，不要只改 model.default
    model:
      default: DeepSeek-V4-Flash
      provider: moark
      base_url: https://api.moark.com/v1

  3. 如果升级后 Codex 仍全部请求失败而 Claude Code 正常（#6936 场景）：关闭/切换系统代理、PAC、v2ray 后重试；查看 ~/.cc-switch/logs/cc-switch.log 中对应时间段的 `[Forwarder]` 日志确认是否为「上游连接失败」；在 macOS 13 等无法升级系统的环境，该问题暂无已确认的修复，有用户报告重启数日后自行恢复（疑似证书问题）。

  4. 如果报错是某个模型「不存在或已下架」（#3255）：在供应商表单里把模型名改成上游真实存在的模型（例如 deepseek-chat），保存后再测；注意测试模型字段需要保存成功才会生效。

Affected Versions

Section titled “Affected Versions”
ToolClaude Code / Codex
Version受影响版本约 3.15.0 - 3.20.1；#2966 的写配置问题在 v3.15.0/v3.16.0 修复，#6465 类问题在 v3.20.0 修复，#6936 在 3.17～3.20.1 未修复
PlatformsWindowsmacOS

Source Issues

Section titled “Source Issues”

本页汇总自 7 个真实 issue

FAQ

Section titled “FAQ”
我在 cc-switch 里切换了 DeepSeek，但 hermes agent / Claude 里还是旧配置？
这正是 #2966/#656 的问题：旧版本只改了部分字段。升级到 v3.16.0+ 后，切换时会同步写入 model.default、model.provider、model.base_url。改完后在 cc-switch 里点一次「启用/保存」让配置重新生成。
用中转 API 直接登 Codex 正常，经过 cc-switch 切换后报 429 too many requests？
#3591 记录过这个现象，有用户把供应商切到 deepseek 就好了。维护者判断 429 更可能来自中转商对请求特征的限流，v4.0 已重写本地路由；若最新版仍复现，需要提供中转商名称和 ~/.cc-switch/logs/cc-switch.log 对应时间段的日志才能定位。
macOS 上 Codex 走 cc-switch 代理全部失败、Claude Code 却正常，检查更新也失败？
见 #6936：3.17～3.20.1 均复现，与系统代理/PAC/v2ray 开关无关。有用户在未升级系统的情况下重启数日后自行恢复，推测与证书有关；该场景暂无已确认的修复，升级 macOS 曾被报告有效（类似 #3968）。
报错说测试模型 claude-haiku-4-5-20251001 不存在或已下架？
这是上游模型名失效，不是 cc-switch 没写入。在供应商配置里把模型改成实际可用的（如 deepseek-chat）并保存即可。

相关问题

Section titled “相关问题”
Select Model 菜单仍然显示切换前模型列表 - Codex关闭现有 Codex 会话后运行 `codex app-server daemon restart`；升级 CC Switch 至 v4.0.7 以上可获得旧目录检测与重启提示。3 issues merged供应商 API Key 被覆盖：Codex 重启或切换后升级到 cc-switch v4.0.0 或更高版本；该版本重写了切换逻辑，避免供应商密钥互相覆盖并恢复官方登录态。6 issues mergedCC Switch 目前的架构是黑盒的，用户无法自定义处理逻辑这是为 CC Switch 增加可编程路由转换脚本的功能请求，原帖尚未提供可验证的正式解法。1 issues merged

这是一个非官方社区 wiki，与 cc-switch 作者及项目本身无隶属关系。内容整理自项目公开的 GitHub issues。本站不分发任何软件。