自建 AI API 中转站：New API 部署、上游选择、定价与试运营

我之前写过一篇 One-API、New API、VoAPI 的横向对比，New API 那一段只给了一条 Docker 命令。

现在回头看，那顶多算"把面板跑起来"。

最近我自己搭了一个小中转站，还在试运营。部署确实是最简单的一步——半小时的事。真正吃掉时间的是另外几件：上游从哪来，倍率填多少才不倒挂，后台显示的"充值总额"里有多少其实根本不能动。

所以这篇不从 Docker 开始。先问一个更基础的问题：用户为什么不直接去官方？

谁会买，为什么买

卖 DeepSeek 是没戏的。大陆用户自己就能注册、充值、调用，官方接口也不难用，凭什么绕你这一层。

Claude 和 OpenAI 是另一回事。截至 2026 年 7 月，两家公布的 API 支持地区都不包含中国大陆——这不是网络快慢的问题，是服务本来就没开放到这里。

还有一个常见误会：订阅了 ChatGPT Plus 或者 Claude Pro，就以为自己有 API 了。没有。网页会员和 API 是两套产品、两套账单。想把模型接进 Claude Code、Chatbox、OpenClaw 或者自己写的脚本，最后还是得有 Base URL、Key 和余额。

于是就有了一批需求很明确的人：想在 Claude Code、Codex、Chatbox 里用 Claude；不想折腾海外账号、支持地区和外币卡；只打算先扔 10 块钱试试，不想一上来就走官方的开户流程；希望一个 Base URL 加一个 Key 就能在几家模型之间切；出问题的时候能找个说中文的人问，而不是自己去翻英文工单。

中转站干的就是把这些麻烦接过来。运营者去找上游、处理协议、计费和故障，用户拿人民币小额充值，换一个统一接口回去接自己的客户端。

所以搭中转站的目的通常只有两个：把国内不方便开户和付款的模型做成容易接入的接口，以及从中间赚钱。

上游允许你这么卖吗

这件事建议你在买 VPS 之前想清楚，而不是之后。

OpenAI 的服务协议一边允许你把 API 集成进自己的应用、提供给最终用户，一边明确禁止买卖或转移 API Key，并且要求客户和最终用户都不得在支持地区之外访问服务。Anthropic 的商业条款更直白：你可以用 Claude 支撑自己的产品，但未经明确批准不得转售服务；它的支持地区列表同样不含中国大陆。

矛盾就在这里。大陆用户的使用门槛是你的市场，而制造这个门槛的地区限制，也随时可以让你的上游断掉。

"服务器放在海外"解决不了这个问题。上游看的是客户是谁、最终用户在哪、你以什么形态提供服务，不是只看 VPS 的出口 IP。

这篇还是会把搭建流程写完，因为这套技术本身有正当用途：企业内部网关、拿到授权的下游分发、多上游统一计费、给自己的产品做接口层。但如果你的计划是向大陆公开零售 Claude、OpenAI 额度，那第一件事不是买机器，是去谈一份能覆盖二次分发和目标地区的书面授权。谈不下来，就得承认这是随时可能断供的生意——别把用户的预付款当成已经到手的钱。

你卖的其实是什么

把自己的上游 Key 原样发给十个人，那不叫中转站，那叫泄漏密钥。

用户真正拿到手的是这么几样东西：一个国内客户端能直接填进去的兼容接口，一枚和你的主 Key 完全隔离的令牌，可用额度，能自己查的用量和余额，以及上游出问题之后有人切换、有人解释。说白了他买的是支付方便、小额起充、协议兼容，还有一个能找到的人。

New API 不是门槛。开源面板，照着文档半小时到一小时就跑起来了，别人也能跑。决定这个站能不能活下来的是另外几件事。

上游的来源你能不能说清楚，断掉一条之后有没有同级别的备用。每个模型的输入、输出、缓存实际花了多少钱，倍率改完会不会倒挂。用户的人民币先进你口袋，你可能要先掏美元给上游预付，中间夹着汇率、冻结和退款。用户也不会因为你装好了 New API 就自动出现，获客、答疑、半夜爬起来处理 401，都得有人干。还有最难的一样：小站真正卖不动的东西不是 Token，是"我这个月充进去的钱，下个月还在不在"。

价格战是小站最容易做、也最容易死的选择。正常用户一天用几毛钱，基本不会来找你；异常用户一分钟能烧掉几十块，还可能顺手把你的上游账号带走。所以风控和售后不是"以后用户多了再加"的功能，它就是这门生意本身。

