Cloudflare 11 月 18 日重大故障概述

文章信息: 作者： IT Pro; 分类：Blog; 日期：2025年11月19日; 点击数：5968

2025 年 11 月 18 日，互联网的一大块阵地坍塌了。
如果你打开 ChatGPT、X（Twitter）、英雄联盟、Shopify、Coinbase 或无数小型网站，迎接你的将是 Cloudflare 品牌的 5xx 错误页面，或者这些网站根本无法加载。起初看起来像是又一个 "互联网坏了 "的大事件，但事实证明它更微妙，而且在某些方面更令人担忧：Cloudflare 自己的基础设施深处出现了一个自找的错误。

以下是Cloudflare 昨日（2025 年 11 月 18 日）故障的详细经过、发生原因、影响对象以及基础设施团队应从中吸取的教训。

昨天到底发生了什么？

2025 年 11 月 18 日星期二，大约在世界协调时晚些时候，Cloudflare 开始对通过其网络的流量返回大量HTTP 5xx 服务器错误。对于终端用户来说，这意味着在尝试访问许多流行网站和应用程序时会出现 "内部服务器错误 "或 "网关错误 "页面。

根据 Cloudflare 自己的事故后博客，这次故障是

于11:28 UTC开始影响客户 HTTP 流量
核心 CDN 和安全服务普遍出现 5xx 错误
UTC时间13:05-14:30左右采取了主要缓解措施
(协调世界时)17:06 时，5xx 错误量恢复到基线水平Cloudflare 博客

Cloudflare 将其描述为2019 年以来最严重的故障，因为它不仅影响了一项功能或仪表板，还破坏了核心代理层，而该代理层通过其网络路由大部分客户流量。Cloudflare 博客

第三方监测证实了这一点。Cisco ThousandEyes 发现 Cloudflare 出现了全球性故障，X、OpenAI (ChatGPT) 和 Anthropic 等服务都出现了超时和 5xx 错误，而网络路径本身看起来是健康的。这强烈表明是后端服务故障，而不是 ISP 级或路由问题。千眼

谁受到了影响？

由于 Cloudflare 位于大量互联网的前端（约20% 的网站依赖 Cloudflare 提供性能和安全性），因此爆炸半径非常大。美联社新闻+1

受影响的服务包括

ChatGPT / OpenAI
X（前 Twitter）
Canva、Shopify、Dropbox、Coinbase
英雄联盟》和其他游戏平台
各种公共交通和政府网站，包括新泽西州交通局和法国 SNCF 铁路数字系统美联社新闻+1

Downdetector 等故障跟踪器在高峰期记录了数千份并发问题报告。路透社报道称，仅 X 系统就一度有约 5000 名用户受到影响，之后随着修复程序的推出，受影响用户数量有所下降。路透社

从用户的角度来看，这表现为

网站根本无法加载
登录流挂起或失败（尤其是涉及 Cloudflare Access 或 Turnstile 的情况）
API 响应断断续续或出现 5xx 错误
仪表板和管理面板超时

换句话说：尽管根本原因集中在单个提供商的内部系统，但互联网的大部分地区都 "感觉瘫痪 "了。

Cloudflare 通常是如何工作的（简单来说）

要了解这次故障如此严重的原因，了解请求通过 Cloudflare 网络的大致路径很有帮助。

Cloudflare 充当反向代理 CDN 和安全层：

您的浏览器或应用程序会连接到 Cloudflare，而不是直接连接到原始站点。
Cloudflare 在其边缘终止 TLS 和 HTTP。
请求流入 Cloudflare 的核心代理系统，即FL（"前线"）及其新一代FL2。
该核心代理系统
- 应用WAF（网络应用防火墙）规则
- 运行僵尸管理模型
- 处理DDoS 保护、缓存、出口到原点
- 将流量路由到其他内部产品，如Workers、R2、Access 等。Cloudflare 博客

在正常运行情况下，这种架构具有很强的弹性：如果一个数据中心出现问题，流量将通过其他数据中心进行路由；配置更改将谨慎推出；个别功能将以包含的方式出现故障。

昨天的故障之所以糟糕，正是因为故障发生在公共代理路径本身，而且与频繁自动向全球推送的配置文件密切相关。

根本原因：僵尸管理功能文件失控

