11 月 18 日晚，Cloudflare 遭遇波及全球的大规模网络故障，导致 ChatGPT、社交媒体平台 X 等多家网站部分用户无法正常访问。

彼时，Cloudflare 在系统状态页面称正就“可能影响多个客户”的问题展开调查。该页面还显示，其客户支持门户此前已出现故障，且当日早些时候已安排在部分地区进行计划内维护。

Cloudflare 团队今天早上在其博客发布了故障复盘文章，以下内容来自冯若航对该文章的翻译：《Cloudflare 11-18 断网故障复盘报告》。

2025 年 11 月 18 日 11:20 UTC（本文所有时间均为 UTC），Cloudflare 的网络开始出现核心网络流量传输的严重故障。 对于尝试访问我们客户网站的 Internet 用户而言，这种故障表现为一个错误页面，提示 Cloudflare 网络内部发生了故障。

此次问题并非由任何形式的网络攻击或恶意活动直接或间接导致。相反，起因是我们一个数据库系统的权限更改， 导致该数据库将多个条目输出到了我们的 Bot 管理系统所使用的一个“特征文件”中。 该特征文件的大小因此翻了一倍。这个超出预期大小的特征文件随后被分发到构成我们网络的所有服务器上。

运行在这些服务器上的软件（用于在我们的网络中路由流量）会读取这个特征文件，以使我们的 Bot 管理系统能够应对不断变化的威胁。 该软件对特征文件的大小设有一个上限，而这个上限低于特征文件翻倍后的大小，导致软件发生了故障。

最初，我们误以为所观察到的症状是一场超大规模 DDoS 攻击所致。 后来，我们正确地识别出了问题的核心原因，并阻止了那个超出预期大小的特征文件继续传播， 将其替换为之前的一个版本。 到 14:30 时，我们的大部分核心流量已经基本恢复正常。此后几小时里，随着流量回升，我们团队持续努力减轻网络各部分面临的过载问题。 截至 17:06，Cloudflare 的所有系统均已恢复正常。

我们对本次事件给客户和整个 Internet 带来的影响深表歉意。 鉴于 Cloudflare 在互联网生态系统中的重要性，我们的任何系统发生中断都是不可接受的。 而我们的网络有一段时间无法路由流量，这让我们团队的每一名成员都深感痛心。我们知道，今天我们让大家失望了。

本文将深入详述事件的经过，以及哪些系统和流程出现了故障。 这也是我们开始着手采取行动以确保类似中断不再发生的起点（但绝非结束）。

故障概况

下图显示了 Cloudflare 网络返回的 HTTP 5xx 错误状态码数量。正常情况下，这个值应当非常低，事实在故障开始前也是如此。

在 11:20 之前，5xx 错误数量保持在我们预期的基线水平。之后的激增及随后的波动表明，由于加载了错误的特征文件，我们的系统发生了故障。 有一点值得注意：我们的系统随后一度自行恢复正常过一段时间——对于内部错误而言，这种现象非常不寻常。

原因在于，这个文件每隔五分钟由一个在 ClickHouse 数据库集群上运行的查询生成，而该集群当时正在逐步更新以改进权限管理。 只有当查询在已更新的集群节点上运行时，才会生成错误数据。因此，每隔五分钟，就有可能生成一套正确的或错误的配置文件，并迅速传播到整个网络。

这种波动使我们难以及时判断发生了什么，因为整个系统会先恢复正常，然后在下一次分发配置文件时（有时文件正确、有时文件错误）再次发生故障。 起初，这让我们认为故障可能是由攻击造成的。最终，当每个 ClickHouse 节点都开始生成错误的配置文件后，系统波动停止并稳定地处于故障状态。

错误一直持续到 14:30，我们才找到根本原因并着手解决问题。 我们通过停止生成和传播错误的特征文件，并手动将一份已知良好的文件插入特征文件分发队列来解决问题，随后强制重启了我们的核心代理。 上图中后面拖长的尾部曲线，代表我们的团队在逐步重启那些进入异常状态的服务；到 17:06 时，5xx 错误数量已恢复正常。

以下服务受到了影响：

•核心CDN与安全服务：返回 HTTP 5xx 状态码。（本文开头的截图展示了终端用户看到的典型错误页面。）

•Turnstile：无法加载。

•Workers KV：出现了显著升高的 HTTP 5xx 错误率，因为对 Workers KV “前端”网关的请求由于核心代理故障而失败。

