Cloudflare 2025年11月18日重大故障分析：Bot Management 配置文件引发的全球性中断

2025年11月18日，全球领先的 CDN 和网络安全服务提供商 Cloudflare 发生了自2019年以来最严重的一次服务中断。此次故障持续近6小时，导致大量依赖 Cloudflare 服务的网站和应用无法正常访问，影响了全球数百万互联网用户。本文将深入分析这次故障的技术细节、影响范围以及带来的重要启示。

事件概览

关键时间线（UTC时间）

11月18日完整事件时间线：

11:05 - 正常运行，ClickHouse 数据库访问控制变更部署
11:28 - 影响开始，变更到达客户环境，HTTP 流量开始出现错误
11:31 - 首个自动化测试检测到问题
11:32 - 人工调查开始
11:35 - 创建事件响应电话会议
11:32-13:05 - 团队调查 Workers KV 服务流量和错误率升高问题
13:05 - Workers KV 和 Cloudflare Access 实施绕过方案，影响减轻
13:37 - 工作重点转向回滚 Bot Management 配置文件到已知良好版本
14:24 - 停止创建和传播新的 Bot Management 配置文件
14:24 - 新配置文件测试完成
14:30 - 主要影响解决，下游受影响服务开始观察到错误减少
17:06 - 所有服务解决，影响结束

总持续时间：约5小时38分钟 严重影响时间：约3小时（11:28-14:30）

故障根本原因分析

技术架构背景

Cloudflare 的请求处理流程：

用户请求
    ↓
HTTP/TLS 终止层
    ↓
核心代理系统（FL/FL2）
    ↓
Pingora（缓存查询/源站获取）

在核心代理系统中运行着各种安全和性能产品，包括 WAF、DDoS 防护、Bot Management 等模块。

故障触发链条

第一步：ClickHouse 权限变更

为了改善分布式查询的安全性和可靠性，Cloudflare 团队在 11:05 对 ClickHouse 数据库系统进行了权限配置变更：

变更前：用户只能看到 default 数据库中的表元数据
变更后：用户可以看到底层 r0 数据库中的表元数据

这个变更的目的是让分布式子查询在初始用户权限下运行，从而实现更细粒度的查询限制和访问授权控制。

第二步：查询行为改变

Bot Management 系统使用以下 SQL 查询来生成特征配置文件：

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

关键问题：这个查询没有过滤数据库名称！

变更前：只返回 default 数据库中的列（约60个特征）
变更后：同时返回 default 和 r0 数据库中的列（超过200个特征）

这导致特征配置文件中出现大量重复的特征行，文件大小翻倍。

第三步：内存预分配限制触发

核心代理的 Bot Management 模块为性能优化进行了内存预分配，设置了特征数量上限为 200个（当前实际使用约60个）。

当包含200+特征的配置文件传播到服务器时，触发了以下 Rust 代码中的检查：

// FL2 Rust 代码中的检查逻辑
if features.len() > MAX_FEATURES {
    panic!("Feature count exceeds limit");
}

这导致了未处理的 panic，进而返回 HTTP 5xx 错误。

第四步：配置文件传播机制

Bot Management 特征配置文件每5分钟生成一次，并快速传播到全球网络。

由于 ClickHouse 集群正在逐步更新权限配置：

查询运行在已更新节点：生成错误配置文件
查询运行在未更新节点：生成正常配置文件

这导致系统每5分钟有概率生成好或坏的配置文件，造成服务间歇性故障。

为什么初期以为是 DDoS 攻击？

误导性症状：

服务间歇性恢复和故障：符合波次攻击特征
状态页面也宕机：Cloudflare 状态页面（完全独立于 Cloudflare 基础设施）恰巧同时出现故障，这纯属巧合但让团队怀疑是协同攻击
近期背景：刚经历过 Aisuru 系列大规模 DDoS 攻击（7.3 Tbps 创纪录攻击）

内部聊天记录显示，团队一度认为这可能是针对 Cloudflare 系统和状态页面的双重攻击。

影响范围详细分析

受影响的核心服务

