做 API 代理的，都该自己搭一套号池——0 元搭建，永不怕封

你手里有 20 个 OpenAI Key、15 个 Claude Key、10 个 Gemini Key。每个 Key 都有独立的限速额度，有些快到期了，有些余额不足，有些已经被限流但还能偶尔通。用户请求打过来的时候——该往哪个 Key 发？Key 被封了怎么办？怎么让下游客户无感知地切换？

更关键的是：有没有办法把这堆散乱的 Key 变成一个”统一的 API 端点”，而且不花一分钱服务器费用？有。这就是 Cloudflare Worker 号池方案——用社区验证的开源项目，直接上架构加代码加生产配置，搭出一个可商用的 API 号池。

一、为什么不用 VPS？三种方案算笔账你就懂了

先看传统方案的三个坑。

1.1 VPS 自建：月付 20 刀，一个 IP 被封全完蛋

常规做法是买一台 VPS（月付 $5-20），装上 Docker，跑 One-API 或 New-API。这方案在 2024 年还行，到现在有几个硬伤：

• 月付成本压不住：一台能稳定跑中转的 VPS 起码 $5/月，配好一点的 $10-15。对个人代理来说，还没开始赚钱就先背成本。
• 单 IP 是天然弱点：你所有请求都从一个 IP 出去。OpenAI / Anthropic 的风控系统一看——”这个 IP 怎么一天发几万次请求，用的是几十个不同账号的 Key？”——封号是迟早的事。
• 需要维护：Docker 挂了、Nginx 配置错了、SSL 证书过期了……不是说不能搞，但时间也是成本。

1.2 第三方中转：1 块钱买 285 万 Token 的坑

市面上的中转站确实便宜，”1 元买 285 万 Token”的广告满天飞。但背后有不少隐患——模型降智（gpt-3.5 冒充 gpt-4）、Key 随时被封导致服务中断、你的 API Key 就裸放在对方服务器上。做代理最怕的就是上游不稳，下游客户只会找你。

1.3 用 Cloudflare：不花钱，还自带 300 个 IP 防封

Worker 方案不是”省钱版 VPS”，它是一套完全不同架构思路的方案：

Worker 的天然防封机制是最大的技术亮点。根据 Cloudflare Workers 文档，Cloudflare 在全球 335 个城市有边缘节点，Worker 的每次出站请求可能从不同节点发出，IP 地址天然不固定。这对 OpenAI / Anthropic 的风控系统意味着什么？它们看到的不是”同一个 IP 在疯狂调用”，而是”全球各地的正常请求”——封号阈值被大幅抬高。

1.4 日活 200 以内免费，够你用多久？

算一笔实账：

• Worker 免费计划：每天 10 万次请求，每分钟 1000 次
• 假设你的下游客户平均每天调用 200-500 次 API
• 日活 200 个用户才摸到 10 万次免费线

对于月流水几千到几万的小型代理来说，免费额度相当充裕。即使超出，付费计划也只需 $5/月（1000 万次），还是远低于一台 VPS 的钱。

免费够用场景 ✓：日活 <200 的代理服务
需要付费场景：日活 >200 的商业化平台
付费成本：$5/月（1000 万次），仍比 VPS 便宜

二、先看清骨架——这套系统到底怎么跑的

在动手之前，先把这个系统的骨架看清楚。后面每一章都在拆解这张图的某个模块。

五个核心模块：

• Auth 层：所有进入 Worker 的请求先过鉴权。不是谁都能调用你的号池。
• 路由层：根据 URL 路径自动匹配目标服务商。一套系统覆盖所有模型。
• 号池调度器：最关键的模块。智能选择用哪个 Key、Key 挂了怎么切。
• 管理面板：Web 界面管理所有 Key 的增删改查和状态监控。
• 监控面板：每个 Key 的请求数、Token 消耗、成功率一目了然。

三、开干：复制粘贴，5 分钟跑起来

