🧭 9Router 本地 AI 路由配置：从 New API 到 CC Switch

安装 9Router 之后，最容易混淆的问题不是命令怎么执行，而是：9Router、CC Switch 和 New API 到底谁负责什么？

这篇文章记录我在 macOS 上的实际配置思路。最终目标是让 AI 客户端只连接一个本地入口，再由 9Router 统一转发到 New API 或其他模型提供商。

先说结论

推荐的请求链路如下：

Codex / Claude Code
        ↓
CC Switch（可选，只管理配置）
        ↓
9Router：127.0.0.1:20128
        ↓
New API 或其他 AI 提供商

简单来说：

工具	主要作用
9Router	真正运行的本地 AI 网关，负责转发、协议转换、配额和故障回退
CC Switch	配置管理器，负责保存和切换多个客户端配置
New API	上游 API 聚合或中转服务，提供实际模型接口
Codex / Claude Code	发起请求的 AI 编程客户端

9Router 本身不是模型，也不会自动提供免费的 Claude 或 Codex 额度。免费额度、订阅额度和 API 费用仍由上游提供商决定。

CC Switch 有两种工作模式

这是整个配置里最容易弄错的地方。

普通切换模式

CC Switch 只是帮忙修改 Codex 或 Claude Code 的配置文件。例如把客户端的 base_url 从 New API 改成 9Router。

CC Switch 修改配置 → Codex / Claude Code 直接访问 9Router

这种模式下，CC Switch 不在请求链路中，只是一个配置管理工具。

本地路由接管模式

CC Switch 也可以启动自己的本地代理，默认地址通常是：

http://127.0.0.1:15721

开启 Proxy 或“应用接管”后，请求链路会变成：

Codex / Claude Code → CC Switch:15721 → 上游提供商

这时请求不会经过 9Router。虽然 15721 和 9Router 的 20128 端口不冲突，但不建议让两个代理同时接管同一个客户端，否则容易出现配置覆盖、重复重试和日志重复记录。

macOS 安装 9Router

当前电脑使用 Node.js 22，满足 9Router 的 Node.js 18 以上要求。安装指定版本：

npm install -g [email protected]

本机启动时建议明确绑定到 127.0.0.1：

9router --host 127.0.0.1 --port 20128 --skip-update --tray

不要直接依赖默认的 0.0.0.0，否则同一局域网内可能可以访问本机的 AI 接口。

启动后打开控制面板：

http://127.0.0.1:20128/dashboard

9Router 的本地数据通常保存在：

~/.9router/

其中包含提供商配置、API Key、OAuth Token、SQLite 数据和用量记录，不要把这个目录提交到 Git 仓库。

把 New API 接入 9Router

原来如果是把 New API 导入到 CC Switch，现在可以把 New API 作为 9Router 的上游提供商。

打开 9Router Dashboard：

Providers → Add Provider → Custom Provider

填写原来 CC Switch 中 New API 配置里的三项内容：

名称：New API
Base URL：原来的 New API 地址
API Key：原来的 New API Key
协议：OpenAI Compatible 或 Anthropic Compatible

Base URL 要注意 /v1 只保留一份。例如：

https://new-api.example.com/v1

保存后先在 Dashboard 中测试连接，并从模型列表确认 New API 实际暴露出来的模型 ID。

这里有两个不同的 Key：

Key	用途
New API Key	9Router 访问 New API 时使用
9Router API Key	Codex、Claude Code 或 CC Switch 访问 9Router 时使用

不要把 New API Key 直接填到客户端的 9Router 配置里。

让 CC Switch 连接 9Router

如果仍然希望用 CC Switch 一键切换配置，可以在 CC Switch 中新增一个供应商，名称例如 9Router：

Base URL: http://127.0.0.1:20128/v1
API Key: 9Router Dashboard 生成的 API Key

然后在 CC Switch 中切换到这个 9Router 配置。

注意：此时只使用 CC Switch 的普通供应商切换功能，不要打开 CC Switch 的 Proxy / 应用接管。实际请求链路应该保持为：

Codex / Claude Code → 9Router → New API

如果打开了 CC Switch 本地路由，实际链路就会变成：

Codex / Claude Code → CC Switch → New API

9Router 会被绕过。

Codex 的配置方式

可以直接使用 9Router Dashboard 中的：

CLI Tools → Codex → Apply

手工配置时，核心内容类似下面这样：

model = "实际可用的模型 ID"
model_provider = "9router"

[model_providers.9router]
name = "9Router"
base_url = "http://127.0.0.1:20128/v1"
wire_api = "responses"

修改前建议备份：

cp ~/.codex/config.toml ~/.codex/config.toml.bak
cp ~/.codex/auth.json ~/.codex/auth.json.bak

如果平时通过 CC Switch 管理 Codex 配置，也可以只在 CC Switch 中激活 9Router 供应商，不要让 9Router Dashboard 和 CC Switch 同时反复改写配置文件。

验证是否配置成功

先确认 9Router 端口确实在监听：

lsof -nP -iTCP:20128 -sTCP:LISTEN

再请求模型列表：

curl http://127.0.0.1:20128/v1/models \
  -H "Authorization: Bearer <9router-api-key>"

如果能返回模型列表，说明客户端到 9Router 的连接和 Key 基本正常。再在 Dashboard 的用量页面确认请求是否继续转发到了 New API。

常见问题

端口 15721 和 20128 不一样，为什么还会冲突？

它们不是端口冲突，而是配置接管冲突。一个客户端应该只指向一个本地代理入口。

请求没有经过 9Router

检查 Codex 或 Claude Code 的实际 base_url。如果还是 127.0.0.1:15721，说明 CC Switch 的本地路由仍然开启；如果是 New API 远程地址，说明客户端绕过了 9Router。

请求返回 401

通常是把 New API Key 和 9Router API Key 填反了。客户端访问 9Router 时必须使用 9Router 生成的 Key。

模型找不到

不要完全照抄旧配置中的模型名称。先请求 9Router /v1/models，使用当前返回的真实模型 ID；必要时再在 9Router 中配置别名或回退组合。

9Router 显示的费用很高

Dashboard 中的费用通常是估算值或节省对比，不一定是 9Router 向你收取的账单。真正的费用以 New API 或其他上游服务的账单为准。

最终建议

如果只是想继续使用原来的 New API，CC Switch 直接连接 New API 就够了。

如果想统一接入多个提供商、做自动回退、统计额度，并且以后不想频繁修改 Codex/Claude 配置，推荐采用：

CC Switch（可选的配置管理）
        ↓
9Router（唯一运行时网关）
        ↓
New API、Codex、Claude、GLM、Kiro 等上游

关键原则只有一句：CC Switch 负责切换配置，9Router 负责转发请求，不要让两个本地代理同时接管同一个客户端。

参考资料

• 9Router 官网
• 9Router GitHub
• 9Router Docker 文档
• CC Switch GitHub
• CC Switch 代理使用指南