手把手教你用 Sub2API 搭一个自己的 AI Token 中转站

最近不少人在研究 AI 中转站。表面上看，大家都在说“搭个网关”“转成 OpenAI 兼容接口”“统一接上游模型”，但真开始找方案时，很快就会遇到 3 个名字：New API、Sub2API、CLI Proxy API。

先用 30秒看懂这三个项目

1）New API
这个项目更像“通用 AI 网关底座”。它的定位是统一聚合和分发不同模型，把各种上游能力转换成 OpenAI / Claude / Gemini 兼容格式。你如果以后想做更综合的模型聚合平台，New API 是值得研究的。

2）Sub2API
这个项目更直接。它的目标就是把 AI 产品订阅能力分发成 API 调用能力，而且已经把多账号、API Key 分发、计费、并发控制、限速、后台管理、支付等能力都做进去了。换句话说，它更接近“能拿来跑业务”的那类项目。

3）CLI Proxy API
这个项目更偏“把 CLI 包起来”。它能提供 OpenAI / Gemini / Claude / Codex 兼容接口，适合把本地或多账号 CLI 访问方式统一成 API 形式。如果你的重点是 CLI 能力接入，这个方向会更对味。

如果你现在的目标是：先快速搭一个有后台、有账号管理、后面还能继续运营的中转站，那我觉得最值得先上手的，就是 Sub2API。

为什么我建议先从 Sub2API 开始

Github：https://github.com/Wei-Shaw/sub2api

很多人第一次搭中转站，会误以为“把请求转发出去”就够了。其实真正麻烦的，往往不是转发本身，而是后面的这些事：

  • 怎么给不同用户发自己的 API Key
  • 怎么统计用量、做计费
  • 怎么限制并发和速率
  • 怎么在后台看日志、看状态
  • 怎么做充值或后续的商业化

而 Sub2API 最大的好处，就是它不是只给你一个“转发器”，而是已经把这些基础能力一并考虑进来了。对想认真做一个小平台的人来说，这比从零拼一堆组件省事得多。

开始部署前，你需要准备什么

这一篇我只讲 Docker Compose 这条线，因为它是上手最快、最适合先跑起来的方式。按照官方说明，Docker Compose 部署方式会把 PostgreSQL 和 Redis 一起带上，所以准备工作相对简单。

  • 一台 Linux 服务器
  • Docker 20.10+
  • Docker Compose v2+
  • 一个能登录服务器的 SSH 环境

建议

如果你是第一次搭，先别急着配域名和 HTTPS。先用 IP + 8080 把后台跑起来，确认服务正常，再做反向代理和正式对外开放。

第一步：一键拉起 Sub2API

如果你想最快把它跑起来，直接按官方给的快速开始命令来。它会自动准备部署目录、下载 Compose 文件和环境样例，并生成必要的安全凭证。

mkdir -p sub2api-deploy && cd sub2api-deploy

curl -sSL https://raw.githubusercontent.com/Wei-Shaw/sub2api/main/deploy/docker-deploy.sh | bash

docker compose up -d

跑完以后，再看一眼日志，确认服务已经启动：

docker compose logs -f sub2api

这一套做完，本质上就已经把主服务、数据库和 Redis 一起拉起来了。对于“先跑起来再说”的第一版，这是最省心的路径。

第二步：如果你想手动配环境，可以这样做

有些人不喜欢“一键脚本”，那就手动来。官方文档给的思路是：克隆仓库、进入 deploy 目录、复制 `.env.example` 为 `.env`，然后自己填写关键配置。

git clone https://github.com/Wei-Shaw/sub2api.git

cd sub2api/deploy

cp .env.example .env

nano .env

`.env` 里你至少要关注这几个东西：

  • POSTGRES_PASSWORD：数据库密码
  • JWT_SECRET：登录和会话相关密钥
  • TOTP_ENCRYPTION_KEY：双因素认证相关密钥
  • ADMIN_EMAIL / ADMIN_PASSWORD：管理员账号（可选，但建议配）
  • SERVER_PORT：服务端口，默认可以先用 8080

如果你不知道这些密钥怎么生成，最简单的办法就是直接用 OpenSSL：

