全网最全AI中转站自建教程：我用 New API 从 VPS 部署到上游接入、模型定价和支付收款

视频教程：https://youtu.be/A68OxDv818k

✦VPS选购攻略▶ https://redman.blog/index.php/cn2vps/ 

✦中转站上游资源▶https://codex3721.com/ai-api-review  

✦Zpay个人支付网关▶https://i.redman3721.com/zpay 

✦服务器ssh连接工具下载▶https://www.hostbuf.com/t/988.html 

✦CN2GIA线路购买▶https://i.redman3721.com/banwagon   （视频同款）

很多人问我：既然平时就在用 AI 中转站，能不能自己搭一个，把不同平台的模型接进来，用自己的地址和 API Key 统一调用？如果以后想开放给其他人使用，分组、定价和收款又该怎么设置？

这次我把自己的搭建流程整理成一篇完整教程。我会先准备 VPS 和 Docker，把 New API 跑起来，再接入上游、配置模型价格，最后打通支付和客户端调用。只想自用，可以跳过支付部分；打算对外运营，就需要继续处理用户、账单、维护和服务支持。

我希望你最终能独立跑通这条链路：客户端 → 自己的 New API → 获得授权的上游模型服务。软件部署只是其中一环，能正常调用、价格算得清楚、发生错误时知道查哪里，才算真正上手。

一、我为什么选择 New API

我把 New API 当作统一的模型入口：上游可以是模型厂商的官方 API，也可以是经过核验、允许相应用途的兼容接口；下游则是我的客户端、应用或团队用户。

这样做以后，我可以在后台调整渠道、模型和分组，而不用每次更换上游都重新修改所有客户端。自用时，我主要关注统一入口与用量管理；对外提供服务时，我还需要关注用户额度、价格、支付和维护。

另一个经常被问到的项目是 Sub2API。在我的选型思路里，如果主要任务是管理相应平台支持的账号接入与账号池，我会另外评估 Sub2API；如果已经有可用的上游 API，重点是聚合渠道、管理密钥和计费，这篇 New API 流程更直接。具体能接哪些账号、支持哪些能力，仍要看各项目版本和上游授权条件。

New API 官方仓库：

✦ New-api官方仓库 ▶ https://github.com/QuantumNous/new-api

二、准备 VPS、域名与上游账号

1. 服务器先看实际线路，再看参数

我的用户主要使用中文环境，选服务器时会特别关注国内访问表现。CPU 核数之外，我还会比较网络线路、带宽、流量、机房位置，以及服务器到上游接口之间的连通性。

我这次用搬瓦工的 CN2 GIA 线路作为演示方案，也会比较 DMIT 同类产品。购买时要看清具体套餐和路由说明，不能只看到商家名字就默认所有产品都有同样的线路。价格和库存变化很快，我不会把某次看到的月费写成长期保证。

小规模学习可以从入门配置开始，但 New API、数据库和 Redis 同机运行时，我会观察内存占用与重启情况，再决定是否升级。低配机器可以跑起来，并不代表能承受大量并发。

✦ VPS选购攻略 ▶ https://redman.blog/index.php/cn2vps/

✦ CN2GIA线路购买（本次演示同款）▶ https://i.redman3721.com/banwagon

2. 开始前把资料放在手边

上游密钥、服务器密码和商户密钥，我会分别保存，不放进公开文章、截图或聊天记录。

三、用 SSH 连接服务器

服务器开通后，我先在服务商控制台确认 IP、SSH 端口和系统。需要重装系统时，我只对新机器或已经完成备份的机器操作；重装会清空系统盘，不能把它当成普通重启。

我可以使用 FinalShell，也可以用系统自带的 SSH 客户端。FinalShell 的优点是终端与文件管理放在同一个界面，刚开始操作 VPS 更直观。

✦ 服务器SSH连接工具下载（FinalShell）▶ https://www.hostbuf.com/t/988.html

