2026年2月20日，Cloudflare 的一项自动化变更引发了服务中断。一个错误的 API 调用导致其“自带IP”（BYOIP）服务中约 25% 的 IP 前缀被错误地从互联网上撤销路由。此次事故影响了部分客户的服务以及 1.1.1.1 的部分地址，持续了约 6 小时。事故的根源在于一个清理脚本的缺陷，它将所有 BYOIP 前缀错误地标记为待删除。Cloudflare 在发现问题后迅速回滚了变更，并承诺通过加强自动化测试、改进 API 规范和部署更严格的变更监控来防止此类事件再次发生。
事故是如何发生的？
此次中断的直接原因是 Cloudflare 试图自动化一个原本需要手动操作的流程：为客户移除其不再使用的 BYOIP 前缀。
工程师们创建了一个自动运行的子任务，用于定期检查并清理那些被标记为待删除的前缀。然而，这个清理任务在查询 API 时存在一个致命的错误。
系统向 API 发送了一个带有
pending_delete参数但没有具体值的请求。API 的设计缺陷导致它将这个请求解读为“返回所有 BYOIP 前缀”，而不是“返回标记为待删除的前缀”。
结果，这个自动化清理任务错误地认为所有 BYOIP 前缀都应被删除，并开始系统性地撤销它们的网络路由公告。工程师发现异常后，紧急终止了这个错误的进程。
- 影响范围: 在被终止前，该任务已成功撤销了约 1,100 个 BYOIP 前缀。
- 服务中断: 这些前缀对应的服务，如网站、应用和 API，都变得无法从互联网上访问。
为什么测试没有发现问题？
尽管 Cloudflare 拥有与生产环境数据相似的测试环境，但这次未能捕获到该缺陷。
- 测试覆盖不全: 测试的重点放在了模拟客户通过 API 自助操作的正常流程上，这个流程本身是正确的。
- 忽略了独立执行场景: 测试没有覆盖到自动化任务独立执行，且没有用户明确输入的情况。正是这种无人监督的自动化场景最终导致了问题的发生。
- 模拟数据不足: 用于模拟生产环境的模拟数据也不足以揭示这种边界情况下的缺陷。
为什么恢复不是即时的？
恢复过程之所以耗时，是因为受影响的前缀处于不同的损坏状态，需要采取不同的恢复措施。
状态一：仅路由被撤销 大多数客户属于这种情况。他们可以通过 Cloudflare 控制面板手动重新启用其 IP 前缀的路由公告，从而自行恢复服务。
状态二：路由被撤销，部分服务绑定被移除 这些客户处于部分恢复的状态，他们可以恢复一些前缀，但另一些则不行。
状态三：路由被撤销，所有服务绑定均被移除 这是最严重的情况。由于前缀与 CDN、Magic Transit 等服务的绑定关系被彻底删除，客户无法通过控制面板自行恢复。工程师必须通过全局配置更新，为这些客户在 Cloudflare 的所有边缘服务器上重新应用服务绑定，这个过程耗时最长。
未来的改进措施
此次事故虽然发生在 Cloudflare 推行旨在提升系统弹性的 “Code Orange: Fail Small” 计划期间，但也暴露了现有流程的不足。为此，Cloudflare 承诺进行以下关键改进：
API 规范标准化: 改进 API 设计，确保所有参数（如
pending_delete）都有明确的类型和值，避免模糊的解释。这使得客户端和服务器都能更好地验证 API 调用的正确性。分离配置状态与操作状态: 将客户的“期望配置”与系统的“实际运行状态”分离开。这样在发生问题时，工程师可以快速回滚到上一个已知的“良好”版本，而不是依赖复杂且耗时的数据库快照恢复。
加强对大规模变更的监控: 建立一种“熔断机制”。系统将监控变更的速度和广度，当检测到类似“短时间内撤销大量 BGP 前缀”的异常行为时，会自动暂停变更部署，防止小错误演变成大范围的故障。