账要算到什么程度

收入无非三层：上游批发价和你零售价之间的差；小额充值、人民币支付、统一协议、中文售后凑起来的便利溢价；以及一个入口挂了多家模型、主备能切之后，用户懒得再搬走。

差价好算：

用户付款 - 上游调用成本 = 差价

真实毛利要难看得多：

真实毛利
= 用户实际支付
- 上游实际扣费
- 汇率和充值损耗
- 支付通道手续费
- VPS、数据库、监控、备份
- 送出去的体验额度
- 退款、坏账、滥用损失
- 你自己处理售后的时间

举个数。假设一个月收到 100 元充值，对应的上游消耗是 72 元。别急着说赚了 28 块，往下扣：

这组数字是拿来演示算法的，不是我站里的真实利润，(我现在还没有利润QAQ)。它只说明一件事：上游加价接近四成，落到手里可能只剩一成三。

比这个更容易搞错的是另一笔：用户余额里还没消费掉的部分，不是利润，是负债。那笔钱对应的是你之后仍然要提供的服务，或者要退的款。上线之前把自己的真数据填进去：

现金流也得单独想一遍。用户可能一次充 100 元，半个月只用掉 10 元；上游那边却要求你预存美元，或者余额低于阈值就自动扣卡。后台那个"充值总额"最容易让人产生错觉。你真能拿去花的，是扣掉未消费余额、退款准备金和下一轮上游预付之后剩下的部分。

三种上游，风险差别很大

官方 API 和正规云平台

模型厂商自己的 API，或者 AWS Bedrock、Google Vertex AI 这类云渠道。

来源和账单最清楚，代价是开户、地区、支付和价格门槛都更高。而且要逐条确认商业条款允不允许你这种产品形态和服务地区。

别把"官方允许我用 API 做应用"自动理解成"允许我把原始接口卖到任何地区"。OpenAI 协议里的地域限制同时约束客户和最终用户，Anthropic 那边还明确写着转售需要它批准。目标用户主要在大陆的话，这类官方自助账户不适合拿来公开零售中转额度。

明确允许下游分发的批发渠道

这条路才更像"中转生意"。你按批发价拿额度，自己做用户、定价、支付和售后。

签约或者充值之前，至少把这几件事问到纸上：能不能二次分发；可以服务哪些国家和地区；对方是官方 API、云平台，还是又套了一层上游；模型价格和倍率什么时候更新；上游故障、封号或清退之后余额怎么处理；有没有并发、RPM、TPM 和单日限额；能不能开票或者提供可核对的账单；用户请求和日志保留多久。

如果对方只肯说"放心跑，稳得很"，别的什么都不落字，这种渠道不适合拿来承接用户充值。

账号转 API、OAuth 逆向、共享订阅

成本可能最低，社区里也最火。

但它是把消费级订阅硬掰成接口服务，账号风控、条款、并发和隐私全都更难控制。自己折腾没问题，损失锁在一个账号里；拿它做付费站，一次封号可能同时影响几十个用户。

真要接，只能当成随时会失效的实验渠道：单独分组、限死额度、不做主力、不对用户承诺稳定。

这篇最后会搭出什么

技术栈是：

Ubuntu VPS + Docker Compose + New API + PostgreSQL + Redis + Caddy 自动 HTTPS

做完之后你会得到一个 https://api.你的域名/v1 的 OpenAI 兼容接口。New API、数据库和 Redis 都不直接暴露到公网，外面只能碰到 80 和 443。

再往后会配主备上游、统一模型名、用户令牌、倍率、体验额度、注册风控、备份和更新。目标不是"网页能打开"，是能开始一轮小规模试运营。

准备工作

一台 VPS

建议从这个配置起步：

1G 内存不是绝对跑不动，但数据库、Redis、Caddy、New API 一起塞进去，余量薄得可怜。省下的几块钱，抵不上后面被 OOM 杀进程时的烦躁。

一个域名

准备一个二级域名，比如：

api.example.com

别照抄。后文所有 api.example.com 都要换成你自己的。

至少一个合法上游，最好两个

验证部署最少要一个能正常调用的上游 Key。但要验证"中转"而不只是反向代理，最好有两个合法渠道。

先把资料记在自己电脑上：

这里故意不点具体服务商。每家的地址、模型名和协议都可能变，照抄别人的截图是最容易翻车的做法。