在 FinalShell 里，我新建 SSH 连接，填写主机 IP、服务商提供的端口和登录用户名，再选择密码或密钥认证。首次连接出现主机指纹提示时，我会先与服务商提供的指纹核对。

使用终端时，连接形式如下，把示例 IP、用户和端口替换成自己的值：

ssh -p 22 [email protected]

连上以后，我先确认系统，避免把 Debian 和 Ubuntu 的软件源混用：

cat /etc/os-release
uname -m
free -h
df -h

下面安装命令以 Debian 的 root 会话为例；如果我使用有 sudo 权限的普通用户，会先运行 sudo -i 进入管理员会话。不要在 Windows 本机终端直接执行服务器上的 APT 安装命令。

四、安装 Docker 与 Compose

1. 在 Debian 配置 Docker 官方软件源

我按 Docker 官方 APT 安装流程准备证书、下载签名文件，再添加对应系统的软件源。以下适用于官方支持的 Debian 稳定版新服务器；已有 Docker 或其他容器软件的机器，先按官方说明检查软件包冲突。

apt update
apt install -y ca-certificates curl git nano openssl
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

我将这些步骤分开执行，前一步没有报错再继续。这里安装的是 Compose 插件，所以后面使用带空格的 docker compose 命令。

✦ Docker官方Debian安装说明 ▶ https://docs.docker.com/engine/install/debian/

2. Ubuntu 不能照抄 Debian 软件源

如果我的 VPS 是 Ubuntu，我会改用 Ubuntu 官方安装页。关键差异包括 GPG 与软件源 URL 中的 ubuntu，以及发行版代号的读取方式。不要先执行上面的 Debian 源配置，再额外叠加一套 Ubuntu 源。

✦ Docker官方Ubuntu安装说明 ▶ https://docs.docker.com/engine/install/ubuntu/

3. 确认 Docker 安装完成

systemctl status docker --no-pager
docker --version
docker compose version
docker run --rm hello-world

如果服务没有运行，我再执行 systemctl start docker。hello-world 能正常打印成功信息，说明容器引擎的基础运行已经通过；如果这里就拉取失败，我会先解决镜像下载与网络问题。

五、部署 New API 并完成初始化

1. 下载项目

我把部署目录放到 /opt，后续命令都在这个目录里执行：

cd /opt
git clone https://github.com/QuantumNous/new-api.git
cd new-api
nano docker-compose.yml

如果 /opt/new-api 已经存在，我会先确认里面是否有正在使用的实例，不直接覆盖。官方仓库的 Compose 配置包含 New API、PostgreSQL 和 Redis；克隆完成后先检查配置，再启动。

✦ New API官方Compose部署说明 ▶ https://docs.newapi.ai/zh/docs/installation/deployment-methods/docker-compose-installation

2. 启动前修改密码和端口

我重点检查以下位置，字段以刚下载的配置文件为准：

我可以用下面的命令生成随机值，分别用于需要修改的密码或密钥；每次用途各自生成并妥善记录：

openssl rand -hex 32

数据库初始化以后，再改 Compose 中的密码文本，并不会自动修改已有数据库账号密码。因此我会在首次启动前完成密码调整。

常见端口映射是 3000:3000，左边是服务器端口，右边是容器端口。如果我改成 3001:3000，浏览器应访问服务器的 3001，而不是 3000。正式使用域名和反向代理后，我会考虑改为 127.0.0.1:3000:3000，让同机代理访问，外部用户统一走 HTTPS。

配置文件中的环境变量要真正传进容器。只复制一份 .env 文件，并不代表里面所有变量都会自动注入；我会检查 Compose 的 environment 或 env_file 引用。

✦ 官方Compose配置文件 ▶ https://github.com/QuantumNous/new-api/blob/main/docker-compose.yml

3. 启动服务并检查日志

docker compose config -q
docker compose up -d
docker compose ps
docker compose logs --tail=100 new-api

