API 公益中转 + 小商业场景：用 New API 搭建安全的密钥共享与分发平台

每到月底，AI 社群里总能看到这样的场景：买了包月订阅的朋友发现额度还剩大半，热心地发到群里免费分享。这份互助心意是好的，但直接把原始 API Key 发出去——密钥一旦流出就收不回来，被刷量也只能干瞪眼，最后吃亏的反而是愿意分享的人。

其实加一层中转就能彻底解决这个问题。本文以 New API（开源项目，GitHub 30K+ stars，one-api 的社区增强版）为例，从原理到部署、从公益共享到小商业分发，完整讲解搭建安全中转平台的全过程。

---

一、New API 是什么？一句话讲明白

你可以把 New API 理解成所有 AI 模型的「总服务台」。以前用 GPT、Claude、Midjourney 得分别注册、充值、保存不同的密钥，每个软件还要单独配置。现在把所有密钥接到 New API 里，它会统一成一套接口，你只需要一把「通用钥匙」，就能在所有 AI 工具里调用所有模型，还能统一记账、自动故障切换。

---

二、一层中转解决什么问题

先看共享池场景的工作原理——所有闲置的原始 API 密钥锁在 New API 后台，对外只发一次性的子令牌。

直接发 Key 和加一层中转的差异，一张表说清楚：

群里常见的悲剧：好心人发了 DeepSeek 的 Key，结果被某个人拿去批量跑了几百万 token，一晚上烧掉好几百块余额。加 New API 中转后这种事情不会再发生——每个人的额度锁死了，用完就停。

---

三、选型对比：为什么选 New API

市面上开源 API 网关不止一个，放一起比：

3.1 文字对比

3.2 星级评分对比

3.3 决策路径

• 只有自己在不同 Key 之间切换 → one-api（更轻量，资源占用小）
• 要把 Key 分发给别人用（共享/客户）→ New API（令牌管理是刚需）
• 公司内部多团队、需要预算审批和部门隔离 → LiteLLM（企业功能更完整）
• 只是把 API 从 A 服务器转发到 B 服务器，零管理需求 → Nginx 够了

---

四、从零搭建：完整部署指南

很多小白看到「部署」两个字就怕，其实 New API 已经把复杂度封装好了。全程不需要写代码，会复制粘贴、会点鼠标就行。

4.1 部署流程图

4.2 第一步：准备环境

• 服务器： 一台 Linux 云服务器，最低 2 核 2G（腾讯云/阿里云轻量应用服务器，约 ¥50-70/月）。1 核 1G 也能跑但 MySQL 可能 OOM。
• 系统： Ubuntu 20.04+ 或 Debian 11+，CentOS 7 也行但推荐 Ubuntu（社区踩坑少）。
• 端口： 安全组/防火墙放行 3000（New API）、80 和 443（后面配 Nginx SSL 用）。
• 域名（强烈推荐）： 几块钱一年的 .cn 域名，后面配 HTTPS。裸 IP + HTTP 跑生产环境不安全，Let’s Encrypt 免费证书几分钟就能配好。

4.3 第二步：安装 Docker

curl -fsSL https://get.docker.com | sh

装完后确认版本：

docker --version  # 应 ≥ 20.10

如果提示权限不够，把当前用户加入 docker 组：

sudo usermod -aG docker $USER
newgrp docker

4.4 第三步：编写 docker-compose.yml 并启动

在服务器上创建项目目录，把下面内容完整复制进去。只需改两处密码和两处随机字符串，其余不用动。

version: '3.8'

services:
  mysql:
    image: mysql:8.0
    container_name: new-api-mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: 改成你自己的强密码
      MYSQL_DATABASE: new_api
      TZ: Asia/Shanghai
    volumes:
      - ./mysql-data:/var/lib/mysql
    command: --default-authentication-plugin=mysql_native_password
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7-alpine
    container_name: new-api-redis
    restart: always
    volumes:
      - ./redis-data:/data
    command: redis-server --appendonly yes
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 5

  new-api:
    image: calciumion/new-api:latest
    container_name: new-api
    restart: always
    depends_on:
      mysql:
        condition: service_healthy
      redis:
        condition: service_healthy
    ports:
      - "3000:3000"
    environment:
      TZ: Asia/Shanghai
      SQL_DSN: "root:你的强密码@tcp(mysql:3306)/new_api?charset=utf8mb4&parseTime=True&loc=Local"
      REDIS_CONN_STRING: "redis://redis:6379/0"
      SESSION_SECRET: "随机字符串一至少16位"
      CRYPTO_SECRET: "随机字符串二至少16位"
    volumes:
      - ./new-api-data:/data