•Dashboard：仪表盘基本保持可用，但由于登录页面上的 Turnstile 无法使用，大多数用户无法登录。

•Email安全：虽然邮件处理和传递未受影响，但我们观察到一度无法访问某个 IP 信誉数据源，导致垃圾邮件检测准确性降低，并使一些基于域名注册时长的检测未能触发（未发现严重的客户影响）。我们还观察到部分自动移动操作（Auto Move）失败；所有受影响的邮件均已过审查并得到处理。

•Access：从故障开始到 13:05 回滚期间，大多数用户的身份验证尝试都失败了（已有的 Access 会话不受影响）。

所有这些失败的身份验证尝试都会出现错误页面，这意味着故障期间这些用户无法访问其目标应用。而在此期间成功的登录尝试都已被正确记录。尝试在故障期间进行的任何 Access 配置更新要么完全失败，要么传播非常缓慢；目前所有配置更新均已恢复正常。

除了返回 HTTP 5xx 错误，我们还观察到在故障影响期间 CDN 响应的延迟显著增加。 这是因为我们的调试和可观测性系统消耗了大量 CPU 资源——它们会在未捕获的错误中自动附加额外的调试信息。

Cloudflare 请求处理流程及本次故障原因

每个发往 Cloudflare 的请求都会沿着我们网络中一条明确的路径进行处理。 请求可能来自加载网页的浏览器、调用 API 的移动应用，或者来自其他服务的自动化流量。 这些请求首先终止于我们的 HTTP 和 TLS 层，然后流入我们的核心代理系统（我们称之为 FL，即 “Frontline”）， 最后经由 Pingora 执行缓存查找，或在需要时从源站获取数据。

我们曾在这里更详细地介绍过 核心代理的工作原理。

当请求通过核心代理时，我们会运行网络中提供的各种安全和性能产品。 核心代理根据每个客户的特定配置和设置处理流量，从执行 WAF 规则、防御 DDoS 攻击，到将流量路由到开发者平台和 R2 等。 这一过程通过一系列特定领域的模块实现，这些模块对经过代理的流量应用相应的配置和策略规则。

这些模块中的一个 —— Bot 管理模块，正是此次故障的源头。

Cloudflare 的 Bot管理系统 包含多个子系统， 其中包括一个机器学习模型，我们用它为经过我们网络的每个请求生成“机器人分数”。 客户可以使用这个分数来控制哪些机器人被允许访问他们的网站，哪些则不被允许。

该模型使用一个“特征”配置文件作为输入。在这里，“特征”是指机器学习模型用来判断请求是否由自动程序发出的单个属性。特征配置文件是由各个独立的特征组合而成的集合。

这个特征文件每隔几分钟就会刷新并发布到我们整个网络上，使我们能够对 Internet 上不断变化的流量模式作出响应。 它让我们能够应对新型的机器人以及新的机器人攻击。因此，需要频繁且快速地发布该文件，因为恶意行为者往往很快改变策略。

在生成该文件的底层 ClickHouse 查询行为发生变化（详见下文）后，文件中出现了大量重复的“特征”行。 这使得原本固定大小的特征配置文件变得比预期更大，导致 Bot 模块触发了错误。

结果是，核心代理在处理任何依赖 Bot 模块的流量时都会返回 HTTP 5xx 错误。 这也影响到了依赖核心代理的 Workers KV 和 Access。

需要指出的是，我们当时正在将客户流量迁移到新版代理服务（内部称为 FL2）。 旧版和新版代理引擎都受到了这一问题的影响，尽管表现出的影响有所不同。

使用新 FL2 代理引擎的客户遇到了 HTTP 5xx 错误。而使用旧版代理（FL）的客户虽然没有看到错误，但机器人分数未能正确生成，所有流量的机器人分数都变成了零。 那些基于机器人分数设置了封禁规则的客户会遇到大量误判；未在规则中使用机器人分数的客户则没有受到影响。

还有一个现象最初使我们误以为遇到了攻击：Cloudflare 的状态页也发生了故障。 状态页完全托管在 Cloudflare 基础设施之外，与 Cloudflare 系统没有任何依赖关系。 虽然事后证明这只是一个巧合，但它使得部分诊断团队成员一度认为攻击者可能同时针对了我们的系统和状态页。 在那段时间访问状态页的用户会看到如下的错误信息：

在内部事故聊天频道中，我们担心这可能是最近一系列高流量 Aisuru DDoS 攻击 的延续：

查询行为的变化