如果你手上只有 DeepSeek 官方 Key，拿它跑一遍部署测试也行。但测完发现自己既没有多用户、也不需要备用渠道和统一入口，那就直接用官方接口，别为了"拥有一个中转站"继续养服务器。

大概花多少钱

中转只是多加了一层管理，不会让官方 API 的成本自动变低。你看到有些站卖得比官方还便宜，背后可能是批量折扣，也可能是来源和稳定性说不清。别拿"别人卖这个价"反推自己的成本。

第一步：登录服务器，先做基础检查

Windows 11 自带 SSH，打开 PowerShell：

ssh root@你的服务器IP

第一次连接会让你确认指纹：

Are you sure you want to continue connecting (yes/no/[fingerprint])?

输入 yes，然后输密码。终端输密码时不显示星号，这是正常的，不是键盘坏了。

进去先更新系统：

apt update
apt upgrade -y
apt install -y ca-certificates curl gnupg openssl nano
timedatectl set-timezone Asia/Shanghai

再看一眼架构和资源：

uname -m
free -h
df -h

x86_64 对应 amd64 镜像，aarch64 对应 arm64。如果内存只有 512M，不建议按本文这套组合往下走；根分区剩余不到 5G，先清理或扩容。

下面的命令都默认你是 root。云厂商给的是普通用户的话，需要权限的命令前面加 sudo。

第二步：装 Docker 和 Compose

网上最常见的是这一句：

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

临时测试可以，长期跑服务我更建议走官方 APT 仓库——Docker 自己也把这个便利脚本定位在测试和开发场景。命令长一点，但来源和后续升级都清楚。

先加官方软件源：

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

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

装 Engine 和 Compose 插件：

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

确认服务起来了：

systemctl enable --now docker
docker version
docker compose version

跑个官方测试容器：

docker run --rm hello-world

看到 Hello from Docker! 才算过关。如果提示 docker: command not found，说明没装成功，先回头检查软件源，别急着往下复制 New API 的命令。

第三步：域名解析到 VPS

去 DNS 控制台加一条记录：

主域名是 example.com 的话，最终效果是：

api.example.com -> 你的服务器 IPv4

用 Cloudflare 的话，第一次申请证书时先把小云朵切成灰色。等 HTTPS 完全正常了，再决定要不要开代理。

有个坑挺隐蔽：服务器没有可用 IPv6，就别留一条指向错误地址的 AAAA 记录。 有些设备会优先走 IPv6，然后你就会遇到"手机打不开、电脑能打开"这种怪事，还查不出原因。

在自己电脑上验证解析：

Resolve-DnsName api.example.com

或者：

nslookup api.example.com

返回的 IP 必须是这台 VPS。DNS 刚改完可能要等一会儿，域名还指着旧机器就开始骂 Caddy 是没道理的。

云控制台的安全组要放行 TCP 22、80、443，HTTP/3 的话再加一个 UDP 443。

3000、5432、6379 不需要对公网开放。 本文的 Compose 文件也不会发布这三个端口。

第四步：建目录，生成密钥

mkdir -p /opt/new-api
cd /opt/new-api

生成三组随机值：

openssl rand -hex 24
openssl rand -hex 24
openssl rand -hex 32

三串十六进制字符，分别拿来做 PostgreSQL 密码、Redis 密码和会话密钥。

为什么特意用十六进制？因为数据库连接字符串里，@、:、/、# 都有特殊含义。随手写一个 Abc@123# 塞进去，DSN 会被截断，而日志只会告诉你"数据库连接失败"，你能查半天。纯十六进制省这份心。

创建环境变量文件：

nano .env

填：

DOMAIN=api.example.com
POSTGRES_PASSWORD=第一串随机值
REDIS_PASSWORD=第二串随机值
SESSION_SECRET=第三串随机值
CRYPTO_SECRET=再生成一串 openssl rand -hex 32 填这里

DOMAIN 换成你的真实域名。等号两边不留空格，也不要用中文引号。

Nano 保存：Ctrl + O，回车确认文件名，Ctrl + X 退出。

然后限制权限：

chmod 600 .env

这个文件里是数据库和会话密钥。不要截图发群，不要上传 GitHub，也不要贴到在线排错网站上去。

第五步：写 Compose 配置

nano docker-compose.yml

完整内容：

