手把手搭建中转站：VPS+CPA+NEW API+Docker保姆级教程

背景

随着 ChatGPT、Claude 等大型语言模型的广泛应用，用户在实际使用中常面临 API 调用不稳定、Token 消耗难以监控、地域限制等问题。为了解决这些痛点，通过搭建一个自有的 AI 中转站，用户可以将多个底层 API（如 OpenAI 的 Codex 模型）整合到一个统一的管理界面中，实现流量转发、密钥认证、用量统计和负载均衡。已有的开源项目如 CLI Proxy API（CPA）和 New API 提供了基础能力，但完整的部署涉及 VPS、Docker、反向代理、数据库、SSL 证书等多个环节，缺乏一份端到端的傻瓜式教程。本文作者在 LINUX DO 社区分享过 CPA 相关的详细教程后，应读者要求，进一步编写了这份从零开始搭建中转站的保姆级指南，帮助有一定 Linux 基础的用户快速上手。

核心内容

本教程完整演示了在腾讯云硅谷区域 2C2G VPS 上，基于 CentOS 7.6 系统，使用 Docker Compose 部署 CPA + New API + Redis + PostgreSQL 的完整流程。核心目标是将 CPA 作为认证文件管理工具和渠道，New API 作为对外服务的 Token 监控与代理节点，Nginx 和 Cloudflare 后续用于反向代理和 SSL 配置（本文主要聚焦内网部分）。具体步骤分为以下五个阶段：

1. 前期准备

• VPS 购买：选择腾讯云硅谷区域 2C2G 实例（新人优惠 99 元/年），并登录控制台查看服务器 IP。
• 连接工具：使用 FinalShell 进行 SSH 连接，利用其可视化文件管理功能减少命令行操作。
• 安全组：默认已开放 22 端口（SSH），后续需自行配置安全组规则。

2. 目录结构创建

执行命令 mkdir -p /opt/proxy/{cpa/{logs,auths},newapi/{data,logs}} && cd /opt/proxy && touch docker-compose.yml cpa/config.yaml，建立如下目录树：

/opt/proxy/
├── docker-compose.yml
├── cpa/
│   ├── logs/
│   ├── auths/
│   └── config.yaml
└── newapi/
    ├── data/
    └── logs/

3. 配置文件详解

CPA 的 config.yaml

关键参数（需修改）：

• port: 8317：CPA 监听端口。
• remote-management.allow-remote: true：允许远程访问管理接口。
• secret-key：管理密钥（明文会被自动哈希）；留空则禁用管理 API。
• api-keys：自定义 API 密钥列表。
• auth-dir: "~/.cli-proxy-api"：认证文件目录，对应挂载卷 ./cpa/auths:/root/.cli-proxy-api。
• usage-statistics-enabled: false：因使用 New API 做统计，CPA 关闭自身统计。

其他参数如 host（空字符串表示绑定所有接口）、tls.enable（false）、request-retry（3）、routing.strategy（round-robin）等可保持默认。

Docker Compose docker-compose.yml

定义了 4 个服务：new-api、redis、postgres、cpa。

• new-api：
  • 镜像 calciumion/new-api:latest，容器名 new-api。
  • 端口映射 3000:3000。
  • 卷挂载 ./newapi/data:/data 和 ./newapi/logs:/app/logs。
  • 环境变量设置 PostgreSQL 连接字符串（需修改密码）、Redis 连接字符串、时区上海，以及错误日志和批量更新开关。
  • depends_on 指定依赖 redis、postgres、cpa（注意 cpa 先启动）。
  • healthcheck 每 30 秒通过 wget localhost:3000/api/status 检测 "success": true。
• redis：标准 Redis latest 镜像，无端口映射（仅在内部使用）。
• postgres：PostgreSQL 15 镜像，设置用户 root、数据库 new-api、密码（需修改），卷挂载 pg_data。
• cpa：镜像 eceasy/cli-proxy-api:latest，卷挂载 config.yaml、auths 目录、logs 目录。无端口映射（仅作为内部渠道）。

另外，顶级 volumes 定义 pg_data 用于持久化 PostgreSQL 数据。

4. 认证文件放置

将已有的 CPA 认证文件（OAuth 登录后生成的凭据）放入 /opt/proxy/cpa/auths/ 目录下，这是 CPA 管理 OpenAI Codex 等模型认证的核心文件。

5. 防火墙与端口开放

执行以下命令确保防火墙开启并放行 3000 端口（New API 对外服务端口）：

systemctl start firewalld
systemctl enable firewalld
firewall-cmd --zone=public --add-port=3000/tcp --permanent
firewall-cmd --reload

如果防火墙未开启，则无需此步骤。后续若需 CPA 或 PostgreSQL 对外，需另行配置防火墙规则。

后续步骤预告

教程提到将继续讲解 Nginx 反向代理、Cloudflare CDN 配置、SSL 证书申请及域名绑定，本文未展开这些内容，但已为内网部署打下完整基础。

关键要点

• 核心架构：CPA 负责管理 OAuth 认证文件和底层 API 密钥，New API 负责统一管理渠道、监控 Token 消耗、对外提供 OpenAI 兼容接口，形成“CPA 做渠道 → New API 做代理”的分层结构。
• 数据库选择：教程使用 PostgreSQL（15），明确需修改 POSTGRES_PASSWORD 和 SQL_DSN 中的密码。MySQL 配置也已注释提供，可二选一。
• 健康检查：New API 内置 healthcheck 机制，确保服务自动恢复，避免单点故障无人知晓。
• CPA 端口不暴露：教程中 CPA 容器的端口映射被注释，意味着 CPA 不直接对外，仅通过内部网络供 New API 调用。这样既安全又简化防火墙配置。
• 文件目录注意事项：auth-dir 在 config.yaml 中写为 ~/.cli-proxy-api，Docker 中需映射到 /root/.cli-proxy-api；日志目录 /CLIProxyAPI/logs 必须映射，否则容器内日志不会持久化。
• 防火墙配置时机：建议在启动容器前配置，避免端口被默认拒绝。若需开放其他端口（如 5432 for PostgreSQL），需重复执行 firewall-cmd --add-port 命令。

意义与影响

1. 降低使用门槛：将 CPA（命令行工具）与 New API（图形化管理面板）有机整合，用户不再需要记住复杂的命令行参数，通过 Web 界面即可管理多个模型的 API 密钥和用量，大幅提升运维效率。
2. 开源生态优化：两个开源项目（CPA 与 New API）的联动示范，展示了如何利用容器化技术将独立组件组合成生产级服务。类似模式可推广到其他 AI 工具链的部署。
3. 成本控制与安全：通过 New API 实时监控 Token 消耗，避免盲目调用导致费用超支；使用独立的认证文件管理机制，避免主 API 密钥泄露风险。
4. 可扩展性：教程预留了 Nginx+Cloudflare+SSL 的扩展路径，后续可轻松接入 CDN 加速和 HTTPS 加密，适用于分发到多个客户端（如第三方应用、浏览器插件）。
5. 社区贡献价值：作者基于自身实践经验编写详细注释和目录结构，并针对常见坑点（如 healthcheck 端口不可修改、auths 目录映射、防火墙顺序）做出提醒，对 Linux 和 Docker 初学者极其友好，是社区高质量技术共享的典型范例。