Sub2API：自带支付系统的新一代 AI API 网关

sub2apiAPI网关AI中转支付系统OpenAI兼容PostgreSQLRedis教程
# Sub2API 概述 ## 是什么 - AI API 网关与订阅分发平台 - Go + Vue 3 + PostgreSQL + Redis - 开源，GitHub 活跃开发中 - 官方演示：demo.sub2api.org ## 核心功能 - 多账号管理（OAuth + API Key） - API Key 分发与鉴权 - Token 级精确计费 - 智能调度 + 粘性会话 - 内置支付（易支付/支付宝/微信/Stripe） - 并发控制 + 速率限制 - Web 管理面板 + Setup Wizard ## 三工具横评 - CLIProxyAPI：OAuth 转 API 代理 - new-api：轻量 AI API 网关 - Sub2API：商业级 API 网关平台 - 关键差异：部署复杂度、支付系统、数据库 ## 部署方式 - 一键脚本安装（推荐） - Docker Compose（含 PG + Redis） - 安装向导自动配置 ## 选型指南 - 个人自用 → CLIProxyAPI - 小团队 → new-api - 对外商业运营 → Sub2API - 三者可串联使用

什么是 Sub2API

Sub2API 是一个开源的 AI API 网关平台，专门用于分发和管理 AI 订阅配额。用户通过平台生成的 API Key 访问上游 AI 服务，平台负责认证、计费、负载均衡和请求转发。

和 new-api 做的事情类似——把上游 API 统一成一个端点，做用户管理、计费——但 Sub2API 的定位更偏向"开箱即用的商业运营平台"。

flowchart LR U1["用户 A\nAPI Key"] --> S2["Sub2API :8080\n鉴权 / 计费 / 限流"] U2["用户 B\nAPI Key"] --> S2 U3["用户 C\nAPI Key"] --> S2 S2 --> CH1["Claude OAuth 账号池"] S2 --> CH2["OpenAI API Key 池"] S2 --> CH3["Gemini 账号池"] S2 --> PAY["内置支付\n支付宝 / 微信 / Stripe"]

三工具横评：CLIProxyAPI vs new-api vs Sub2API

三个工具都围绕"把 AI 订阅/API 统一分发给多用户"这个目标，但落在不同位置：

维度 CLIProxyAPI new-api Sub2API
定位 OAuth 订阅 → OpenAI API 代理 轻量级 AI API 网关 商业级 AI API 网关平台
后端 Rust / Go Go Go 1.25
前端 管理面板（静态 HTML） React Vue 3.4 + TailwindCSS
数据库 无（凭证文件） SQLite / MySQL PostgreSQL 15+
缓存 无 无 Redis 7+
用户系统 无（只有 api-keys） 内置（管理员/普通用户） 内置（管理员/普通用户）
计费 无 Token 级（手动配置） Token 级（模型独立定价）
支付 无 无（需自建，见 new-api 系列 9、10 篇） 内置（易支付/支付宝/微信/Stripe）
限流 无 QPM 限制 QPM + 并发数双重控制
多账号调度 round-robin / fill-first 优先级 + 权重 优先级 + 权重 + 粘性会话
部署 单二进制 ~10MB 单二进制 ~25MB 二进制 + PG + Redis
内存占用 <15MB ~50MB ~200MB（含 PG + Redis）
5 分钟上手 是 是 否（需 PG + Redis）
移动端 无 无 sub2api-mobile
适合规模 个人 ~ 5 人 5 ~ 50 人 50 人以上 / 商业运营

一句话定位

  • CLIProxyAPI：把 OAuth 订阅变成 API 端点。没有用户系统、没有计费——就是纯代理层。
  • new-api：在代理层之上加了用户管理、计费、限流。轻量，适合小团队，但支付需要自己搭。
  • Sub2API：完整商业平台。自带支付、PG + Redis 高并发、粘性会话——开箱就能卖 API。