⚠️ SESSION_SECRET 和 CRYPTO_SECRET 必须改成随机值，别用示例。用 openssl rand -hex 16 生成。

保存后启动：

docker compose up -d

等待约 1 分钟让 MySQL 初始化和健康检查通过。查看状态：

docker compose ps
# 三个容器都显示 Up 和 healthy 才算成功

如果 new-api 容器反复重启，看日志定位问题：

docker compose logs new-api --tail 50

4.5 第四步：初始化后台

浏览器访问 http://你的服务器IP:3000：

1. 首次访问进入初始化向导，设置管理员账号密码
2. 模式选择「自用模式」——这是最简单的模式，省去复杂的多用户权限配置
3. 进入后台后，左侧菜单「渠道管理」→「添加渠道」
4. 渠道类型选「OpenAI」（99% 的第三方订阅都兼容 OpenAI 接口格式）
5. 填入上游提供的 Base URL 和 API Key，勾选支持的模型
6. 点「测试」验证连通性，通过后保存

4.6 第五步：配置 HTTPS（生产必备）

裸 HTTP 跑生产环境是安全隐患——中间人攻击可以直接窃取 API Key。用 Nginx + Certbot 几分钟就能配好 HTTPS。

安装 Nginx 和 Certbot：

sudo apt install -y nginx certbot python3-certbot-nginx

创建 Nginx 反向代理配置：

sudo nano /etc/nginx/sites-available/new-api

写入以下内容（把 api.example.com 换成你的域名）：

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        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;
        proxy_read_timeout 300s;
        proxy_buffering off;
    }
}

启用站点并申请证书：

sudo ln -s /etc/nginx/sites-available/new-api /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d api.example.com

Certbot 会自动修改 Nginx 配置加上 SSL，证书每 90 天自动续期。

配完 HTTPS 后别忘了把 3000 端口从安全组关掉——所有流量走 Nginx 443 端口进，不用再暴露 3000。

---

五、公益共享池配置实战

5.1 接入闲置 API

所有兼容 OpenAI 接口格式的订阅都能接入。步骤：

1. 后台 →「渠道管理」→「添加渠道」
2. 渠道类型选「OpenAI」
3. 填写 Base URL 和 API Key
4. 勾选支持的模型，点「测试」
5. 测试通过后保存

可以同时接入多个渠道。例如同时接入小米包月 + DeepSeek 余量 + 某个第三方中转。系统会自动负载均衡——单个渠道挂了不影响整体使用。

渠道分组技巧： 如果某些渠道只愿意分享给熟人、某些可以公开分享，用「渠道分组」功能做隔离。在创建令牌时指定只能访问哪个分组的模型。

5.2 生成安全分享令牌

这一步最关键——分享出去的不是原始密钥，是你生成的子令牌。

1. 后台 →「令牌管理」→「添加令牌」
2. 令牌名称： 方便区分，如「7 月末共享-通用版」
3. 剩余额度： 按人头设。例如总余量 1000 万，分给 10 人，每人设 80 万（留 200 万做缓冲）
4. 过期时间： 统一设为当月最后一天 23:59:59，到点自动失效
5. 可使用模型： 只勾选愿意分享的模型。高价模型（GPT-4o、Claude Opus 等）默认不开放
6. IP 白名单（可选）： 如果使用群体固定，可以加 IP 白名单进一步增强安全性
7. 点击提交，生成令牌字符串

5.3 发给群友

只需要发两样东西：

• 接口地址： https://你的域名/v1（配了 HTTPS 的话）或 http://你的IP:3000/v1
• API Key： 刚生成的子令牌字符串

对方拿到后填到任意支持自定义 OpenAI 接口的客户端（ChatGPT-Next-Web、LobeChat、Cherry Studio 等）就能用。

重要提醒： 发之前测试一下——自己先在客户端里用子令牌调一次，确认能通再发。别发出去才发现令牌配错了。

