作者 | 华卫

半个互联网又又又断了。

刚刚，Cloudflare 公司遭遇了持续数小时的宕机事故，导致多款热门网站和 AI 服务下线。据报道，此次服务中断持续约五个半小时，OpenAI 的 ChatGPT 和 Sora 均在受影响应用之列，Claude、Shopify 以及美国新泽西州公共交通系统的官网也出现了故障。

神秘流量激增，导致大范围宕机

据外媒报道，美国东部时间 11 月 18 日凌晨 5 点 20 分左右，Cloudflare 首次发现平台出现异常流量。约一个半小时后，该公司在状态页面更新公告，告知客户此次宕机事件，服务中断表现为出现错误提示及延迟升高。“Cloudflare 内部服务出现故障。部分服务可能会间歇性受到影响，”Cloudflare 在美国东部时间早上 7 点前不久发布的公告中表示。

而受此次宕机影响的并非仅有面向网站的 CDN 服务。故障还波及了其应用服务产品套件，该套件为云端及本地工作负载提供 CDN 功能，同时保护这些工作负载的应用程序接口免受恶意流量攻击。

Cloudflare 在今年 7 月的一篇博客指出，全球约 20% 的网站依赖其管理和保护流量。据 DownDetector 称，此次宕机事件影响了包括 X、Spotify、OpenAI 的 ChatGPT、特朗普的社交媒体网站 Truth Social、在线设计平台 Canva 以及电影评分应用 Letterboxd 等，甚至 DownDetector 自己的网站也曾短暂受到影响。

此次宕机还影响了至少另外两项服务。在故障排查过程中，Cloudflare 工程师关闭了伦敦地区的 WARP 虚拟专用网络（VPN）服务。此外，部分用户无法正常使用该公司的 Cloudflare Access 零信任网络访问（ZTNA）工具。ZTNA 产品的用途与 VPN 类似，但能提供更优的安全性和性能。

美国东部时间 11 月 18 日上午 8:09，该公司表示，问题“已查明，正在实施修复”，但恢复过程并不算顺利。美国东部时间 11 月 18 日上午 8 点 13 分左右，Cloudflare 重新启用了伦敦地区的 WARP 服务。据 Cloudflare 称，控制面板服务已于美国东部时间上午 9:34 恢复。上午 9 点 42 分，该公司在状态页面宣布，工程师已修复宕机的根本原因。接下来的几个小时里，Cloudflare 持续监控恢复进程，并“寻找加速全面恢复的方法”。最终，此次服务中断于上午 11 点 44 分结束。

Cloudflare 的一位发言人向外媒证实，在发布第一份状态更新之前，他们发现“旗下一项服务出现异常流量激增”，这 “导致部分流经 Cloudflare 网络的流量出现错误”。“我们全员出动，确保所有流量无误。之后，我们将集中精力调查流量异常激增的原因。”Cloudflare 在声明中说道。

而从故障根因来看，有专家认为这次宕机并非单点失误，而是一连串低概率事件的叠加。Cloudflare 在故障复盘中提到，问题最初源于一次数据库用户权限的变更，意外导致一条 SQL 返回了重复数据；再叠加上不够严谨的 Rust 代码实现、以及多年遭受 DDOS 攻击带来的“PTSD 式误诊”，几件本不至于造成灾难的小事，最终触发了今年全球范围内持续时间最长、影响最广的一次网络故障。

值得一提的是，在 X 平台上，有网友评价，“Cloudflare 的 Rust 重写版本并未经得起时间的考验。”9 月 26 日，Cloudflare 采用 “内存安全” 的 Rust 语言重写核心代码。该公司称，得益于 Rust 语言的特性，此次重构 “速度更快、安全性更高”。

Cloudflare 故障报告中，专门指出了导致这次宕机的那行 Rust 代码。

“一行 Rust 代码崩溃，导致全球一半的流量瘫痪。”不少人认为，写过 Rust 的都知道随意使用 unwrap 都不是一个好习惯。也有人指出，“只有当配置文件有问题时，unwrap 才会失败。”

还有一位声称“朋友在 Cloudflare 工作”的人士表示，“宕机是因为有个工程师试图修改一份旧配置文件，删掉了一堆看起来已经过时的代码行。结果发现，正是这些代码行在维持着他们路由系统的稳定。配置文件一经部署，一半的监控系统直接变红报警，整个网络开始出现一些甚至他们内部文档都无法完全解释的异常现象。修复过程得找回一份尘封已久的备份，回滚一连串自动重载操作，还要想办法让一个彻底乱了套的服务器集群恢复正常运行。”

并且，其透露，“当时（Cloudflare）办公室里满是红牛罐子，大家都在暗自慌神，还有个资深开发者一直在重复念叨‘啥也别碰’。”

官方披露：宕机的深层原因

Cloudflare 运营着全球约 20% 网站所依赖的内容分发网络（CDN）。该平台通过创建网站内容的多个副本，并将其分布在全球各地的数据中心来运作。当用户访问网页时，Cloudflare 会从距离用户最近的数据中心加载内容。该公司表示，这种架构能为全球 95% 的人口提供 50 毫秒或更低的延迟。

除了提升网站速度，Cloudflare 的平台还有其他用途。将流量处理任务卸载到 CDN 可减轻网站运营商的服务器负载，进而提高运营效率。此外，Cloudflare 还提供网络安全功能，能够过滤恶意机器人程序及其他威胁。

关于造成流量激增的原因，当晚，Cloudflare 首席技术官 Dane Knecht 在 X 平台的帖子中透露，此次宕机由公司的恶意机器人流量过滤功能引发，并非攻击所致。这位高管强调，“我们的机器人防护功能所依赖的一项服务中存在潜在漏洞，在一次常规配置变更后开始崩溃，进而导致我们的网络及其他服务大范围出现性能下降。”

