当 Cloudflare API 密钥意外泄露时，很多人的第一反应是立刻删除密钥。但直接删可能引发更大的问题——如果密钥正在被生产系统调用，突然撤销会导致 DNS 更新、缓存清理、SSL 续期等操作全部失败。正确的紧急处理遵循“先判断、再替换、后清理”的顺序。以下是根据通用经验整理的应对步骤，每一步都附带适用场景和风险边界。
先别急着删密钥：确认泄露事实
确认API密钥是否被泄露后，第一步是检查Cloudflare的API审计日志。登录Dashboard，进入“审计日志”或“API令牌”页面，查看在密钥泄露前后是否有来自异常IP的请求，特别是非预期的操作，如创建新令牌、修改DNS记录或更改防火墙规则。如果日志中出现大量来自陌生地区的请求，或存在你记忆中未操作过的修改，基本可以断定密钥已被滥用。需要注意的是，审计日志默认保留时间有限，如果泄露发生较早，可能部分记录已被覆盖，此时应结合第三方监控工具判断。
在查看审计日志时，建议按时间倒序筛选操作类型。重点观察是否存在“创建 API 令牌”、“更新 DNS 记录”、“更改 SSL/TLS 设置”等敏感操作。如果发现有异常 IP 地址（比如来自你从未访问过的国家或云服务商 IP 段），最好记录下这些 IP 和请求时间，便于后续上报或取证。如果日志已被覆盖，可以检查 Cloudflare 的 API 调用指标页面，那里可能保留近期的请求量变化，但精确度低于审计日志。
应急撤销：先替换再删除，避免服务中断
一旦确认密钥泄露，应立即在Cloudflare Dashboard中撤销该API密钥。进入“我的资料”下的“API令牌”页面，找到对应的密钥，点击“删除”或“禁用”。同时，不要只删除就完事，还需要立即生成一个新的API密钥，并更新所有使用了旧密钥的集成点——例如CI/CD流水线、监控脚本、第三方服务中的环境变量。常见的一个坑是：只更新了生产环境，却遗漏了测试或本地开发配置，导致后续调用失败或安全漏洞持续存在。
但这里有一个关键矛盾：直接删除旧密钥会导致正在使用它的自动化作业立即报错。因此实际操作建议先不删除旧密钥，而是先创建新密钥。在 Cloudflare Dashboard 的 API 令牌页面，点击“创建令牌”，根据需要选择作用域（比如只给单个域名的 DNS 编辑权限）。然后将新密钥安全地配置到所有集成点：生产环境、预发环境、本地开发环境、CI/CD 密钥管理服务（如 GitHub Secrets、GitLab CI Variables、AWS Secrets Manager 等）。配置完成后，运行一轮自动化脚本来验证新密钥是否正常工作。确认无误后，再返回旧密钥页面，点击“删除”或“禁用”。
撤销前先限制，降低中断风险
撤销API密钥时需要注意服务中断风险。如果该密钥正在被生产系统或自动化脚本实时使用，突然删除会导致所有依赖它的操作立即失败，比如DNS更新、CDN缓存清除、SSL证书续期等。因此，建议先创建新的密钥并替换到所有需要的地方，确认新密钥正常工作后，再删除旧密钥。实际操作中，可以先用新密钥完成一轮替换，期间让旧密钥保持可访问但限制其权限（如临时改为只读），待切换稳妥后再彻底清理。避免在业务高峰期进行此操作。
限制旧密钥权限的具体方法：在 Cloudflare Dashboard 的 API 令牌页面，点击旧令牌旁边的“编辑”，可以对权限范围进行缩减。例如，将原有的“所有区域”权限改为“读取”权限，或者只保留对特定 DNS 记录的读取权限。这样即使攻击者仍然拥有旧密钥值，能造成的影响也被局限在只读操作内。但要注意，一旦将权限改为只读，某些原本依赖该密钥的写入操作也会失败，所以必须在替换完新密钥之后再进行此操作。如果旧密钥不支持细粒度权限修改（如老式全局密钥），则只能直接删除，这种情况下需要更谨慎地规划替换窗口。
必须排查 DNS 记录是否被篡改
密钥泄露后，必须排查是否已被用于篡改DNS记录。登录Cloudflare Dashboard，逐个域名检查DNS记录，重点关注最近新增或修改的A、CNAME、MX、TXT记录，特别是那些指向可疑IP或域名的条目。攻击者可能通过添加TXT记录来验证你域名的所有权以便用于钓鱼，或者修改MX记录劫持邮件服务。如果DNS记录数量较多，可以导出所有记录并用对比工具与历史备份比对。如果没有备份，可借助Cloudflare的“DNS Analytics”查看记录变更历史，但注意该功能可能需付费。
检查时建议使用“DNS Records”页面中的“Last Modified”列，可以按修改时间排序。如果发现某个记录在泄露时间点附近被修改，且修改来源不是你的内部 IP，则需要立即恢复。恢复方法：手动将记录改回正确的值，同时留意该域名是否被添加了额外的 NS 服务器（攻击者有时会通过 API 修改 Nameserver 指向恶意 DNS 提供商）。如果怀疑域名所有权被转移，还需检查 Cloudflare 账户中的“域注册”设置。
别忘了检查密钥权限和账户安全
一个容易忽视的细节是：泄露的API密钥如果权限过大（例如使用全局API密钥而非作用域受限的Token），攻击者可能不仅限于操作某个域名，还能修改账户级别设置、创建子用户、更改计费信息等。因此，在紧急处理中，除了撤销旧密钥，还应审查该密钥的权限范围，并立即将所有旧式全局密钥替换为精细控制的API Token。同时，务必检查账户下是否有因该泄露被攻击者创建的额外API令牌或用户，如果有，要一并移除。
检查方法：进入“我的资料” -> “API令牌”，查看所有令牌列表。注意每个令牌的“最近使用”时间和 IP 来源。如果发现有未知令牌，立即删除。同时检查“用户管理”页面，看是否有未经授权的子用户被添加。攻击者可能利用泄露的全局密钥创建新的用户，赋予管理员权限。如果发现可疑用户，立即停用并更改主账户密码。另外，建议开启 Cloudflare 的两步验证（2FA），并检查账户关联的邮箱是否有异常登录或转发规则。
改完后观察这几个信号
完成密钥替换和 DNS 检查后，需要持续观察一段时间以确保没有遗留风险。重点关注以下信号：
- 审计日志中是否仍有来自旧密钥 IP 的请求（说明某个集成点未更新）
- DNS 查询响应是否返回异常 IP（可使用 dig 或 nslookup 从不同节点测试）
- Cloudflare 的“安全性”页面是否有针对你域名的异常违规报告
- 第三方监控工具是否报告 SSL 证书续期失败（新密钥未更新到自动续期脚本）
如果观察期内（建议 72 小时）未发现异常，则可以认为泄露事件已得到控制。但建议将旧密钥彻底删除后的备份保留至少一周，以便在需要时回滚。同时，将此次事件记录到内部复盘文档，完善 API 密钥的访问控制策略，例如采用最小权限原则、定期轮换密钥、监控密钥使用情况等。不能因为处理完了就放松警惕，因为攻击者可能潜伏在账户内部，尝试其他途径访问。