config -q 用来检查配置语法；up -d 拉取镜像并在后台启动；ps 查看各服务状态。我不会只看到下载进度结束就认定部署完成，还会检查是否反复重启，以及日志有没有数据库连接错误。

需要持续观察日志时，我执行：

docker compose logs -f new-api

这里按 Ctrl+C 只是退出日志查看，不会停止已经在后台运行的服务。

4. 打开初始化页面

使用默认端口映射时，浏览器地址形式为：

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

我先在服务商防火墙或安全组里限制管理访问来源，及时完成初始化。若端口只绑定到 127.0.0.1，公网 IP 直接访问不到是正常的，需要通过反向代理或 SSH 隧道访问。

初始化时，我按页面创建管理员账号和密码。只给自己使用就选择对应模式；要了解完整的站点功能，可以选择对外运营模式。这个选项影响功能配置，本身并不代表已经具备对外经营资格。

完成后刷新页面，使用刚创建的账号登录后台。做到这里，我得到的是一个可管理的站点，接下来还要添加能调用的上游。

六、添加上游渠道与模型

1. 先准备上游的地址、密钥和余额

我可以接官方 API，也可以评估其他兼容接口。挑选上游时，我会同时看模型能力、计费、延迟、错误率、日志与售后，再用小额度验证。价格便宜或榜单靠前，都不能替代实际测试。

我维护的资源页可以作为筛选入口，但我仍会去各家的页面确认模型、分组和使用条件：

✦ 中转站上游资源 ▶ https://codex3721.com/ai-api-review

我这次用 MetaRouter 演示接入思路：注册并登录后，先确认账户有可用余额，再在后台创建 API Key。如果创建密钥时可以选分组，我会核对该分组对应的模型与价格，而不是直接接受默认值。

需要记下三项内容：上游 API 基础地址、属于正确分组的密钥、这个密钥实际能调用的模型。上游官网首页网址不一定就是 API 地址，我会从控制台或接口文档复制。

2. 回到自己的 New API 创建渠道

在后台进入渠道管理，点击创建渠道。对于本次使用的 OpenAI 兼容接口，我按下面的逻辑填写：

这里有一个容易混淆的地方：New API 渠道里的上游地址，与客户端连接 New API 的地址，不一定采用同样的 /v1 写法。 我会分别看两端的字段提示，不把一个配置框里的地址原封不动复制到所有地方。

获取模型列表后，我只开放准备测试和使用的模型，再保存渠道。模型能被列出来，不等于所有接口能力都能通过，还要继续测试实际请求。

3. 测试渠道连接

我先运行后台的连接测试。如果测试失败，优先检查密钥是否复制完整、上游余额是否足够、模型是否属于该分组，以及 VPS 是否能访问上游地址。

连接测试通过后，我再去游乐场发送一条简单请求。如果提示模型没有价格，下一步就去配置模型定价，不要反复重建渠道。

✦ New API官方渠道管理说明 ▶ https://docs.newapi.ai/zh/docs/guide/feature-guide/admin/channel

七、配置分组和模型价格

1. 我先分清三套数字

我会把上游实际成本、自己的模型基础价格、自己的分组倍率分开记录。前者决定我花了多少钱；后两者共同影响我这边怎么扣额度。把它们混成一个倍率，很容易重复加价。

上游的密钥分组属于上游平台；我在自己 New API 里创建的分组属于自己的站点。名字可以相似，但两边设置不会自动同步。

2. 成本加价 50%，应该怎么算

假设上下游采用相同的计价基准、充值换算和模型计费口径，上游的等效成本倍率为 0.72，我想在成本上加价 50%，对应计算是：

销售倍率 = 0.72 × 1.5 = 1.08
价差 = 1.08 - 0.72 = 0.36
毛利率 = 0.36 ÷ 1.08 ≈ 33.3%