服务	影响描述
核心 CDN 和安全服务	返回 HTTP 5xx 状态码，用户看到典型的 Cloudflare 错误页面
Turnstile	人机验证服务加载失败
Workers KV	由于核心代理故障，KV 前端网关请求返回大量 5xx 错误
Dashboard	控制面板大部分功能正常，但由于 Turnstile 不可用，大多数用户无法登录
Email Security	邮件处理和投递未受影响，但 IP 信誉源暂时不可用，降低了垃圾邮件检测准确性
Access	大多数用户认证失败（11:28-13:05），现有会话未受影响，失败的认证尝试都显示错误页面

性能影响

除了 5xx 错误，还观察到 CDN 响应延迟显著增加：

原因：调试和可观测性系统消耗大量 CPU

这些系统会自动为未捕获的错误增强额外的调试信息
在大规模错误情况下，这些系统本身成为性能瓶颈

FL 和 FL2 代理的不同表现

Cloudflare 当时正在将客户流量迁移到新版代理服务（FL2）：

FL2（新版本）：

直接返回 HTTP 5xx 错误
用户完全无法访问

FL（旧版本）：

不返回错误，但 Bot 评分未正确生成
所有流量收到的 Bot 评分为 0
配置了阻止 Bot 规则的客户会看到大量误报
未使用 Bot 评分的客户没有影响

恢复过程技术细节

多工作流并行恢复

工作流 1：快速绕过（13:05 完成）

为 Workers KV 和 Cloudflare Access 实施内部系统绕过，让它们回退到旧版核心代理：

Workers KV → 绕过 FL2 → 使用 FL（旧版）
Access → 绕过 FL2 → 使用 FL（旧版）

虽然旧版本也存在问题，但影响较小（只是 Bot 评分错误而非服务不可用）。

工作流 2：配置文件回滚（14:30 完成）

停止生成（14:24）：停止自动生成和传播新的 Bot Management 配置文件
准备良好文件：从备份中获取已知良好的配置文件
手动注入：将良好文件手动插入特征文件分发队列
强制重启：强制重启核心代理

工作流 3：清理长尾问题（14:30-17:06）

重启进入错误状态的剩余服务，5xx 错误率逐步恢复正常。

Dashboard 过载问题

恢复特征配置数据后，出现了新的问题：

积压的登录尝试开始涌入 Dashboard
结合重试请求，导致延迟升高
通过扩展控制平面并发能力，在约15:30恢复可用性

对不同行业的影响

电商和在线零售

影响时段分析：

欧洲时段（12:28-15:30 CET）：
- 正值工作日午餐时段购物高峰
- 移动端购物流量受严重影响
- 结账流程中断率估计 70-80%

美国东部时段（06:28-09:30 EST）：
- 早晨购物时段
- 企业采购活动受影响
- B2B 交易延迟

亚洲时段（19:28-22:30 CST）：
- 晚间购物黄金时段
- 直播带货活动中断
- 用户投诉激增

损失估算：

大型电商平台：约 $800-1200 万
中小型电商：约 $300-500 万
长尾商家：难以统计但累计可观

广告投放和营销行业

直接影响：

实时竞价系统故障
- RTB 请求失败率 > 85%
- 出价响应超时
- 广告位填充率骤降
转化跟踪中断
- 像素追踪失败
- 归因数据丢失
- ROI 计算不准确
落地页不可用
- 托管在 Cloudflare Pages 的落地页完全不可用
- 通过 Cloudflare CDN 加速的页面返回错误
- 跳出率接近 100%
A/B 测试数据失真
- 测试期间数据缺失
- 样本分布不均
- 统计显著性受损

业务损失维度：

媒体采购成本浪费：
- 流量已购买但无法转化
- 预算消耗但无效果数据
- 估计浪费率 60-70%

品牌信誉损害：
- 用户体验差
- 投诉和负面反馈
- 长期品牌价值影响

数据完整性问题：
- 历史数据出现空白
- 趋势分析受影响
- 机器学习模型训练数据污染

SaaS 和企业应用

关键服务中断：

身份认证系统
- Cloudflare Access 故障
- 企业员工无法登录
- 远程办公受阻
API 服务
- API Gateway 不可用
- 第三方集成中断
- 自动化流程失败
实时协作工具
- WebSocket 连接失败
- 文档同步中断
- 团队协作效率下降

