API 中转站怎么搭建？用云服务器自建 AI API 网关完整教程

摘要

API 中转站的技术内核是一层模型调用代理，个人完全可以在一台云服务器上把它搭起来，用于统一管理自己手里的多家官方 API Key。本文先划清“自用”与“对外经营”的边界，再给出从选购服务器、安装 Docker、拉起服务、配置密钥、放通端口、绑定域名与 HTTPS，到添加模型渠道、生成访问令牌、客户端接入的完整步骤，最后补齐部署后必须做的四件安全事。读完你能独立完成一套只服务于自己或小团队的 AI API 网关。

一、先明确边界：什么情况适合自建，什么情况不要做

在动手之前必须把定位想清楚，因为同一套技术，用途不同，性质完全不同。

适合自建的情况有三类。第一类是你手上已经有多家模型厂商的官方 API Key，散落在不同的配置文件、备忘录和环境变量里，想收拢到一个入口统一管理。第二类是小团队内部共用，需要给每个人分配独立令牌、看到各自的用量。第三类是企业内部业务要接入多个模型，需要审计日志、限流和成本归因。

不要做的情况同样清晰。把服务开放注册、按 Token 向外收费、发展下级代理，这类行为涉及增值电信业务经营许可、ICP 备案、生成式人工智能服务备案以及数据出境等一系列要求。2026 年 6 月，国家安全部门发布了针对“AI 中转”市场的风险提示，指出部分站点存在运营资质缺失、安全防护薄弱、用户隐私泄露与数据倒卖等问题；2026 年 5 月也有运营者被采取刑事强制措施的公开报道。此外，任何绕过厂商授权机制获取调用能力的做法，都不在本文讨论范围内，也不建议尝试。

本文的全部内容都限定在第一种语境：你用自己合法获取的官方 API Key，为自己或团队内部搭一个私有网关。

二、准备工作：服务器、域名、官方 API Key 清单

开始前把三样东西准备好，能省掉大半的返工。

一台云服务器。个人自用选 2 核 2G 就够，系统盘 50 GB，带宽 3～5 Mbps。开源项目公开的部署文档给出的最低要求是 1 核 2G，留一点余量运行更稳。系统建议选主流的 Linux 发行版，本文以 Ubuntu 24.04 为例，Debian 与 CentOS 系的命令差异主要在包管理器上。

一个域名。不是必须，但强烈建议有。直接用 IP 加端口访问，浏览器会提示不安全，而且无法申请证书，管理后台的登录凭据相当于在公网明文传输。域名不需要多好，能解析就行。

官方 API Key 清单。把你要接入的模型整理成一张表：厂商、Base URL、API Key、要用的模型名称。这一步提前做，后面在后台添加渠道时会快很多。注意这些 Key 必须来自厂商官方渠道或合规的服务商，来源不明的 Key 不要接进来。

三、选购并初始化云服务器

个人自建这个场景，轻量应用服务器是比较合适的起点。它把计算、存储、网络做成套餐式售卖，并提供高带宽流量包，开支比较直观；管理控制台把从服务器到服务器内应用系统的运维操作收在一起，对不想花时间在基础设施上的开发者更友好。如果你后续需要灵活调整 vCPU 与内存配比，或者要跟私有网络、云数据库做更复杂的编排，换成云服务器 CVM 更合适，CVM 的 CPU、内存、硬盘和带宽都可以按需调整。

实例创建好之后做三件事。

第一，登录服务器并更新软件源：

sudo apt-get update -y
sudo apt-get install -y ca-certificates curl gnupg lsb-release vim

第二，确认系统版本，后面装 Docker 要用到：

cat /etc/os-release | head -5

第三，把服务器的时区设置为你所在的时区，否则日志和用量统计的时间会对不上：

sudo timedatectl set-timezone Asia/Shanghai

四、安装 Docker 与 Compose

网关服务用容器跑最省事，升级和回滚都简单。

添加 Docker 官方 GPG 密钥并写入软件源：

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

CODENAME=$(. /etc/os-release && echo "$VERSION_CODENAME")
ARCH=$(dpkg --print-architecture)
echo "deb [arch=$ARCH signed-by=/etc/apt/keyrings/docker.asc] \
https://download.docker.com/linux/ubuntu $CODENAME stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt-get update -y

安装 Docker 与 Compose 插件：

sudo apt-get install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker

验证是否装好：

docker --version
docker compose version

顺手把容器日志的大小限制上，避免跑久了把磁盘写满：

sudo tee /etc/docker/daemon.json > /dev/null <<'EOF'
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}
EOF
sudo systemctl restart docker