Cloudflare 的官方解释指出了一个关键的罪魁祸首：
他们的僵尸管理系统使用的一个功能配置文件。Cloudflare 博客

以下是一连串事件的简要说明：

僵尸管理系统使用 "功能文件
- Cloudflare 的僵尸检测模型依赖于一组 "特征"--每个请求的信号，用于判断是人类请求还是僵尸请求。
- 这些特征捆绑在一个配置文件中，每隔几分钟重新生成一次，并在全球范围内推广，因此 Cloudflare 可以快速适应新的攻击模式。Cloudflare 博客
ClickHouse 查询行为的变化
- 特征文件由针对 ClickHouse 数据库的查询生成。
- Cloudflare 在世界协调时 11:05左右进行了更改，以提高分布式查询的安全性和权限--允许用户不仅查看默认模式的元数据，还查看底层r0表的元数据。Cloudflare 博客
- 构建特征列表的查询没有按数据库名称进行过滤；突然，它开始从默认和r0表中获取重复列，这实际上使特征行的数量增加了一倍。
特征文件大小爆炸
- 机器人管理模块对接受的特征数量有硬性限制（设置为 200，远高于通常使用的 ~60）。
- 当新生成的文件超过该限制时，由于在错误值上使用了Result::unwrap()的 Rust 代码中出现了一个未处理的错误，模块触及了上限并陷入了恐慌。Cloudflare 博客
核心代理服务开始返回 5xx 错误
- 由于机器人管理已集成到核心代理路径中，因此对于依赖该模块的任何流量，恐慌都会以HTTP 5xx 响应的形式出现。
- 在新的FL2引擎上，客户看到了明确的 5xx 错误。
- 而在旧版FL引擎上，僵尸得分会自动归零，这可能会导致僵尸拦截规则出现误报。Cloudflare 博客
真正令人讨厌的部分：文件不断在 "好 "与 "坏 "之间切换
- ClickHouse 集群正在逐步更新，特征文件每五分钟重新生成一次。
- 有时查询在更新的节点上运行（产生一个坏文件），有时在未更新的节点上运行（产生一个好文件）。
- 这意味着，随着不同版本文件的传播，Cloudflare 的网络在正常运行和故障之间摇摆了一段时间。Cloudflare 博客

这种摆动使内部情况非常混乱。起初，Cloudflare 的团队怀疑发生了大规模的 DDoS 攻击，因为错误模式不像是简单的软件崩溃。甚至 Cloudflare的状态页面（托管在他们自己的基础设施之外）也出现了短暂的错误--这种巧合进一步加剧了外部攻击的嫌疑。Cloudflare 博客+1

只有当他们意识到共同因素是僵尸功能文件时，情况才变得明朗起来。

事件时间表

根据 Cloudflare 的事后分析和第三方报告，我们可以拼凑出 2025 年 11 月 18 日的大致时间表：Cloudflare 博客+2ThousandEyes+2

11:05 UTC- ClickHouse 部署了数据库访问控制变更。
11:20-11:30 UTC- 开始生成和传播僵尸管理功能文件的错误版本。
11:28 UTC- 首次客户影响：客户流量中出现 HTTP 5xx 错误。
11:30-11:32 UTC- 外部监控工具和自动测试开始检测间歇性故障。
11:35 UTC- Cloudflare 打开内部事件呼叫；开始调查。
~11:48 UTC- Cloudflare 发布状态更新，确认发生事故。重新发送
11:30-13:05 UTC- 团队重点关注看似降级的工人 KV 行为，并调查多种可能的原因（包括攻击场景）。
13:05 UTC- 关键缓解措施：Workers KV 和 Cloudflare Access 转移到绕过核心代理；影响降低。Cloudflare 博客
14:30 UTC- 已查明根本原因；停止生成和传播不良特征文件。手动插入已知的良好配置文件，并重新启动核心代理。大部分核心流量恢复正常。Cloudflare 博客
14:40-15:30 UTC- 由于 Turnstile 和积压的验证尝试造成二次负载高峰，仪表板和登录问题挥之不去。Cloudflare 博客
17:06 UTC- 错误率恢复到基准；Cloudflare 宣布系统完全正常。Cloudflare 博客

从用户的角度来看，UTC 时间上午晚些时候到下午早些时候的故障最严重，但具体的影响窗口因地区和每项服务所依赖的 Cloudflare 产品而异。

