2025年11月28日-Cloudflare史诗级事故:一次配置失误，引爆全球宕机

2025年11月28日-Cloudflare史诗级事故:一次配置失误，引爆全球宕机 前言

继今年10月19号亚马逊云AWS的 us-east-1的大故障，导致美国一半的线上服务不可用，波及到全球用户。

2025 年 10 月 29 日，，持续近 9 小时。受影响的不仅包括微软自家核心服务（Office 365、Xbox Live、Copilot 等），还波及航空、医疗、零售等多个行业。

“不甘寂寞”的Cloudflare人称赛博活佛CF也出事故了！

2025年11月18日，Cloudflare 发生了一次堪称“史诗级”的全球宕机。作为全球最大的 CDN 与安全服务提供商之一，它的服务覆盖了数百万网站和应用。这次事故直接导致全球范围的访问异常，用户看到的不是网页，而是熟悉的 Cloudflare 错误页。

官方承认，这是自 2019 年以来最严重的一次宕机。

一、事故概述

2025 年 11 月 18 日 11:20 UTC，Cloudflare 全球网络爆发大规模故障，核心流量交付功能出现严重异常，用户访问其客户网站时普遍收到 HTTP 5xx 系列错误（主要为 500 内部服务器错误）。此次故障并非由网络攻击或任何恶意行为导致，系内部数据库配置变更引发的连锁反应，是 Cloudflare 自 2019 年以来最严重的一次服务中断事件。

故障发生后，技术团队启动紧急响应，14:30 核心流量基本恢复正常，17:06 所有受影响服务完全恢复稳定运行。期间多个核心产品及服务受到不同程度影响，对广大客户及全球互联网访问体验造成了负面影响，Cloudflare 官方已就此公开致歉。

二、影响范围

云服务、内容分发网络（CDN）和安全服务中断，导致包括 ChatGPT、X（原 Twitter）、Spotify、游戏服务、零售商及公共交通系统在内的多个大型网站和应用出现访问失败或 5xx 系列错误。

几乎所有依赖 Cloudflare 服务的平台都受到了波及。

（一）核心 CDN 与安全服务

直接返回 HTTP 5xx 错误码，用户无法正常访问依赖 Cloudflare CDN 加速及安全防护的网站，页面显示 Cloudflare 网络内部故障提示。

（二）Turnstile 服务

完全无法加载，导致依赖该服务进行验证的场景出现功能中断。

（三）Workers KV

核心代理故障引发其前端网关请求失败，HTTP 5xx 错误率显著升高，功能可用性大幅下降。

（四）管理后台（Dashboard）

虽主体功能未完全中断，但由于登录页面集成的 Turnstile 服务不可用，多数用户无法正常登录；后续恢复阶段因登录请求积压及重试机制，出现 latency 升高问题。

（五）邮件安全（Email Security）

邮件处理与交付未受影响，但暂时丢失部分 IP 信誉数据源，导致垃圾邮件检测准确性下降，部分新域名年龄检测功能失效；部分自动转移（Auto Move）操作失败，相关邮件已完成复核与修复。

（六）Access 服务

11:20 起多数用户出现认证失败，无法访问目标应用，已建立的有效会话不受影响；故障期间的认证失败均记录在案，配置更新操作要么直接失败，要么传播速度极慢，后续已完全恢复。

此外，故障期间 Cloudflare CDN 响应延迟显著增加，原因是调试与可观测性系统消耗大量 CPU 资源，用于收集未捕获错误的额外调试信息。

三、应急措施

1. 1. 故障初期启动多维度排查，快速排除 DDoS 攻击等外部因素，锁定内部服务异常。

2. 2. 针对 Workers KV 和 Access 服务启用旁路机制，绕开故障核心代理，快速降低关键服务影响范围。

3. 3. 定位特征文件异常后，立即停止异常文件的生成与传播，避免故障进一步扩散。

4. 4. 全球部署经验证的历史正常特征文件，强制重启核心代理服务，修复核心流量处理链路。

