中转站事故处理手册：从发现到恢复的六步

"站点出事了"有好几种：接口报错、被限流、余额异常、模型被换、甚至直接跑路。不同事故的处置方式完全不同，但有一个共同点：前十分钟做什么，决定了你后面能不能拿回钱。

一、先分类，再动手

不要一边重试一边等。重试会把余额烧掉，也会让日志变得难以分析。

二、第一步：止损

• 如果是 Key 相关，先吊销。
• 如果是站点整体故障，切到备用站。这就是为什么建议至少配置两家。
• 如果是计费异常，停止所有非必要调用。

止损的目标不是"解决问题"，是"防止损失扩大"。问题可以慢慢查。

三、第二步：留证

在站点还能访问的时候，把下面这些导出或截图：

• 账户余额和充值记录
• 最近的调用记录（时间、模型、token、金额）
• 站点的公告和服务条款（尤其是退款条款）
• 客服对话记录

站点跑路后，这些是你唯一能拿出来的东西。现在就做，不要等。

四、第三步：判断责任方

这一步决定你后面跟谁沟通：

• 上游问题（官方 API 挂了）：站点通常也是受害者，等恢复，要求补偿。
• 站点问题（配置错误、超卖、限流）：站点负责，要求解释和补偿。
• 你自己的问题（Key 泄露、代码 bug）：自己承担，改流程。

判断方法：用一个已知正常的模型发最小请求。如果也失败，问题在上游或站点；如果只有特定模型失败，问题在路由或分组。

五、第四步：沟通

给客服的消息要包含：

账号：（注册邮箱或用户名，不要给密码）
时间：2026-11-12 14:02 – 14:35（UTC+8）
现象：所有 claude-* 模型返回 502，gpt-* 正常
请求 ID：req_abc123, req_def456
已排除：本地网络正常，同 Key 调 gpt-4o-mini 成功
诉求：确认故障原因；这段时间的扣费是否退还

不要：

• 贴完整 Key
• 情绪化指责
• 一次发十几条消息
• 在公开群里曝光对方的个人信息

前两条会让沟通失效，后两条会让对方不愿意配合。

六、第五步：恢复与验证

站点说"修好了"之后，不要立刻切回生产。先：

1. 用最小请求验证基本可用。
2. 跑一遍模型身份检查，确认没有趁机换模型。
3. 对比延迟，确认没有明显劣化。
4. 观察 24 小时再切主要流量。

七、第六步：复盘

不管事故大小，写下来：

• 发生了什么（时间线）
• 影响范围（多少请求、多少钱）
• 根本原因（如果知道）
• 做了什么（止损、沟通、恢复）
• 下次怎么避免（备用站、告警、Key 管理）

这份记录的价值在下次事故时体现——你会发现自己上次踩的坑，这次能提前避开。

八、三种特殊情况的处理

站点跑路

特征：客服失联、公告停更、网站打不开。

处置：立刻停止充值，导出所有记录，在能联系到的渠道（群、论坛）和其他用户互通信息。不要相信"再充一点就能恢复"的说法。

余额被清空

先查是不是自己的 Key 泄露（看调用记录里有没有你不认识的模型或时段）。如果不是，要求站点提供调用明细。多数站点能查到 IP 和模型，这些能帮助判断。

模型被换

不要只凭"感觉变笨了"下结论。按模型指纹那篇的方法收集证据：token 比例、model 字段、上下文行为。有证据再谈，比情绪化投诉有效得多。

九、一份备用站清单

至少准备两家，并且：

• 不同的上游渠道（避免同时挂）
• 都实际测过（不是只注册了）
• Key 都配好了（出事时不用现找）
• 余额都够用一周

切换的成本应该是一次配置改动，不是一次紧急采购。

十、最后

中转站是一个有对手方风险的生意。你付的钱买的是"现在能调用"，不是"永远能调用"。把它当成一个需要监控和备份的外部依赖，而不是一个基础设施，心态会正常很多。