Cloudflare 被 React 坑了！两周内二次“翻车”

---TITLE---
React Server Components漏洞触发Cloudflare大规模宕机：两周内二次发布事故剖析
---TAGS---
Cloudflare,React,Server Components,Lua,代理系统
---CONTENT---
💥 短短25分钟内，全球高达28%的网站遭遇服务不可用，集体“躺平”。

然而，这次事件的源头并非外部黑客攻击，而是云服务提供商Cloudflare自身的一次“手滑”操作。更令人关注的是，这已是该平台在两周之内第二次因内部更新而引发的大规模故障。

本次事故发生在12月5日。Cloudflare的全球节点开始大规模返回HTTP 500内部服务器错误。调查发现，其根源是Cloudflare为了紧急应对React Server Components所暴露出的一个严重安全漏洞而进行的加固操作。可以说，这次Cloudflare在某种程度上是为上游框架的漏洞“背了锅”。

为了更快地保护开发者，Cloudflare团队采取了双重措施：先将Web应用防火墙（WAF）的缓冲区扩大至1MB，随后关闭了一个内部测试工具。然而，正是这两项变更的组合，意外激活了运行在旧版FL1代理中一段“沉睡多年”的Lua代码缺陷。该缺陷的逻辑是：当某条规则被跳过时，未正确生成相应对象，导致系统后续尝试访问一个nil值，从而直接抛出500错误。

Lua语言虽然早在1993年发布，并在2008年就已相当成熟，但它被Cloudflare在2009年成立之初、2010年服务上线时，选定为早期网络堆栈的基石之一。这导致了部分历史代码难以被完全替换，使得此类古老的bug有机会在多年后被意外的操作序列重新激活。从数据库/中间件的演进历史来看，这种因技术债积累而导致的生产事故并不少见。

本次故障仅影响了那些仍在使用旧版FL1代理并开启了特定托管规则集的客户，但这一部分流量却占据了Cloudflare总流量的28%。颇具讽刺意味的是，已经用Rust重写的新版FL2代理则完全不存在此类问题。

更令人不安的是，此次事故与发生在11月18日的另一次故障模式高度相似：都是紧急发布补丁 → 全球同步生效 → 击穿老旧代码路径 → 最终引发大规模宕机。尽管在上次事故后，Cloudflare承诺对其发布体系进行改造，但显然改造尚未完成，新的事故便已再次发生。

事故发生后，Cloudflare宣布冻结全部网络变更，并将发布流程的稳健性、应急响应能力以及故障开放（fail-open）容错机制列为最高优先级的改进项。这起事件清晰地揭示了一个根本问题：在当今高度复杂的全球分布式系统中，即便是一行多年未被触发的旧Lua代码，只要与一次“全球同步推送”的发布策略相结合，便足以产生足以拖垮半个互联网的连锁效应。

这两次密集的事故暴露了同一个核心挑战：在安全性要求日益增高、系统复杂度不断攀升的互联网基础设施领域，如何避免“被自己的更新打趴下”，已经成为比抵御外部攻击更为紧迫和严峻的运维/DevOps工程难题。