这段配置的含义是单个容器最多保留 3 个日志文件、每个不超过 10 MB，总量控制在 30 MB 以内。

五、拉起 AI 网关服务并做数据持久化

目前这类网关的主流开源实现是 One API 以及在它基础上二次开发的 New API，能力覆盖渠道管理、令牌分发、用户分组、用量统计与计费配置，并把各家模型的接口统一封装成 OpenAI 兼容格式。它们都提供了打包好的容器镜像，可以直接跑。

先建目录，把数据、日志和数据库文件分开放：

sudo mkdir -p /opt/ai-gateway/{data,logs,mysql,redis}
sudo chown -R $USER:$USER /opt/ai-gateway
cd /opt/ai-gateway

数据持久化是这一步最容易踩的坑。容器本身是无状态的，如果不把数据目录映射到宿主机，容器一重建，你配置的渠道、令牌和历史用量就全没了。所以 volumes 这一段不能省。

一个最小可用的 docker-compose.yml 结构如下：

services:
  gateway:
    image: <网关镜像地址>
    container_name: ai-gateway
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      - TZ=Asia/Shanghai
      - SESSION_SECRET=${SESSION_SECRET}
      - CRYPTO_SECRET=${CRYPTO_SECRET}
    volumes:
      - ./data:/data
      - ./logs:/app/logs

个人自用、模型数量不多的情况下，用容器内置的轻量数据库就够了，不必额外起 MySQL 和 Redis。等到要给多人分配令牌、需要保留较长时间的用量明细时，再按第七节的思路把数据层拆出来。

启动服务：

docker compose up -d
docker compose ps

六、配置必填环境变量与强密码

有两个变量必须配，而且不能留空。

会话密钥决定登录状态能不能保持。它为空或使用默认值，会出现登录后频繁提示会话失效的情况；如果以后扩到多个节点，所有节点的这个值必须完全一致，否则请求打到不同节点就会掉线。

加密密钥用于敏感配置的加密存储，在使用外部缓存时属于必填项。

用系统的随机源生成，不要自己想：

# 生成会话密钥
openssl rand -hex 32
# 生成加密密钥
openssl rand -hex 16

生成后写入项目目录下的环境变量文件，并把权限收紧，只允许当前用户读写：

cat > /opt/ai-gateway/.env <<EOF
SESSION_SECRET=$(openssl rand -hex 32)
CRYPTO_SECRET=$(openssl rand -hex 16)
EOF
chmod 600 /opt/ai-gateway/.env

这两个值只生成一次，务必存进密码管理工具。丢了就得重置，已有的登录会话和加密数据都会失效。同时管理员账号的初始密码要立刻改掉，不要沿用默认值。

七、放通端口：防火墙与安全组两处都要改

这是新手最常卡住的地方：服务在服务器上跑得好好的，浏览器就是打不开。原因几乎都是端口只放通了一处。

云上的网络访问控制是两层的，两层都要过。

第一层是服务器操作系统内的防火墙。如果你装了宝塔一类的面板，要在面板的安全设置里放行；如果是裸系统，检查系统自带的防火墙规则。

第二层是云平台的安全组。云服务器运行在逻辑隔离的私有网络里，通过网络访问控制列表和安全组来控制进出流量。你需要在控制台里找到实例绑定的安全组，添加一条入站规则，放通服务监听的端口。轻量应用服务器对应的是控制台里的防火墙配置项。

排查顺序建议这样：先在服务器上确认服务真的在监听，再看系统防火墙，最后看安全组。

# 确认端口在监听
ss -tlnp | grep 3000
# 在服务器本机测试是否能访问
curl -I http://127.0.0.1:3000

本机 curl 能通、外网打不开，问题就一定在防火墙或安全组这两层。

八、绑定域名并部署 SSL 证书，强制 HTTPS

管理后台的登录凭据、上游 API Key、令牌，全都要经过这个入口，所以 HTTPS 不是可选项。

先把域名解析到服务器公网 IP，添加一条 A 记录，等解析生效。

证书方面，腾讯云 SSL 证书支持在线自动生成 CSR、自动添加 DNS 解析，域名型证书 1 个工作日内签发。更省事的是它支持自动部署到多种云资源，并支持托管续期，旧证书到期前自动替换，不用每年手动折腾一次。

拿到证书后，在服务前面加一层反向代理，把 80 端口的请求跳转到 443，由代理层终止 TLS，再转发到容器的监听端口。这里有一个容易忽略的细节：这类网关大量使用流式响应，反向代理必须关闭响应缓冲，否则前端会出现“卡很久然后一次性吐出全部内容”的现象，而不是逐字输出。同时把读超时设置得长一些，长文本生成的单次请求耗时可能远超默认阈值。