services:
  new-api:
    image: calciumion/new-api:latest
    container_name: new-api
    restart: always
    command: --log-dir /app/logs
    expose:
      - "3000"
    volumes:
      - ./data:/data
      - ./logs:/app/logs
    environment:
      SQL_DSN: postgresql://newapi:${POSTGRES_PASSWORD}@postgres:5432/newapi
      REDIS_CONN_STRING: redis://:${REDIS_PASSWORD}@redis:6379/0
      SESSION_SECRET: ${SESSION_SECRET}
      CRYPTO_SECRET: ${CRYPTO_SECRET}
      TZ: Asia/Shanghai
      ERROR_LOG_ENABLED: "true"
      BATCH_UPDATE_ENABLED: "true"
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    healthcheck:
      test:
        - CMD-SHELL
        - "wget -q -O - http://localhost:3000/api/status | grep -o '\"success\":\\s*true' || exit 1"
      interval: 30s
      timeout: 10s
      retries: 5

  postgres:
    image: postgres:15-alpine
    container_name: new-api-postgres
    restart: always
    environment:
      POSTGRES_USER: newapi
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: newapi
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U newapi -d newapi"]
      interval: 10s
      timeout: 5s
      retries: 10

  redis:
    image: redis:7-alpine
    container_name: new-api-redis
    restart: always
    environment:
      REDIS_PASSWORD: ${REDIS_PASSWORD}
    command:
      - sh
      - -c
      - exec redis-server --appendonly yes --requirepass "$$REDIS_PASSWORD"
    volumes:
      - redis_data:/data
    healthcheck:
      test: ["CMD-SHELL", "redis-cli -a \"$$REDIS_PASSWORD\" ping | grep -q PONG"]
      interval: 10s
      timeout: 5s
      retries: 10

  caddy:
    image: caddy:2-alpine
    container_name: new-api-caddy
    restart: always
    environment:
      DOMAIN: ${DOMAIN}
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      new-api:
        condition: service_healthy

volumes:
  pg_data:
  redis_data:
  caddy_data:
  caddy_config:

有几个地方别随手改。New API 用的是 expose 而不是 ports: 3000:3000，所以 3000 只在 Docker 内网可见；PostgreSQL 和 Redis 没有 ports，公网扫不到 5432 和 6379；数据分别落在 pgdata、redisdata 和当前目录的 data、logs；SESSIONSECRET 不能照抄官方示例里的 randomstring，新版会直接拒绝启动。

latest 对第一次部署方便。真的开始长期运营之后，建议看完 Release Note 再固定到你验证过的版本，别自动追新。

接着写 Caddy 配置：

nano Caddyfile

{$DOMAIN} {
    encode zstd gzip

    reverse_proxy new-api:3000 {
        flush_interval -1
    }
}

Caddy 看到真实域名会自动申请和续期证书。flush_interval -1 是低延迟模式，直接关掉响应缓冲，AI 的流式输出就不会攒一大段再一起蹦出来。

第六步：启动

先让 Compose 检查格式：

cd /opt/new-api
docker compose config

出现 variable is not set，多半是 .env 少了一项，或者你不在 /opt/new-api 目录下。顺便提醒：这条命令会展开配置，录屏和截图时别把密码带出去。

拉镜像启动：

docker compose pull
docker compose up -d

看状态：

docker compose ps

四个服务都在跑，New API、PostgreSQL、Redis 最终显示 healthy，就对了。第一次启动数据库会慢一点，New API 暂时是 health: starting 就等半分钟再看一次。

还不正常就翻日志：

docker compose logs --tail=100 new-api
docker compose logs --tail=100 postgres
docker compose logs --tail=100 redis
docker compose logs --tail=100 caddy

别一上来就重装系统。日志里通常已经把问题说清楚了。

第七步：初始化管理员

浏览器打开：

https://api.example.com

首次访问进初始化页面，按提示创建管理员用户名和密码。

强调一下：新版流程不是 root / 123456。你要是看到哪篇教程让你用这个默认密码登录，那篇文章至少在初始化这一段已经过期了。

管理员密码别和 VPS、邮箱、上游 Key 共用。登录后先做三件事：确认网站地址、站点名称和时区；暂时关闭新用户注册；在安全设置里开 2FA 或 Passkey。

关注册不是摆架子。渠道、模型价格和额度都还没对完就放人进来，人家第一次请求可能直接报错，也可能按错误倍率扣钱。

第八步：加主渠道和备用渠道

