Cloudflare官方事件报告(全世界就是个大的草台班子)

昨晚老杨就发博文说本次事件在互联网灾难史上绝对可以单独摘出来写一篇传记,整个事件跟老杨的付费文章描述的场景都差不多.一个p0故障的事件回顾

在看官方事件报告前老杨先给各位铺垫一下这个事件的性质.

初步统计受影响企业名单

推特架构师发文展示cloudflare故障期间整个推特的流量曲线

一个小白号

在故障前1个小时发推文表示非常开心能入职cloudflare,主要是还写了自己的岗位是system engineer.故障发生几个小时这个小白号下面留言就已经达到2000多条了.

现实版找拖车结果拖车又掉沟里了

初期大家都以为是自己网站有问题,所有运维和sre齐上阵.这就发生了很多有趣的事情.reddit上就有用户爆料说推荐用Downdetector来了解一下业务宕机的原因.结果发现Downdetector也宕机了

猛然间大家才发现职cloudflare在整个互联网上的生态位

关于Cloudflare要赔多少钱?

Cloudflare目前没公布赔付计划,但是在其官网的对Business和Enterprise计划客户提供SLA（服务水平协议）信用补偿：如果可用性低于99.9%，可获部分月费退款（本次约4.5小时中断，预计10-20%信用）,推特已经开启收集故障期间付费用户的赔付申请了.

ClickHouse事件报告的小结

老杨看了官方的故障报告,这次主要是他们对ClickHouse数据库权限做了一次的常规安全加固，导致系统表查询未按数据库名过滤，返回了大量重复列，使每5分钟生成的Bot Management机器学习“特征文件”大小突然翻倍，超过核心代理（FL/FL2）预设的200个特征上限，触发软件panic崩溃，进而导致大量HTTP请求返回5xx错误。因为是逐步变更所以生产环境表现为时好时坏.导致在判断故障时误以为是DDoS攻击。毕竟DDoS之前才发生过一次.等到查明原因后开始停止错误文件生成、回滚变更至并重启服务，于14:30核心流量恢复，17:06全部服务恢复正常。

ClickHouse官方事件报告(译文)

2025年11月18日11:20 UTC（本博客中所有时间均为UTC），Cloudflare的网络开始出现严重故障，无法正常传输核心网络流量。尝试访问我们客户网站的互联网用户会看到一个错误页面，提示Cloudflare网络出现故障。

事件期间显示的HTTP错误页面

该问题并非直接或间接由任何形式的网络攻击或恶意活动引起。相反，它是由我们数据库系统权限的更改触发的，该更改导致数据库向我们的机器人管理系统使用的“特征文件”输出了多个条目。该特征文件的大小因此翻倍。随后，这个异常大的特征文件被传播到我们网络中的所有机器。

这些机器上运行的用于路由网络流量的软件会读取这个功能文件，以使我们的机器人管理系统能够及时更新，应对不断变化的威胁。该软件对功能文件的大小有限制，小于其两倍大小的限制。这导致软件运行失败。

最初，我们误以为观察到的症状是由大规模DDoS攻击引起的，但随后我们正确地找到了问题的根源，并成功阻止了异常大的功能文件的传播，将其替换为早期版本。到下午2:30，核心流量基本恢复正常。接下来的几个小时里，我们努力缓解网络各部分因流量恢复而增加的负载。截至下午5:06，Cloudflare的所有系统均已恢复正常运行。

我们对此次事件给客户和整个互联网带来的影响深表歉意。鉴于 Cloudflare 在互联网生态系统中的重要性，任何系统故障都是不可接受的。我们的网络一度无法正常路由流量，这令我们团队的每一位成员都感到非常痛心。我们知道今天我们让您失望了。

这篇文章详细记述了事件经过以及哪些系统和流程出现故障。它也是我们为确保此类故障不再发生而计划采取的措施的开始，但并非结束。

服务中断

下图显示了 Cloudflare 网络处理的 5xx 错误 HTTP 状态码的数量。通常情况下，这个数量应该非常低，而且在服务中断开始之前确实如此。

Cloudflare网络处理的HTTP 5xx请求量

11:20 之前的流量是我们网络中 5xx 错误预期基线水平。流量峰值及其后的波动表明，我们的系统由于加载了错误的特征文件而发生故障。值得注意的是，系统随后会恢复一段时间。对于内部错误而言，这种行为非常不寻常。

解释是，该文件由ClickHouse数据库集群上运行的查询每五分钟生成一次，而该集群正在逐步更新以改进权限管理。只有当查询在集群中已更新的部分运行时，才会生成错误数据。因此，每五分钟都有可能生成一组正确的或错误的配置文件，并迅速在网络中传播。

