Cloudflare对2025年11月18日故障的复盘

2025年11月18日11:20 UTC（本博客中的所有时间均为UTC），Cloudflare的网络开始经历重大故障，无法传输核心网络流量。对于试图访问我们客户站点的互联网用户来说，这表现为一个错误页面，显示Cloudflare网络内部的故障。

该问题不是由网络攻击或任何形式的恶意活动直接或间接引起的。相反，它是由我们一个数据库系统的权限更改触发的，该更改导致数据库向我们Bot Management系统使用的"特征文件"输出多个条目。该特征文件的大小随之翻倍。然后，这个大于预期的特征文件被传播到构成我们网络的所有机器上。

这些机器上运行的用于路由网络流量的软件会读取此特征文件，以使我们的Bot Management系统与不断变化的威胁保持同步。该软件对特征文件的大小有一个限制，该限制低于其翻倍后的大小。这导致软件失败。

在我们最初错误地怀疑我们看到的症状是由超大规模DDoS攻击引起之后，我们正确识别了核心问题，并能够停止传播大于预期的特征文件，并用该文件的早期版本替换它。到14:30，核心流量基本恢复正常。在接下来的几个小时里，我们努力缓解网络各个部分的负载增加，因为流量迅速恢复在线。截至17:06，Cloudflare的所有系统都恢复正常运行。

我们对客户和整个互联网造成的影响深表歉意。鉴于Cloudflare在互联网生态系统中的重要性，我们任何系统的任何故障都是不可接受的。我们的网络有一段时间无法路由流量，这让我们团队的每一位成员都深感痛苦。我们知道今天我们让你们失望了。

这篇文章详细叙述了到底发生了什么，以及哪些系统和流程失败了。这也是我们计划采取措施确保此类故障不再发生的开始，但不是结束。

故障情况

下图显示了Cloudflare网络提供的5xx错误HTTP状态码的数量。通常这应该非常低，而且在故障开始之前确实如此。

11:20之前的数量是我们网络中观察到的5xx错误的预期基线。峰值和随后的波动显示我们的系统由于加载不正确的特征文件而失败。值得注意的是，我们的系统随后会恢复一段时间。这对于内部错误来说是非常不寻常的行为。

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

这种波动使得不清楚发生了什么，因为整个系统会恢复，然后随着有时好、有时坏的配置文件分发到我们的网络而再次失败。最初，这让我们认为这可能是由攻击引起的。最终，每个ClickHouse节点都在生成错误的配置文件，波动稳定在失败状态。

错误持续到14:30开始识别并解决根本问题。我们通过停止生成和传播错误的特征文件，并手动将已知良好的文件插入特征文件分发队列来解决问题。然后强制重启我们的核心代理。

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

以下服务受到影响：

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

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

每个到Cloudflare的请求都会在我们的网络中经过一条明确定义的路径。它可能来自加载网页的浏览器、调用API的移动应用程序，或来自另一个服务的自动化流量。这些请求首先在我们的HTTP和TLS层终止，然后流入我们的核心代理系统（我们称之为FL，即"Frontline"），最后通过Pingora，它执行缓存查找或在需要时从源站获取数据。

我们之前在这里分享了有关核心代理如何工作的更多详细信息。

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

其中一个模块，Bot Management，是今天故障的根源。

Cloudflare的Bot Management包括一个机器学习模型，我们用它为通过我们网络的每个请求生成机器人评分。我们的客户使用机器人评分来控制允许哪些机器人访问他们的站点——或不允许。

该模型将"特征"配置文件作为输入。在这种情况下，特征是机器学习模型用来预测请求是否自动化的单个特性。特征配置文件是各个特征的集合。

此特征文件每隔几分钟刷新一次，并发布到我们的整个网络，使我们能够对互联网上流量流的变化做出反应。它使我们能够对新型机器人和新的机器人攻击做出反应。因此，随着恶意行为者快速改变策略，频繁快速地推出它至关重要。

我们底层ClickHouse查询行为的变化（如下所述）导致生成此文件时出现大量重复的"特征"行。这改变了先前固定大小特征配置文件的大小，导致机器人模块触发错误。

结果，处理客户流量的核心代理系统返回了HTTP 5xx错误代码，对于任何依赖机器人模块的流量都是如此。这也影响了依赖核心代理的Workers KV和Access。

与此事件无关，我们过去和现在正在将客户流量迁移到我们代理服务的新版本，内部称为FL2。两个版本都受到该问题的影响，尽管观察到的影响不同。

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