这一步才是中转站的核心，前面那些都算铺路。

进 控制台 -> 渠道 -> 添加渠道，先配主渠道：

Base URL 后面先别自己补 /v1/chat/completions。这里填的是根地址，路径由 New API 处理。不同供应商需不需要带 /v1 不一样，遇到 404 回官方文档核对。

保存后在列表里点"测试"。测试通过说明四件事：New API 能访问上游、Key 能通过鉴权、测试模型名存在、基础请求格式没写错。

失败就看返回信息：

• 401 Unauthorized：Key 错了、失效了，或者没余额
• 404 model not found：模型名不对，或者还在用已经停用的旧名字
• connection timeout：VPS 到上游的网络有问题
• insufficient balance：上游余额不足，跟 New API 无关
• quota exceeded：上游账户或项目额度用完了

主渠道通了，同样步骤加备用渠道：

New API 里优先级数值越高越先被选中，上面这组会优先走 主渠道-A。

两个渠道提供同一个模型但上游名字不同的话，用"模型映射"给它们套一个共同名称。假设主渠道真实模型是 provider-a-code，备用是 provider-b-code，你想对用户公开 coding-model：

先把主渠道"模型"字段里的名字改成 coding-model，然后在主渠道的"模型映射"里填：

{
  "coding-model": "provider-a-code"
}

备用渠道的"模型"字段同样改成 coding-model，映射填：

{
  "coding-model": "provider-b-code"
}

这个 JSON 左边是用户请求的名字，右边是该渠道真正发给上游的名字。New API 先按 coding-model 找可用渠道，再在选中的渠道里换成真实模型名。用户以后只请求 coding-model，不需要知道后面走的哪家。

两个上游的模型名本来就一样，那就不用映射，两条渠道都勾同一个名字即可。

但别把能力差很多的模型硬映射成一个名字。今天返回的是高端代码模型，明天故障切换变成便宜小模型，接口不报错，结果已经完全不是一回事了。备用渠道至少要在协议、上下文长度和工具调用能力上接近。

两条渠道都单独点一次"测试"。然后去 设置 -> 运营设置 -> 通用设置 -> 失败重试次数，把重试设成至少 1。没有重试的话，主渠道一报错请求就直接失败了，压根轮不到备用渠道。

接下来临时禁用主渠道，测 coding-model 能不能从备用渠道正常返回；测完把主渠道恢复，再连续请求几次，确认正常情况下还是优先走主渠道。

这套主备验证才是中转站的价值所在。只测一条 DeepSeek 官方渠道，证明的仅仅是 New API 会转发请求而已。

后台显示"渠道测试成功"也还不算完。下一步得拿真的用户令牌从公网调一次。

第九步：建令牌，实际调一次

进 控制台 -> 令牌 -> 创建令牌。

名称按用途写，比如 Windows-Chatbox、OpenClaw-VPS、临时测试-7天。别让所有设备共用一个 Key——某台机器泄漏的时候，独立令牌可以单独删掉，不用把全家配置都改一遍。

测试令牌这么限制就行：过期时间 7 天，剩余额度给个小数，模型限制只勾刚测通的那个，分组 default。IP 白名单等固定服务器调用时再填，手机和笔记本经常换 IP，先留空。

完整 Key 通常只在创建时显示一次，立刻复制到密码管理器，别发微信。

回自己电脑打开 PowerShell，先测模型列表：

curl.exe https://api.example.com/v1/models `
  -H "Authorization: Bearer sk-替换成你的令牌"

能返回 JSON 模型列表，再发一条真请求：

$body = @{
  model = "coding-model"
  messages = @(
    @{
      role = "user"
      content = "只回复：中转站调用成功"
    }
  )
  stream = $false
} | ConvertTo-Json -Depth 5

curl.exe https://api.example.com/v1/chat/completions `
  -H "Authorization: Bearer sk-替换成你的令牌" `
  -H "Content-Type: application/json" `
  --data-binary $body

返回里出现模型回复，这条链路才算真的通了：

客户端 -> 你的域名 -> Caddy -> New API -> 上游模型 -> 返回结果

最后回后台看日志和额度变化。如果后台完全没有这次调用的记录，说明请求可能根本没走你的站。

第十步：接进常用客户端

大部分 OpenAI 兼容客户端只要三个值：

Chatbox、Cherry Studio 这类客户端，供应商选"OpenAI API 兼容"或者"自定义 OpenAI"，再填上面三项。