这种波动导致系统运行状况不明，因为整个系统会时而恢复，时而再次崩溃，有时是正常的配置文件，有时是错误的配置文件，这些文件被分发到我们的网络中。起初，我们怀疑这可能是攻击造成的。最终，每个 ClickHouse 节点都生成了错误的配置文件，系统也稳定在了故障状态。

从 14:30 开始，错误持续出现，直到我们找到并解决了根本问题。我们通过停止生成和传播错误特征文件，并手动将一个已知正常的特征文件插入特征文件分发队列，然后强制重启核心代理来解决了这个问题。

上图中剩余的长尾是我们的团队重新启动了进入不良状态的剩余服务，5xx 错误代码量在 17:06 恢复正常。

以下服务受到影响

除了返回 HTTP 5xx 错误外，我们还观察到在受影响期间，CDN 的响应延迟显著增加。这是由于我们的调试和可观测性系统占用了大量 CPU 资源，这些系统会自动为未捕获的错误添加额外的调试信息。

Cloudflare如何处理请求，以及今天出了什么问题。

每个发送到 Cloudflare 的请求都会沿着我们网络中预设的路径进行。这些请求可能来自加载网页的浏览器、调用 API 的移动应用，或是来自其他服务的自动化流量。这些请求首先在我们的 HTTP 和 TLS 层终止，然后流入我们的核心代理系统（我们称之为 FL，即“Frontline”），最后通过 Pingora。Pingora 会根据需要进行缓存查询或从源服务器获取数据。

我们之前在这里分享了有关核心代理工作原理的更多细节。

我们的反向代理架构图

当请求经过核心代理时，我们会运行网络中可用的各种安全和性能产品。代理会应用每个客户的独特配置和设置，从强制执行 WAF 规则和 DDoS 防护到将流量路由到开发者平台和 R2。它通过一组特定于域的模块来实现这一点，这些模块会将配置和策略规则应用于经过我们代理的流量。

其中一个模块——机器人管理模块——是造成今天系统故障的根源。

Cloudflare 的机器人管理功能包含多种系统，其中包括一个机器学习模型，我们使用该模型为通过我们网络的每个请求生成机器人评分。我们的客户使用机器人评分来控制哪些机器人可以访问他们的网站，哪些机器人则不能。

该模型以“特征”配置文件作为输入。在此上下文中，“特征”是指机器学习模型用于预测请求是否为自动化请求的个体属性。特征配置文件是各个特征的集合。

此功能文件每隔几分钟就会刷新一次，并发布到我们的整个网络，使我们能够应对互联网流量的变化。它使我们能够应对新型机器人和新型机器人攻击。因此，频繁且快速地部署此功能至关重要，因为恶意行为者的策略变化迅速。

由于我们底层 ClickHouse 查询行为的更改（详见下文），导致生成此文件的查询中出现大量重复的“feature”行。这改变了之前固定大小的 feature 配置文件的大小，从而导致机器人模块触发错误。

因此，负责处理客户流量的核心代理系统对所有依赖于机器人模块的流量都返回了 HTTP 5xx 错误代码。这也影响了依赖于该核心代理的 Workers KV 和 Access 服务。

与此事件无关，我们正在将客户流量迁移到新版本的代理服务（内部代号FL2）。两个版本都受到了该问题的影响，但影响程度有所不同。

使用全新 FL2 代理引擎的客户观察到了 HTTP 5xx 错误。使用旧版代理引擎 FL 的客户虽然没有遇到错误，但机器人评分生成不正确，导致所有流量的机器人评分均为零。已部署规则阻止机器人的客户会看到大量误报。未在其规则中使用机器人评分的客户则未受到任何影响。

另一个明显的症状让我们误以为这是一次攻击：Cloudflare 的状态页面宕机了。该状态页面完全托管在 Cloudflare 的基础设施之外，不依赖于 Cloudflare。虽然最终证实这只是巧合，但它让参与问题诊断的团队成员开始怀疑攻击者可能同时针对我们的系统和状态页面。当时访问状态页面的用户会看到一条错误信息：

Cloudflare 状态页面出错

在内部事件聊天室中，我们担心这可能是近期Aisuru高流量DDoS攻击的延续：

内部聊天截图

查询行为变化

我前面提到过，底层查询行为的改变导致特征文件中出现大量重复行。涉事数据库系统使用的是ClickHouse的软件。

为了更好地理解，了解 ClickHouse 分布式查询的工作原理很有帮助。一个 ClickHouse 集群由多个分片组成。为了查询所有分片的数据，我们Distributed在名为 `<database_name>` 的数据库中使用了所谓的分布式表（由表引擎驱动）default。分布式引擎会查询数据库中的底层表r0。底层表用于存储 ClickHouse 集群中每个分片上的数据。

