摘要
2026 年 9 月 8 日上午（ET），Cloudflare 发生全球范围中断，大量客户网站出现 5xx 错误，并波及其自身 Dashboard、API、CAPTCHA/Turnstile、WARP 等控制面。CTO Dane Knecht 与 CEO Matthew Prince 公开致歉，称这是「2019 年以来最严重」的一次。根因为一次例行配置变更触发了 Bot Management 底层服务中的潜在 bug，生成超大 feature file 并分发全网，导致流量路由软件触及大小上限而失败。Cloudflare 起初怀疑 DDoS，后排除攻击。约 09:40 ET 实施修复，当日大体恢复。
时间线
2026-09-08 ~08:00 ETCloudflare 检测到影响多客户的「大范围 5xx 错误」，Dashboard 与 API 同时故障
2026-09-08 早工程团队定位问题并实施针对性 workaround 与回滚，停止问题文件继续传播
2026-09-08 09:40 ET修复实施，服务开始恢复
2026-09-08 当日大多数服务恢复，部分客户仍可能遇到 Dashboard 登录等残留问题，持续监控
根因
一次例行的配置变更触发了 Cloudflare Bot Management 底层服务中的一个潜在 bug。该 bug 使 Bot Management 生成了一份包含重复条目、体积约为正常两倍的 feature file，并被分发到 Cloudflare 全球网络。流量路由软件在处理该文件时触及大小上限并失败，导致 proxy 无法交付核心流量，返回大范围 5xx。问题表现为类似大规模 DDoS 的故障特征，但 Cloudflare 事后排除任何攻击或恶意行为。
放大因素
- 变更触发的缺陷位于 Bot Management 这一广泛依赖的基础服务，影响面覆盖全网 edge 与路由层。
- 超大的 feature file 被自动分发到全球节点，故障随传播迅速放大。
- Cloudflare 自身的控制面（Dashboard/API/Turnstile/WARP）也依赖同一套边缘，导致运维与客户的「观察-处置」闭环同时受损。
缓解措施
- 检测到异常后，工程团队实施针对性 workaround 与配置回滚，停止问题文件继续传播。
- 修复后恢复服务并持续监控残留错误。
- CEO 承诺发布详细技术 postmortem 并落实防复发措施。
- 初期误判为 DDoS，但通过调查快速排除攻击，避免误伤正常流量。
经验教训
- 全局下发的配置/特征文件必须设置体积与条目数硬上限，并在边缘节点做「超限即拒绝加载」的熔断。
- 底层安全/ bot 服务应与其他控制面解耦，避免单点故障同时瘫痪运维通道。
- 例行配置变更需走渐进式灰度与自动回滚，降低「一次变更打满全网」的爆炸半径。
- 故障特征与 DDoS 相似时，应以数据快速鉴别（如内部传播路径），避免误判。
检查清单
- 全局下发的 feature/file 是否设体积与条目硬上限 + 边缘熔断
- 底层安全服务与运维控制面是否解耦、互不雪崩
- 配置变更是否强制灰度发布 + 自动回滚
- 是否建立「类 DDoS 症状 ≠ 攻击」的快速鉴别流程
- 是否对重大中断的公开 postmortem 与防复发项做闭环跟踪