因此，我会把它称为“成本加价 50%”，不会写成“毛利率 50%”。如果销售倍率设成 1.2，在同一假设下，价差占销售收入的比例为 (1.2 - 0.72) ÷ 1.2 = 40%。

这还没有扣掉 VPS、支付手续费、充值折扣、退款、汇兑以及维护等成本，更不是净利润。实际账单还可能包含缓存、图片、工具调用或其他项目，我会用同一组请求核对上下游账单后再定价。

3. 在自己的站点创建分组

我进入系统设置中的分组定价，添加一个便于识别的名称，例如 GPT-Pro，填写自己准备采用的倍率和描述。保存分组设置后，再回到渠道，把对应渠道关联到这个分组。

我也会检查用户与令牌是否有权限使用该分组。渠道配置完成但客户端仍提示无可用渠道，经常就要回到这里排查。

对已有站点，我不会为了照着教程操作就删除现存分组。先确认有没有用户、令牌和渠道正在使用，再决定调整方式。

4. 配置模型输入、输出与缓存价格

在模型定价里，我找到尚未设置价格的模型，核对模型名称与计价单位，再分别填写输入、输出、缓存读取、缓存写入等实际存在的项目。

我采用“基础价格＋分组倍率”的方法时，基础价格填对应的基准价，加价放在分组倍率里处理，避免两边同时乘一遍。价格字段与倍率字段不能混填：有的界面显示每百万 Token 的货币价格，有的界面显示相对倍率，必须按字段说明操作。

模型价格更新很快，我不会把某次演示里的数字套给所有模型，也不会把缓存价格、输出价格和输入价格当成同一个值。保存之后，我会回到游乐场，发一条短请求，再看日志中的模型、分组、Token 与扣费是否符合预期。

如果站点采用“充值 1 元对应 1 单位站内美元额度”的显示方式，那只是平台自己的额度换算，不是现实世界人民币与美元的汇率。我会明确对外说明充值与扣费规则，避免只用一个美元符号让人误解。

八、设置域名、HTTPS 与站点额度

临时测试可以用 IP 和端口。长期使用时，我会改为自己管理的域名和 HTTPS 地址，尤其是要登录后台、传输 API Key 或接收支付回调时。

我的处理顺序是：先给子域名添加指向 VPS 公网 IP 的 DNS 记录，再配置反向代理，把域名请求转到 New API 的 3000 端口；证书与 HTTPS 正常后，才把正式地址填进 New API 的服务器地址设置。域名解析只负责找到服务器，不会自动完成反向代理和 HTTPS。

例如，我的对外地址可以是 https://ai.example.com，同机反向代理连接 http://127.0.0.1:3000。这里是说明结构的示例域名，使用时替换为自己的真实域名。

如果使用支持安全会话选项的版本，我会按项目说明设置 SESSION_COOKIE_SECURE=true，并将 SESSION_COOKIE_TRUSTED_URL 设成准确的 HTTPS 源地址；HTTP 临时测试阶段不照搬 HTTPS 配置。代理还需要正确处理流式响应与 WebSocket 等实际用到的连接。

✦ New API部署与会话配置参考 ▶ https://github.com/QuantumNous/new-api/blob/main/README.md

站点额度方面，我会按需要设置新用户免费配额、充值换算和分组规则。首次对外开放时，我倾向于先把额度与权限设小一些，用测试账号走完注册、充值、请求与扣费流程，再逐步开放。

九、对接 ZPAY 支付网关

1. 先确认自己是否需要收款

如果只是我自己调用模型，可以跳过这一节。要让其他用户在线充值，才需要接支付网关。New API 提供相应支付配置，实际可用方式取决于版本、账户条件和网关是否已经启用。

我这次选择 ZPAY 演示易支付风格接口的接入流程。申请前，我会先核对平台当前接受的主体、业务类型、费率和结算条件；个人账户能否开户、哪些支付方式能开通，都以审核结果为准。

