「CLIProxyAPI × Octopus」API反代 & 集中管理

“工具不在多，在于你能不能用一把钥匙打开所有的门。”

如果你和我一样，手上同时有好几种 AI 接入方式/工具：

官方订阅账号，比如 Gemini、Claude、OpenAI 这类订阅计划中包含 CLI 工具的服务
一些平台提供的 API Key
公益站、第三方渠道、临时月抛Team车位之类的补充来源

那你大概率也遇到过下面这些问题：

每家接入方式都不一样：有的走 OAuth 登录，有的只给 API Key，Claude与标准Open AI的协议还不完全兼容。
工具链很割裂：Cherry Studio、LobeChat、Open WebUI、各种脚本和 CLI 工具，大多只能使用标准 API。
切换成本很高：某条线路挂了要手动换，某个账号额度不够了又得重新改配置。
后期很难维护：API地址、Key太多，模型和映射乱七八糟，时间久了自己都忘了这套 API 配置是哪来的。

我折腾这套方案的目的而是想解决一个很朴素的问题：

能不能把零散的 API 统一归纳成一个稳定、带故障转移、可长期维护的使用方式？

我最后采用的方案，是把我使用 API 的方式拆成两层：

CLIProxyAPI 负责把订阅账号和官方 CLI 能力变成标准 API
Octopus 负责把这些 API 再统一聚合、故障转移、监控和统计

这套组合不一定是唯一的解决方案，但对我来说，它的好处是非常明显的：可以部署在我的美西优化服务器上，尽可能避免 AI 降智，在大陆也有不错的网络连通性。

1. 我为什么会需要这套东西#

最开始我只是想把手上的几类额度都尽量利用起来。

比如有些模型的订阅权益，其实很香，但官方主要是给网页端或者 CLI 用的；而我平时真正高频使用的，却是下面这些工具：

桌面客户端 Cherry Studio
命令行工具 OpenCode、Claude Code
自己写的小脚本或工作流

问题是明明我已经有订阅、有账号、有额度，但如果不能把它们转成标准 API 形式，那很多工具根本用不了对我来说，这种碎片化体验比“没有额度”还烦。

2. 为什么是 CLI Proxy API + Octopus#

有了 CLIProxyAPI，你能把很多原本只能走官方 CLI 的能力转成 API，但当渠道一多，还是会乱，而 Octopus，它很适合做聚合和路由。所以这两个项目放在一起，刚好形成一个完整链路：

1
客户端 / 工具 / 脚本
2
        ↓
3
    [ Octopus ]        ← 中枢层：聚合、路由、统计
4
        ↓
5
  [ CLIProxyAPI ]      ← 入口层：OAuth 认证、格式转换
6
        ↓
7
 Gemini / Claude / OpenAI / Qwen / iFlow ...

3. 部署 CLI Proxy API#

router-for-me

CLIProxyAPI

Waiting for api.github.com...

00K

Waiting...

前面已经讲清楚为什么要折腾这套东西了，这里就不继续做介绍。这一层的目标很简单：Docker 部署 CLI ProxyAPI，把原本依赖官方 CLI 登录的能力，转成可直接调用的标准 API。

3.1 部署前准备#

建议先确认下面几件事：

你有一台能长期在线的 Linux 服务器，或者本地已经装好了 Docker
已安装 Docker 和 Docker Compose

3.2 先准备目录#

CLI Proxy API 官方仓库里提供了 compose 文件，我更推荐直接用 Docker Compose 允许服务。先建一个工作目录：

1
mkdir -p ~/cliproxyapi
2
cd ~/cliproxyapi

3.3 用 Docker Compose 启动 CLI Proxy API#

可以在当前目录下新建一个 docker-compose.yml：

1
services:
2
  cli-proxy-api:
3
    image: eceasy/cli-proxy-api:latest
4
    container_name: cli-proxy-api
5
    restart: unless-stopped
6
    pull_policy: always
7
    ports:
8
      - "8317:8317"
9
      - "8085:8085"
10
      - "1455:1455"
11
      - "54545:54545"
12
      - "51121:51121"
13
      - "11451:11451"
14
    volumes:
15
      - ./config.yaml:/CLIProxyAPI/config.yaml
16
      - ./auths:/root/.cli-proxy-api
17
      - ./logs:/CLIProxyAPI/logs
18
    environment:
19
      DEPLOY: ""

然后执行：

1
docker compose up -d

3.4 如何使用 CPA 的 WebUI#

根据官方文档，CLI Proxy API 的 WebUI 入口是：

1
http://你的服务器IP:8317/management.html

如果你是本机部署，也可以直接访问：

1
http://localhost:8317/management.html

不过这里要注意，WebUI 不是容器一启动就一定能直接用。按照官方教程，你需要先在配置里加入 remote-management 相关配置，例如是否允许远程访问、管理密钥，以及是否禁用控制面板。

配置改完之后，重启程序；等服务生效后，再用浏览器打开上面的 management.html 页面。

第一次进入时，需要输入你在配置里设置的管理密钥（secret-key），输入正确后才能进入 WebUI。

官方教程里提到，进入之后界面本身比较直观，可以直接在面板里继续查看和操作；但有一个限制要特别注意：OAuth 认证功能仅支持本地运行环境，也就是 localhost 或 127.0.0.1，如果你是远程服务器部署，就不能直接在 WebUI 里完成这一步。

另外，如果你不想暴露内置控制面板，也可以把 remote-management.disable-control-panel 设为 true。这样一来，访问 /management.html 时就会直接返回 404。

简单理解的话，这一节可以记成下面这几步：

在配置文件里启用 remote-management
设置自己的管理密钥
重启 CLI Proxy API
访问 http://你的服务器IP:8317/management.html
输入管理密钥进入 WebUI

参考文档：

https://help.router-for.me/cn/management/webui.html

https://help.router-for.me/cn/hands-on/tutorial-6.html

4. Docker 部署 Octopus#

bestruirui

octopus

Waiting for api.github.com...

00K

Waiting...

当 CLIProxyAPI 已经确认可用之后，再来搭 Octopus。

这一层的职责也很明确：把多个来源统一收进一个中枢里，让客户端以后只认一个入口。

4.1 用 Docker Compose 启动 Octopus#

1
mkdir -p ~/octopus
2
cd ~/octopus
3
nano docker-compose.yml

1
services:
2
  octopus:
3
    image: bestrui/octopus
4
    container_name: octopus
5
    restart: unless-stopped
6
    ports:
7
      - "8080:8080"
8
    volumes:
9
      - ./data:/app/data

启动：

1
docker compose up -d

4.2 首次登录和默认账号#

根据官方 README，服务启动后可以直接访问：

1
http://你的服务器IP:8080

默认账号密码是：

用户名：admin
密码：admin

这里一定要注意：第一次登录后马上修改默认密码。

4.3 把 CLIProxyAPI 接进 Octopus#

当 Octopus 面板已经能正常打开之后，下一步就不是继续折腾 Octopus 本身了，而是：

把 CLIProxyAPI 当作一个上游来源接进去。

写在最后#

如果你只是偶尔体验一下某个模型，那这套方案确实有点重。

但如果你已经进入“来源越来越多、客户端越来越多、配置越来越散”的阶段，把入口层和中枢层拆开，后面的维护会轻松很多。

简单总结就是：

CLIProxyAPI 先负责把订阅能力转成标准 API
Octopus 再负责把这些 API 聚合成统一入口

按这个顺序搭，基本是最稳的。先把第一条链路真正跑通，后面无论是加渠道、做轮询，还是做成本统计，都会顺很多。