对分布式表的查询目前通过共享系统帐户运行。为了提高分布式查询的安全性和可靠性，我们正在努力使其改用初始用户帐户运行。

在此之前，ClickHouse 用户在查询 ClickHouse 系统表（例如 ` <table_name>` 或 `<table_name>` default）中的表元数据时，只能看到数据库中的表。system.tablessystem.columns

由于用户已经拥有对底层表的隐式访问权限r0，我们在 11:05 进行了更改，使这种访问权限显式化，以便用户也能查看这些表的元数据。通过确保所有分布式子查询都能在初始用户下运行，可以更精细地评估查询限制和访问权限，从而避免一个用户的恶意子查询影响其他用户。

上述更改使得所有用户都能访问到他们有权访问的表的准确元数据。遗憾的是，过去存在一些假设，即此类查询返回的列列表仅包含“ default”数据库：

SELECT  name,  typeFROM system.columnsWHERE  table='http_requests_features'orderby name;

请注意，该查询并未按数据库名称进行筛选。由于我们逐步向特定 ClickHouse 集群的用户授予显式权限，因此在 11:05 的更改之后，上述查询开始返回“重复”列，因为这些列对应于存储在 r0 数据库中的底层表。

不幸的是，这正是 Bot Management 功能文件生成逻辑执行的查询类型，用于构建本节开头提到的文件的每个输入“功能”。

上述查询将返回一个类似于所示列的表格（简化示例）：

代码块示例

然而，作为授予用户的额外权限的一部分，响应现在包含了r0模式的所有元数据，有效地使响应中的行数增加了一倍以上，最终影响了最终文件输出中的行数（即特征数）。

内存预分配

为了避免内存无限制消耗并进行内存预分配以优化性能，我们代理服务上运行的每个模块都设置了多项限制。具体来说，机器人管理系统限制了运行时可使用的机器学习特征数量。目前该限制设置为 200，远高于我们当前使用的约 60 个特征。同样，设置此限制的原因是出于性能考虑，我们需要为这些特征预分配内存。

当包含超过 200 个特征的错误文件被传输到我们的服务器时，达到了此限制，导致系统崩溃。下面显示的是执行此检查并导致未处理错误的 FL2 Rust 代码：

导致错误的代码

这导致了以下系统崩溃，进而引发了 5xx 错误：

thread fl2_worker_thread panicked: called Result::unwrap() on an Err value

事件中的其他影响

此次事件中，其他依赖我们核心代理的系统也受到了影响，包括 Workers KV 和 Cloudflare Access。团队于 13:04 对 Workers KV 进行了补丁更新，绕过了核心代理，从而降低了这些系统受到的影响。随后，所有依赖 Workers KV 的下游系统（例如 Access 本身）的错误率均有所降低。

由于内部使用了 Workers KV，并且 Cloudflare Turnstile 已部署到我们的登录流程中，Cloudflare 控制面板也受到了影响。

Turnstile系统受到此次故障的影响，导致没有活跃控制面板会话的客户无法登录。如下图所示，在两个时间段内，系统可用性有所降低：11:30至13:10，以及14:40至15:30。

事件期间 Cloudflare 内部 API 的可用性

第一个中断期（11:30 至 13:10）是由于 Workers KV 受到影响，部分控制平面和仪表盘功能依赖于 Workers KV。13:10 时，Workers KV 绕过了核心代理系统，服务恢复正常。第二个中断期发生在恢复功能配置数据之后。大量的登录尝试导致仪表盘不堪重负。这些尝试加上重试，导致延迟升高，降低了仪表盘的可用性。大约 15:30，通过扩展控制平面并发性，仪表盘恢复了可用性。

补救和后续步骤

现在我们的系统已恢复正常运行，我们已经开始着手研究如何加强系统，以防止未来再次发生类似故障。具体来说，我们正在：

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

今天发生的故障是 Cloudflare自 2019 年以来最严重的。我们之前也遇到过导致控制面板无法访问的故障，也曾出现过导致一些新功能暂时无法使用的情况。但在过去的六年多时间里，我们从未遇到过像今天这样导致大部分核心流量停止通过我们网络的故障。

像今天这样的故障是不可接受的。我们的系统架构设计使其具有极高的故障容错能力，以确保流量始终畅通无阻。过去每次发生故障，我们都会着手构建新的、更具容错性的系统。

我谨代表 Cloudflare 的全体员工，对今天我们给互联网带来的困扰表示歉意。

官方事件报告原文

LYSTech是一个AI驱动的企业资讯情报平台。全球新闻聚合+真实性评估+价值评分+智能摘要,让团队高效捕捉关键信号、快速沉淀优质素材。