API 中转站搭建实战:从账号池到住宅代理

很多做工具站的朋友会问:别人的 API 中转站是怎么做到又便宜又稳定的?这篇文章用真实案例拆解一套完整的中转站架构:账号池、出口节点、质量守卫、住宅代理,四层配合。

整体架构

中转站的核心是"用免费或低成本的账号,提供标准 OpenAI 格式的 API"。以 Grok 中转为例,架构分四层:

客户端 → 中转网关(CLIProxyAPI/Grok2API)
            ├── 账号池:100 个 Grok 账号
            ├── 出口节点:10 条住宅代理通道
            └── 质量守卫:自动探测节点健康,隔离异常

第一层:账号池

中转站需要大量账号做负载均衡。账号分三种来源:

• CLI 账号(如 Grok Build):OAuth 令牌,走官方 CLI 网关,稳定
• 网页版账号:通过会话保持,免费但脆弱
• 控制台账号:额度高但容易风控

账号导入后统一格式存储(认证文件),网关按轮询或权重分发请求。关键点:同一令牌不能同时在两个系统使用,否则平台检测到多端登录会封号。所以账号从 A 系统迁移到 B 系统时,要禁用 A 侧对应账号。

第二层:出口节点

出口 IP 是风控的重灾区。同 IP 大量请求,账号很快会被标记。解决方案是每个账号绑定独立出口:

• 免费代理池:便宜但质量波动大,经常有死节点
• 住宅代理(如 711proxy):每次连接轮换 IP,IP 干净,风控压力最小
• 自建代理池:从免费源抓取,筛选可用节点

实测对比:免费池 236 个节点里只有 164 个能用,延迟 98ms-530ms;住宅代理延迟约 1.2s,但每次请求出口 IP 都在变,基本不会被按 IP 风控。

第三层:质量守卫

节点会挂,账号会死,所以必须有自动巡检:

• 定时探测每个节点的连通性和延迟
• 异常节点自动隔离(标记 disabled,不再分配请求)
• 隔离后,绑在该节点上的账号自动迁移到健康节点

这层做好了,运维基本可以躺平——坏节点自己退场,好节点自动接管。

第四层:伪装与合规

给上游平台的请求要伪装成正常客户端:

• 固定 User-Agent:模拟某个版本的真实客户端,不能随机
• 固定出口 IP:住宅代理可以做到每次不同,但如果是付费 Key 分享场景,固定反而更安全
• 请求频率:单账号控制 QPS,避免触发限流

踩坑记录

1. 示例 Key 是炸弹:网关配置里混入示例占位符(如 your-api-key-3),整个 API 会被自动禁用,所有请求 403。上线前必须检查配置里没有示例值。
2. 代理 URL 误填:全局代理字段被误填成 OAuth 令牌,导致启动报 proxy URL missing scheme/host。这类配置错误很隐蔽,但日志会给线索。
3. 账号迁移要禁用源侧:两边同时持有同一令牌,等于把账号放在风控的枪口上。

总结

中转站的稳定性 = 账号池广度 × 出口 IP 干净度 × 守卫自动化程度。先把三层架构搭起来,再用真实流量调优,比一开始追求完美方案实在得多。