11月18日，互联网基础设施巨头Cloudflare发生大规模宕机事故，导致全球范围内大量网站及在线服务陷入瘫痪，这场“半个地球互联网陪葬”的故障持续近6小时，引发全球网友集体哀嚎，上演了一出互联网大戏。

一、宕机现场：从社交到游戏，互联网“停摆”百态

事故初期，用户纷纷反馈各类服务异常：推特（X）登录困难、内容刷不出，ChatGPT、设计工具Canva无法打开，正在进行LOL、瓦罗兰特排位的玩家直接断开服务器连接。更具戏剧性的是，当众人试图通过Down Detector查询故障网站时，发现该平台也因访问量激增而崩掉，“想看热闹却成了热闹本身”。

网友们的反应花样百出：有人哭诉“因Cloudflare宕机，连AI女友都联系不上了”；有人用“美国人没汉堡吃（点餐机崩了）”来形容故障的严重程度；还有人调侃“Cloudflare崩了后，生活全是蓝天白云”。期间，用户MrShibolet发布的“Cloudflare入职第一天推送更新，下午准备休息”的整活推特爆火，60万次阅读量下网友纷纷调侃“兄弟第一天上班就是最后一天”，而实际上该用户在上个月AWS宕机时也曾发布类似内容。

二、Cloudflare是谁？为何能“牵一发动全身”

Cloudflare被喻为“互联网的物业公司”，核心业务涵盖CDN（内容分发网络）、DDoS防护、Web应用防火墙、DNS服务等，负责网站的安全、加速与流量管理。正常访问流程中，若网站使用Cloudflare服务，路径会变为“用户浏览器→Cloudflare→网站服务器→Cloudflare→返回用户”，通过全球330多个数据中心将用户导向最近节点，实现访问加速，同时像“保镖”一样拦截恶意攻击、减轻源服务器压力，相当于为网站配备“五星级物业”。

但这一模式也存在隐患：一旦Cloudflare系统崩溃，就如同物业保安集体“宕机”，所有用户都会被拦在网站“门外”，形成“一家公司打个喷嚏，全世界感冒”的连锁反应。

三、宕机原因：权限微调引发的“数据库精神分裂”

根据Cloudflare发布的事故报告，故障源于Bot Management（机器人管理）功能的特征文件生成机制异常。该功能通过特征文件（含60种判断标准）对访问者打分，网站管理员可依分数设定访问权限。正常情况下，系统每5分钟向后台数据库请求最新特征清单，流程为“系统→前台总管（Default，仅存索引目录）→分仓库（r0，存实际数据）→返回60条特征”。

11月18日11时（UTC时间），工程师对数据库进行权限微调，误将指向“前台总管”的单线请求改为全公司“大喇叭”广播。当系统再次请求特征清单时，前台总管与各地分仓库纷纷抢答，60条特征被重复推送成数百条，远超系统设定的200条特征上限，导致系统崩溃。更复杂的是，数据库集群更新分批进行，部分节点为老版本（正常响应）、部分为新版本（重复响应），使得网站呈现“时好时坏”的“仰卧起坐”式故障状态。

四、修复过程与损失：6小时宕机背后的真金白银

工程师起初误以为遭遇DDoS攻击（此前曾挡下7.3Tbps超级攻击），尝试限流、切换路由等操作无果后，于14时24分停止自动生成配置文件，手动启用旧版本正常配置并推送至全球服务器，大部分服务开始恢复。17时06分，所有下游服务重启完成，宕机正式结束，整个过程持续近6小时。

此次宕机对企业造成显著损失。上月AWS宕机曾影响60国1700多万用户、3500多家公司，每小时经济损失超7500万美元，而Cloudflare作为全球众多网站的“基础设施”，此次6小时宕机的损失规模可想而知。对于普通用户而言，故障仅是“网站打不开”的短暂困扰，但依赖在线服务的企业却面临业务中断的直接冲击。

五、反思：互联网“空中楼阁”的地基隐忧

Cloudflare在报告中承诺加强配置文件检查、审查模块容错能力，但此类“宕机后保证书”已屡见不鲜。当前互联网建立在少数基础设施公司之上，如同“空中楼阁”，地基仅靠几根“柱子”支撑，任一“柱子”晃动都可能引发全局震荡。尽管开发者可通过多云部署降低风险，但高成本与复杂度让小公司难以承受。未来，如何提升基础设施的稳定性与容错能力，仍是整个行业需要持续破解的难题。

图片、资料来源：Cloudflare outage on November 18，2025；Reddit、X