媒体和内容分发

流媒体服务：

视频加载失败
直播中断
用户流失

新闻网站：

页面加载缓慢或失败
广告收入损失
流量统计不准确

深度技术剖析

ClickHouse 分布式查询机制

架构理解：

ClickHouse 集群
│
├── 分布式表（default 数据库）
│   └── 表引擎：Distributed
│       └── 查询所有分片数据
│
└── 底层存储表（r0 数据库）
    └── 各分片实际存储数据

权限变更逻辑：

目标：让用户明确看到他们有权访问的所有表（包括 r0 中的底层表）
实现：在系统表查询中暴露 r0 数据库的元数据
副作用：未考虑到现有查询未按数据库名称过滤

防御性编程的缺失

问题代码模式：

// 不安全的假设
let features = load_features_from_file();
assert!(features.len() <= MAX_FEATURES); // 硬限制

// 应该的防御性处理
let features = load_features_from_file();
if features.len() > MAX_FEATURES {
    log_error("Feature count exceeds limit, truncating");
    features.truncate(MAX_FEATURES);
    // 或返回错误但不 panic
}

关键教训：

对外部输入（包括内部生成的配置文件）应该视为不可信
限制应该是软限制（警告+降级）而非硬限制（panic）
即使是内部数据也可能出错

配置传播的双刃剑

快速传播机制：

优势：

✅ 能快速响应新威胁
✅ 及时更新 Bot 检测策略
✅ 适应互联网流量变化

风险：

❌ 错误配置快速扩散
❌ 难以回滚
❌ 影响范围广

改进方向：

金丝雀部署：先在小范围测试新配置
配置验证：部署前进行严格的模式和限制检查
快速回滚机制：自动检测异常并回滚

监控和告警的局限性

为什么没有提前发现：

渐进式部署：ClickHouse 集群逐步更新，问题时有时无
间歇性故障：每5分钟可能产生好或坏的配置，难以捕捉模式
多重症状：Workers KV 错误掩盖了真正的根本原因
误导信号：状态页面巧合性故障导致攻击假设

监控盲区：

配置文件大小变化没有告警
特征数量突变没有预警
ClickHouse 查询结果集大小没有监控

企业应对策略

1. 依赖管理策略

评估 CDN 依赖风险：

风险评估矩阵：
┌─────────────────────────────────────┐
│ 高影响/高概率 → 优先处理             │
│ 高影响/低概率 → 准备应急预案          │
│ 低影响/高概率 → 持续监控             │
│ 低影响/低概率 → 接受风险             │
└─────────────────────────────────────┘

多 CDN 策略：

主 CDN: Cloudflare (60% 流量)
备用 CDN: Fastly/Akamai (30% 流量)
直连源站: 10% 流量（健康检查+应急）

实施要点：

DNS 级别的快速切换能力
自动故障检测和切换
定期测试备用路径

2. 关键资源自托管

不应依赖 CDN 的资源：

认证和授权
- 登录页面
- 验证码服务
- Session 管理
关键业务逻辑
- 支付处理
- 订单确认
- 核心 API
监控和告警
- 状态页面
- 告警系统
- 运维工具

3. 降级和容错设计

多级降级策略：

级别 1: 完全功能（正常状态）
    ↓ CDN 延迟增加
级别 2: 优化功能（减少非必要请求）
    ↓ CDN 部分不可用
级别 3: 核心功能（仅保留关键业务）
    ↓ CDN 完全不可用
级别 4: 静态内容（提示信息）

实施技术：

// 前端降级示例
async function loadResource(url) {
  try {
    // 尝试从 CDN 加载
    return await fetch(cdnUrl(url), { timeout: 2000 });
  } catch (cdnError) {
    // CDN 失败，回退到源站
    try {
      return await fetch(originUrl(url), { timeout: 5000 });
    } catch (originError) {
      // 使用本地缓存或显示降级内容
      return getCachedResource(url) || getDegradedContent();
    }
  }
}

4. 监控和响应体系

外部监控必不可少：

监控维度：
├── 可用性监控（多地域探测）
├── 性能监控（响应时间、错误率）
├── 业务监控（转化率、收入）
└── 用户体验监控（真实用户监测）