直接用社区验证过的成熟项目开局：api-pool。这个项目在 LINUX DO 社区是现象级爆款，已经过数千用户验证。

3.1 准备工作

三样东西：

• Cloudflare 账号 —— 免费注册，2 分钟
• 至少 2 个 AI API Key —— 用于演示号池效果（OpenAI / Claude / SiliconFlow 都可以）
• 域名（可选） —— 不用也行，Worker 会给你一个 *.workers.dev 免费域名

3.2 部署步骤

第一步：创建 Worker

1. 登录 Cloudflare 控制台
2. 左侧菜单 → Workers & Pages → 创建应用程序 → 创建 Worker
3. 给 Worker 起个名字（比如 api-pool-prod），点击部署

第二步：创建 D1 数据库

D1 是 Cloudflare 的 Serverless SQL 数据库，免费版提供 5GB 存储。对于号池场景，D1 比 KV 更适合生产环境——容量更大、查询更快。

# 通过 Wrangler CLI 创建（推荐）
npx wrangler d1 create api-pool-db

记下输出的 database_id，下一步要用。

第三步：写代码

点击 Worker 的”编辑代码”，把 api-d1.js 的完整代码粘贴进去。然后修改顶部的配置常量：

// === 必改配置 ===

// 目标 API 地址（你要代理哪个服务商）
const API_BASE_URL = "https://api.openai.com"; 
// 示例：如果用硅基流动就改成 https://api.siliconflow.cn

// 管理员密码（务必改！默认密码人人皆知）
const DEFAULT_ADMIN_PASSWORD = "你的密码，越长越好";

// 给下游客户用的 API Key（也务必改！）
const API_KEY = "sk-你的自定义Key，建议32位以上随机字符串";

// 存储类型（D1 更适合生产）
const STORAGE_TYPE = "d1";

第四步：绑定 D1 数据库

在 Worker 设置页面 → 变量和机密 → 绑定 → 添加 D1 数据库绑定：

• 变量名称：DB
• D1 数据库：选择你刚创建的 api-pool-db

第五步：部署

点击”保存并部署”。完成。你会得到一个类似 https://api-pool-prod.你的用户名.workers.dev 的地址。

3.3 验证号池是否正常工作

# 测试：用你配置的 API_KEY 发一个请求
curl https://api-pool-prod.你的用户名.workers.dev/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-你的自定义Key" \
  -d '{
    "model": "gpt-3.5-turbo",
    "messages": [{"role": "user", "content": "ping"}]
  }'

如果返回正常的 OpenAI 响应，号池已经跑起来了。但现在它还没有 Key 可用，接下来是关键步骤。

3.4 往号池里加 Key

1. 浏览器访问你的 Worker 地址（比如 https://api-pool-prod.xxx.workers.dev）
2. 用你设置的管理员密码登录管理面板
3. 在 Key 管理页面，批量粘贴你的 API Key（支持逗号或换行分隔）
4. 系统会自动检测每个 Key 的余额和状态

加完 Key 后，再跑一次上面的 curl 测试——请求会自动分发到号池中状态最好的 Key。

四、最值钱的部分——号池内部怎么选 Key、怎么切 Key

这一章是全篇最值钱的。大部分教程只告诉你”复制代码、点击部署”，但没人讲清楚号池内部到底是怎么工作的。做完代理的人都知道，号池的调度能力直接决定下游客户的体验——请求延迟、错误率、Key 利用率都跟它相关。

4.1 不是随机挑，是”余额最多、成功率最高”的优先

普通的”轮询”就是随机挑一个 Key。但 api-pool 用的是一种加权优先级选择算法：

这套逻辑的价值在哪？

1. 额度多的 Key 优先用——避免有的 Key 快过期了还剩一堆额度没用
2. 成功率低的 Key 自动降权——不用手动去排查哪个 Key 不稳定
3. 自动故障转移——用户基本无感知 Key 层面的问题