有的客户端会自己再拼一次 /v1。如果你填了 /v1 之后请求变成 https://api.example.com/v1/v1/chat/completions，就把客户端里的 Base URL 改成不带 /v1 的版本。

没有哪一条 Base URL 能适配所有客户端。遇到 404，先去看客户端实际请求的地址，比来回换 Key 有用得多。

Claude Code 走第三方接口还涉及 Anthropic 格式和环境变量，我单独写过一篇，不在这里硬塞半篇进来：

Claude Code 接第三方 / 中转 Key：环境变量怎么配，401 和模型名怎么排查

Claude Code 要用中转或自建网关的 Key，得改 ANTHROPIC_BASE_URL 和鉴权变量。按官方支持的接法写配置步骤，以及 401、路径不对、模型名对不上、流式卡死时怎么查。

TuBaiBai's BlogTuBaiBai

开门收钱之前

先对三天账

拿你自己的测试用户连续跑几天，核对三份数据：New API 日志里的输入输出 Token，上游后台的实际调用量和扣费，以及用户余额的变化。

三边对不上就别收钱。

New API 的倍率不是"随便填个利润率"这么简单。模型的输入、输出、缓存、分组都会影响扣费，没配价格的模型在计费模式下还可能直接报"倍率或价格未配置"。倍率也不等于你的利润率——它只是把 Token 和用户分组换算成平台配额而已。要知道自己到底赚没赚，只能拿 New API 的用户扣费和上游真实账单硬对。

先做一两个模型，比一口气挂几十个靠谱。

把一个模型的价格算对

New API 当前的内部换算是：

1 美元 = 500,000 配额点数

按 Token 计费的核心公式：

配额消耗
=（输入 Token + 输出 Token × 补全倍率）
× 模型倍率
× 分组倍率

上游报价是"每百万 Token 多少美元"的话，可以先这么换算：

模型倍率 = 上游每百万输入 Token 价格 ÷ 2
补全倍率 = 上游每百万输出 Token 价格 ÷ 输入价格

分组倍率再决定用户实际按什么系数扣：

internal-test = 1.0
trial         = 1.0
standard      = 【按真实进价、支付和风险成本算】

别为了看起来便宜，先把 standard 拍脑袋填成 0.5。等用户充进来才发现上游成本高于扣费，那就是调用越多亏越快。

第一轮挑一个准备主推的模型，做 10 次固定测试，每次都记：

短对话、长文本、带工具调用的任务各测一次。只拿"你好"测，你发现不了长输出、缓存和工具调用带来的计费差异。

体验额度别直接塞进主余额

比如你计划给前 50 个用户每人 2 元、7 天有效。稳妥的做法是：建一个 trial 分组，只开放准备测试的少量模型，给体验令牌设 2 元对应的配额上限和 7 天过期时间，再给这个组配更低的请求频率。测试期结束再决定是否转正式用户。

这样即便有人批量注册，最多也就消耗掉那一枚体验令牌，不会拿着赠送余额长期跑。

注意 New API 底层存的是配额点数，不一定等于页面显示的人民币。先确认站点货币和换算设置，再生成兑换码或者手动加余额——别把"2"直接当成"2 元"填进去。

试运营先用兑换码

New API 支持兑换码、易支付、Stripe 这些充值方式。能接上，不代表第一天就该接。

我的做法是：前 50 人只发兑换码或手工额度，把支付回调、重复通知、退款、少充多到账这些情况都测完，确认经营和上游授权的问题之后，再开自动充值。最低充值额也别定太低，否则手续费和售后成本会把利润吃干。

顺便说一句，"易支付"只是一种接口协议风格，不代表它本身是持牌支付机构。资金实际由谁收、怎么结算、出问题找谁，取决于你接的具体渠道。

注册默认关闭，再一点点放

开放之前至少确认：邮箱验证能正常收到；新用户默认额度不是无限；新用户能调哪些模型已经限死；每个令牌都有速率和额度限制；错误日志不会把完整 Key 打出来；管理员开了 2FA；上游明确允许你这种用法。

然后再配邮箱验证码和 Cloudflare Turnstile。只做"注册送 2 元"而不做人机验证，活动会很快变成批量注册脚本的压力测试。

如果只是给几个朋友用，手动建账号或者发兑换码就够了。为了显得"像个平台"硬上支付、工单和几十个套餐，只是给自己多加维护点。

给自己划一条停机线