---

六、小商业场景实操

同一套 New API 部署，不仅能做公益共享，还能支撑小规模商业分发。以下是三个已验证可行的场景。

6.1 场景一：小团队内部 API 管理

几个朋友合买一个 API 订阅，每个人用不同令牌、各自额度独立核算。

配置方式： - 接入共享订阅到渠道 - 为每人创建独立令牌，额度按出资比例分配 - 所有人在各自的 AI 客户端填自己的令牌

好处： 谁用超了不影响别人，费用透明，月底直接看每个令牌的消耗统计就行，不用手动算账。

6.2 场景二：小规模客户 API 分发

接了几个小外包项目或者有几个稳定客户，需要给他们提供 API 接入。

定价参考（2024 年末行情）：

配置方式： - 在「令牌管理」为每个客户创建令牌，额度 = 套餐额度 - 过期时间按月设（如 30 天后），续费后更新过期时间 - New API 后台支持自定义模型定价倍率，可以对不同模型设不同的利润率

客户自助方案（进阶）： New API 支持「在线支付」和「卡密兑换」功能。配上微信/支付宝支付后，客户可以自己充值、自己兑换，你只需要定期检查渠道余额——完全自动化运营。

6.3 场景三：多项目成本核算

同时跑好几个项目，每个项目用不同令牌，方便月底按项目统计 API 成本。

配置方式： - 每个项目一个令牌，名称标注项目名 - 月初记录各令牌的初始额度 - 月底在「日志」页面按令牌筛选，导出用量报表 - 直接按实际消耗向甲方收费或内部记账

⚠️ 合规边界提醒

• 个人之间小范围公益共享、不涉及盈利，属于互助行为，风险低
• 小规模对外分发 API、收取合理服务费，属于技术服务范畴，一般没问题
• 不要以远低于上游官方的价格公开兜售 API 接入——可能违反上游厂商的服务协议
• 如果涉及支付收款，记得正常报税

---

七、核心功能全景

New API 不止是一个转发代理，它的功能覆盖了从接入到运营的完整链路。

---

八、踩坑实录

以下是搭建和运维中真实遇到过的坑，帮你节省排查时间。

坑1：MySQL 容器无限重启，健康检查失败

现象： docker compose up -d 后 MySQL 反复重启，new-api 容器一直等 MySQL 就绪但等不到。

根因： 权限问题。MySQL 数据目录 ./mysql-data 如果之前被 root 用户创建过，容器内的 mysql 用户没有写入权限。

解决：

sudo chown -R 999:999 ./mysql-data   # 999 是容器内 mysql 用户的 UID

如果问题依旧，删掉数据目录重新初始化：

docker compose down -v   # -v 会删除数据卷，谨慎
docker compose up -d

坑2：数据库密码含特殊字符导致连接失败

现象： new-api 日志报 SQL_DSN 连接错误，但密码确认没写错。

根因： SQL_DSN 是 URL 格式，密码中的 @ : / ? # [ ] % 需要 URL 编码，否则解析错误。

解决： 数据库密码只用纯字母数字。用 openssl rand -hex 16 生成的就是这种格式。

坑3：配了 HTTPS 后 API 调用全部 502

现象： 浏览器访问域名正常，但客户端调 API 报 502 Bad Gateway。

根因： Docker 的 ports: "3000:3000" 绑定在 0.0.0.0:3000，但 Nginx proxy_pass http://127.0.0.1:3000 走的是 lo 接口。某些云服务器上 Docker 默认不监听 lo。

解决： 确认 New API 容器在监听：

docker compose exec new-api netstat -tlnp | grep 3000
# 应该看到 0.0.0.0:3000 或 :::3000

如果连接不上，改用 Docker 内部网络——在 docker-compose.yml 的 new-api 服务中去掉 ports，在 Nginx 配置里用 proxy_pass http://new-api:3000;（容器名作为主机名），然后给 Nginx 也加到同一个 compose 网络里。

更简单的方式： 直接用 proxy_pass http://172.17.0.1:3000;（Docker 默认网桥网关），不用改 compose。

坑4：忘记关 3000 端口导致被扫

现象： 服务器流量异常，日志里大量来自陌生 IP 的请求。