flowchart LR Q{"你的需求?"} -->|"自己用\n没几个人"| CPA["CLIProxyAPI\n纯代理，零管理开销\n内存 <15MB"] Q -->|"小团队内部\n需要计费"| NA["new-api\n用户 + 计费 + 限流\n单二进制部署"] Q -->|"对外卖 API\n需要支付"| S2["Sub2API\n内置支付 + PG + Redis\n商业就绪"]

核心功能详解

多账号管理

支持两种上游账号类型：

  • OAuth 账号：Claude Pro、Gemini、Codex 等订阅账号，通过 OAuth 登录后纳入账号池
  • API Key 账号：OpenAI、Anthropic 等商业 API Key

多个同类型账号自动轮询，配合粘性会话让同一会话的请求尽量落在同一账号上，充分利用 Prompt Cache。

内置支付系统（最大亮点）

这是 Sub2API 相比 new-api 最显著的差异。它把支付系统做进了平台内部，不需要像 new-api 那样另外部署回调服务、写充值页面。

支持的支付渠道：

渠道 说明
易支付 国内个人站长最常用的聚合支付
支付宝 官方接口
微信支付 官方接口
Stripe 国际信用卡支付

用户在前端选择套餐 → 扫码/跳转支付 → 支付回调直接更新 Sub2API 内的余额 → 额度即时生效。零外部依赖。

sequenceDiagram participant U as 用户 participant S2 as Sub2API participant PAY as 支付宝/微信/Stripe U->>S2: 选择套餐，发起充值 S2->>PAY: 创建支付订单 PAY-->>S2: 返回支付链接/二维码 S2-->>U: 展示支付页面 U->>PAY: 完成付款 PAY->>S2: 异步回调通知 S2->>S2: 验证签名，更新用户余额 S2-->>U: 显示充值成功

之前社区有一个独立的 Sub2ApiPay 项目专门做支付，现已合并进主仓库成为内置功能。

Token 级精确计费

Sub2API 按实际 Token 消耗量计费，输入和输出 Token 分开计价。管理员可以为每个模型设置独立价格，也可以按用户分组设置倍率（类似 new-api 的分组倍率）。

智能调度与粘性会话

多账号场景下，Sub2API 的调度策略比简单的 round-robin 更智能：

  • 粘性会话（Sticky Sessions）：通过 session_id 头将同一会话的请求绑定到同一上游账号，最大化 Prompt Cache 命中率，减少重复计费
  • 故障转移：某个账号触发限流或报错时自动切换到其他可用账号
  • 权重分配：可以给不同账号设置不同权重

Nginx 用户注意：Nginx 默认丢弃带下划线的请求头（如 session_id），需要在 http 块加 underscores_in_headers on;

并发控制与速率限制

双重限流机制：

  • 按用户限流：每个 API Key 可以设置独立的 QPM 和并发数
  • 按上游账号限流：防止单个 OAuth 账号被过多请求打爆

部署

方式一：一键脚本安装（推荐）

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

脚本自动检测架构、下载二进制、创建 systemd 服务。前置条件：PostgreSQL 15+ 和 Redis 7+ 已运行。

安装完成后：

sudo systemctl start sub2api
sudo systemctl enable sub2api
# 浏览器打开 http://YOUR_SERVER_IP:8080

首次访问会进入 Setup Wizard，引导配置数据库、Redis、管理员账号。

方式二：Docker Compose

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

# 自动部署脚本（下载 docker-compose.yml + 生成 .env）
curl -sSL https://raw.githubusercontent.com/Wei-Shaw/sub2api/main/deploy/docker-deploy.sh | bash

# 启动
docker compose up -d

脚本自动完成：下载 compose 文件、生成 JWT/TOTP/PostgreSQL 密钥、创建数据目录。

两种 Compose 文件的区别

文件 数据存储 迁移
docker-compose.local.yml 本地目录 tar 整个文件夹即可搬家
docker-compose.yml Docker named volumes 需 docker cp 操作

