Sub2API 是一个开源 AI API Gateway，可以把 Claude、OpenAI、Gemini、Antigravity 等订阅或账号资源统一成一个 API 入口，并通过平台生成的 API Key 提供访问、计费、调度和管理能力。它更适合技术学习、团队内部测试、账号资源管理和自托管网关场景。
在正式部署前要先说明：这类中转和订阅额度分发工具可能涉及上游服务条款风险。请先阅读相关服务商的用户协议，只在符合法律法规和服务条款的场景下使用。本文只讨论技术部署流程，不建议将未经授权的账号或订阅资源公开售卖。
Sub2API 适合做什么
适合：个人或团队学习 API Gateway、内部统一管理多个 AI 账号、做调用统计、做额度和并发控制、测试 Claude Code / Codex / Gemini CLI 等工具的接入方式。
不适合：不了解服务器运维、不愿意处理账号风控、不准备做 HTTPS 和访问控制、想直接拿来公开运营的人。
服务器准备
推荐准备一台 Linux VPS，配置可以从 2 核 2G 起步。如果只是测试，1 核 1G 也能跑，但 PostgreSQL、Redis 和后端一起运行时会比较紧。
基础要求：
- Linux 服务器，amd64 或 arm64。
- Docker 20.10+。
- Docker Compose v2+。
- 一个域名，建议提前解析到服务器。
- 开放 80、443 端口；测试阶段可以临时开放 8080。
安装 Docker 和 Compose
如果你的服务器还没有 Docker，可以先安装 Docker。Ubuntu / Debian 常见安装方式如下：
curl -fsSL https://get.docker.com | bash
systemctl enable docker
systemctl start docker确认 Docker 和 Compose 可用：
docker --version
docker compose version方法一：Docker Compose 一键部署，推荐
Sub2API 官方 README 推荐使用 Docker Compose 部署。这个方式会一起准备 Sub2API、PostgreSQL 和 Redis，比较适合生产环境和后续迁移。
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.local.yml、生成 .env、创建数据目录，并自动生成 JWT_SECRET、TOTP_ENCRYPTION_KEY、POSTGRES_PASSWORD 等密钥。
查看服务状态：
docker compose ps查看 Sub2API 日志：
docker compose logs -f sub2api浏览器访问：
http://你的服务器IP:8080如果后台管理员密码是自动生成的，可以在日志里查找：
docker compose logs sub2api | grep "admin password"方法二：手动 Docker Compose 部署
如果你想手动控制配置，可以克隆仓库后自己编辑环境变量：
git clone https://github.com/Wei-Shaw/sub2api.git
cd sub2api/deploy
cp .env.example .env
nano .env至少建议配置这些变量：
POSTGRES_PASSWORD=your_secure_password_here
JWT_SECRET=your_jwt_secret_here
TOTP_ENCRYPTION_KEY=your_totp_key_here
[email protected]
ADMIN_PASSWORD=your_admin_password
SERVER_PORT=8080可以用下面的命令生成随机密钥：
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初始化后台
第一次访问 http://服务器IP:8080 时，会进入初始化向导。一般需要完成数据库配置、Redis 配置和管理员账号创建。Docker Compose 脚本部署时，数据库和 Redis 通常已经在同一个 compose 网络里。
初始化完成后，建议立刻做三件事：修改管理员密码、关闭不需要的注册入口、确认 API Key 前缀和默认用户额度。
配置域名和 HTTPS
生产环境不建议直接暴露 http://IP:8080。更稳妥的方式是用 Nginx 或 Caddy 做反向代理，并配置 HTTPS。
如果使用 Nginx 反代 Sub2API，并且需要兼容 Codex CLI，官方 README 特别提醒要在 Nginx 的 http 块里加入：
underscores_in_headers on;原因是 Nginx 默认会丢弃带下划线的请求头，例如 session_id。这会影响多账号场景下的 sticky session 路由。
一个简化的 Nginx 反代示例：
server {
listen 80;
server_name api.example.com;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}配置 HTTPS 可以使用 Certbot、acme.sh 或 Caddy 自动签发证书。正式使用 API Key 和账号授权时，务必使用 HTTPS。
添加上游账号和生成 API Key
部署完成后，真正能否调用模型取决于后台是否配置了可用的上游账号或 API Key。你需要在管理后台添加对应账号类型，然后配置分组、价格、并发限制和用户 API Key。
测试时建议先创建一个低权限测试用户，给少量额度，生成一个测试 API Key，再用兼容 OpenAI 或 Anthropic 的客户端调用，确认路由、计费和日志都正常。
升级 Sub2API
如果使用 Docker Compose 部署，可以拉取最新镜像并重建容器：
docker compose pull
docker compose up -d如果你使用的是 docker-compose.local.yml，则使用：
docker compose -f docker-compose.local.yml pull
docker compose -f docker-compose.local.yml up -d备份和迁移
官方更推荐 docker-compose.local.yml，因为数据保存在本地目录，更方便备份和迁移。迁移前先停止服务：
docker compose -f docker-compose.local.yml down
cd ..
tar czf sub2api-complete.tar.gz sub2api-deploy/把压缩包传到新服务器后解压并启动：
tar xzf sub2api-complete.tar.gz
cd sub2api-deploy/
docker compose -f docker-compose.local.yml up -d安全建议
Sub2API 这类网关系统会处理 API Key、账号授权、用户余额和调用日志，不应该裸奔。至少建议做到：
第一，必须使用 HTTPS。不要让用户 API Key 在明文 HTTP 里传输。
第二，限制后台访问。后台最好只允许固定 IP、VPN 或内网访问。
第三，做好额度和并发限制。避免单个用户或单个 Key 把上游账号打爆。
第四，定期备份。至少备份 PostgreSQL 数据、Redis 关键数据、.env 和配置文件。
第五，保管好密钥。JWT_SECRET、TOTP_ENCRYPTION_KEY、数据库密码和上游账号凭据不要发到 GitHub、聊天记录或公开日志里。
自己搭建还是直接使用现成中转站
如果你只是想稳定使用 Claude Code、Codex、Gemini CLI、ChatGPT 等工具，自己搭建 Sub2API 可能有点重：你需要维护服务器、域名、HTTPS、数据库、Redis、上游账号、风控和安全策略。
如果你不想自己维护，也可以直接了解 YYLX.IO 鱼鱼连线 这类已经搭好的 AI 中转站，更适合只想稳定使用 AI 工具、不想花时间运维网关的人。
总结
使用 Sub2API 搭建 AI 中转站，最推荐的路线是 Docker Compose 部署：先准备服务器和 Docker，再运行官方 docker-deploy.sh，通过 8080 端口完成初始化，最后用 Nginx 或 Caddy 配置域名和 HTTPS。
真正上线前，请重点检查合规风险、后台权限、HTTPS、备份、并发限制和上游账号安全。中转站不是装起来就结束，后续稳定性和安全维护才是长期工作。
发表回复