✦ Zpay个人支付网关 ▶ https://i.redman3721.com/zpay

2. 获取商户信息

我先注册账户，按签约页面提交要求的身份与收款资料，并保持收款账户和实名信息一致。审核完成后，在 API 安全或商户接口页面取得网关信息、商户 ID 和商户密钥。

我把这些内容填进 New API 支付设置的对应位置：网关/API 地址、商户 ID（PID）、商户密钥（KEY），再按界面启用对应的支付方式并保存。

3. 网关地址不要只凭“补一个 submit”来猜

我核对的 ZPAY 官方文档中，页面跳转支付入口是完整的 /submit.php 路径，而不是只写 /submit。实际网关域名要从自己的商户后台确认。

New API 不同版本或支付库，对“基础网关地址”和“完整提交地址”的处理可能不同。我会查看这个字段的提示与最终生成的支付 URL：如果程序已经拼接 submit.php，就不再重复添加；如果字段要求完整入口，才填完整地址。不要把 / 写成反斜杠 \。

✦ ZPAY官方支付接口文档 ▶ https://www.z-pay.cn/doc.html

4. 回调要能真正到达自己的站点

支付完成后，平台需要通知 New API 更新订单与余额。我会先确认系统里的服务器地址是实际可访问的正式地址；如果使用额外的回调地址设置，也必须确保它能从公网访问。

当前 New API 代码会为易支付构造 /api/user/epay/notify 通知路径。因此，配置页某个“回调地址”输入框可以留空，并不等于支付过程不需要回调。我不会把“页面付款成功”当成“余额入账成功”，而是继续核对订单和余额。

✦ New API支付设置说明 ▶ https://docs.newapi.ai/zh/docs/guide/feature-guide/admin/system-setting-advanced

✦ New API支付回调实现 ▶ https://github.com/QuantumNous/new-api/blob/main/controller/topup.go

我会用平台允许的小额订单验证整条流程：创建充值订单 → 跳转收银台 → 完成付款 → 订单更新 → 余额增加 → 模型请求正确扣费。若已经付款但没有入账，我先保留订单号并排查回调和签名，不重复付款。

十、接入 Codex++ 与其他客户端

1. 生成自己站点的 API Key

上游密钥已经放在渠道里。现在我还需要在自己的 New API 中生成一个供客户端使用的令牌，并配置正确的分组、可用模型和额度。

这两个密钥用途不同：

我不会把上游密钥直接发给下游用户，否则自己的额度和路由管理就失去了意义。

2. 在 Codex++ 添加供应商

我这里使用的是 Codex++ 的供应商管理界面，具体菜单属于这个客户端，并不表示所有 Codex 客户端都有相同设置。

我的操作顺序是：打开管理工具，在供应商里选择添加；接入方式选纯 API；名称填一个方便识别的名字；URL 填自己的 New API 地址；Key 填自己站点生成的令牌。

在这个接入示例里，客户端 URL 的形式为：

https://你的域名/v1

临时 IP 测试可以采用 http://服务器IP:3000/v1，但长期传输密钥和使用服务时，我会切换到 HTTPS。8080 不是 New API 的默认端口；如果我没有修改映射，这里仍然是 3000。具体客户端若自动补全路径，应按它的说明避免重复 /v1。

填好后，我点击从上游获取模型，选择需要的模型并保存，再切换到这个供应商，按客户端要求重启或重新加载。

3. 模型能显示，还要继续测试实际能力

我会先发一个简单文本请求，再验证准备使用的功能。聊天通过不等于图片生成、工具调用、插件或其他接口都能使用；这些能力取决于模型、渠道协议、客户端和上游实际支持情况。

我也可以使用 Cherry Studio 等客户端测试同一套地址与令牌，辅助区分问题出在站点还是客户端设置。最终仍要回到自己 New API 的日志里，看请求走了哪个渠道、使用哪个分组、消耗多少额度。