4.2 Key 被封了？系统自己切，你根本不用管

号池最怕的情况：一个 Key 被封，后续所有请求打到这个 Key 上全部失败。

api-pool 的处理机制：

Key 层面：
  连续失败 ≥ MAX_CONSECUTIVE_ERRORS（默认 3 次）
  → 自动标记为"禁用"
  → 后续请求不会再选到它

恢复机制：
  系统每隔一段时间（默认 5 分钟）
  → 对已禁用的 Key 做一次"健康检测"
  → 如果恢复成功 → 重新加入可用池
  → 如果仍然失败 → 继续禁用，等下一轮检测

所以你不需要 24 小时盯着 Key 的状态——系统自己会处理。你只需要保证号池里随时有足够多的”活 Key”就行。

4.3 一套系统，同时管 OpenAI / Claude / Gemini

一个 Worker 同时代理所有模型，通过 URL 路径区分：

// 路由逻辑
if (path.startsWith('/openai'))  → 转发到 OpenAI Key 池
if (path.startsWith('/claude'))  → 转发到 Claude Key 池
if (path.startsWith('/gemini'))  → 转发到 Gemini Key 池
// 默认走 OpenAI 格式（兼容大部分国产模型）

不同模型的 Key 天然隔离：

• OpenAI Key 池挂了不影响 Claude 的请求
• Gemini 的免费层 Key 可以和付费 Key 混合使用
• 下游客户的请求自动路由到正确的池子

4.4 逐字输出不卡壳——SSE 怎么处理才不翻车

这是很多人容易忽略的坑。大部分 AI 应用（ChatBox、LobeChat、NextChat、Cursor）都依赖 SSE 流式输出来实现”逐字打印”效果。如果号池不完整转发 SSE 事件，客户端就会卡住。

api-pool 在 SSE 处理上做了两件事：

1. 保留原始 SSE 事件格式——不截断、不拼接、不改写。确保与所有 OpenAI 兼容客户端正常工作。
2. 自适应延迟算法——根据内容大小和生成速度动态调整发送速率。防止”一句话分 20 个包发”导致的客户端渲染撕裂。

五、绑个自己的域名，再加三道安全锁

5.1 绑定自定义域名

.workers.dev 免费域名有明显的局限：部分网络环境下解析不稳定、URL 看起来不专业。

建议绑定一个你自己的域名（比如 api.yourdomain.com）：

1. Worker 设置 → 触发器 → 添加自定义域
2. 输入你的域名 → Cloudflare 自动添加 DNS 记录
3. 等 DNS 生效（通常 1-2 分钟）

绑定自定义域名有两个额外好处：

• 路由优化：Cloudflare 会根据你的 DNS 配置优化网络路径，通常比 .workers.dev 延迟更低
• SSL 自动配置：Cloudflare 自动签发和管理 HTTPS 证书

5.2 安全加固清单

以下每一项都建议在生产环境部署前完成：

环境变量的正确用法：

// ❌ 错误：硬编码
const ADMIN_PASSWORD = "admin123";

// ✅ 正确：从 Worker Secret 环境变量读取
const ADMIN_PASSWORD = env.ADMIN_PASSWORD;

在 Worker 设置 → 变量和机密 → 添加机密：

• 变量名：ADMIN_PASSWORD，值：你的密码，类型选”加密”
• 变量名：API_KEY，值：你的自定义 Key，类型选”加密”

5.3 添加自定义 Auth Header

如果你的 Worker URL 意外泄露，任何人知道了你的 API Key 就能调用。可以再加一层防护：

在 Worker 代码中添加：

// 在最外层 fetch 处理器中
const customAuth = request.headers.get('X-Pool-Auth');
if (customAuth !== env.POOL_SECRET_TOKEN) {
  return new Response('Unauthorized', { status: 401 });
}

下游客户端调用时需要额外带上这个 Header：