让我们偏离方向并让我们相信这可能是一次攻击的另一个明显症状是：Cloudflare的状态页面宕机了。状态页面完全托管在Cloudflare基础设施之外，不依赖Cloudflare。虽然这只是一个巧合，但它导致诊断问题的一些团队成员认为攻击者可能同时针对我们的系统和我们的状态页面。当时访问状态页面的访问者看到了一条错误消息：

在内部事件聊天室中，我们担心这可能是最近一系列大容量Aisuru DDoS攻击的延续：

查询行为变化

我上面提到，底层查询行为的变化导致特征文件包含大量重复行。所讨论的数据库系统使用ClickHouse的软件。

为了提供背景，了解ClickHouse分布式查询的工作原理很有帮助。ClickHouse集群由许多分片组成。要从所有分片查询数据，我们在名为default的数据库中有所谓的分布式表（由表引擎Distributed提供支持）。Distributed引擎查询名为r0的数据库中的底层表。底层表是数据存储在ClickHouse集群的每个分片上的地方。

对分布式表的查询通过共享系统账户运行。作为改进分布式查询安全性和可靠性工作的一部分，正在进行的工作是让它们在初始用户账户下运行。

在今天之前，当从ClickHouse系统表（如system.tables或system.columns）查询表元数据时，ClickHouse用户只能看到default数据库中的表。

由于用户已经对r0中的底层表具有隐式访问权限，我们在11:05进行了更改，使此访问权限显式化，以便用户也可以看到这些表的元数据。通过确保所有分布式子查询都可以在初始用户下运行，可以以更细粒度的方式评估查询限制和访问授权，避免一个用户的错误子查询影响其他用户。

上述更改导致所有用户访问他们有权访问的表的准确元数据。不幸的是，过去有一些假设，即这样的查询返回的列列表只包括"default"数据库：

SELECT

  name,

  type

FROM system.columns

WHERE

  table = 'http_requests_features'

order by name;

请注意查询如何不过滤数据库名称。随着我们逐步向给定ClickHouse集群的用户推出显式授权，在11:05的更改之后，上述查询开始返回列的"重复项"，因为这些列是存储在r0数据库中的底层表的列。

不幸的是，这正是本节开头提到的Bot Management特征文件生成逻辑执行的查询类型，用于为文件构造每个输入"特征"。

上述查询将返回如下所示的列表（简化示例）：

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

内存预分配

在我们的代理服务上运行的每个模块都有许多限制，以避免无限制的内存消耗，并预分配内存作为性能优化。在这个特定实例中，Bot Management系统对运行时可以使用的机器学习特征数量有一个限制。目前该限制设置为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本身）观察到错误率降低。

Cloudflare仪表板也受到影响，因为内部使用了Workers KV，并且Cloudflare Turnstile作为我们登录流程的一部分部署。

Turnstile受到此次故障的影响，导致没有活动仪表板会话的客户无法登录。这表现为两个时间段内可用性降低：从11:30到13:10，以及14:40到15:30之间，如下图所示。

第一个时期，从11:30到13:10，是由于对Workers KV的影响，一些控制平面和仪表板功能依赖于它。这在13:10恢复，当时Workers KV绕过了核心代理系统。仪表板的第二个影响时期发生在恢复特征配置数据之后。积压的登录尝试开始压垮仪表板。这个积压，加上重试尝试，导致延迟升高，降低了仪表板可用性。扩展控制平面并发性在大约15:30恢复了可用性。

修复和后续步骤

现在我们的系统已经恢复在线并正常运行，关于我们将如何加固它们以防止将来发生此类故障的工作已经开始。特别是我们正在：

• 以与处理用户生成输入相同的方式加固Cloudflare生成的配置文件的摄取
• 为功能启用更多全局终止开关
• 消除核心转储或其他错误报告压垮系统资源的能力
• 审查所有核心代理模块的错误条件的故障模式

今天是Cloudflare自2019年以来最严重的故障。我们曾经历过使仪表板不可用的故障。一些导致较新功能在一段时间内不可用的故障。但在过去6年多的时间里，我们没有遇到过另一次导致大部分核心流量停止流经我们网络的故障。

像今天这样的故障是不可接受的。我们设计了高度弹性的系统以确保流量始终继续流动。当我们过去遇到故障时，它总是促使我们构建新的、更具弹性的系统。

在使我们的系统恢复在线并正常运行后，关于我们将如何加固它们以防止将来发生此类故障的工作已经开始。我代表Cloudflare的整个团队，对我们今天给互联网造成的痛苦表示歉意。

时间线

原文：https://blog.cloudflare.com/18-november-2025-outage/?utm_campaign=cf_blog&utm_content=20251118&utm_medium=organic_social&utm_source=facebook,linkedin,threads,twitter%2F%2F