根因： 配完 Nginx HTTPS 后忘了从安全组里关掉 3000 端口，New API 直接暴露在公网上。自动化扫描脚本找到 3000 端口后不断尝试弱密码登录。

解决： 1. 立刻去云控制台安全组删除 3000 端口的入站规则 2. 改掉管理员密码为强密码 3. 打开 New API 后台的 2FA 双因素认证

教训： Nginx HTTPS 配完后的第一步就应该是关掉 3000 端口——所有流量走 Nginx 443。New API 管理后台绝对不要裸奔在公网上。

坑5：pandoc 生成的 HTML 中表格溢出移动端

现象： 手机上打开文章，表格撑爆屏幕宽度，需要横滑但体验很差。

根因： 内容中的 <table> 没有包裹 overflow wrapper，移动端没有横向滚动机制。

解决： 文章发布时对所有 <table> 加 overflow wrapper——这个已纳入经验分享发布技能的标准样式修正步骤，不会遗漏。

---

九、安全加固 checklist

部署完成 ≠ 完事。以下 6 项加固做得越多，睡得越踏实。

---

十、成本分析

公益共享池 10 人分摊，每人每月不到 ¥6。小商业场景下，一个客户月费 ¥30 就能覆盖全部成本 + 有利润。

---

十一、运维 checklist

每天 30 秒 + 每周 1 分钟 + 每月 2 分钟：

每日（30 秒）： 后台看一眼总用量和剩余额度。某令牌用量异常飙升 → 立刻吊销。

每周（1 分钟）： 测试各渠道连通性（后台点测试按钮）。挂掉的渠道及时下线。

每月第一天（2 分钟）： 上月令牌已自动过期，生成本月新令牌。备份数据库：

docker exec new-api-mysql mysqldump -uroot -p'你的密码' new_api > backup-$(date +%Y%m).sql

把备份文件下载到本地——别只放在服务器上，服务器故障一起丢。

---

十二、常见问题

问：对方拿到子令牌能反查我的原始 Key 吗？

不能。调用链路是「用户 → New API → 上游渠道」，子令牌是 New API 自己生成的凭证，用户在任何一个环节都接触不到上游原始 Key。

问：多个渠道同时用，费用怎么算？

New API 不修改上游计费逻辑，是透明代理。上游扣多少就是多少。但 New API 有自己的「倍率」系统——你可以对上游 $1 的成本设 1.5x 倍率，让客户看到 $1.5 的消耗，差价就是你的利润。

问：有没有免费的部署方式？

Railway、Render 有免费额度但不够跑 MySQL + Redis + New API 三个容器。最省钱的方案还是轻量云服务器 ¥50/月，而且所有 side project 都能扔上去。

问：能限制每人每天的调用次数吗？

New API 原生支持总量限制和过期时间限制。按日/IP 限频需要额外在 Nginx 层面配 rate limiting。

问：和 ChatGPT-Next-Web 这类客户端冲突吗？

不冲突。New API 是后端网关，Next-Web 是前端 UI，刚好搭配。在 Next-Web 里填 New API 的接口地址 + 子令牌就行。

问：New API 和 one-api 是什么关系？

New API 是 one-api 的社区增强版（fork 后大量改进），原作者 songquanpeng 的 one-api 更新已放缓。New API 新增了多模态支持、商业运营功能、更好的 UI。新部署的话选 New API。

问：如果上游渠道被封了怎么办？

所有渠道的原始 Key 都在你手里，换一个上游供应商重新添加渠道就行，子令牌完全不用动——使用者无感知。这就是多加一层中转的好处：对于下游用户，上游换了哪家供应商他们完全不知道也不关心。

---

最后

有额度闲置分享是好事，但直接发原始 Key 就像把银行卡密码贴到群里——不是不信任大家，是没必要冒这个风险。加一层 New API 中转，花一次部署的时间，换长期安心。

公益共享也好，小团队管理也好，甚至接几个小外包项目也好，同一套方案都能覆盖。希望这篇文章能让更多人既分享资源，又保护好自己。

有问题去 New API 的 GitHub Issues 搜或提，社区响应很快。搭建遇到卡点也可以来评论区交流。

---

New API 项目地址：github.com/Calcium-Ion/new-api

本文涉及的 docker-compose.yml 完整配置可在此处复制：[配置直达链接]