背景图片来源／Yamu_Jay on pixabay

美国网络基础设施服务商Cloudflare于世界协调时间（UTC）周二（11月18日）上午11时许发生故障（约为北京时间11月18日晚上7时许），最初内部误判为遭遇大规模分布式拒绝服务（DDoS）攻击，后查明是因一系列数据库权限变更操作所引发。此次故障持续约6小时，至北京时间11月19日凌晨1时许才恢复正常。Downdetector数据显示，Spotify、Facebook、Anthropic、X、OpenAI与AWS等服务在Cloudflare故障期间也出现大量用户报告异常，虽无法确认直接因果关系，但时间高度重合，推测可能受到波及。

成立于2010年的Cloudflare提供内容分发与性能优化、网络安全、边缘计算与开发者服务、企业云网络等多项服务，旨在让全球网站、应用及企业网络更快速、更安全。该公司在全球数百个城市部署边缘节点，是目前覆盖范围最广的网络传输与安全平台之一，许多网站的流量都会先经过Cloudflare，再抵达终端用户。

Cloudflare很快公布了此次事故的详细经过：UTC时间11:05，团队在ClickHouse数据库上部署了一项权限更新，允许用户显式查看底层数据库r0的字段信息。然而，Bot Management功能文件的生成查询未过滤数据来源，更新后同时抓取了default与r0两组相同字段，导致功能文件内容翻倍。

功能文件在全球传播后，代理模块（FL/FL2）因特征数量超出预设上限而触发错误并崩溃，自UTC时间11:20起，全球范围内出现第一波服务器错误（HTTP 5xx）。

Cloudflare的核心代理模块（FL/FL2）是所有HTTP流量的统一入口，无论是网站、API、登录验证、Workers、CDN还是Turnstile，用户的每一个请求都必须先经过这一层，再依次经过Bot Management、WAF、防火墙与缓存等模块处理。因此，该代理模块相当于Cloudflare整个网络的交通中枢。此次Bot Management功能文件异常导致代理模块崩溃后，所有流量均无法被正确处理，系统只能返回5xx错误，致使所有依托Cloudflare的客户同步受影响，引发全球性大规模中断事件。

从权限变更部署（UTC 11:05）到错误发生（11:28），再到定位根本原因（13:37），耗时约两个半小时。随后Cloudflare立即停止生成与发布新文件，14:30恢复大部分服务，至17:06才完全恢复正常。

Cloudflare表示，尽管事故起因仅为常规性的数据库权限调整，但影响范围远超预期。公司强调，此次故障并非遭受外部攻击，而是内部多个系统相互耦合，使一个功能文件的异常翻倍扩散至代理系统，最终导致全局流量中断。

Cloudflare承认，这是自2019年以来最严重的一次全网中断，对依赖其服务的网站与应用造成了实质性影响。公司将全面审查模块依赖关系、配置文件验证机制与错误处理流程；未来将强化相关机制，包括为所有内部自动生成的配置文件增加更严格的校验、部署更多可即时生效的全局禁用开关，并避免调试与监控系统在事故中进一步加重服务器负担。

此外，该公司还将重新评估核心代理模块的故障模式，确保即使某一子系统异常，整体流量仍能以降级模式安全运行。