API Key 泄露被盗刷怎么办：排查、止损与预防

某天早上打开账单，昨天的消费是平时的 40 倍，请求记录里全是没见过的模型和 IP——这不是限流问题，也不是计费 bug，大概率是你的 API Key 泄露了，正被别人当免费额度用。

Key 泄露的麻烦在于：它不会报错、不会影响你的正常调用，只在账单上安静地体现。等到发现时，往往已经刷掉了不少余额。这篇按「发现 → 止损 → 预防」三步讲清楚怎么处理。

先确认：是不是真的泄露了#

五个征兆里中两个以上，基本可以断定：

• 消费异常：账单出现你没用过的模型（尤其是高价模型），或凌晨时段大量请求
• 余额消耗速率对不上：自己的调用量没变，消耗翻了几倍
• 请求日志里有陌生来源：IP 归属地、User-Agent 与你的服务完全对不上
• 收到了平台的异常告警邮件：部分网关会检测异常调用模式
• 代码仓库公开过、前端打包文件发布过、日志对外暴露过：有这些历史，即使暂时没异常也要当隐患处理

30 分钟止损清单#

发现泄露后的动作顺序很重要，错了会漏：

1. 立刻作废旧 Key：在控制台删除或吊销该 Key，不是新建一个就完事——旧 Key 不作废，刷子会一直用下去
2. 轮换所有引用：全局搜索代码、配置、CI 变量、Docker 环境、服务器环境变量里的旧 Key，全部替换为新 Key
3. 设消费上限：新 Key 配置每日或每月消费限额，把最坏情况的损失封顶
4. 检查衍生泄露：泄露的 Key 如果被别人转发出售，你可能无法控制它的使用，但作废后所有下游立刻失效
5. 回查日志估算损失：按泄露 Key 的调用记录统计非本人请求的消费额，确认是否有必要申诉或调整预算

止损之后才是查原因，顺序反过来会边查边继续被刷。

四个最常见的泄露渠道#

按实际出现频率排：

1. 前端硬编码。 把 Key 写进浏览器端 JS、小程序代码或 App 客户端里，任何拿到安装包的人解包就能提取。这是最严重也最常见的一种：客户端里的 Key 等于公开发放。正确做法是 Key 只放在服务端，客户端请求你自己的后端，后端再转发。

2. Git 提交历史。 临时调试时把 Key 写进代码提交了，后来删掉也没用——历史提交里还在。公开仓库直接被爬虫扫；私有仓库也不保险，仓库权限一变动就露。提交过的 Key 一律视为已泄露，直接作废换新。

3. 日志与错误上报。 请求头里的 Authorization 被打进日志，错误堆栈带着完整请求体上报到第三方监控平台，都是隐性出口。日志脱敏要覆盖所有打「headers」的地方。

4. 公开文档和分享。 接口文档示例里带真实 Key、群聊里贴 Key 让人测试、公开 Notebook 里留在单元格里。这类泄露传播慢但范围不可控。

预防：一套可落地的 Key 管理方案#

按用途拆 Key。 开发、测试、生产各一个；接给不同项目各一个。Key 的粒度就是损失隔离的粒度——一个项目泄露，作废它不影响其他项目。

Key 不落盘，走环境变量或密钥管理。 本地开发用 .env（并加进 .gitignore），服务器用环境变量注入，有条件用云平台的密钥管理服务。

设消费上限并开告警。 每个配消费上限，消耗到阈值触发告警。这是最后一道保险：即使预防全部失效，损失也有限且能第一时间知道。

聚合网关加一层隔离。 如果用 zaimod 这类聚合网关，好处是官方渠道的 Key 只存在网关侧，业务代码里用的是网关的 Key，泄露后作废换新即可，不用动到上游账号。模型多、Key 多的团队尤其适合这种收敛方式。接入方法见 OpenAI API 中转站怎么选。

定期轮换。 生产 Key 至少每季度轮换一次，轮换流程和止损流程一样：新 Key 上线 → 观察旧 Key 无调用 → 作废旧 Key。

常见问题#

Q：Key 泄露了能追回被刷掉的余额吗？

取决于平台政策，多数平台对非授权使用的处理口径是按实际情况个案处理，需要在发现后第一时间联系客服并提供调用记录作为证据。越晚上报，追回难度越大。

Q：我在 .env 里放了 Key 但仓库是私有的，还安全吗？

私有仓库的泄露风险低但不为零。重点检查两点：.env 是否真的被 .gitignore 覆盖（用 git check-ignore 确认），以及是否有 CI、构建脚本、协作者环境会把它带出去。

Q：消费上限设多少合适？

按「这个用途单日最大正常消耗 × 3」设定。宁可偶尔触发上限手动调高，也不要留出「被盗刷一周才发现」的空间。

延伸阅读#

• OpenAI API Key 怎么购买：国内开发者完整指南
• 大模型 API 429 报错：原因、重试与并发调优
• 2026 大模型 API 价格对比：主流模型实测数据
• API 中转站跑路的 5 个信号：余额、响应、更新