配置完成后，用浏览器访问域名，确认地址栏是 HTTPS、证书有效、HTTP 会自动跳转。到这一步，管理后台就不应该再通过 IP 加端口的方式暴露在公网了。

九、后台添加模型渠道与生成访问令牌

登录管理后台，先改管理员密码，再做两件事。

添加渠道。渠道对应“连向哪家上游”。进入渠道管理，新建渠道，选择对应的接口类型，填入该厂商的 Base URL 和你自己的官方 API Key，然后配置这个渠道支持的模型列表。添加完用后台的测试功能跑一下，确认能正常返回。把第二节整理的清单逐个加进去，就完成了多模型的统一纳管。

如果同一个模型你有多个来源，可以配置成多个渠道并设置权重，某个渠道异常时自动切换到其他可用渠道，可用性会好不少。

生成令牌。令牌对应“对外暴露什么”。它和上游 API Key 是两套东西，这也是自建网关的核心价值：上游 Key 只存在服务端，客户端拿到的是你自己签发、可随时吊销的令牌。

生成令牌时把这几项配上：设置有效期，不要用永久；设置可用额度上限；限制这个令牌能访问的模型范围；如果调用来源固定，加上 IP 限制。按用途拆分令牌是个好习惯，比如编辑器一个、脚本一个、临时测试一个，出问题时只吊销受影响的那一个即可。

十、客户端接入：只改 Base URL 和 Key 两个参数

这类网关对外统一成 OpenAI 兼容格式，所以接入几乎零成本，业务代码不用动。

以 Python 为例：

from openai import OpenAI

client = OpenAI(
    api_key="你在网关生成的令牌",
    base_url="https://你的域名/v1"
)

resp = client.chat.completions.create(
    model="你在渠道里配置的模型名",
    messages=[{"role": "user", "content": "你好"}]
)
print(resp.choices[0].message.content)

命令行工具、各类编辑器插件、支持自定义接口地址的桌面客户端，逻辑都一样：找到设置里的接口地址和密钥两项，填成你的网关域名和令牌。

接入后回到后台看用量统计，确认调用记录、Token 消耗和费用明细都正常上报，这套东西就算真正跑起来了。

十一、部署后必做的四件安全事

服务能用不等于能放心用，这四件事建议当天就做完。

第一，管理后台不裸奔。后台入口不要直接暴露公网端口，统一走域名加 HTTPS。如果条件允许，给管理路径加一层访问限制，比如限定来源 IP。对于需要长期对外提供访问的入口，可以在前面接一层 Web 应用防火墙，它基于规则与 AI 的方式识别常见 Web 攻击，也提供 CC 攻击防护和自定义访问控制；它还提供面向大模型应用场景的安全能力，包括算力滥用防护、提示词攻击拦截与敏感信息识别。

第二，数据库和缓存不开公网。如果你把数据层独立出来了，务必只允许内网访问，不要图方便开放公网端口配上弱密码。

第三，日志留存与外置。调用日志要能查、能追溯。放在本机有两个问题：磁盘容易被写满，机器故障时日志也一起丢。可以接入日志服务 CLS，通过 Agent、API 或 SDK 把日志集中采集上去，写入即可检索，也支持配置留存策略。

第四，密钥定期轮换。上游官方 API Key 和网关令牌都要有轮换节奏。网关把所有 Key 集中到了一处，好处是管理方便，代价是一旦泄露影响面更大，所以轮换机制必须建立起来。

另外补一句备份：把数据目录和环境变量文件定期打包，上传到对象存储 COS 存一份。COS 为每个对象提供高持久性的数据存储，比放在同一台机器上可靠得多，恢复时也快。

十二、小结与下一步

整个流程可以压缩成一句话：一台 2 核 2G 的云服务器，装好 Docker，拉起网关容器并做好数据持久化，配齐会话密钥与加密密钥，两层网络都放通端口，绑域名上 HTTPS，然后在后台把你的官方 Key 配成渠道、签发令牌给客户端用。

它解决的核心问题不是省钱，而是把调用链路和密钥收回到自己手里：请求走谁家的服务器你清楚，日志留在哪儿你清楚，用了多少 Token 你清楚。这三点，用来源不明的第三方中转站是做不到的。

后续可以按需要往两个方向延伸：一是把数据层换成云数据库、前面挂负载均衡做多实例，提升可用性；二是如果不想自己承担版本升级、上游接口变更适配和长期运维，直接评估托管形态的网关服务。

搭建自用 AI 网关只需一台轻量级云服务器，可前往腾讯云了解当前可选的服务器配置与镜像：https://cloud.tencent.com/act/pro/featured-202607