Cloudflare全球互联网瘫痪：安全升级的好心办坏事

事件背景

2025年11月18日，全球最大的互联网基础设施服务商之一 Cloudflare 遭遇一次严重的中断事件。从各类商务网站，到社交媒体，再到在线支付，全球超半数的依赖 Cloudflare 提供的服务的网站和应用都受到了影响。用户在访问这些网站时普遍会收到 HTTP 5xx 错误，如 502 Bad Gateway。

在随后的 Cloudflare 官方调查中证明了这不是一次外部网络攻击（DDoS），而是由于内部软件的配置错误引发的连锁崩溃。

瘫痪的起因

此次事故的源头源自于旨在提高系统安全性的一次例行维护操作。

• 数据库的权限变更（导火索）：
  Cloudflare 工程师对内部使用的 ClickHouse 数据库集群进行了权限配置更新，并且允许“最小权限原则”，工程师显示地配置了服务账户对底层数据表（r0 库）的访问权限。
  • 变更发生后，原本只向查询者暴露默认视图（default）的系统，同时暴露了默认视图和底层数据表
• 有缺陷的 SQL 查询：
  一个负责生成“机器人管理（Bot Management）”配置文件的自动化脚本，每 5 分钟运行一次。其内部包含一条查询系统列信息的 SQL 语句，但未指定数据库名称。
  • 由于数据库权限的变更，脚本运行时意外查询得到了两份元数据 default 和 r0 ，导致结果集中的数据行瞬间翻倍。

瘫痪的原因

如果只是单纯的数据重复，应该并不会造成全球互联网的瘫痪，真正的原因还是来自于全球边缘节点的核心代码问题

1. 病毒般的配置文件：
   包含重复数据的查询结果被写入配置文件后，被迅速分发到 Cloudflare 位于全球的每一个数据中心。

2. 代码的逻辑错误：
   Cloudflare 的核心流量代理组件采用 Rust 编写。该组件在加载错误包含重复数据的配置文件时，出发了一个硬编码的逻辑错误：

   • 组件的代码逻辑中设定了特征数量的预分配上限
   • 组件加载到超过分配上限的数据时，虽然得益于 Rust 的内存安全特性未完全溢出内存，但却触发了代码中的校验失败
   • 工程师在组件的错误逻辑处理中使用了unwrap()方法，在 Rust 中，这意味着如果程序运行遭遇到错误，程序并不会尝试恢复或报错，而是直接崩溃或被自己Kill

3. 无限的重启尝试：
   伴随着全球各地数据中心服务器在重新加载新配置时的瞬间集体崩溃。看门狗进程（Watchdog）尝试着重新启动各个服务。但这些服务再重启后依然会再次加载错误的重复数据配置，进而再次崩溃。至此，所有经过 Cloudflare 的流量陷入了无人处理，直接返回了 5xx 错误

事件的完整时间线

• UTC 11:05（北京时间 19:05） - 变更实施
  Cloudflare 工程师开始部署 ClickHouse 数据库的权限变更。此时并未立即引发故障，因为配置文件的生成是周期性的。

• UTC 11:28（北京时间 19:28） - 毒配置生成与扩散
  自动化脚本运行，首次生成了包含重复数据的“有毒”配置文件，并开始推送到全球边缘节点的分发队列。

• UTC 11:32（北京时间 19:32） - 全球瘫痪开始
  随着全球边缘节点加载新配置，核心代理进程开始大规模崩溃。监控仪表盘瞬间变红，全球用户访问中断。

  • 初期混淆： 由于部分节点尚未更新配置，部分节点已经崩溃，网络表现为极不稳定的“抖动”，这让 Cloudflare 团队最初误以为是遭遇了复杂的 DDoS 攻击。

• UTC 13:05（北京时间 21:05） - 错误的排查方向
  由于依赖核心代理的 Workers KV 服务报错最明显，Cloudflare 工程团队花费了大量时间排查 KV 存储系统，试图通过限流来缓解问题，但收效甚微。

• UTC 13:37（北京时间 21:37） - 定位根本原因
  Cloudflare 高级工程师通过分析崩溃日志（Core Dumps），终于发现是“机器人管理”模块在解析配置文件时发生了 Panic。随后确认了配置文件的体积和内容异常。

• UTC 14:24（北京时间 22:24） - 紧急止血与修复

  1. 切断源头： 停止了配置文件生成脚本的运行。
  2. 回滚配置： 团队手动提取了一个历史版本的“已知良好”配置文件。
  3. 强制注入： 通过带外管理通道，将好文件覆盖到全球节点的分发队列中。

• UTC 14:30（北京时间 22:30） - 服务恢复
  随着正确的配置文件被加载，Cloudflare 边缘节点的代理进程成功启动并保持运行。全球流量开始恢复正常。

事故后续

Cloudflare 团队称已经开始着手研究如何加强系统，以防止未来再次发生类似故障。他们提出了一些初步的改进措施：

• 加强对 Cloudflare 生成的配置文件的摄取，就像我们加强对用户生成输入的摄取一样。
• 为功能启用更多全局终止开关
• 消除核心转储或其他错误报告占用系统资源的可能性
• 审查所有核心代理模块的错误情况故障模式

至此，正常事故已经得到了修复，Cloudflare 团队称此次 11月18日故障是 Cloudflare 自 2019 年以来最严重的一次。