Cloudflare 三小时 5xx：一次配置变更如何打穿半个互联网

2025 年 11 月 18 日，从 11:20 UTC 左右开始，访问大量网站的人看到了 5xx 错误页。它们有一个共同点：都用了 Cloudflare。故障持续约三小时，恢复是逐步的，不是一刀切。

事后 Cloudflare 发布了复盘，明确说不是网络攻击，也不是配置被入侵。

根因不是攻击

按复盘的描述，触发点是内部的一次配置变更：某个 Bot Management 特性使用的配置文件由系统自动生成，权限调整之后，这个文件被写入的内容远超预期大小。核心代理在解析它时触发了一个潜伏的缺陷，进程异常，于是所有经过该代理的流量开始报错。

三个要素凑在一起才出事：自动生成的配置、没人预料到的体积、以及一个从未在真实规模下被踩到的解析路径。单看任何一项都不像事故。

为什么影响这么大

Cloudflare 在架构上本来就是“单点”：全球流量都要经过它。这不是设计失误，而是它的产品定位——反代、WAF、CDN 都要求流量经过同一层。代价是这一层的任何故障都会被放大成“半个互联网不可用”。

这次故障还暴露了两个传播细节：

• 配置是全局下发的。一份坏配置不是影响一个区域，而是随着边缘节点同步扩散；
• 回滚比下发慢。下发是自动的，回滚要人判断、要确认、要逐层推进，中间的时间差就是故障时长。

三条工程教训

1. 配置要有金丝雀。任何全局配置的下发都应该先经过一小部分节点，观察指标再放量。这次如果先放 1%，代价会小两个数量级；
2. 给配置设上限。自动生成的配置文件需要硬性的大小上限与校验，超出就拒绝下发。很多事故不是“值错了”，而是“值太大了”；
3. 故障时的降级路径要提前设计。fail-open 还是 fail-closed 是产品决策，但必须提前定好，并在演练里验证。

一句判断

这次事故里没有黑客、没有零日，只有一个被自动生成的配置文件和一段没被踩过的代码。现代基础设施的脆弱点，往往不在攻击面，而在“正常操作”的爆炸半径。对自建服务的启发很直接：凡是全局生效的配置，都当成一次部署来对待。

封面图：Cloudflare 官方复盘配图（blog.cloudflare.com）。