curl https://api.yourdomain.com/v1/chat/completions \
  -H "Authorization: Bearer sk-你的Key" \
  -H "X-Pool-Auth: 你设置的额外Token" \
  -d '...'

六、从自己跑到卖给别人——号池怎么”商用化”

你的号池目前能跑了，但要对外提供给付费客户，还需要几个关键步骤。

6.1 存 Key 用 KV 还是 D1？超过 50 个就别犹豫了

api-pool 支持两种存储后端：

做代理的话，建议直接用 D1。原因：

• D1 支持 SQL 查询，你可以自己写 SQL 拉取每个 Key 的用量统计
• D1 的写入性能更好，批量操作 Key 不容易丢数据
• KV 在 Key 数量超过 100 时可能出现一致性延迟

6.2 每个客户一把独立钥匙，用量清清楚楚

这个功能 api-pool 默认支持——你在管理面板添加的”下游 API Key”就是给客户用的。

建议策略：

客户 A → API Key: sk-customer-A-xxxx
客户 B → API Key: sk-customer-B-xxxx
客户 C → API Key: sk-customer-C-xxxx

每个客户一个独立 Key，好处是：

1. 用量可追溯——知道哪个客户用了多少 Token
2. 可单独限速——某个客户用太猛不会影响其他人
3. 可随时撤销——客户到期停用直接删 Key

6.3 从 10 个 Key 到 200 个——三阶段怎么走

阶段一：个人验证（第 1-2 周）
├─ 1 个 Worker
├─ 10-20 个上游 Key  
├─ 1-3 个测试客户
└─ 用 KV 存储，先跑通流程

阶段二：小型代理（第 3-4 周）
├─ 1 个 Worker + 自定义域名
├─ 50-100 个上游 Key
├─ 10-30 个付费客户
├─ 迁移到 D1 数据库
└─ 配置安全加固 + Rate Limiting

阶段三：业务扩展（第 2 个月起）
├─ 多个 Worker 做地理负载均衡
├─ 200+ 上游 Key  
├─ 50+ 付费客户
├─ 配合外部计费系统
└─ Grafana 定制监控大盘

注意：Cloudflare Worker 在单个 Worker 上的 CPU 时间是有限制的（免费版 10ms/请求），但对于 API 代理这种轻计算场景完全够用。真正需要多个 Worker 的时候通常是因为你需要按地域分流（比如国内用户走亚太节点、海外用户走美西节点），而不是因为计算瓶颈。

七、5 条防封实操：Key 分账户、错误码分类、缓存兜底

7.1 Worker 的天然优势

重温一下：Cloudflare 全球 335 个边缘节点，每次 Worker 请求的出站 IP 不固定。这意味着：

• OpenAI 的风控系统看到的是”分布在全球各地的请求”，而不是”一个 IP 在疯狂调用”
• Anthropic 的 Rate Limit 是按 API Key 而非 IP 计算的，Worker 不会引入额外的 IP 层面限速
• Gemini 对 IP 的封禁策略相对宽松，但在高并发场景下 IP 分散仍有帮助

7.2 实操五条

1. 上游 Key 分散注册

不要把所有 Key 注册到同一个支付账户下。一个支付账户被封，所有子 Key 全挂。

推荐布局：
  账户 A（PayPal A + 美国地址 A）→ 5 个 OpenAI Key
  账户 B（PayPal B + 美国地址 B）→ 5 个 OpenAI Key
  账户 C（虚拟卡 C + 英国地址 C）→ 5 个 Claude Key

2. 合理设置故障阈值

MAX_CONSECUTIVE_ERRORS 不要设太小（比如 1），一次网络抖动可能导致正常 Key 被禁用。建议设 3-5。

3. 恢复检测间隔错开

不要所有 Key 的恢复检测在同一时间。如果一号池的 Key 被 OpenAI 统一封了，批量恢复检测会被 OpenAI 识别为”同一来源在反复试探”。

