Snapshot Reader
最近用 API 的需求太杂，本想搭个简单的个人 Token 中转站，结果越缝越上头，最后硬是在 VPS 上堆出了个跑着 8 个容器的“缝合怪”。搞完之后，顺手给大家水一贴，聊聊这玩意儿是怎么捏起来的。
先说结论：别学我，自用只需“三剑客”
先说最核心的结论：如果你只是想搭个稳定自用的中转站，千万别被我这 8 个容器的阵仗唬住了，你根本不需要搞这么重！
折腾一圈下来，真正天天在干活的绝对主力，其实就一条线上的三个服务：
any-auto-register（前线全自动造小号，基本用来注册GPT） → CLIProxyAPI（把小号的请求协议洗成标准格式） → new-api（最后在门口给你发 Token、算额度）。
这“三剑客”一条直线打通，自用应该是够了。至于我搞的其他 5 个组件，纯属“差生文具多”，完全是无序探索，为了榨干各种边角料渠道而搞的赛博废品回收站。
摸索过程：这台“赛博流水线”是怎么运转的？
本人基本也是个小白，所有的知识都是在L站学的，读了不少各路大神的帖子。既然都搭出来了，还是给大家盘一盘我这台机器上到底在跑些什么牛鬼蛇神。我是在远程的 VPS 上部署的，所有的项目通过 Coolify 部署在同一个 project 下。我把它们分成了三个车间：
1. 地下造号车间
这里压根不对外接客，纯在阴暗角落里爆兵，各种注册机，还有自己手搓的号，都是在这个环节，本质上是生产 token 的源头。
any-auto-register：这个属于成品一条龙，无情的填表/过验证码机器，我个人自用，基本上每天就是刷20个号左右就差不多了。目测观察，这个注册机刷的号差不多也就撑死了三天。inbucket：极轻量的内存邮箱。配上自己的域名，专门用来秒接注册机需要的验证码，产线完全闭环。（这个我只是部署看了一下，具体还没有用起来。冰佬的公益站发过神秘代码，用的就是这个邮箱服务。）
2. 协议清洗车间
基本上脏活累活都是在这个车间干，把各种不能直接用的白嫖接口，硬生生洗成 OpenAI等大厂标准格式，可以理解为是传输 token。
CLIProxyAPI：这个不用多说，属于重器神器，专治各种 OAuth 认证的命令行模型，基本上二开的项目都会支持 CPA。。sub2api：网页版榨汁机，把买的 Plus/Pro 网页端转成 API，这个放在这里也不一定合适，事实上它既有协议清洗的功能，也有 token 分发的功能，属于相对比较集成的应用。codex2api：这个专注于 Codex，在账号的管理和分发上还是比较专注的，尤其是账号的健康度的监测，这一块挺好。
3. 门面与分发车间
这个环节主要是做分发token。直接和你下游应用对接（或比如你的沉浸式翻译、Cursor、各种 agents）。
gpt-load：负载池。前面造出来的一大堆容易死的小号渠道全扔给它，它在后台自己轮询保活，这个主要是做负载均衡自动派发调度。纯粹是看需，自用的话，没啥必要。有一点印象深刻，他的日志请求记录非常详细。metapi：高级网关，中转站的中转站。我一般就把中转站收集在这汇总，然后统一出口，再接入到new-API 中。反正就是瞎折腾，有时候感觉确实是脱裤子放屁。new-api：绝对的 C 位，唯一的对外大门，其他的都走的是内网服务名互相调用。如果想访问的话，开一个 SSH 通道就行了。基本上接入了我所有的号池渠道、中转公益站渠道、还有我自己买的一些套餐都放在这里。统一出口，统一密钥，区别只在于不同模型的调用。
整个流程就是：造号车间疯狂产出 → 扔给清洗车间洗干净 → 倒进 gpt-load 负载池 → 最后 new-api 给你端茶倒水。
踩坑经验：怎么才能稳如老狗？
这套玩意儿跑通容易，但想让它不死，得守住几个底线。这也是我熬夜重装了几次才总结出来的血泪教训：
第一，内网服务名调用
我一开始图省事，容器互相调用全填的公网域名。结果数据绕着 Nginx 出去再回来，中间动不动就因为 SSL 证书或者网络抖动给你报个错。
现在只要在同一台机器上，互相调用一律死磕 Docker 内网别名（比如直接填 http://relay-cli-proxy:8080）。不仅速度快了一点，而且只要宿主机没炸，内部网络绝对不会断。公网域名只留给 new-api 露脸就行了。
第二，主动查日志。
绝大多数情况下，遇到 502 Bad Gateway，是背后的容器挂了——比如 new-api 没连上数据库，或者 cli-proxy 配置写错罢工了。面板上显示容器“Up”都是骗人的。排障一定要先 docker logs 看应用进程存活了没有，端口有没有真在监听，最后再去怀疑反代。
第三，启动顺序。
不要用 docker-compose up -d 一键全起然后去泡面。数据库（PG/Redis）没就绪之前，后面的网关和代理全都会无限重启。手动把底层状态跑稳了，再去接上游流量。
反正就这点事。周末折腾这么一圈，最大的乐趣其实看着数据在自己搭的流水线里跑通的那种爽感。大家平时自用中转都在玩啥架构？欢迎在下面接着吹水，互相学习一下，优化方案。
最后的最后，折腾一圈下来，我本来想把这上面的服务都打包成一个 Docker Compose 一键启动项目。但感觉有点走偏了，我本来就是自用，最理想的其实就是花钱买服务省时间，以上的方案只是建议作为一个备份而已。
1 个帖子 - 1 位参与者