十一、常见问题与日常维护

页面打不开，我先查什么？

我先在服务器执行 docker compose ps 和 docker compose logs --tail=100 new-api，确认服务正常，再检查端口映射、防火墙、DNS 与反向代理。如果绑定的是 127.0.0.1，公网不能直接连接对应端口是预期行为。

模型列表能获取，但请求失败？

我会核对上游余额、模型权限、协议类型，以及这个模型是否支持当前调用的接口。获取列表只是一个检查点，不能替代实际请求。

提示无可用渠道或未配置价格？

我把渠道的模型列表、渠道分组、用户/令牌分组和模型定价放在一起核对。接入地址正确，也可能因为分组不匹配或价格缺失而无法调用。

充值付款成功，余额却没有增加？

我先保留订单号，检查通知是否到达站点、商户密钥与签名是否一致、服务器地址是否正确，再查看日志和商户后台。不要只检查浏览器跳转页面，也不要盲目手工补余额造成重复入账。

为什么实际成本和预估不一样？

我会比较同一请求上下游的 Token、缓存命中、额外计费项目和充值换算，再检查是否对模型价格与分组倍率重复加价。站内额度数字相同，不一定代表现实支付成本相同。

后续怎样维护？

我会定期检查余额与渠道错误、磁盘和日志增长、数据库备份，以及模型列表和价格变化。用户注册需要邮箱验证时，再按邮件服务商与当前 New API 的设置补上邮件配置。

升级前，我先保存正在使用的版本和配置，并备份实际数据库、挂载数据及必要密钥。使用 PostgreSQL 的实例，只复制 data 目录不足以备份业务数据库；需要采用对应数据库的备份方式并验证能恢复。

需要重新拉取已选定的镜像版本时，我在部署目录执行：

docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 new-api

这些命令不会替我判断版本是否兼容。我会先看发布说明，再决定升级；也不会使用会删除数据卷的清理命令来“解决”普通启动问题。

十二、适合谁、有哪些优缺点

我认为，这套方案适合已经开始使用 API、希望统一管理多个模型的个人用户，也适合愿意承担服务器维护工作的团队。它能让我集中管理渠道、密钥、模型和用量，后续换上游时也更方便。

代价是我需要自己承担运维、上游故障排查、价格核对和数据保护。对外提供服务还会增加支付、退款、用户支持等工作，不能简单理解为部署完成就能自动赚钱。

如果只是偶尔调用一个模型，也不想管理服务器，我会先判断有没有必要增加这一层。自建更适合有明确管理需求、并且愿意持续维护的人。

我的建议：先跑通一条完整链路，再扩展

我会先选择一个上游、一个分组和少量模型，确认请求成功、扣费正确、客户端可用，再逐步添加其他渠道。要对外运营，就继续把支付入账、日志、备份和用户支持补齐。

这样我能清楚知道每一步解决了什么问题。发生故障时，也能顺着“客户端 → 自己的网关 → 上游”逐层检查，而不是把所有配置重新改一遍。

AI 新手攻略与相关资源

✦ GPT&Codex充值攻略 ▶ https://youtu.be/0b2gNZLPIzM

✦ AI学习资源合集 ▶ https://i.redman3721.com/ai-doc

✦ AI交流群 ▶ https://redman.blog/index.php/aibook/

✦ 6种AI赚钱方法 ▶ https://youtu.be/bvqG8Eo_gbk

✦ 美区APPLE ID注册 ▶ https://youtu.be/IPW_LoSIitc

**说明：**我整理的是搭建流程与自己的操作思路，文中的版本、模型、价格、库存与支付条件可能变化，请以实际页面和官方说明为准。我只建议使用获得授权的接口，并按适用规则处理对外服务、用户数据与收款。部分链接可能包含推广或返佣关系；本文不构成收益保证，是否采购和运营请结合自己的需求判断。