openssl rand -hex 32

openssl rand -hex 32

openssl rand -hex 32

然后创建本地数据目录，再启动服务：

mkdir -p data postgres_data redis_data

docker compose -f docker-compose.local.yml up -d

docker compose -f docker-compose.local.yml ps

docker compose -f docker-compose.local.yml logs -f sub2api

第三步：进入后台

服务起来之后，直接在浏览器里打开：

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

如果管理员密码是自动生成的，可以从日志里找：

docker compose -f docker-compose.local.yml logs sub2api | grep “admin password”

到这里，其实你已经完成了最关键的一步：平台已经能访问，后台已经能登录。后面要做的，无非就是继续往里面填配置、接上游账号、配 API Key、设置用户策略。

第四步：添加 Codex / OpenAI 账号授权

Sub2API 跑起来之后，下一步就是把上游账号接进去。以 Codex / OpenAI 账号授权为例，流程大致是：在系统里生成授权链接，复制到浏览器打开，登录 OpenAI 账号完成授权，然后把回调链接复制回 Sub2API。

这个步骤不是在服务器命令行里完成，而是在 Sub2API 的管理后台里操作。

具体流程如下。

1）进入添加账号页面

登录 Sub2API 后台后，找到账号管理相关入口，点击“添加账号”。在授权方式里选择 OpenAI 账户授权。

你会看到几个选项：

  • 手动授权
  • 手动输入 RT
  • 手动输入 Mobile RT

对普通用户来说，优先用“手动授权”就行。这个方式最直观，不需要你自己去找 refresh token。

2）生成授权链接

点击页面里的“生成授权链接”。系统会生成一个 OpenAI 授权地址。

这个链接不要在后台页面里反复点，直接复制出来，然后在浏览器的新标签页里打开。

3）在浏览器里登录 OpenAI 并完成授权

打开授权链接后，浏览器会跳到 OpenAI 的登录 / 授权流程。这里正常登录你的 OpenAI 账号，并完成授权。

授权完成后，页面地址通常会跳转到一个类似这样的回调地址：

http://localhost:xxx/auth/callback?code=…

注意，这里看到 localhost 开头并不代表失败。它通常只是 OAuth 回调地址。你需要做的是把这个完整链接复制下来。

重点

不要只复制前面的 localhost，也不要手动改链接。直接复制浏览器地址栏里的完整回调链接，或者复制 code 参数后面的值。

4）把回调链接复制回 Sub2API

回到 Sub2API 的添加账号页面，在“授权链接或 Code”输入框里，把刚才复制到的完整回调链接粘贴进去。

系统一般会自动识别完整链接里的 code 参数。也就是说，你可以复制完整链接，也可以只复制 code 参数值。

5）点击完成授权

粘贴完成后，点击“完成授权”。如果没有报错，这个 OpenAI / Codex 账号就会被添加到 Sub2API 后台。

后面你就可以继续配置模型、用户 API Key、调用额度、并发限制和计费规则。

这里容易卡住的地方

第一，浏览器打开授权链接后可能加载比较慢，要等页面完整跳转。

第二，授权完成后看到 localhost 不要慌，重点是复制地址栏里的完整 callback 链接。

第三，如果复制 code 参数，注意不要漏掉字符，也不要带多余空格。

这几个细节，建议你一开始就注意

1）优先用 `docker-compose.local.yml`
官方文档明确给了两个版本：一个用本地目录存数据，一个用 Docker 命名卷。前者更适合备份和迁移，后面你要换服务器会轻松很多。

2）把 `.env` 保存好
JWT_SECRET、TOTP_ENCRYPTION_KEY、数据库密码这些东西一旦丢了，后面你会很难受。建议部署后第一时间做好备份。

3）先跑通，再优化
第一次部署时，不要同时上域名、反代、HTTPS、支付、监控。先把最小闭环跑通：服务能启动、后台能登录、能接上游、能出 API Key。后面再一层一层加。

提醒

如果你后面真的打算对外提供服务，部署只是开始。真正花时间的，往往是上游管理、额度控制、风控、支付、售后和稳定性。

发表回复