5. 5. 恢复阶段扩容控制平面并发能力，处理登录请求积压问题，修复剩余异常服务实例。

四、补救和后续步骤

现在我们的系统已恢复正常运行，我们已经开始着手研究如何加强系统，以防止未来再次发生类似故障。具体来说，我们正在：

• • 加强对 Cloudflare 生成的配置文件的摄取，就像我们加强对用户生成输入的摄取一样。

• • 为功能启用更多全局终止开关

• • 消除核心转储或其他错误报告占用系统资源的可能性

• • 审查所有核心代理模块的错误情况故障模式

时间（UTC）

地位

描述

11:05

普通的。

数据库访问控制变更已部署。

11:28

冲击开始。

部署到达客户环境后，在客户 HTTP 流量中首次发现错误。

11:32-13:05

该团队调查了 Workers KV 服务流量异常增加和故障情况。

最初的症状似乎是 Workers KV 响应速率下降，导致对其他 Cloudflare 服务产生下游影响。 为了使 Workers KV 服务恢复到正常运行水平，我们尝试了流量控制和账户限制等缓解措施。 第一次自动化测试于 11:31 检测到问题，人工调查于 11:32 开始。事件报告于 11:35 创建。

13:05

已实施 Workers KV 和 Cloudflare Access 绕过措施——影响已降低。

调查期间，我们对 Workers KV 和 Cloudflare Access 使用了内部系统绕过机制，使其回退到我们核心代理的旧版本。虽然该问题在之前的代理版本中也存在，但影响较小，具体情况如下所述。

13:37

工作重点是将 Bot 管理配置文件回滚到最后一个已知良好的版本。

我们确信是机器人管理配置文件引发了此次事件。团队分多个工作流程开展工作，寻找修复服务的方法，其中最快的方案是恢复该文件的先前版本。

14:24

已停止创建和传播新的机器人管理配置文件。

我们发现 Bot Management 模块是导致 500 错误的根源，而这又是由错误的配置文件引起的。我们已停止自动部署新的 Bot Management 配置文件。

14:24

新文件测试完成。

我们观察到使用旧版本的配置文件可以成功恢复，然后集中精力加快全球修复速度。

14:30

主要影响已解决。下游受影响的服务开始出现错误减少的情况。

正确的机器人管理配置文件已在全球范围内部署，大多数服务开始正常运行。

17:06

所有服务已恢复正常。影响已结束。

所有下游服务已重启，所有操作已完全恢复。

官方事故报告

                                                           https://blog.cloudflare.com/18-november-2025-outage/


 Cloudflare System Status： https://www.cloudflarestatus.com/

1. 1. 出了啥事？ 在那天，Cloudflare的网络挂了，导致很多网站都访问不了，显示5xx错误。

2. 2. 为啥挂了？ 这次不是被黑客攻击了，而是他们自己的一个技术问题。起因是他们改了一个数据库的权限，结果导致一个给“机器人管理”系统用的配置文件大小翻了一倍。

3. 3. 技术细节： 他们系统里有个软件要读取这个配置文件，但是这个软件对文件大小有限制。结果这个超大的文件被推送到全网的服务器上，直接把软件干趴下了，然后就各种报错。

4. 4. 咋解决的？ 工程师们一开始还以为是DDoS攻击，后来才找到真正原因。他们停止了那个错误文件的分发，换上了旧的正常版本，然后重启了核心服务，网络才慢慢恢复正常。

这次 Cloudflare 的全球宕机，再次提醒我们：在分布式系统里，最危险的往往不是黑客，而是自己的一行配置。一个权限改动，就能让全球互联网瞬间失速。

对运维和架构团队来说，最大的反思是——配置要当代码管，熔断要随时可用，监控要能分辨“自己人”。只有这样，才能避免下一次“史诗级事故”重演。

互联网的脆弱性在这一天被放大，但也让我们更清楚：稳定不是理所当然，而是每一次谨慎改动、每一道防线共同守护的结果。