AI中转站上游模型密钥泄露应急处理

如果你的 AI 中转站（比如 OneAPI、NewAPI 这类服务）出现了上游模型密钥泄露，比如被上传到 GitHub、被爬虫抓到、或被人拿到后疯狂调用，那后果可能是一夜之间账单爆炸，甚至账户被封。
下面这套紧急处理流程是针对完全没有相关经验的站长准备的，按顺序执行，每一步都写清了操作路径和注意事项。

先确认密钥真的泄露了吗

在动手之前，先确认泄露的范围。
最常见的线索有三个：

• 上游服务商（如 OpenAI、Azure）后台出现异常的调用量或 IP 请求。
• 在日志或监控中看到来自非预期的 IP 大量调用你的中转站。
• GitHub、Pastebin 等公开平台搜到了你的密钥片段。

如果符合任意一条，立即进入下一步，不要等确认完整，先停止泄露的密钥。

立即禁用并替换泄露的密钥

这里分两个层面操作：先把 AI 中转站里的密钥禁用或删除，再去上游服务商那边彻底撤销。

1. 在中转站后台禁用旧密钥

登录你的 AI 中转站管理后台（比如 OneAPI 的管理面板）：

1. 进入 密钥管理 -> 渠道管理。
2. 找到泄露对应的那个上游渠道（通常是一个 Key 绑定一个渠道）。
3. 立即禁用（或删除）该渠道。如果面板支持“停用”状态，选停用；如果不支持，直接删除。
4. 检查是否还有其它渠道引用了同一个上游密钥，一并处理。

注意：不要只删除不新建，否则所有依赖该渠道的请求都会失败。下一步会创建新密钥。

2. 在上游服务商撤销旧密钥

到你的上游模型供应商（例如 OpenAI、Azure、Anthropic）的管理页面：

• OpenAI：登录 platform.openai.com -> API Keys，找到泄露的那个 Key，点击“Revoke”。
• Azure：在 Azure OpenAI 资源下 -> Keys and Endpoint，点击“Regenerate”或删除。
• Anthropic：console.anthropic.com -> API Keys，点击“Revoke”。

撤销之后，旧密钥会立即失效，攻击者再用就会返回 401 错误。

3. 生成新密钥并配置到中转站

在上游服务商创建新 Key，然后回到你的 AI 中转站后台：

1. 新建一个渠道（或编辑刚才禁用的渠道）.
2. 粘贴新密钥，保存后启用。
3. 测试一下，如果你的中转站支持“测试”按钮，点一下；如果不支持，手动发一个请求检查。

检查并清理泄露源

禁用密钥只是止损，如果泄露源头不堵住，新密钥也会再次泄露。

常见的泄露来源：

• 环境变量文件（.env、.env.example）被提交到公共仓库。去 GitHub 查看仓库历史，如果存在敏感信息，立刻删除并强制 Github 清理缓存（联系 GitHub Support）。
• 代码中的硬编码。检查所有代码文件（.py、.js、.yaml 等）是否直接写密钥。如果使用了版本控制，在提交前建议用 .gitignore 排除所有配置文件。
• 日志文件。AI 中转站可能记录了完整的请求参数，包括密钥。登录服务器查看日志目录（如 /var/log/oneapi/），使用 grep 搜索旧密钥，如果日志中有泄露风险，需要清除或截断。
• 数据库。如果旧密钥被写入数据库（比如用户自己上传的API Key），考虑重置相关记录。

一个常见误区：有人只在中转站删除密钥，却忘了上游服务商那边密钥还是有效状态。一定要两边同时撤销。

验证修复是否生效

完成以上步骤后，需要验证几个点：

1. 旧密钥失效：用命令行或在线工具（如 curl）手动调用旧密钥，应该返回 401：

   curl -H "Authorization: Bearer 旧密钥" https://api.openai.com/v1/models

预期输出 401 Unauthorized 或 invalid_api_key。

1. 新密钥工作：用新密钥测试同样的请求，应该返回正常数据。
2. 中转站调用正常：用自己的账号在中转站前端发一条消息，确认能成功返回模型回答。

高频问题与避坑说明

Q：密钥已经泄露但还没产生费用，可以不管了吗？
A：不行。攻击者可能先扫描记录，过段时间再集中使用，那时损失会更大。必须立刻处理。

Q：我忘了密钥关联了哪些服务怎么办？
A：登录上游服务商，看 API Keys 列表里的“Last used”时间和请求 IP 信息。你可以在 AI 中转站后台查看每个渠道的调用日志。如果实在不确定，直接撤销所有密钥重新生成。

Q：新密钥配置后服务依然报错？
A：检查中转站的渠道配置是否正确，尤其是模型名称、Endpoint URL 是否需要附加路径。另外，中转站可能缓存了旧密钥，尝试重启服务。

最后提醒

密钥泄露是很常见的安全事件，不用特别紧张，但一定要按上面的顺序先停用、再撤销、后重建、最后查源头。
建议以后启用密钥轮换策略（比如每 30 天换一次），并给中转站加上 IP 白名单限制，只允许你信任的服务器调用。
如果存储环境是宝塔面板，可以在宝塔中开启日志报警，实时监控异常请求。

如果你在处理过程中遇到其它报错，先回去检查步骤 2 的密钥状态是否真的被撤销了，这是最容易忽略的一步。