Cloudflare的宕机影响有多大

2025 年 11 月 18 日，互联网经历了近年来最严重的一次中断。Cloudflare——这个承载着全球约 20% 网站流量的基础设施巨头——发生了长达近 6 小时的全球性宕机，影响了约 24 亿月活用户。

这是 Cloudflare 自 2019 年以来最严重的一次故障。

📊 影响范围#

当 Cloudflare 打喷嚏，整个互联网都会感冒。

受影响的主要服务#

服务	月活用户
ChatGPT	7 亿
Spotify	7.13 亿
X (Twitter)	5.57 亿
Canva	2.4 亿
Discord	2 亿
Claude	1900 万
Figma	1300 万

此外还有 DigitalOcean、Medium、1Password、Trello、Namecheap、Postman、Vercel 等无数平台受到波及。

Cloudflare 自身服务影响#

核心 CDN 和安全服务：返回 HTTP 5xx 错误
Turnstile：验证码服务完全失效
Workers KV：大量 500 错误
Cloudflare Access：认证服务中断
Dashboard：大部分用户无法登录
Email Security：IP 信誉源暂时丢失

⏱️ 事件时间线#

以下时间均为 UTC 时间（北京时间 +8 小时）：

时间 (UTC)	事件
11:05	数据库访问控制变更部署
11:20	故障开始，网络流量出现大规模失败
11:28	首批 HTTP 错误出现
11:31	自动监控检测到问题
11:32	人工调查开始
11:35	创建事故响应通道，工程团队集结
11:32-13:05	团队尝试各种缓解措施，最初误判为 DDoS 攻击
13:05	Workers KV 和 Access 实施绕过方案，影响减轻
13:37	确认根本原因：Bot Management 配置文件翻倍
14:24	停止自动部署新的配置文件
14:30	部署正确的配置文件，主要影响解除
17:06	所有系统完全恢复正常

总故障时长：约 5 小时 46 分钟

🔍 根本原因分析#

这不是网络攻击#

Cloudflare 明确表示，这次故障不是由网络攻击或任何恶意活动引起的。

真正的原因：一个数据库权限变更#

故障的根源是一个看似无害的数据库权限变更，引发了连锁反应：

1. ClickHouse 权限变更#

Cloudflare 使用 ClickHouse 作为分布式数据库。为了改进分布式查询的安全性，团队在 11:05 部署了一个权限变更，让用户能够看到底层 r0 数据库的表元数据。

2. 查询返回重复数据#

Bot Management 系统使用以下查询获取特征列表：

1
SELECT name, type
2
FROM system.columns
3
WHERE table = 'http_requests_features'
4
ORDER BY name;

问题在于：这个查询没有过滤数据库名称。

权限变更后，查询开始返回 default 和 r0 两个数据库的列，导致结果翻倍。

3. 配置文件超出限制#

Bot Management 的机器学习模型使用一个”特征文件”，正常情况下包含约 60 个特征，系统硬编码限制为 200 个。

当特征数量翻倍超过 200 后，代理软件触发了 panic：

1
thread fl2_worker_thread panicked: called Result::unwrap() on an Err value

4. 全球传播#

这个错误的配置文件被快速传播到 Cloudflare 全球 300+ 个数据中心的所有机器，导致核心代理服务崩溃。

为什么故障是间歇性的？#

一个有趣的现象是：故障初期，服务会短暂恢复然后再次失败。

原因是配置文件每 5 分钟重新生成一次，而 ClickHouse 集群是逐步更新的。只有当查询命中已更新的节点时才会生成错误文件。所以每 5 分钟都是一次”抽奖”——可能生成好文件，也可能生成坏文件。

这种间歇性让团队最初误以为是 DDoS 攻击。

雪上加霜：状态页也挂了#

更让人困惑的是，Cloudflare 的状态页（托管在完全独立的基础设施上）恰好在同一时间也出现了问题。这纯属巧合，但让团队一度怀疑是有针对性的攻击。

💰 经济损失估算#

根据保守估计，这次宕机造成的直接收入损失约为 1.8 - 3.6 亿美元：

ChatGPT：约 2100 万美元
Spotify：约 1500 万美元
X：约 600 万美元
其他服务：数千万美元

这还不包括：

Cloudflare 的 SLA 赔偿
数百万中小网站的损失
电商平台的订单流失
品牌声誉损失

🛡️ Cloudflare 的改进措施#

Cloudflare CEO Matthew Prince 公开道歉：

“今天这样的宕机是不可接受的。我们的系统架构本应具有高度的故障恢复能力，确保流量始终能够正常流动。”

Cloudflare 宣布的改进措施包括：

配置文件验证：在多个层面强制执行大小限制和格式验证
改进错误处理：用优雅的错误处理替代 unwrap()，回退到已知良好的配置
全局紧急开关：允许工程师在几分钟内禁用全网功能，而不是几小时
可观测性系统优化：防止调试系统在故障期间消耗过多 CPU
动态内存分配：用软限制替代硬编码的 200 特征限制
数据库变更测试：要求对所有受影响的查询进行全面测试
渐进式发布策略：基础设施变更采用金丝雀部署和自动验证

🤔 反思：互联网的中心化风险#

这次事件暴露了现代互联网的一个严重问题：过度中心化。

Cloudflare 有多重要？#

全球约 20.5% 的网站使用 Cloudflare
反向代理市场份额约 81%
网络覆盖 300+ 城市
与 12,000+ 网络互联
可在 50ms 内触达全球 95% 的人口

当 ChatGPT、Spotify、X、Canva 这些完全不同的公司因为同一个供应商的故障而同时宕机时，我们不得不思考：

单点故障的风险是否被低估了？
企业是否应该采用多 CDN 策略？
监管机构是否应该将这类服务视为关键基础设施？

📝 给开发者的建议#

多 CDN 策略：配置 DNS 在多个 CDN 提供商之间分发流量
优雅降级：设计应用在 CDN 不可用时能回退到直连源站
独立监控：使用第三方监控服务，不要依赖 CDN 提供商的状态页
审查 SLA：确认 SLA 是否足以覆盖业务损失
定期演练：模拟 CDN 故障场景，验证应急方案

总结#

2025 年 11 月 18 日的 Cloudflare 宕机事件，起因是一个简单的数据库权限变更，却导致了近 6 小时的全球性互联网中断，影响了 24 亿用户。

这次事件再次提醒我们：在享受云服务便利的同时，也要警惕过度依赖单一供应商带来的系统性风险。

参考来源：

Cloudflare 官方事后分析

Pinggy 事件分析

TechCrunch 报道