正如前文提到的，底层查询行为的更改导致特征文件中包含了大量重复行。此处涉及的数据库系统使用的是 ClickHouse 软件。

这里有必要说明一下 ClickHouse 分布式查询是如何工作的：一个 ClickHouse 集群由许多分片组成。 为了从所有分片查询数据，我们在名为 default 的数据库中使用所谓的分布式表（由 Distributed 表引擎提供支持）。 Distributed 引擎会查询名为 r0 的数据库中的底层表；这些底层表是每个分片上实际存储数据的地方。

对分布式表的查询是通过一个共享的系统账户执行的。作为提高分布式查询安全性和可靠性工作的其中一环，我们正在努力使这些查询改为在初始用户账户下运行。

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

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

上述改动使得所有用户都可以获取到其有权限访问的表的准确元数据。 不幸的是，此前有些代码假定这类查询返回的列列表只会包含 “default” 数据库下的内容。例如下面的查询并没有按数据库名过滤：

SELECT name, type FROM system.columns WHERE table = 'http_requests_features' ORDER BY name;

注意，上述查询并未按数据库名称进行过滤。随着我们逐步在该 ClickHouse 集群上推出显式授权， 上述查询在 11:05 的改动后开始返回列的“重复”，因为结果中包含了存储在 r0 数据库中底层表的列。

不巧的是，Bot 管理特征文件的生成逻辑执行的正是上述类型的查询来构建文件中的每一个“特征”。

上述查询会返回一个类似下表所示的列清单（示例经过简化）：

然而，由于给用户授予了额外的权限，查询结果现在包含了 r0 模式下的所有相关元数据，有效地使响应行数增加了一倍多，最终导致输出文件中的特征数量大大超出正常范围。

内存预分配

我们的核心代理服务中的每个模块都设置了一些上限，以防止内存无限增长，并通过预分配内存来优化性能。在本例中，Bot 管理系统限定了运行时可使用的机器学习特征数量。 目前该上限设置为 200，远高于我们当前大约 60 个特征的使用量。再次强调，这个限制存在是出于性能考虑，我们会预先为这些特征分配内存空间。

当包含超过 200 个特征的错误文件被传播到我们的服务器时，这一限制被触发——系统因此发生了 panic。下面的 FL2（Rust）代码片段显示了执行该检查并导致未处理错误的部分：

由此产生了如下所示的 panic 日志，进而导致了 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 仪表盘（Dashboard）也受到了影响，因为仪表盘内部使用了 Workers KV，且我们的登录流程中部署了 Cloudflare Turnstile。

这次中断也影响了 Turnstile：对于没有活跃仪表盘会话的用户，他们在事故期间无法登录。 仪表盘的可用性在两个时间段内下降：11:30 至 13:10，以及 14:40 至 15:30（如下图所示）。

第一个时间段（11:30 至 13:10）的可用性下降是由于 Workers KV 受到了影响——一些控制平面和仪表盘功能依赖于 Workers KV。 在 13:10，当 Workers KV 绕过核心代理系统后，这些功能恢复了正常。 第二个时间段的仪表盘可用性问题发生在恢复特征配置数据之后。 大量积压的登录尝试开始让仪表盘不堪重负。这些积压的请求结合用户重试操作，导致了高延迟，仪表盘可用性下降。 通过提升控制平面的并发处理能力，我们在大约 15:30 恢复了仪表盘的可用性。

补救措施和后续步骤

现在，我们的系统已经恢复正常运行，我们已经开始着手研究如何在未来加强系统抵御类似故障的能力。具体来说，我们将：

•像对待用户生成的输入那样，强化对 Cloudflare 内部生成的配置文件的摄取和校验；

•为功能启用更多全局性的紧急开关；

•消除核心转储或其他错误报告占用过多系统资源的可能性；

•审查所有核心代理模块在错误情况下的失效模式。

今天的事故是 Cloudflare 自 2019 年以来最严重的一次中断。我们过去也出现过让仪表盘无法使用的停机，还有一些导致较新功能暂时不可用的故障。但在过去超过 6 年的时间里，我们没有再出现过让大部分核心流量停止的中断。

像今天这样的中断是不可接受的。我们在架构设计上让系统具备高度的容错能力，以确保流量始终可以继续传输。 每次过去发生故障后，我们都会据此构建新的、更可靠的系统。

我谨代表 Cloudflare 全体团队，对我们今天给互联网带来的影响表示诚挚的歉意。

原文：https://blog.cloudflare.com/18-november-2025-outage