小站最怕的不是偶尔 502，是上游已经在异常扣费、你还在自动接新订单。

至少定三个阈值：

单用户每分钟请求上限：【待补充】
单用户每日最大消费：【待补充】
全站当日亏损停机线：【待补充】

出现下面任意一条，先暂停充值或者禁用问题渠道：New API 扣费和上游账单连续对不上；上游错误率突然升高；某个用户的消耗速度明显不正常；上游改价了而本地倍率还没更新；主备渠道同时异常；当天实际亏损超过停机线。

关站不等于生意做不下去。知道什么时候该先关充值，本身就是运营的一部分。

用户的请求不是无关数据

中转站站在请求链路中间。用户发的提示词、代码、文件，模型的回复，全都会经过你的服务器。

所以至少要做到：明确告诉用户服务会经过第三方模型；不要求用户上传公司源码、真实密钥和隐私资料；日志只留排错真正需要的内容；给用户删令牌和停用账号的入口；做公网服务前把隐私政策、服务条款和投诉入口补齐。

如果是向中国境内公众提供生成式 AI 服务，还得自己核对备案、许可、内容安全、实名、日志、税务和上游授权这一整套要求。《生成式人工智能服务管理暂行办法》明确把"通过可编程接口提供服务"也算作服务提供者。个人自用和公开运营不是同一个合规等级，一句"仅供学习"糊弄不过去。

备份：别等数据库坏了才想起来

面板可以重装，用户、令牌、渠道和账单数据丢了很难补。

手动备份 PostgreSQL：

cd /opt/new-api
mkdir -p /opt/backups/new-api
docker compose exec -T postgres \
  pg_dump -U newapi -d newapi \
  | gzip > "/opt/backups/new-api/newapi-$(date +%F-%H%M).sql.gz"

检查文件不是 0 字节：

ls -lh /opt/backups/new-api

另外单独保存这三个文件：

/opt/new-api/.env
/opt/new-api/docker-compose.yml
/opt/new-api/Caddyfile

备份放在同一台 VPS 只能防误操作，防不了硬盘损坏和账号被封。至少再同步一份到你控制的其他存储，含密钥的备份记得加密。

最危险的命令是这条：

docker compose down -v

-v 会删掉 Compose 管理的数据库卷。平时停服务只用：

docker compose down

别手滑多敲那个 -v。

更新：先备份，再追新

New API 更新很快。自动更新看着省事，数据库迁移出问题的时候也最容易把你从床上叫起来。

我建议手动更新：

cd /opt/new-api
docker compose pull
docker compose down
docker compose up -d

更新前做数据库备份，去 New API Releases 看一眼改了什么。

更新后检查：

docker compose ps
docker compose logs --tail=100 new-api

然后再走一遍：后台登录、渠道测试、/v1/models 请求、一次真实对话、日志和扣费核对。别看到容器是绿的就宣布升级成功。

常见问题

域名打不开，Caddy 申请证书失败

先看解析和日志：

Resolve-DnsName api.example.com

docker compose logs --tail=100 caddy

常见原因：A 记录没指向这台 VPS；留了一条错误的 AAAA 记录；云安全组没放行 80、443；另一套 Nginx、Apache 或者面板占着 80、443；Cloudflare 的代理和 SSL 设置干扰了第一次签发。

查端口占用：

ss -lntp | grep -E ':80|:443'

PostgreSQL 一直 unhealthy

docker compose logs --tail=100 postgres

如果你改过 .env 里的数据库密码，而数据库卷已经初始化过了，旧卷里的密码不会跟着变——Compose 里的新密码和数据库里的旧密码对不上，就是这个原因。

这也是我让你在第一次启动之前就把随机密码定好的原因。已经有数据的话不要删卷重来，按 PostgreSQL 正常流程改密码，或者从备份恢复。

客户端报 401

先把三样东西分清楚：管理员密码只用来登录后台；上游 API Key 只填在渠道里；New API 用户令牌才是填进 Chatbox、脚本和其他客户端的东西。

客户端用第三种，带上：

Authorization: Bearer sk-你的令牌

渠道测试成功，客户端却 404

先看客户端实际请求的 URL。最常见的是这个：

/v1/v1/chat/completions

其次是客户端走了 Responses API，而你的渠道或者当前转换路径只适配 Chat Completions。先用前面那段 PowerShell 请求跑通，再回头处理客户端自己的协议差异。

