对于全球数以百万计的网站运营者与网民来说，本周的周二，注定又是一个难忘的一天。

如我们所见（在所见），在这一天的短短数小时内，包括X（原Twitter）、ChatGPT、Spotify等（海外）常用巨头服务在内，海外互联网领域几乎陷入瘫痪。无论刷新多少次，映入眼前的都是同样的“InternalServerError”报错页面。但后来总结来看，这并不是一次外部攻击导致的人为事故，而是一场由Cloudflare内部引发的全球性技术故障。

事情的起因源于一次再常规不过的例行升级。正常情况下，每天，Cloudflare都会为其Bot管理模块生成一个“特征文件”，用来帮助识别恶意机器人。这本是一项普通的后台流程，但当天文件的生成程序因为数据库权限调整出现异常，意外重复写入部分内容，文件体积因此比平时大了整整一倍。这看上去可能只是一个细小的问题，但对于系统层面来说，却足以成为彻底击穿代理层的导火索。

眼熟么？

按照Cloudflare的说法，Cloudflare的网络结构决定了这种配置文件需要在全球所有边缘节点同步。也就是说，一旦生成，它会被迅速推送至遍布世界的数千台服务器。而当这些节点接收到异常文件后，负责处理全部HTTP请求的核心程序没能成功解析，直接崩溃。由于文件同步速度极快，多个国家、多个地区的节点几乎在相近时刻出现同样的故障，也就形成了用户看到的“全球同步掉线”的奇怪场景。

更让情况复杂的，是系统还会每隔几分钟自动检查更新。这意味着，旧的正确文件偶尔会让部分节点短暂恢复，但很快又会被新的错误文件覆盖，再次宕机。自然而然的，外界当时看到的也就是网站“恢复—再报错—再恢复”的循环。

这一剧本直到工程师们最终追踪到特征文件本身，并暂停了错误文件的更新，情况才逐渐稳定下来。当天稍晚时间，Cloudflare开始向全球节点重新推送正常版本，各地的代理服务陆续恢复，错误量在短时间内迅速下降。不久后，Cloudflare宣布所有系统回到正常状态，但这次宕机的影响已经被记录为近期互联网基础设施事故中“规模最为罕见的之一”。

Cloudflare：“Cloudflare网络处理的5xx错误HTTP状态代码的数量。通常情况下，这个数值应该非常低，而且在故障发生前也确实如此。”

作为全球互联网基础设施的重要组成部分，Cloudflare此次大规模宕机迅速引发了各界的关注和反响。而事发当日，Cloudflare盘前股价也一度下跌超过2%。Cloudflare首席技术官Dane Knecht随后在X上公开致歉，承认网络在当天出现严重问题，“辜负了依赖我们的客户和整个互联网···”但回到事故本身，不难发现，它之所以引发如此强烈的讨论，很大程度上是因为于此揭示出的是一个越来越需要回应的问题。

你猜这张图我们还能再看到几遍？

当下，越来越多的平台将性能优化、安全防护、访问控制等关键能力托付给行业巨头——以Cloudflare本身为例，其承载着全球大约五分之一的互联网流量。在这样的结构下，一旦核心代理层出现故障，它所依赖的多个产品链路会同时失效，而这里承载的成千上万家服务也会在极短时间内同步感受到冲击。

而这也正像我们在上个月前刚看到的那样。彼时，互联网的另一大基础构成——AWS也经历了一次的中断。根据监测平台数据，当时共有超过两千家服务受到影响，累计超过八百万条用户报错被记录。此次Cloudflare的事故，则再次让““互联网的命运，过度依附于少数几家巨头”这个问题放置在了人们的面前。当然，在这个面前的是这样的一组数据，就云计算领域而言，全球前三家巨头（AWS、微软Azure和谷歌云）掌控了超过其中近七成的基础设施。

Cloudflare：我知道谁在点我名

当然，也正是基于这一点，不难预料，无论是AWS还是Cloudflare，在此之后，我们显然还会再度经历同样的经历。但，当这些这些故障越来越多的发生时，这些问题也注定会随之变得越来越无法回避。