跳到主要内容

Cloudflare 2025 年 11 月 18 日严重故障总结

这是一个关于 Cloudflare 2025 年 11 月 18 日严重故障的总结，以及针对用户方（运维人员）的应对措施建议。

一、事故总结 (Executive Summary)​

  • 时间： 2025 年 11 月 18 日 11:20 UTC - 17:06 UTC (核心影响约 3 小时)。
  • 现象： 全球范围内的 Cloudflare 网络出现大量 HTTP 5xx 错误，导致核心 CDN 服务、Turnstile（验证码）、Workers KV、Dashboard 登录及 Access 认证服务不可用。甚至 Cloudflare 自己的状态页（Status Page）也因巧合一度无法访问。
  • 根本原因 (Root Cause):
    • 非网络攻击： 官方确认与 DDoS 或黑客攻击无关。
    • 数据库变更引发连锁反应： 对 ClickHouse 数据库的一次权限变更，导致某个用于生成“Bot 管理功能文件”的查询语句意外返回了底层数据库的元数据，造成查询结果包含大量重复行。
    • 配置文件膨胀： 包含重复数据的“功能文件”大小翻倍，并下发到了全球边缘节点。
    • 代码崩溃 (Panic): 边缘节点运行的 Rust 代码（新版 FL2 代理引擎）预设了内存分配上限（硬编码限制），超出大小的文件导致系统 panic（崩溃）并抛出未处理的异常，进而导致服务无法处理请求并返回 5xx 错误。
  • 解决： 停止下发错误文件，回滚到旧版本文件，并重启核心代理服务。

二、用户方运维应对措施清单 (Checklist)​

作为依赖 Cloudflare 的用户，面对此类基础设施级别的“黑天鹅”事件，完全避免极其困难，但可以通过架构设计和应急预案来降低影响。

以下是按优先级 (P0-P3) 排序的行动清单：

P0: 监控与感知 (尽早发现问题)​

在此类事故中，官方状态页可能挂掉或更新滞后，依靠自身监控至关重要。

  • 部署第三方合成监控 (Synthetic Monitoring):
    • 使用与 Cloudflare 无关 的外部监控服务（如 Datadog, ThousandEyes, Pingdom, UptimeRobot）。
    • 关键点： 必须配置检查返回的状态码（不仅仅是 ping 通），报警规则应包含“连续 N 次返回 5xx 错误”。
  • 端到端业务监控：
    • 不仅仅监控首页，还要监控API 接口和关键流程（如登录接口、验证码加载）。本次事故中，Turnstile 挂了导致很多人无法登录，单纯监控静态页面可能无法发现业务瘫痪。
  • 关注第三方情报源：
    • 订阅 DownDetector、Hacker News、Twitter (X) 上的运维圈子 tag。往往在官方承认故障前，社区已经炸锅。

P1: 架构与预案 (核心避险手段)​

这是决定你是否能在 CF 挂掉时“逃生”的基础。

  • 评估接入方式 (CNAME vs NS):
    • CNAME 接入 (推荐商业版以上): 如果资金允许，使用 CNAME 方式接入 Cloudflare（即 DNS 托管在 AWS Route53 或阿里云，只把 www CNAME 到 CF）。
      • 优势: 故障时，修改 DNS 指向源站或其他 CDN，可以绕过 CF。
    • NS 接入 (免费/Pro 版常见): 如果 DNS 托管在 CF，故障时你基本束手无策（修改 NS 生效极慢）。
  • 准备“逃生”DNS 记录：
    • 如果使用 CNAME 接入，提前在 DNS 服务商处准备好指向源站 IP 或 备用 CDN 的记录，并设置较短的 TTL (如 60s - 300s)，以便快速切换。
  • 降级策略 (Failover):
    • 前端代码应具备容错性。例如，如果 Turnstile (验证码) 加载超时或失败，是否允许用户“降级”通过（Fail Open）或切换到传统的图片验证码？
    • 静态资源若加载失败，是否有备用域名（Domain Sharding）？

P2: 故障时的应急操作 (止损)​

当监控报警，且确认为 CF 故障时：

  • 尝试“灰云” (Grey-clouding):
    • 如果你还能访问 CF Dashboard 或 API，尝试将关键域名的代理状态从“橙云（代理）”改为“灰云（仅 DNS）”。这将直连源站，恢复访问。
    • 风险提示: 这会暴露源站真实 IP，可能面临 DDoS 风险。需评估风险收益比。
  • DNS 切流 (如果架构支持):
    • 执行 P1 中准备的 DNS 切换，将流量切到备用 CDN 或源站。
  • 启用独立状态页：
    • 确保你的业务状态页（Status Page）不托管在主业务使用的 CDN（Cloudflare）后。建议托管在 Notion、独立 S3 bucket 或专门的 Status 服务商上，用于第一时间告知用户“我们要挂一会，不是由于我们代码的问题”。

P3: 事后加固 (长期优化)​

  • 多 CDN 策略 (Multi-CDN):
    • 对于超大型业务，实施多 CDN 负载均衡（通过 DNS 策略根据可用性分配流量）。这是解决单一家供应商故障的终极方案，但成本和维护复杂度较高。
  • 源站保护回顾：
    • 如果故障期间你切换到了直连源站，事后记得更换源站 IP（如果担心 IP 泄露被后续攻击）。

总结建议​

对于本次 Cloudflare 这种由于核心代码逻辑崩坏导致的全局故障，最有效的手段是“拥有快速切走流量的能力”（即不把 DNS 锁死在 Cloudflare 上）。对于中小型用户，如果无法承担多 CDN 成本，最务实的做法是：外部监控报警 + 独立的 DNS 托管 + 紧急切回源站的预案。