配了模型映射还是 model not found

按这个顺序查：渠道的"模型"字段里有没有用户请求的公开名称（比如 coding-model）；模型映射左边是不是 coding-model；右边是不是该渠道真实存在的上游模型名；主备渠道有没有各自配好映射；令牌的模型限制里有没有放行 coding-model。

最容易写反的是方向。错的：

{
  "上游真实模型名": "coding-model"
}

对的，"用户请求名 → 上游真实名"：

{
  "coding-model": "上游真实模型名"
}

回复不是一个字一个字出来，憋半天一起蹦

检查 Caddyfile 里有没有这行：

flush_interval -1

然后重载：

docker compose restart caddy

还不行就临时关掉 Cloudflare 代理直连测试。有时候卡的不是 New API，是前面的 CDN 或者客户端自己在做缓冲。

容器明明起来了，重装后数据没了

先确认你是不是换了目录运行 Compose。命名卷默认带 Compose 项目名，在 /root/new-api 和 /opt/new-api 分别启动，会得到两套不同的卷。

docker volume ls

看到一套"空站"别马上删旧卷。先查清原来的项目目录和卷名。

防火墙关了 3000，为什么以前还能访问

Docker 发布端口时可能绕过 UFW 的常规规则，这也是本文不写 3000:3000 的原因。应用、数据库、Redis 都只在 Docker 内网通信，公网入口只留给 Caddy。

装个 UFW 不等于安全做完了。少暴露端口这件事本身更重要。

最后：要不要自己搭

如果你看到这里，目的只是想在 Claude Code、Chatbox、OpenClaw 里用上 Claude 或 OpenAI，并不打算自己卖额度，那真没必要从买 VPS 开始。

搭面板不难。难的是找到允许分发的上游、算清价格、配对倍率、处理地区和条款风险，还要在用户问"昨晚还能用的模型今天怎么 401 了"的时候给出个说法。

我自己那个小中转站还在试运营阶段。模型和价格以站内实际显示为准，我不会在文章里承诺"全模型永久可用"。利益关系也说清楚：那是我自己的站，不是第三方客观推荐。

现阶段前 50 个新用户送 10刀体验额度，7 天有效，想试的话在公众号 TuBaiBai 后台回复"中转"，我把地址和领取方式发过去。名额和活动状态以后台回复为准。

我不承诺永久低价，也不承诺永不停机——试运营期间会有维护和调整。所以先拿体验额度跑几个小任务，觉得合适再说。

愿意自己搭，就按这篇把控制权拿在手里；嫌维护烦，就先用现成的把客户端跑通。这两条路谈不上谁高级，区别只是你想把时间花在哪。

资料来源

• New API 官方 Docker Compose 部署文档
• New API Docker Compose 配置说明
• New API 环境变量配置指南
• New API 渠道管理
• New API 令牌管理
• New API 倍率设置与配额公式
• New API 充值与兑换码
• New API 支付设置
• New API 注册与安全设置
• New API GitHub 与最新 Release
• Docker Engine 官方 Ubuntu 安装文档
• Caddy 自动 HTTPS 与反向代理文档
• OpenAI API 支持的国家和地区
• OpenAI 服务协议
• Anthropic 支持的国家和地区
• Anthropic 商业服务条款
• Anthropic 关于非支持地区销售限制的说明
• 《生成式人工智能服务管理暂行办法》

相关阅读

VPS 自建 AI API 网关完整教程：One-API、New-API、VoAPI 三方案对比

买了一堆 AI API Key，每个软件都要重复配一遍？在 VPS 上自建一个 OpenAI 兼容的 API 网关，一次配好，所有工具统一走一个地址。折腾了三个方案之后写的对比 + 部署实录。

TuBaiBai's BlogTuBaiBai

抛弃繁重的服务器：零成本用 Vercel / Cloudflare 部署专属 AI API 中转网关

告别 VPS 维护，白嫖 Vercel / Cloudflare 的边缘计算资源，零成本部署一个属于你自己的多模型 AI API 中转网关。

TuBaiBai's BlogTuBaiBai

CLIProxyAPI 终极指南：VPS 自建 OpenAI 兼容接口（WebUI + Docker + Nginx）

在 VPS 上通过 Docker 或直装方式部署 CLIProxyAPI，解决 Gemini/Claude 地区限制，附带 Nginx HTTPS 配置和多客户端实战对接指南。

TuBaiBai's BlogTuBaiBai