同时，Cloudflare 发言人也向外媒提供了更详细的最新进展。据称，“此次宕机的根本原因是一个自动生成的威胁流量管理配置文件。该文件的条目数量超出预期规模，引发了为 Cloudflare 多项服务处理流量的软件系统崩溃。”发言人表示，“需要明确的是，目前没有证据表明这是攻击行为或恶意活动导致的。我们预计，事件结束后流量会自然激增，部分 Cloudflare 服务可能会出现短暂性能下降，但所有服务将在未来几小时内恢复正常。”

在后续发布的博客中，Cloudflare 进一步解释了出现故障的完整经过、受影响系统和处理流程。据称，“问题是由于我们数据库系统的一项权限更改触发的，该更改导致数据库向一个由 Bot 管理系统使用的功能文件中输出了多个条目。该功能文件的大小随后翻倍。预期之外的大功能文件随后被传播到构成我们网络的全部机器上。这些设备上运行的网络流量路由软件会读取这份特征文件，确保机器人管理系统能及时应对不断变化的威胁。该软件对特征文件的大小设有限制，而此次文件大小翻倍后超出了这一限制，导致软件故障。”

具体来说，“机器人管理”模块正是此次宕机的根源。据介绍，Cloudflare 的机器人管理模块包含多个系统，其中一款机器学习模型会为流经其网络的每一项请求生成机器人评分。客户借助这些评分决定是否允许特定机器人访问其网站。该模型的输入数据是一份 “特征” 配置文件，这份特征文件每几分钟更新一次，并同步至整个网络，使其能够应对互联网流量的变化。

而正是底层 ClickHouse 查询行为的一项变更，导致生成的文件中出现大量重复的 “特征” 行。这一变化改变了此前固定大小的特征配置文件的尺寸，引发机器人模块触发错误。结果是，负责为客户处理流量的核心代理系统，向所有依赖该机器人模块的流量返回了 HTTP 5xx 错误码。这一问题还影响了依赖核心代理的 Workers KV 和 Access 服务。

其做出的变更是，让所有用户都能获取其有权访问的表的准确元数据。但问题在于，他们过去的代码中存在一个预设前提：此类查询返回的列列表只会包含 default 数据库的内容，该查询不会对数据库名进行过滤。随着他们逐步向目标 ClickHouse 集群的用户推出这一显式权限，上述查询开始返回列的 “重复项”，这些重复项来自存储在 r0 数据库中的底层表。不巧的是，机器人管理模块的特征文件生成逻辑，正是通过这类查询来构建本节开头提到的文件中的每个输入 “特征”。

由于用户获得了额外权限，查询响应现在包含了 r0 数据库模式的所有元数据，导致响应行数增加了一倍多，最终影响了输出文件中的行数（即特征数量）。起初，他们还误判观察到的症状是由超大规模分布式拒绝服务（DDoS）攻击引发，但随后准确识别出核心问题，成功阻止了这份超出预期大小的特征文件继续传播，并替换为早期版本。

详细报告链接：https://blog.cloudflare.com/18-november-2025-outage/

六年来最严重中断，“真相”被嘲疯了？

在大范围宕机期间，Cloudflare 的股价下跌了约 3%。

“鉴于 Cloudflare 服务的重要性，任何宕机都是不可接受的。网络曾一度无法正常路由流量，这让我们团队的每一位成员都深感痛心。我们知道，今日辜负了大家的信任。”Cloudflare 在博客中也表示。

并且，该公司说明了后续加固系统以防止此类故障的步骤，包括以下方面：

• 按用户生成输入的防护标准，强化对 Cloudflare 内部生成配置文件的接收校验；

• 为相关功能增设更多全局紧急关闭开关；

• 避免核心转储或其他错误报告占用过多系统资源；

• 全面审查所有核心代理模块的各类错误场景故障模式。

对于此次的宕机事故，Cloudflare 承认，这是其自 2019 年以来最严重的一次宕机。“我们以往也发生过宕机事件，比如导致控制台无法访问，或是部分新功能暂时不可用，但在过去六年多里，从未出现过导致大部分核心流量无法通过我们网络传输的情况。”

据了解，该公司上一次重大宕机发生在 6 月，当时其超过六项服务下线约两个半小时。那次宕机由 Workers KV 数据存储平台的故障引发。

专家认为，这可不是 Cloudflare 一家的问题。AWS、Azure、Google Cloud、阿里云，全都翻过车。系统越复杂，链条越长，一个小小改动就能在依赖迷宫里撞出大灾。云计算的规模红利，正在被它带来的复杂度和系统性风险反噬。要解决这个问题，也许要借鉴其他行业的经验，把 IaaS 层当“算力电网”管起来，PaaS/SaaS 层放开竞争，可能才是出路。

有网友评价，“这纯属 Cloudflare 自己搞砸了。一个小故障，就成了第一块多米诺骨牌。”也有人认为，“这次宕机本身是件小事，但它暴露了 Cloudflare 自身服务之间过度的耦合问题，导致控制面板也无法访问它。如果控制面板可用，将能让许多服务更快地部分恢复功能。”

还有人发出疑问：“互联网真的需要如此严重地依赖单一供应商吗？”同时，亦有批评人士表示，此类宕机事件充分暴露了互联网的脆弱性，尤其是当所有人都依赖相同的服务提供商时。

参考链接：

https://siliconangle.com/2025/11/18/cloudflare-outage-briefly-takes-chatgpt-claude-services-offline/

https://arstechnica.com/tech-policy/2025/11/widespread-cloudflare-outage-blamed-on-mysterious-traffic-spike/