生产环境推荐 local 版本，备份和迁移更方便。

升级

Sub2API 支持在管理面板内一键升级：左上角点「Check for Updates」→ 检测新版本 → 一键下载更新。也支持回滚。Docker 用户直接 docker compose pull && up -d。

技术栈

组件 技术
后端 Go 1.25、Gin、Ent ORM
前端 Vue 3.4+、Vite 5+、TailwindCSS
数据库 PostgreSQL 15+
缓存/队列 Redis 7+

PostgreSQL + Redis 的组合比 new-api 的 SQLite 更接近企业级，但代价是部署时需要额外维护这两个服务。

生态项目

项目 说明
sub2api-mobile 移动端管理 App（iOS/Android/Web），Expo + React Native 构建，支持用户管理、账号管理、监控面板
内置支付 原 Sub2ApiPay 项目已合并入主仓库，不再需要单独部署

官方演示环境

Sub2API 提供了在线 Demo：https://demo.sub2api.org/

邮箱 密码
admin@sub2api.org admin123

可以直接体验管理面板、支付流程等功能（共享演示环境，不要存敏感数据）。

选型决策指南

按规模和需求

场景 推荐方案 原因
个人自用，只自己一个人 CLIProxyAPI 零管理开销，内存 <15MB
3~5 个朋友共享订阅 CLIProxyAPI + 手动分发 api-key 够用，不值得上网关
小团队（5~20 人），需要计费但不需要支付 new-api 单二进制部署，SQLite 零维护
小团队，偶尔需要支付 new-api + V免签/易支付 参考 new-api 系列第 9 篇
对外商业运营（20~200 人），需要支付 Sub2API 内置支付，PG + Redis，开箱即卖 API
对外商业运营，已有 new-api 且不想迁移 new-api + Stripe/PayPal 参考 new-api 系列第 10 篇
需要移动端管理面板 Sub2API 社区 sub2api-mobile
已有大量 OAuth 订阅账号，想统一分发 CLIProxyAPI 做代理层，网关做管理层 串联部署

组合使用

三个工具可以串联：

Claude Pro / Gemini OAuth 订阅
        |
CLIProxyAPI（OAuth 转 API，账号轮询）
        |
Sub2API 或 new-api（用户管理 / 计费 / 支付）
        |
  用户 A / 用户 B / 用户 C

CLIProxyAPI 负责把 OAuth 订阅转成 API 端点，Sub2API（或 new-api）负责用户管理、计费和支付。两者互补而非替代。

迁移路径

个人自用：CLIProxyAPI（零管理开销） | 不够用就加一层 v 小团队共享：new-api（用户 + 计费） | 需要支付就升级 v 对外商业运营：Sub2API（内置支付 + PG + Redis）

社区反馈与口碑

以下是截至 2026 年 6 月，三个项目在 GitHub 上的数据快照和社区讨论热点。

数据概览

指标 CLIProxyAPI new-api Sub2API
Stars 36K 37K 26K
Forks 6.0K 8.5K 5.0K
开放 Issues 416 771 1,487
最近更新 今天 今天 今天

三个项目都处于活跃开发状态。new-api 的 fork 数最高（8.5K），说明社区二次开发最活跃。Sub2API 的开放 issue 最多（1487），部分原因是用户基数大且功能模块多。

CLIProxyAPI — 聚焦代理层，痛点集中在模型兼容性

定位准确，满意度高。CLIProxyAPI 恪守"只做代理不做管理"的边界，功能范围最小、出问题的面也最窄。

社区高频讨论：

  • Codex 认证下的 GPT 模型卡死（150 条讨论）：通过 Codex OAuth 调用 GPT 模型时偶发卡死无响应，是目前社区最热的议题
  • Antigravity 账号有额度但返回 429（51 条讨论）：Google 订阅账号的配额检测机制偶有误判，实际有额度却被限流
  • Resource exhausted 误报（59 条讨论）：部分账号明明有余额，上游仍返回配额耗尽

