看别人开中转站赚钱，或者团队内部想统一收口模型调用，于是动了自建的念头。真动手才发现坑不在代码，而在账号从哪来、代理怎么串、计费怎么记、被刷了怎么办。这篇按上线顺序给一份可对照的执行清单，写清每步该确认什么、什么情况下这套方案根本不适用。
看别人开中转站，或者团队内部想把模型调用统一收口，于是动了自建的念头。真动手才发现，难的不是把程序跑起来，而是账号从哪来、代理怎么串、计费怎么记、被刷了怎么办。这篇按上线顺序给一份能对照执行的清单，每一步写清该确认什么、什么情况下这套做法根本不适用。
先说立场：自建中转站不是省钱的万能解。如果你的调用量很小、只是自己偶尔用，直接买现成服务通常更划算，自建光维护渠道健康就够折腾。只有当你需要统一收口、做内部计费、或者对外经营时，自建的价值才体现出来。下面按「想清楚」到「上线验收」的顺序走。
动手之前先想清楚三件事
第一件事是目的。自用省钱、团队内收口、对外卖额度，这三者的架构要求完全不同。自用只要一把 Key 加个反代就能凑合；团队内收口必须做用户体系、额度分配、调用审计；对外经营还要额外考虑合规、退款、发票这些非技术问题。目标没定就开工，后面大概率推倒重来。
| 目的 | 必须有的能力 | 可以不做的事 |
|---|---|---|
| 自用省钱 | 多渠道切换、基础限流 | 用户体系、对账报表 |
| 团队内收口 | 多用户鉴权、额度池、调用日志 | 对外支付、退款流程 |
| 对外卖额度 | 完整计费、余额管理、公告渠道 | 内部成本分摊细节 |
第二件事是账号来源，这是整个站的命门。官方直连、云厂商托管、渠道分组，决定了你后面会不会突然全线掉线。动手前先去站内 /official-api 和 /providers 把可用来源和各自限制摸一遍，确认哪些来源适合做主力、哪些只能做备用。
- 先算真实成本：服务器、带宽、代理、上游溢价、被刷损耗都要摊进去，别只看上游单价；用 /tools/model-cost-calculator 把账先跑一遍再决定要不要开工
- 确认来源稳定性：单一来源等于单点故障，至少要有一个能顶上来的备选渠道，再决定买多大机器
- 想清楚合规边界：对外经营涉及资质与内容责任，这部分不解决，技术做得再好也不能上线
部署顺序：照这个次序走，别跳步
部署最容易犯的错是跳步。很多人上来就拉中转程序镜像，结果系统时区没设、数据库没起、反代端口占用，报错一堆分不清是程序问题还是环境问题。按下面的顺序走，出问题时排查范围会小很多。
- 先把基础环境装齐系统、运行时、数据库、反向代理四样先到位，时区和系统时间也要校准，否则后面 token 计费或签名校验会出现难以定位的偏差。装完挨个启动一遍确认监听正常。
- 再装中转程序本体环境齐了再拉镜像或部署包，此时报错基本只会出在程序配置上，排查面窄。第一次启动先用默认配置跑起来，能打开后台即可，不要急着加渠道。
- 单渠道打通链路只配一个上游渠道，发一条非流式请求、一条流式请求，确认返回正常、用量能记上。这一步通了，才说明鉴权、转发、计费三段都活着。
- 加反代与限速反代负责 TLS 和限速，中转程序负责鉴权和转发，两层职责别混。限流放反代层更省事，也更能挡住脚本刷量，配完用压测工具验证限速真的生效。
- 本地回环测完再解析域名配置改动先在 127.0.0.1 上验证，确认没问题再把域名指过去。否则调试期的报错页面会直接暴露在公网上，等于给扫描器发邀请。
最容易翻车的四类坑
跑通不代表能稳定运行。下面四类问题在自建站里出现频率最高，而且多数在出事之后才被发现。每一条都给了可落地的判断标准，不确定自己是否踩中，就按标准逐条核对。
- 账号池不稳定
- 单账号被限速或被风控就会拖垮整站。判断标准：渠道掉线后是否会全站不可用；做法是给多渠道配健康检查与自动摘除，别只靠人工发现。
- 密钥与日志没脱敏
- 请求日志里存了完整 Key 或用户内容，一旦库被拖走就是连带事故。判断标准：随便翻一条日志，看能否直接看到可用密钥。
- 计费口径不统一
- 上游按量、你按次，或者倍率写错，对账时一定出问题。倍率怎么摊到报价上，可参照站内 /guides/relay-rate-calculation 的口径，先定规则再上线。
- 没有限额与告警
- 单 Key 无上限等于把钱包敞开。判断标准：给一个 Key 设了日额度没有；异常用量有没有通知渠道；出事多久能发现。
这四类里，账号池和计费最容易被低估。账号池靠人盯是盯不住的，必须让程序自动判活；计费口径如果一开始就没统一，后面补账几乎不可能，用户也不会认。上线前把这两条当作硬性门槛。
上线前跑一遍验收清单
发布前别只测「能不能出结果」，按功能、性能、安全、运营四个面各过一遍。每一项都给了动作，做完打勾即可，没做的项目就是上线后的风险点。
| 验收面 | 要测什么 | 不通过意味着 |
|---|---|---|
| 功能 | 非流式、流式、长上下文、报错返回各测一次 | 错误码被吞掉，用户排障全靠猜 |
| 性能 | 并发打一波，量出延迟基线 | 瓶颈可能在本地也可能在上游，分不清 |
| 安全 | 后台不裸奔、默认口令已改、Key 权限最小化 | 被扫到就是一个入口 |
| 运营 | 余额过期、退款口径、渠道变更公告方式 | 规则不清，后续全是扯皮 |
- 功能面重点看错误码是否透传：上游返回的具体错误要能让调用方看到，而不是统一回一句「请求失败」
- 性能面到 /tools/speed-test 对照你自己的链路耗时，判断瓶颈在本地还是上游，别凭感觉优化
- 安全面确认管理后台不对公网裸奔、默认口令已改；团队共用一把 Key 的风险和替代做法见 /guides/shared-key-risk-control
- 运营面把余额过期规则、退款口径、渠道变更公告方式写成文字，放在用户能看到的地方
验收清单不是走形式。上述任何一项缺位，上线后都会以投诉或对账纠纷的形式找回来，而且处理成本远高于上线前花的那点时间。小团队人手少，可以合并执行，但四类都要有人负责确认。
最后提醒一句：验收通过不等于长期稳定。渠道会变、上游会调整、攻击会升级，站内 /price-watch 和 /sites 这类页面适合定期回看，把自己的渠道价格和健康情况跟同行对照一下，早发现异常比晚处理省事得多。
下一步准备开工前，先到站内把上游来源和成本口径摸清楚，再动手装环境。→常见问题
自己没有海外账号，还能搭中转站吗？
技术上可以，但上游来源会决定成败。用国内云厂商或合规平台做上游，链路短、稳定性好，代价是模型选择和价格受平台约束；绕道境外账号则要自行承担封号与合规风险。先想清楚你要接哪几家模型，再去 /official-api/providers 逐个看接入方式和限制，比先搭架子再找货靠谱。
自建和直接买别人的中转，哪个划算？
取决于量和使用人群。只有自己用、量不大，买现成的省心，出问题还有人背；团队几十号人共用、或者需要审计和限额，自建的价值才体现出来。判断标准不是单价高低，而是你能不能持续投入时间做运维——上游掉线、程序升级、账号风控，这些活不会自己消失。
搭好之后怎么知道它到底稳不稳？
别靠体感。固定几个模型和几条真实请求，按天跑，记录成功率、首字延迟和错误类型；同时挂一个外部探针，避免自己电脑网络波动干扰判断。站内 /tools/verify 和 /tools/quality-monitor 可以帮你做真假与质量层面的交叉验证，但长期趋势还是得靠自己攒数据。
