API 密钥泄露了怎么办——四步止损与后续措施

密钥泄露的典型迹象

如果你怀疑 API 密钥可能泄露了，留意以下信号：

• API 响应 header 里的剩余余额突然减少
• API 请求出现了你自己没有发出的调用模式（特别是大量并发或分钟级高频请求）
• 收到 notrack.ai 关于"密钥异常使用"的邮件通知（如果你的密钥设置了每日上限）
• 你曾经把密钥提交到公开代码仓库（如 GitHub）、公开日志、或分享给了不可信的第三方

四步止损方案

第一步：在控制台禁用或删除密钥

notrack.ai 的 API 密钥管理页面允许你查看、禁用和删除已创建的密钥。第一时间进入控制台，禁用或删除被泄露的密钥。

禁用后，所有使用这个密钥的请求会立即返回 401 Unauthorized。已经在运行的客户端（如 SillyTavern、LangChain 脚本）会报错，这是正常的——等你替换成新密钥后再启动。

第二步：检查消费明细

在密钥被禁用前（或刚禁用后），到 API 控制台查看该密钥的消费明细。确认：

• 被泄露的密钥已经消耗了多少积分
• 是否在你的每日上限之内（你设置了的话）
• 有没有异常的消费模式（比如短时间内大量请求）

如果消费金额在每日上限之内，损失已经封顶，不会扩大。如果没设每日上限、且密钥泄露后被大量使用，可能需要联系 support 页面协商处理——但官方明确说"积分不予退款"，这种情况下协商空间有限。

第三步：创建新密钥并替换

创建一个新的 API 密钥，然后在你的所有客户端里替换掉旧密钥：

• SillyTavern：API Connection → 换成新密钥 → Connect
• Python / Node / curl 脚本：替换 api_key / Authorization header 里的值
• LangChain / Open WebUI / VS Code 插件：在各自的设置里替换

新密钥创建时务必设置每日消费上限（建议先设置一个保守值，比如 $5/天），这样即使新密钥再次泄露也不会损失太多。

第四步：定位泄露源头并修复

密钥泄露的常见源头：

• 提交到了 GitHub（最常见）：用 git log -p 检查提交历史，找出泄露的那个 commit。即使后来删掉了，git 历史里还留着。用 git rebase 重写历史（但如果已经 push 到远程，需要 force push）
• 写在了公开的配置文件、README、Dockerfile 里
• 通过邮件、聊天工具发给了不可信的第三方
• 服务器日志被公开或被攻破

修复方式：把旧密钥彻底废弃（你已经做了），新密钥永远不出现在公开可见的文件里。用环境变量、密钥管理服务、或本地 .env 文件存储。

防止泄露的日常习惯

1. 给每个应用配独立密钥

这是 notrack.ai 官方强烈建议的做法：

• SillyTavern 用一个密钥
• LangChain 脚本用另一个
• Open WebUI 用第三个
• 自己的 Python 脚本用第四个

这样即使某个客户端泄露，只需要禁用那一个密钥，不影响其他应用。

2. 设置每日消费上限

每个密钥创建时都可以设置一个每日消费上限（比如 $10、$20）。这是防止密钥泄露后被刷爆余额的最有效手段——即使泄露了，最多也只是损失每天 $X。

3. 用环境变量存储密钥

永远不要把 API 密钥硬编码在源代码里。正确做法：

# 好的做法
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.notrack.ai/v1",
    api_key=os.environ["NOTRACK_API_KEY"]  # 从环境变量读取
)

4. 密钥只显示一次

notrack.ai 在创建密钥时只完整显示一次。如果你之后忘了密钥值，不要去控制台找"显示密钥"按钮——应该直接删除旧密钥、创建新密钥。这是设计用来防止密钥被反复查看泄露的机制。