4. 错误码分类处理

// 不同错误码应该区别对待
429 Rate Limit → 暂停使用该 Key 30 秒，不标记为"失败"
403 Forbidden  → 该 Key 已封，立即禁用，缩短恢复检测间隔
500 Server Error → 上游服务挂了，重试下一个 Key 但不标记为失败
401 Unauthorized → Key 无效（过期或被吊销），永久禁用

5. 可预测的高频请求做缓存

如果下游客户反复发送相同的 prompt（比如”翻译这段代码”），可以在 Worker 层加一个简单的 KV 缓存：

// Key 缓存策略伪代码
const cacheKey = hash(model + messages);
const cached = await env.KV_CACHE.get(cacheKey);
if (cached) return cached;  // 命中缓存，不消耗 API 额度

这能显著减少重复请求对上游 Key 的消耗，间接降低封号风险。

八、算账：一年只花 $10，利润做到 60%

8.1 号池方案 vs VPS 方案的全年成本对比

8.2 代理业务的简化盈利模型

假设一个小型代理业务的真实数据：

月收入：
  20 个付费客户 × $50/月 = $1,000

月支出：
  API 额度采购（批发价）：$400
  Cloudflare 费用：$0（免费套餐内）
  域名分摊：$0.83/月
  
月利润：
  $1,000 - $400.83 = $599.17（利润率 ~60%）

利润率的大头不是来自”卖更贵”，而是来自 号池让 API 额度的利用率最大化——你不会因为某个 Key 余额用不完而浪费钱，也不会因为一个 Key 被封导致服务中断而丢客户。

8.3 什么时候该升级付费计划

免费套餐够用的标准：
  √ 日请求 < 10 万次
  √ 存储 < 5 GB（D1）
  √ 日活下游用户 < 200

需要升级到 $5/月付费版的信号：
  → 连续 3 天请求量接近或超过 10 万
  → 需要更详细的 Analytics 数据
  → 需要更长的 Worker CPU 时间（但 API 代理基本不需要）

常见问题

Q: 这个方案支持哪些模型？

api-pool 兼容所有 OpenAI 格式的 API，包括但不限于：OpenAI / Azure OpenAI / Claude（兼容模式）/ Gemini（兼容模式）/ DeepSeek / 硅基流动 / 通义千问 / 智谱 / Moonshot 等。

Q: Worker 部署后国内访问会慢吗？

Workers 默认的 .workers.dev 域名在国内部分网络环境下可能有波动。解决方法是绑定一个自己的域名——Cloudflare 的 CDN 节点会就近接入，通常比直连 VPS 快。

Q: 上游 Key 是 Claude 订阅转化的，能用吗？

能。api-pool 本质是一个 HTTP 代理，只要你的 Key 能正常调用 API，它就能转发。这种场景建议在上游配一个 Sub2API 做订阅到 API Key 的转化，再由 api-pool 做号池调度——两者配合是比较推荐的实践方式。

Q: 多个 Worker 怎么共享 Key 池？

让所有 Worker 绑定同一个 D1 数据库即可。D1 支持多 Worker 读写同一个数据库，天然是分布式的。

Q: 能追踪每个下游客户的用量吗？

基础版 api-pool 按 Key 统计用量。如果需要更精细的客户级追踪，需要在 Worker 代码里添加请求日志（写入 D1 或外部服务）。这是一个常见的定制化需求。

结语

号池不是”锦上添花的优化”，它是 AI API 中转站的技术护城河。

一个没有号池的中转站，本质上就是一条转发规则——任何一个会配置 Nginx 的人都能做，没有壁垒。但一个生产级的号池，需要智能调度、故障转移、安全加固、用量追踪——这些才是在用户面前建立”稳定”印象的关键。

Cloudflare Worker 免费套餐，足够支撑一个小型代理走完从 0 到 1 的阶段。你要做的，就是动手搭起来。