为什么这次故障如此重要

集中化风险

Cloudflare 与主要云平台（AWS、Azure、GCP）和其他大型 CDN 一样，都是小型中央互联网基础设施提供商。当其中一家出现故障时，影响范围很广，而且往往不明显。

这次故障

不是因为 BGP 路由故障或 ISP 电缆被切断。
并非来自恶意攻击（尽管最初有所怀疑）。
而是来自一个内部组件的单一配置和限制错误。

这一点很重要，因为它显示了即使没有外部干扰，复杂、紧密耦合的系统也可能发生灾难性故障。当许多组织建立在同一个提供商的基础上时，该提供商就会成为互联网中事实上的重要系统。

"软 "依赖也会受到影响

一些受影响的服务并不只是将 Cloudflare 作为哑 CDN 使用。它们是

使用Cloudflare Access进行身份验证和零信任访问。
使用Workers KV作为内部控制平面的一部分。
依靠Turnstile进行防僵尸登录。Cloudflare 博客+1

当这些产品出现故障时，宕机的不仅仅是网站内容，登录、管理功能和内部 API也会损坏。这使得恢复变得更加复杂：您的状态页面、事件工具或管理用户界面可能也依赖于刚刚发生故障的提供商。

Cloudflare 表示将做出哪些改变

Cloudflare 在博客中概述了公司已经采取的几项补救措施，以降低类似事件再次发生的风险：Cloudflare 博客

加强对自动生成的配置文件的摄取
对内部生成的配置文件采取与用户提供的输入相同的怀疑和验证态度，包括在推出前进行严格的模式和大小检查。
更多全局关闭开关
在全网范围内更轻松地快速禁用有问题的内部模块（如僵尸管理），使其无法打开，而不是惊动整个代理路径。
保护系统资源免受错误风暴影响
确保当错误开始激增时，核心转储、调试元数据和可观察性工具不会占用 CPU 和内存。
审查核心代理模块的故障模式
系统地审核每个内部模块在意外输入或配置下的行为，确保优雅降级而不是全局故障。
完善推出和隔离
虽然没有详细说明，但这一事件表明 Cloudflare 可能会进一步细分新配置和 DB 行为的传播方式，以降低单个错误变更影响整个团队的几率。

他们还将此次事件视为其弹性预期的绝对失败，称其为 "不可接受的"，并明确承认给客户和普通互联网用户带来的痛苦。Cloudflare 博客

给基础设施和 SRE 团队的启示

即使您运行的不是 Cloudflare 这样的庞然大物，这次故障也为您提供了一些非常实用的设计和操作经验：

将内部配置视为不可信任的输入

我们很容易认为 "我们自己 "生成的配置总是正确的。昨天的事故说明了为什么这样做很危险：

在应用配置文件之前，一定要验证其大小、形状和限制。
考虑首先对一小部分流量或节点应用配置，并在出现异常时自动回滚。
在功能数量、内存预分配和 CPU 使用量方面保持严格的上限和断路器。

设计优美的部分故障

机器人管理模块中的一个错误不应导致整个代理路径瘫痪：

在某些安全层中，如果选择完全中断，则默认为故障打开与故障关闭。
为非核心功能建立明确的、经过测试的关闭开关。
确保关键子系统（认证、状态页面、事件工具）能够在降级模式下或通过备用路径运行。

观察正确的信号

每五分钟在 "好配置 "和 "坏配置 "之间摇摆的信号看起来像是攻击流量或嘈杂的外部行为：

确保在可观察性管道中具有每个版本或每个配置的相关性。
构建仪表盘，在错误图上直观地显示配置更改。
从外部视角进行强大的合成测试，以便快速区分内部故障和网络/路径问题。

不要把鸡蛋放在一个基础设施篮子里

对于使用 Cloudflare 的企业：

考虑为真正的关键任务属性设置多 CDN。
避免使您的状态页面完全依赖于与您的主堆栈相同的提供商（Cloudflare 就是这样做的，但昨天他们的状态页面主机出现了巧合的故障，使事情变得更加混乱）。Cloudflare 博客+1
在将身份验证、API 控制平面和前端交付紧密耦合到同一供应商且没有后备路径之前，请三思而后行。