11月18日Cloudflare宕机事故报告：从配置错误到全球影响的深度复盘

网络服务的稳定运行是现代数字社会的基础。当大型基础设施服务出现大规模中断时，其影响范围和严重性不容小觑。近期一次引人注目的网络事件，清晰地展示了看似微小的系统变更如何引发全球性的连锁反应。

事件概览：核心网络流量中断

在2025年11月18日，全球知名的内容分发网络（CDN）服务商Cloudflare的网络开始出现大规模故障。用户在尝试访问依赖其服务的网站时，频繁遭遇指示网络内部错误的HTTP 5xx错误页面。这次中断并非源于外部的网络攻击或恶意行为，而是由一次内部的配置变更引发。

故障期间影响的服务如下：

故障的根源：数据库权限变更与特征文件膨胀

此次故障的核心触发点在于对一个数据库系统的权限管理进行了更新。具体来说，这次变更导致用于其Bot管理系统的“特征文件”（feature file）在数据库中产生了大量冗余或重复的条目，使其体积异常膨胀。

• 权限变更：为了提升分布式查询的安全性和可靠性，对ClickHouse数据库的权限管理进行了细化调整，使得原本仅对特定数据库可见的元数据现在被暴露。
• 特征文件生成异常：Bot管理系统依赖定期从该数据库读取特征文件，以实时更新对自动化流量的判断模型。权限变更后，一个关键查询开始返回双倍的数据行（来自原始数据库和暴露的底层数据库），直接导致特征文件大小翻倍。
• 软件限制触发：运行在网络设备上的核心代理软件（Proxy）在加载这个超规格的特征文件时，触发了其预设的内存或文件大小限制。由于系统预先分配了内存用于处理特定数量的特征，超限导致系统恐慌（Panic），直接抛出无法处理的错误。

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

上述更改导致所有用户访问其有权访问的表的准确元数据。不幸的是，过去有一些假设，即像下面这样的查询返回的列列表将只包含“default”数据库：

SELECT
  name,
  type
FROM system.columns
WHERE
  table = 'http_requests_features'
order by name;

注意查询没有按数据库名称进行过滤。随着我们逐步向 ClickHouse 集群的用户推广显式授权，在 11:05 更改后，上述查询开始返回列的“重复项”，因为这些是针对存储在 r0 数据库中的底层表的。

连锁反应：核心服务大面积受影响

由于Bot管理模块位于核心流量处理路径上，其故障迅速波及了依赖它的多个关键服务，造成广泛的HTTP 5xx错误。

主要受影响产品线：

• 核心CDN和安全服务：直接导致了用户网站返回5xx错误，网络访问受阻。
• Cloudflare Access：身份验证服务大规模失败，用户无法登录目标应用。
• Workers KV：作为一项分布式键值存储服务，因依赖核心代理系统而出现大量错误。
• Turnstile（人机验证）：该组件的失败使得许多用户无法登录到Cloudflare的控制台Dashboard。

值得注意的是，此次故障期间，系统错误率出现了不稳定的波动。这是因为特征文件每五分钟自动生成一次，有时生成的是正确的版本，有时是错误的膨胀版本，导致网络中断状态时断时续，初期曾误导技术团队认为是外部攻击。

排查与恢复过程：精确锁定与快速回滚

在故障发生后的初期，团队曾怀疑是高强度的DDoS攻击所致，但随后通过深入分析，最终将焦点锁定在了Bot管理系统加载的配置错误上。

关键恢复步骤：

1. 隔离问题源头：在故障发生约两个小时后，团队确定了Bot管理配置文件的错误是根本原因。
2. 阻止错误扩散：立即停止了自动生成和传播新的Bot管理配置文件。
3. 实施回滚：最快的解决方案是手动推送一个已知的、正常的旧版本特征文件到所有网络节点，并强制重启核心代理服务。
4. 下游服务降级与恢复：在核心问题解决前，Workers KV和Access服务被快速打上补丁，绕过受影响的核心代理层，以减轻对其他依赖系统的影响。

在核心问题解决后，团队花了数小时时间重启了进入错误状态的剩余服务。直到事件发生后约六小时，所有系统的错误率才恢复正常基线。

系统韧性与未来改进

这次事件是自2019年以来Cloudflare经历的最严重的网络架构中断之一。它深刻揭示了在高度耦合的分布式系统中，一个看似独立的子系统故障可能带来的毁灭性后果。

为避免重蹈覆辙，技术团队正在重点加强以下几个方面的建设：

• 配置输入强化：像对待外部用户输入一样，对所有由内部系统生成的配置数据进行更严格的校验和净化。
• 增加“熔断开关”：在关键特性模块中增加更具全局控制力的“Kill Switch”，以便在异常发生时能迅速禁用特定功能。
• 错误处理机制优化：重新审查和加固所有核心代理模块在遇到未知错误或资源耗尽时的处理逻辑，防止单点恐慌导致全面崩溃。

此次事件虽然给用户带来了不便，但同时也推动了系统架构的进一步成熟，确保未来面对任何规模的流量和复杂性时，网络连接的可靠性都得到更坚实的保障。

事件时间线 (UTC)