DeepSeek API Key 被覆盖导致 401 - CC Switch
Quick fix
升级 cc-switch 到 v3.16.2+，并重新填写 DeepSeek API Key，避免切换供应商时被其他 Key 覆盖。
Symptom
Section titled “Symptom”开启路由还是报错401,配置走的官方文档在 cc-switch 3.16.1 - 3.16.3 中，切换不同供应商（如 DeepSeek、OpenRouter、Xiaomi MiMo）并开关本地路由时，代理配置备份/恢复逻辑可能把当前 Live 配置中的 API Key 用另一个供应商的 Key 覆盖，导致目标供应商鉴权失败，出现 401 或“重连5次失败”。维护者在 v3.16.2 中修复了 proxy backup/restore 逻辑，但部分用户反馈 3.16.2/3.16.3 仍可能出现配置被改回的问题。
该 cluster 中还混有其他变体：mimo-v2.5-pro 在 Codex 登录 ChatGPT 账号时会返回 400 模型不支持；DeepSeek 首轮成功后失败可能与向 DeepSeek API 发送图片有关；DeepSeek V4 非多模态，macOS 拖拽图片会提示不支持；Zhipu GLM “查询失败”是用量查询默认查 Coding Plan 导致，与 API Key 覆盖不是同一问题。
将 cc-switch 升级到 v3.16.2 或更新版本；如果当前在 v3.16.3 仍复现，先回退到 v3.16.2 或等待/关注上游归并的修复 issue。
升级后重新打开 DeepSeek 供应商配置，检查 API Key 是否已变成 OpenRouter、Xiaomi MiMo 等其他供应商的 Key；如被覆盖，重新粘贴 DeepSeek 官方 API Key 并保存。
避免在多个第三方供应商之间频繁切换并反复开关本地路由；切换后先确认当前供应商的 API Key、base_url 和路由状态，再启动 Codex。
如果仍出现 401，关闭 Codex，重新在 cc-switch 中选择 DeepSeek 并开启路由，然后重新启动 Codex 测试。
Affected Versions
Section titled “Affected Versions”Source Issues
Section titled “Source Issues”本页汇总自 4 个真实 issue
- 为什么切换到 DeepSeek 后 API Key 会变成别的供应商的 Key？
- 这是 cc-switch 早期版本中 proxy backup/restore 的配置覆盖问题，尤其在切换第三方供应商并开关路由时容易触发。升级到 v3.16.2+ 后应改善，但部分用户反馈仍需要手动重填 Key。
- 升级到 v3.16.2 后还会被覆盖怎么办？
- 有用户反馈 v3.16.2/3.16.3 仍出现配置被改回。此时回退到 v3.16.2、避免复杂切换顺序，或重新添加/手动填写 DeepSeek 配置；如持续复现，应带上版本号和复现步骤反馈给维护者。
- 报错 400 提示 The 'mimo-v2.5-pro' model is not supported when using Codex with a ChatGPT account. 也是这个 Key 覆盖问题吗？
- 不是。这是 Codex 使用 ChatGPT 账号时不支持该模型的 400 错误，需要改用兼容的模型/登录方式或参考 CCMimoLink 适配方案。
- DeepSeek 首轮对话成功，后续报错，是不是 API Key 被覆盖？
- 不一定是。issue 中有用户指出向 DeepSeek API 发送 image 会报错；如果后续请求包含图片或多模态内容，需要确认模型是否支持该输入。
- Zhipu GLM 显示“查询失败”但 API 可用，也和 Key 覆盖有关吗？
- 通常无关。该问题多是用量查询默认查询 Coding Plan/Token Plan 而账号没有对应订阅导致；API 本身可用时可关闭或自定义用量查询。
这是一个非官方社区 wiki，与 cc-switch 作者及项目本身无隶属关系。内容整理自项目公开的 GitHub issues。本站不分发任何软件。