Sukka 写前端、网络和基础设施时，习惯先把边界和代价摊开。把「[翻译] Cloudflare 在 2019 年 7 月 2 日宕机的技术细节 | Sukka's Blog」整理成可落地的中文笔记：问题在哪、默认做法会踩什么坑、该怎么选。原站导航和广告已去掉。

7 月 2 日事故的回顾

原文标题：Details of the Cloudflare outage on July 2, 2019 原文作者： John Graham-Cumming 原文链接 https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/ 本文由 Sukka 翻译，首发于 Sukka’s Blog

差不多九年前，在 Cloudflare 成立一个月后。那时候 Cloudflare 还是一家规模很小的网络公司，我还是 Cloudflare 的客户、不是 Cloudflare 的员工，有一天告警系统警告我说我的网站 jgc.org 的权威 DNS 下线了。Cloudflare 刚刚开始使用 Protocol Buffer ，结果搞砸了 DNS。

都发生了些什么

我直接就给 Matthew Prince（译者注：Cloudflare 的联合创始人、首席执行官）发了一封「我的 DNS 怎么不见了？」的电子邮件。他回复了一封 非常详细的、技术性的回复 。于是我给他回信：

From: John Graham-Cumming Date: Thu, Oct 7, 2010 at 9:14 AM Subject: Re: Where's my dns? To: Matthew Prince Awesome report, thanks. I'll make sure to call you if there's a problem. At some point it would probably be good to write this up as a blog post when you have all the technical details because I think people really appreciate openness and honesty about these things. Especially if you couple it with charts showing your post launch traffic increase. I

Cloudflare 内部的运营和管理机制

From: Matthew Prince Date: Thu, Oct 7, 2010 at 9:57 AM Subject: Re: Where's my dns? To: John Graham-Cumming Thanks. We've written back to everyone who wrote in. I'm headed in to the office now and we'll put something on the blog or pin an official post to the top of our bulletin board system. I agree 100% transparency is best. 译者注：这封信是 Matthew Prince 的回信，大意是 Cloudflare 会回复每一封邮件并认为开诚布公是不可或缺的。

如今，作为规模已经不可同日而语的 Cloudflare 的员工，现在轮到我成为那个写作的人，开诚布公描述我们犯下的错误、造成的影响、和我们是如何解决问题的。

WAF 威胁

在 Cloudflare，我们不断的改进 Cloudflare 管理的 WAF 规则集来应对不断出现的漏洞和威胁。比如两个月前，我们迅速 发布了一条用于防御 SharePoint 高危漏洞的规则 。Cloudflare WAF 的特征就是能够快速地在全球部署和更新。

在 7 月 2 日，我们在 Cloudflare 管理的 WAF 规则集中部署了一条新的规则。不幸的是，这个规则中包括了一个需要大量回溯查询的正则表达式，导致 Cloudflare 全球网络中负责处理 HTTP/HTTPS 流量的 CPU 性能冗余迅速地耗尽 。这直接瘫痪了 Cloudflare 核心代理功能、CDN 缓存功能和 WAF 防御功能。 下图显示了负责处理 HTTP/HTTPS 流量的 CPU，这些 CPU 的使用率一度达到 100%。

QuickSilver

这导致我们的客户的网站的访客会看到 502 错误页面。这个 502 页面是由前置的 Cloudflare Web Server 生成的。分配给 Cloudflare Web Server 的 CPU 核心仍然可用，但是他们无法获得后端的 HTTP/HTTPS 流量。

我们知道这对我们的客户的严重影响，我们对此感到非常羞愧。甚至在我们处理这一事故时，我们的修复操作甚至影响了我们自己内部的运营系统。

什么地方出了问题？

如果您是我们的客户，那么这一次事故将会是令人沮丧、导致难以置信的压力和灾难性的后果。对于我们来说，更令人沮丧的是我们已经 连续六年没有发生过这种全球性的宕机事故 了。

译者注：2013 年，Cloudflare 一条错误的 DDoS 流量清洗规则导致所有边界路由器宕机，进而导致 Cloudflare 的路由宣告中断、Cloudflare 从互联网上脱离。

值得单独记下的点

• 在之前对 WAF 重构的时候，错误地删除了一个保护 CPU 不被过度使用的保护机制
• 正在使用的正则表达式引擎不能保证在复杂的表达式下的可靠性
• 我们针对 WAF 的标准操作流程允许 WAF 规则变动快速部署到生产环境、即使这个变动并没有那么紧急可以进行阶段测试
• 由于 WAF 宕机，我们甚至无法访问我们的内部系统
• 我们的客户无法通访问操作面板或者 API，因为这些东西被部署在同一套服务上
• 重新引入被删除的 WAF CPU 保护模块（已完成）
• 手动检查 Cloudflare 现有的 3868 条规则，查找可能存在的过度回溯（已完成）
• 切换到使用 re2 或者 Rust 的正则表达式引擎（预计在 7 月 31 日之前完成）

落地时建议先做的 5 件事

1. 用自己的流量和设备测，不要只抄厂商推荐最小配置。
2. DNS、CDN、代理分流先画清 Fake IP 和 Real IP 的边界。
3. 前端性能看 CLS、白屏和重复渲染，而不是只看打包体积。
4. 基础设施变更走 Git，能复现、能回滚。
5. 结论写成可检查的清单：接口、超时、失败样本、回滚版本。

和智能体产品怎么接

龙虾PRO做 OpenClaw 落地时，网络、DNS 和前端性能笔记最有用的是「边界」：哪一层该加速、哪一层不该假装智能。数字员工调用外部能力前，先把超时和失败路径写死。

本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源