Cloudflare 故障 5 小时：互联网的根基，比你想的还要脆弱
Cloudflare 是全球最大的 CDN 之一，但当它出现故障时，影响范围极广。这不是技术问题，而是系统设计的必然结果。
2022 年 7 月 21 日，Cloudflare 挂了 5 个小时。
GPT、推特、Discord……大量你每天都在用的服务全面瘫痪。这不是黑客攻击，不是 DDoS，而是一次配置更新。
一个错误的 WAF（Web 应用防火墙）规则被全球发布，导致所有边缘节点的 CPU 被打满。
这也提醒了各位：互联网这个强大的科技产物，比你想的还要脆弱。
5 小时发生了什么
Cloudflare 是全球最大的 CDN 之一，核心定位就是流量的第一道关卡。每个用户请求都要经过 Cloudflare 的边缘节点，然后才被转发到源站。
这次故障的源头，是一次 WAF 规则更新。
WAF 的工作很简单：识别恶意流量，比如爬虫、攻击请求。它会在每个 HTTP 请求上执行一系列规则，判断这个请求是否可疑。
问题出在哪里？
这次更新的规则写错了。它使用了一个极其复杂的正则表达式，在每个 HTTP 请求上执行时，计算成本非常高。
可以理解成：每个请求都要做一次"超级复杂计算"。
后果是什么？
- 每个请求都触发这个高成本规则
- CPU 被迅速打满
- 边缘节点无法处理新请求
- 直接返回 500 / 502 / 超时
为什么会全球一起挂？
Cloudflare 是边缘计算架构，配置是全球同步的。几分钟内，这个错误的规则被推送到所有节点。
一个 bug = 全球一起挂。
为什么看起来"一会好一会坏"？
因为部分节点的缓存和状态不同：
- 有的节点还没加载规则
- 有的节点已经炸了
- 有的节点负载较低还能撑
于是就出现了过山车状态：一会好 → 一会挂 → 再好 → 再挂。
怎么修复的？
Cloudflare 做了三件事：
- 回滚规则——直接撤掉问题 WAF
- 加强发布机制——增加灰度发布、自动检测规则性能
- 加保护机制——CPU 过高自动降级，限制规则复杂度
整个事故持续了 5 个小时。
三个致命问题
这次故障的原因，说白了就是三个架构问题叠加：
第一，把高风险逻辑放在了请求主路径上。
WAF 是在请求链路中的，不是后台任务，是"必须执行"的。所以一旦慢，整个请求就卡住。
正确做法应该是：慢规则异步分析，快规则同步执行，或者有熔断机制。
第二，全球统一发布，没有灰度。
Cloudflare 的配置是全球同步的，几分钟内推到所有节点。这意味着一个错误会瞬间影响全球。
如果有灰度发布，先在一个节点测试，再逐步扩大范围，影响会小很多。
第三，没有自动熔断机制。
当时系统缺少 CPU 保护机制，不会自动降级 WAF。系统不会说：“规则太慢了，我先跳过”。
结果就是 CPU 被打满，节点直接瘫痪。
互联网的脆弱性
一个正则表达式写错了，全球互联网就瘫痪了 5 个小时。
这不是 Cloudflare 一家的问题，而是整个互联网架构的脆弱性。
从功能层面上看，DNS、CDN 这些在发明之初，就是为了方便数据交流的"翻译表"和"加速器"，逐渐成为大家最依赖的基础功能。随便一个出问题，整个"互联网"都会瞬间变成"不联网"。
而从资源层面上看，网络基建聚集在 Cloudflare 等几个企业，应用基建聚集在 AWS、GCP 等几个云服务商上。
现在懂行的人都知道，想要破坏人类社会，不需要多少枚核弹，往弗吉尼亚北部投一枚 EMP 就够了——那里是 AWS、GCP、Cloudflare 等大量数据中心的核心聚集地。
这也是有点讽刺的。毕竟互联网的鼻祖，就是为了去中心化进行设计的、具有高度容错的军事系统。但随着互联网的发展，各种新服务的诞生，容错非但没有提高，反而是越来越低的。
但不可否认的是，如果没有这些发展，互联网或许还能保留当初的理论优点，但肯定就不会像现在那样，成为几十亿人赖以生存的社会基建了。
效率 vs 冗余，永远是系统设计的核心取舍。
你选择了全球同步发布，就要承担一个 bug 影响全球的风险。你选择了在请求主路径上执行逻辑，就要接受一旦出错就全线瘫痪的后果。你选择了集中化的 CDN，就要面对单点故障的可能。
单点故障不是会不会发生的问题，而是什么时候发生的问题。
我们该怎么办
面对这种系统性风险，我们能做什么？
第一，多元化供应商。 不要把所有流量都压在一家 CDN 上。不要把所有服务都部署在同一个云服务商上。这不是 paranoid，这是基本的风险意识。
第二，容灾设计。 假设你的依赖随时会挂。假设你的数据库随时会崩。假设你的网络随时会断。然后问自己：我的系统还能跑吗？
第三，监控和应急响应。 Cloudflare 这次故障之所以能被发现，是因为用户投诉量激增。建立有效的监控体系，确保故障能在第一时间被发现和定位。
结尾
互联网的脆弱性不是技术问题，而是系统设计的必然结果。理解这一点，比抱怨更重要。
下次你的服务挂了，别急着骂云服务商。问问自己：我做了什么来降低这种风险？
你的系统，做好容灾了吗？
在评论区聊聊你的经验。说不定你的一个做法，就能帮到正在踩坑的人。