作为支撑全球约20%网站运行的核心互联网基础设施服务商，CloudFlare的稳定性直接关系到全球网络生态的正常运转。然而在2025年11月至12月期间，CloudFlare接连发生两起全球性服务中断事件，导致ChatGPT、X（原Twitter）等海量服务瘫痪，引发行业对集中式网络基础设施可靠性的广泛讨论。本文将从技术视角复盘这两起故障，明确故障出现时间，解析深层原因，并探讨分布式基础设施的韧性建设方向。

一、核心事件回顾：两次全球故障的关键时间线

近期CloudFlare共发生两起影响范围广、关注度高的全球服务中断事件，具体出现时间及核心节点如下：

11月大规模长时间宕机事件

  • 故障出现时间：世界标准时间（UTC）2025年11月18日11:20，对应北京时间2025年11月18日19:20

  • 故障发现节点：CloudFlare监测到网络流量处理异常，大量用户访问依赖其服务的网站时出现HTTP 5xx错误页面

  • 初步误判阶段：初期工程师怀疑是超大规模DDoS攻击导致，延误了部分排查时间

  • 核心修复节点：UTC时间14:30（北京时间22:30），官方确认根因并停止错误配置文件传播，核心流量恢复正常

  • 完全恢复时间：UTC时间18日17:06（北京时间19日01:06），所有系统恢复正常运行，故障持续时长约5小时46分钟

12月短时宕机事件

  • 故障出现时间：世界标准时间（UTC）2025年12月5日08:47，对应北京时间2025年12月5日16:47

  • 故障特征：约28%的HTTP流量受到影响，主要表现为HTTP 500错误，中国大陆地区服务未受波及

  • 修复节点：UTC时间09:12（北京时间17:12）完成配置回滚，服务完全恢复，故障持续时长25分钟

二、故障根因深度解析：配置变更触发的技术连锁反应

两起全球故障均非网络攻击所致，核心诱因均为全网快速传播的配置变更，但具体技术链路存在差异，暴露出不同层面的架构隐患。

11月故障：权限变更导致配置文件“膨胀”触发系统崩溃

此次故障的技术链路可概括为“权限变更→数据重复→文件超限→软件失效”：

  1. 根源触发：CloudFlare在对ClickHouse数据库集群进行权限管理更新时，一项权限变更导致数据库向Bot Management（机器人管理）系统的“功能文件”中输出大量重复条目。

  2. 文件异常：重复条目使功能文件大小翻倍，超出了核心流量路由软件的预设大小限制。该功能文件每5分钟自动生成并同步至全球所有服务器，用于支撑机器人威胁检测能力。

  3. 系统崩溃：全球服务器上的流量路由软件读取超限文件时触发崩溃，直接导致核心CDN、Turnstile验证、Workers KV等服务返回5xx错误，甚至登录控制面板的验证功能也失效。

  4. 修复关键：官方停止错误文件生成，手动插入历史正常文件并重启核心代理，才逐步恢复流量处理能力。值得注意的是，由于错误文件每5分钟可能随机生成正常版本，期间系统曾出现“自动恢复后再次崩溃”的异常现象。

12月故障：旧代码缺陷被配置变更激活

此次故障源于安全漏洞应对过程中的配置调整，触发了旧版系统的代码缺陷：

  1. 背景前提：为缓解CVE-2025-55182漏洞风险，CloudFlare计划将Web应用防火墙（WAF）的请求体解析缓冲区从128KB提升至1MB。

  2. 配置变更：升级中发现内部测试工具不支持新缓冲区大小，团队通过全球配置系统关闭该工具。该系统的特性是“全网瞬时推送”，而非区域灰度发布，导致变更立即影响所有服务器。

  3. 代码缺陷触发：旧版FL1智能体中存在Lua代码缺陷，当系统处理“关闭测试工具”的配置结果时，尝试访问不存在的“execute”字段，触发“attempt to index field 'execute' (a nil value)”错误，直接导致流量处理失败。

  4. 关键差异：新版基于Rust的FL2智能体无此缺陷，因此受影响用户仅限使用FL1智能体并启用CloudFlare托管规则集的客户。

三、共性问题暴露：全球分布式架构的韧性短板

两次故障虽触发点不同，但共同指向CloudFlare在全球配置管理、旧系统治理、故障容错机制上的核心短板：

1. 全网瞬时部署机制的“双刃剑”效应

CloudFlare的全球配置系统支持“一次变更、全网同步”，这种机制虽能快速响应安全威胁，但也使错误配置具备了“全球级破坏能力”。两次故障中，若能采用“区域灰度发布+流量验证”的策略，完全可在影响扩大前发现问题并回滚。

2. 旧代码与新架构的兼容治理缺失

12月故障中的Lua代码缺陷已存在多年，却未随架构升级（FL1→FL2）完成清理或兼容改造。这种“技术债务”在常规场景下隐藏，一旦遇到特殊配置变更便会爆发。对于服务全球的基础设施而言，旧系统的全量审计与缺陷修复至关重要。

3. 故障检测与容错机制不完善

11月故障初期的“DDoS误判”延误了修复时间；12月配置变更后缺乏即时的可用性验证，均反映出故障检测的滞后性。此外，核心流量处理软件未启用“Fail-Open”（故障开放）模式，一旦崩溃便完全阻断流量，未预留应急处理通道。

四、行业启示：分布式基础设施的韧性建设方向

CloudFlare的两次故障为全球互联网基础设施服务商提供了重要警示，韧性建设需从“快速部署”向“安全部署”“容错部署”转型：

  • 灰度发布与强制验证机制：核心配置变更必须采用“区域分层推送+流量比例验证”模式，设置最小可行部署单元（如单区域1%流量），验证通过后再逐步扩大范围。对高影响操作强制要求双重验证和自动化回归测试。

  • 旧系统技术债务治理：建立旧架构、旧代码的全生命周期管理机制，明确淘汰时间表。对暂无法替代的旧系统，需通过静态代码分析、异常场景注入测试等方式，提前发现潜在缺陷。

  • 完善故障容错设计：关键数据平面组件应启用“Fail-Open”模式，确保极端情况下核心流量可绕行故障模块；同时构建多区域冗余配置分发通道，避免单一配置系统故障引发全局问题。

  • 精准的故障根因定位体系：建立跨模块的日志关联分析平台，针对核心组件设置多维度监控指标（如配置文件大小、代码运行异常、流量错误率），避免故障初期的误判。

五、总结

CloudFlare 2025年11月18日（UTC11:20）和12月5日（UTC08:47）的两起全球故障，本质是“快速迭代需求”与“基础设施韧性”失衡的结果。对于支撑全球网络生态的核心服务商而言，任何配置变更都可能引发蝴蝶效应，因此“安全冗余”应优先于“效率优先”。目前CloudFlare已冻结所有网络变更，推进发布机制增强、故障旁路流程完善等工程改造。此次事件也再次证明，全球互联网的稳定性依赖于每一个基础设施节点的韧性设计，而这种韧性，恰恰藏在每一次配置变更的严谨验证、每一行旧代码的缺陷修复和每一套故障容错机制的完善之中。