社区评价关键词：轻量、稳定、功能边界清晰、多账号轮询好用。主要抱怨集中在特定模型的兼容性 edge case 上。

new-api — 部署最简单，V1 界面争议大

上手门槛最低，单二进制 + SQLite 的组合让很多非技术用户也能跑起来。

社区高频讨论：

  • V1 新版界面集中反馈帖（36 条讨论）：new-api 最近更新了前端 UI，部分老用户对新版操作习惯有意见，团队开了集中帖收集反馈
  • 日志无自动清理导致数据堆积几十 GB：使用 SQLite 的用户在请求量上来后，日志表快速膨胀，需要手动清理
  • OpenAI→Claude 协议转换丢 cache_control：多协议转换时 Prompt Cache 命中率下降，影响成本和延迟
  • Stripe 支付可配置化：社区呼吁 Stripe 支持微信/Alipay 支付方式可配置

社区评价关键词：易部署、UI 好看（新版）、日志胀库是坑、协议转换偶有损耗。new-api 最多的反馈是"功能要有、但又不要太复杂"，团队在这条线上走得比较稳。

Sub2API — 功能最全，但稳定性是代价

商业就绪度最高，内置支付 + PG + Redis 的组合让它可以开箱即用跑商业服务。但功能覆盖面越广，出问题的点也越多。

社区高频讨论：

  • 版本更新后 Claude 封号严重（19 条讨论）：某次更新后，通过 Sub2API 调用的 Claude 账号被封率明显上升，社区讨论集中在如何降低封号风险
  • 有额度却报 "No available accounts"（19 条讨论）：调度层偶发误判账号不可用，实际账号池有剩余额度
  • 钉钉登录绑定报错（21 条讨论）：OAuth/SSO 集成时偶发绑定失败
  • Team 账号导入相互覆盖：同 Team 下多成员导入时后导入的账号覆盖前面的，需要手动处理
  • 社区功能请求活跃：gRPC 插件架构、Composite Group（跨协议路由）、订阅套餐支持等需求都在积极讨论中

社区评价关键词：功能齐全、支付省心、封号风险需关注、issue 多但团队响应快。

三工具口碑总结

维度 CLIProxyAPI new-api Sub2API
稳定性 最高（单一职责） 中（偶有协议转换损耗） 中（功能多做多）
部署体验 简单 最简单 较复杂（需 PG+Redis）
社区活跃度 高 最高 高
Issue 积压 低（416） 中（771） 高（1487）
团队响应 中 快 快
适合谁 懂技术的个人用户 不想折腾的小团队 愿意投入运维的商业运营者

社区共识

  1. 三个工具不是替代关系，是分层关系：社区里最常见的架构是 CLIProxyAPI 做代理层 + new-api 或 Sub2API 做管理层
  2. 封号问题是行业通病：不是某个工具的问题，而是上游 Anthropic/Google 的风控策略在收紧，所有中转工具都受影响
  3. PG + Redis 是商业化的必要代价：SQLite 在小规模够用，但一旦日志上千万行或者并发上两位数，切 PG 是早晚的事
  4. 支付内置是 Sub2API 最大的差异化优势：new-api 社区里关于支付的讨论一直在诉求内置，但团队目前没有这个计划

实操清单

  • 了解 Sub2API 与 new-api 的关键差异
  • 确认服务器已安装 PostgreSQL 15+ 和 Redis 7+
  • 选择部署方式（脚本安装 / Docker Compose）
  • 通过 Setup Wizard 完成初始化配置
  • 添加上游账号（OAuth 登录或 API Key 导入）
  • 配置模型价格（输入/输出 Token 分别定价）
  • 创建 API Key 分发给用户
  • 配置支付渠道（易支付 / 支付宝 / 微信 / Stripe）
  • 测试完整链路：用户注册 → 充值 → 调用 API → 查看日志
  • 如用 Nginx 反代，加 underscores_in_headers on;