告警分级：

级别	响应时间	通知方式	示例
P0 - 紧急	< 5分钟	电话 + 短信 + IM	核心服务完全不可用
P1 - 严重	< 15分钟	短信 + IM	错误率 > 10%
P2 - 重要	< 1小时	IM + 邮件	延迟增加 50%
P3 - 一般	< 4小时	邮件	非核心功能异常

5. 应急响应流程

标准操作程序（SOP）：

1. 检测阶段（0-5分钟）
   - 自动监控告警触发
   - 初步验证影响范围
   - 启动事件响应

2. 评估阶段（5-15分钟）
   - 确定受影响的服务
   - 评估业务影响程度
   - 决定响应级别

3. 响应阶段（15分钟-2小时）
   - 执行预定义的应急预案
   - 实施流量切换或降级
   - 持续监控恢复进度

4. 恢复阶段（2-8小时）
   - 逐步恢复完整功能
   - 验证系统稳定性
   - 客户沟通和服务补偿

5. 复盘阶段（1-2周）
   - 撰写详细的事后报告
   - 识别系统改进点
   - 更新应急预案

Cloudflare 的改进计划

根据官方博客，Cloudflare 正在采取以下措施：

1. 配置文件处理加固

验证机制：对 Cloudflare 生成的配置文件像对待用户输入一样进行严格验证
模式检查：在分发前检查配置文件是否符合预期模式
大小限制：监控配置文件大小变化，超过阈值时告警

2. 全局紧急开关

功能级开关：为每个模块提供全局紧急关闭能力
快速响应：在检测到问题时能立即禁用有问题的功能
隔离影响：防止单个模块故障影响整个系统

3. 资源管理优化

错误处理优化：消除核心转储和错误报告压垮系统资源的可能性
CPU 配额：为调试和可观测性系统设置 CPU 使用上限
优先级调度：确保关键功能优先获得资源

4. 故障模式审查

全面审查：检查所有核心代理模块的错误处理逻辑
防御性编程：将硬失败（panic）改为软失败（降级）
模糊测试：增加对异常输入的测试覆盖

5. 部署流程改进

金丝雀部署：

阶段 1: 单个数据中心（1%）→ 监控 30 分钟
阶段 2: 单个区域（5%）→ 监控 1 小时
阶段 3: 多个区域（20%）→ 监控 2 小时
阶段 4: 全球部署（100%）→ 持续监控

自动回滚：

错误率阈值触发
延迟增加触发
人工干预

行业启示

1. 基础设施供应商的责任

Cloudflare CEO Matthew Prince 的致歉：

“今天是 Cloudflare 自2019年以来最严重的故障。像今天这样的故障是不可接受的。我们已经构建了高度弹性的系统来确保流量始终能够流动。过去每次故障都促使我们构建新的、更有韧性的系统。”

行业标准提升：

透明的事后报告
详细的技术分析
明确的改进计划

2. 复杂系统的脆弱性

连锁反应：

数据库权限变更（看似无害）
    ↓
SQL 查询返回重复数据（未预料）
    ↓
配置文件大小翻倍（未监控）
    ↓
内存限制触发（硬限制）
    ↓
核心代理 panic（未降级）
    ↓
全球服务中断（灾难性）

关键教训：

看似无关的变更可能产生意外后果
需要全链路的测试和验证
防御性编程至关重要

3. 监控的重要性

多维度监控需求：

基础设施层：
- 数据库查询性能
- 配置文件大小
- 系统资源使用

应用层：
- 错误率和错误类型
- 响应时间分布
- 功能可用性

业务层：
- 流量模式
- 转化率
- 用户体验指标

4. 测试的局限性

为什么测试没有发现问题：

单元测试通过：代码逻辑正确
集成测试通过：模块间交互正常
性能测试通过：使用预期大小的配置文件

缺失的测试：

异常输入测试：超大配置文件
边界值测试：接近/超过限制
混沌工程：故意注入错误

5. 文化和流程

事后不责备文化：

鼓励透明地分享失败经验
关注系统改进而非个人责任
从错误中学习和成长

持续改进机制：

定期的灾难演练
故障注入测试
事后复盘和行动项跟踪

