Cloudflare 全球网络宕机

11 月 18 日（UTC）晚间，如果你刷 X、打开 ChatGPT 或各种网站时，突然看到一片 5xx / “Internal Server Error”，背后其实是同一个原因 —— 全球最大的网络基础设施服务商之一 Cloudflare 出了问题。
这次事故波及了 X、ChatGPT、Spotify、Canva、Uber、Downdetector 以及多家媒体和电商网站。考虑到 Cloudflare 覆盖了大约 20% 的全球 Web 流量，一次故障的影响范围可想而知。

事件时间线（UTC）

截止到本文发布时，全球服务整体已恢复正常，Cloudflare 仍在监控相关指标。

下表整理自 Cloudflare 官方状态页，方便对照 UTC 与北京时间来回顾这次事故的处理过程：

时间（UTC） | 北京时间（CST, UTC+8） | 阶段 / 状态 | 官方内容要点
11:48 | 19:48 | Investigating | Cloudflare 报告内部服务退化，一些服务间歇性受影响，优先恢复对客户可见的核心功能。
12:03 | 20:03 | Update | 继续排查问题，确认影响范围。
12:21 | 20:21 | Update | 观察到部分服务开始恢复，但客户仍可能看到高于正常的错误率，工程团队持续修复。
12:37 | 20:37 | Update | 仍在定位具体原因与受影响组件。
12:53 | 20:53 | Update | 继续排查同一问题，暂无新的结论。
13:04 | 21:04 | Update | 为缓解问题，暂时禁用了伦敦地区的 WARP 访问，伦敦区域通过 WARP 上网的用户会遇到连接失败。
13:09 | 21:09 | Identified | 已定位到问题原因，开始实施修复方案。
13:13 | 21:13 | Update | 已推送部分变更，Cloudflare Access 和 WARP 已恢复，错误率回到故障前水平；伦敦 WARP 访问重新启用。
13:35 | 21:35 | Update | 持续推进 Application Services（应用服务）客户的恢复工作。
13:58 | 21:58 | Update | 继续推进应用服务客户的服务恢复工作。
14:22 | 22:22 | Update | 修复进入收尾阶段，关注残余影响。
14:34 | 22:34 | Update | 已部署新一轮变更，控制台（Dashboard）基本恢复，但广泛的应用服务影响仍在修复中。
14:42 | 22:42 | Monitoring | 官方认为事件已得到解决，进入监控阶段，确保所有服务恢复到正常水平。

从时间线可以看到，这次故障从首次「承认有问题」到进入 Monitoring，差不多持续了三小时左右，中间经历了几个典型阶段：发现异常 → 局部缓解（限流 / 关闭部分区域服务）→ 找到根因 → 大范围推送变更 → 宣布恢复并进入监控。

波及范围

从各大媒体报道和用户监控平台（如 Downdetector）的数据来看，这次宕机几乎把互联网按下了几分钟的 “暂停键”：

社交 & 内容：X（原 Twitter）、部分新闻网站（如 Axios、Politico）等

AI 产品：ChatGPT、Claude、Perplexity 等多家大模型服务

在线工具与生产力：Canva、Spotify、Zoom、Microsoft Teams 等

出行与公共服务：Uber、NJ Transit 官方网站及应用等

一个比较戏剧性的情节是：就连平时大家用来确认 “到底谁挂了” 的 Downdetector，也被一起干趴下了。

事故原因

目前 Cloudflare 给出的公开说法大致可以归纳为两点（参考 Ars Technica）：

内部服务退化（internal service degradation）
也就是 Cloudflare 自身某些内部组件表现异常，进而影响到了通过其网络转发的用户流量和控制平面（Dashboard / API）。

异常流量激增（a spike in unusual traffic）
Cloudflare 对媒体表示，检测到某一服务上出现了 “异常流量激增”，从而导致部分流量在网络中转时出现错误。具体是配置错误、软件 Bug 还是其他原因，目前尚未公开详细 root cause。

站在架构的角度，可以简单这样理解：

Cloudflare 夹在「用户」和「源站服务器」之间，负责 DNS 解析、缓存、DDoS 防护、WAF 规则、访问挑战页（如 challenges.cloudflare.com）等；

一旦这些 “中间层” 出现问题，即便你的源站是健康的，用户看到的也会是各种 5xx 错误、页面卡住、Dashboard 打不开 —— 这次事件就是一个典型例子。

对开发者

如果你是开发者、运维或在做架构设计，这次事件值得做一点 “事故后的反思”：

先问一句：是不是 “整个互联网” 都怪怪的？”
同时打不开好几个大站（比如 X、ChatGPT、Spotify）时，很可能不是你的服务器出了问题，而是类似 Cloudflare / AWS 这类基础设施出了问题。

看一眼状态页或第三方监控

Cloudflare 官方状态页：https://www.cloudflarestatus.com（Cloudflare 状态）

Cloudflare Radar 中断中心：可以看到各地区的异常流量与中断情况。（Cloudflare Radar）

类似 Downdetector 这类站点也能从侧面验证是否为大规模故障。（downdetector.com）

别急着重装系统 / 换 VPN
这类全球性的基础设施故障通常持续时间相对较短（级别在几十分钟到数小时），多数场景下只需要等服务提供商恢复即可。

结语

这次 Cloudflare 全球网络宕机，从时间上看不算 “史诗级长时间故障”，但影响面绝对够大：从社交媒体、AI 聊天，到音乐、出行、在线办公，几乎所有你日常会点开的互联网角落都被它顺手按了个暂停键。

对普通用户来说，这类事件是一次 “科普”：

原来我们以为彼此独立的网站，背后其实绑在同一根 “网线” 上。

对开发者来说，它更像是一堂现实世界里的架构课：

把所有关键流量交给同一家基础设施供应商，是效率，也是风险。

如果你还想顺着这次事件继续读一点英文报道，下面几篇可以作为延伸阅读（技术 + 新闻视角都有）：

The Verge

Reuters

卫报

纽约邮报

The Times of India

此文由 Mix Space 同步更新至 xLog
原始链接为 https://blog.astrasolis.top/posts/info/cloudflare-networkoutage