对广告投放行业的特别建议

架构设计

关键资源独立部署：

广告投放系统架构：
├── 竞价引擎（自托管，低延迟）
├── 追踪系统（多 CDN，高可用）
├── 落地页（多 CDN + 源站直连）
├── 数据分析（离线 + 实时双轨）
└── 管理后台（独立部署，不依赖 CDN）

CDN 选择策略：

静态资源：Cloudflare（性价比高）
动态内容：Fastly（边缘计算能力强）
视频内容：专用视频 CDN
关键 API：不经过 CDN 或使用专用线路

监控和告警

广告特定指标：

实时监控：
- 竞价请求成功率
- 广告展示率
- 点击转化率
- 落地页加载时间

告警阈值：
- 竞价成功率 < 95% → P1 告警
- 落地页错误率 > 5% → P0 告警
- 转化追踪失败率 > 10% → P1 告警

应急预案

广告投放应急响应：

场景 1: CDN 完全不可用
→ 自动切换到备用 CDN
→ 调整出价策略（补偿延迟）
→ 通知客户并提供替代方案

场景 2: 追踪系统故障
→ 启用备用追踪服务
→ 记录原始日志用于事后归因
→ 暂停依赖实时数据的自动优化

场景 3: 落地页不可用
→ 切换到备用落地页
→ 调整流量分配
→ 考虑暂停相关广告活动

数据完整性保护

多层数据备份：

实时层（Redis）：最近 1 小时数据
    ↓ 每 5 分钟同步
热存储（MySQL）：最近 7 天数据
    ↓ 每小时归档
冷存储（S3）：历史全量数据
    ↓ 跨区域复制
灾备存储（Glacier）：长期保留

数据一致性验证：

定期校验各层数据一致性
发现差异时自动告警
保留原始日志用于事后重建

总结与展望

关键要点回顾

看似简单的变更可能产生灾难性后果
- ClickHouse 权限变更看似合理，却引发全球性故障
- 需要更全面的影响分析和测试
防御性编程至关重要
- 不要对任何输入（包括内部生成的数据）做假设
- 软失败（降级）优于硬失败（panic）
快速传播是双刃剑
- 能快速响应威胁，也能快速传播错误
- 需要金丝雀部署和自动回滚机制
监控需要全方位覆盖
- 不仅要监控最终症状，还要监控中间状态
- 配置文件大小变化应该有告警
多云和多供应商策略的价值
- 单点依赖风险巨大
- 备用方案不仅要有，还要定期测试

对未来的影响

技术演进方向：

更智能的故障检测
- 基于 AI 的异常检测
- 预测性维护
- 自动根因分析
更快的恢复能力
- 秒级故障检测
- 分钟级自动回滚
- 小时级完全恢复
更好的隔离机制
- 模块级故障隔离
- 租户级资源隔离
- 地域级独立性
更强的韧性设计
- 混沌工程常态化
- 故障注入测试
- 灾难演练自动化

最后的思考

这次 Cloudflare 故障再次提醒我们：

没有系统是完美的，故障是常态而非例外。

关键不在于完全避免故障（这不现实），而在于：

快速检测问题
迅速响应和恢复
持续学习和改进
透明地与用户沟通

对于依赖 Cloudflare 或任何基础设施服务的企业：

不要盲目相信”99.99%“的 SLA
准备好应对”0.01%“的故障场景
投资于冗余和应急能力
将韧性作为核心竞争力

正如 Cloudflare 在博客中所说：

“An outage like today is unacceptable. We’ve architected our systems to be highly resilient to failure to ensure traffic will always continue to flow. When we’ve had outages in the past it’s always led to us building new, more resilient systems.”

让我们共同期待一个更加可靠和韧性的互联网未来。

参考资料

Cloudflare 官方博客：https://blog.cloudflare.com/18-november-2025-outage/
事件时间：2025年11月18日 11:20-17:06 UTC
影响范围：全球 Cloudflare 网络
根本原因：ClickHouse 数据库权限变更导致 Bot Management 配置文件异常

本文基于 Cloudflare 官方事后报告深度分析，旨在为技术团队提供故障分析和系统设计参考。关注我们获取更多云服务和基础设施可靠性分析。