小程序版
微信扫码，随时查命令
本文是公开报告的摘要与解读，事实以原始报告为准。
2020 年 7 月 17 日，Cloudflare 发生 27 分钟的中断。官方复盘《Cloudflare outage on July 17, 2020》记载，故障时间为 21:12 至 21:39 UTC，Cloudflare 的互联网资产和服务受影响，网络总流量下降约 50%。报告称影响“局限于特定地理区域”，其他位置的节点仍正常工作，并明确排除攻击或入侵。
这起事故常被概括为“DNS 故障”，但官方报告给出的是骨干网 BGP 配置错误，DNS 不是根因。事故发生在 Cloudflare 的私有骨干网上：工程师在处理纽瓦克（EWR）到芝加哥（ORD）的链路问题时，修改了亚特兰大（ATL）路由器的一条策略，本意是减少亚特兰大承载的部分骨干流量，实际却让该路由器向骨干对等体泄漏了全部 BGP 路由。携带更高 local-preference 的路由把各地流量吸向亚特兰大，亚特兰大被压垮，连接到骨干的多个位置随之中断。
报告没有给出受影响客户数量。可以确认的是，中断发生在多个具体节点，且属于 Cloudflare 自身网络配置问题，不是外部攻击，也不是 DNS 解析服务本身发生代码或数据故障。
以下时间均为 2020 年 7 月 17 日 UTC。
| 时间 | 事件 |
|---|---|
| 20:25 | 纽瓦克（EWR）与芝加哥（ORD）之间的骨干链路丢失；亚特兰大（ATL）与华盛顿（IAD）之间的骨干开始拥塞 |
| 21:12–21:39 | 亚特兰大吸引了来自整个骨干的流量，Cloudflare 资产与服务中断，持续 27 分钟 |
| 21:39–21:47 | 亚特兰大路由器被移出骨干，流量恢复正常 |
| 21:47–22:10 | 核心拥塞导致部分日志丢失，边缘网络继续运行 |
| 22:10 | 完全恢复，包括日志和指标 |
报告列出的受影响位置包括：圣何塞、达拉斯、西雅图、洛杉矶、芝加哥、华盛顿特区、里士满、纽瓦克、亚特兰大、伦敦、阿姆斯特丹、法兰克福、巴黎、斯德哥尔摩、莫斯科、圣彼得堡、圣保罗、库里蒂巴和阿雷格里港。其他位置继续正常工作，这与“全球所有节点同时宕机”的常见概括不同。
按报告，Cloudflare 网络总流量下降约 50%。对用户而言，访问经过这些节点的互联网资产和 Cloudflare 服务可能失败或变慢；具体错误形态和客户数量报告没有展开。21:39 服务恢复后，核心拥塞仍导致部分日志在 21:47 至 22:10 之间丢失，但边缘网络继续运行；22:10 日志和指标也恢复。
事故同时提醒我们，“网络还能转发”和“可观测性完整”不是一回事。服务恢复后日志管道仍可能拥塞，排障和审计数据会出现缺口；如果关键日志只存在本地或单一中心，恢复阶段的证据可能正好缺失。
Cloudflare 通过私有骨干连接各地数据中心。20:25，EWR–ORD 链路丢失，ATL–IAD 链路拥塞；工程师为缓解拥塞，在亚特兰大路由器上做了一处变更。报告说，正确做法应是停用整个策略项（term），但实际变更停用的是 prefix-list 6-SITE-LOCAL 这个匹配条件，策略项本身仍然生效。
匹配条件消失后，该策略项继续为匹配到的路由设置 local-preference 200，并接受它们；路由器于是把它知道的所有 BGP 路由都导出到骨干对等体。边缘路由器上本地计算节点的路由 local-preference 是 100，而 BGP 选路中数值更高者优先，因此本来要送往本地计算节点的流量被送往亚特兰大。亚特兰大路由器被来自全网的流量压垮，连接到骨干的位置随之失效。
报告把这一点说得很直接：一行变更开始把全部 BGP 路由泄漏进骨干。根因不是“DNS 被攻击”，也不是“BGP 协议失效”，而是路由策略的语义被改错，叠加 local-preference 的不对称，形成了一个把全网流量吸向单点的正反馈。
团队把亚特兰大路由器从骨干中移除，流量在 21:39 恢复正常，中断持续 27 分钟。之后核心拥塞导致部分日志丢失，直到 22:10 才连同日志和指标完全恢复。
报告列出的后续措施包括：对骨干配置做一次全球变更，防止同类问题再次发生；原计划在 7 月 20 日（周一）为骨干 BGP 会话增加最大前缀数限制（maximum-prefix），一旦某个节点过度宣告路由，会话会被关闭，而 Cloudflare 的网络设计允许在失去某段骨干时继续运行；事故后还修改了本地服务器路由的 BGP local-preference，避免单个位置再次把其他位置的流量吸过来。报告称更多变更会在周一继续。
值得注意的是，最大前缀限制是“事后才计划加上”的熔断器。它在事故发生时并不存在，因此不能把这次恢复描述成该机制已经生效；真正让服务恢复的是移除亚特兰大路由器。
第一，路由策略变更要按语义审查，而不是按行数审查。一行配置可能改变整个策略项的匹配范围；变更评审应展示策略对象的前后语义、匹配条件和默认动作，并在实验环境验证路由表差异。
第二，local-preference 的不对称会把局部故障放大成全局流量牵引。各地本地路由与骨干路由的相对优先级必须有明确设计，确保任何一个节点都不能因为策略错误而吸走其他节点的流量。
第三，最大前缀限制是骨干的必要熔断器。它不能阻止错误配置产生，但能在路由泄漏扩散时自动关闭异常会话；这类保护应提前部署并演练，而不是等事故发生后再补。
第四，处理一个故障时引入的变更，同样需要爆炸半径评估。本次变更原本是为了缓解 EWR–ORD 和 ATL–IAD 的拥塞，却成了新的故障源；应急变更也应有复核、最小改动和快速回退路径。
第五，日志和指标要能在核心拥塞时独立存活。服务恢复后仍有日志丢失，说明可观测性管道与数据面共享了瓶颈；关键审计数据应有本地缓冲或多个出口。
第六，术语要准确。把它称为 DNS 故障会误导排查方向；官方报告明确指出是骨干 BGP 路由泄漏。复盘摘要应尊重原始报告的因果链，而不是沿用传播中的简化标签。
合上页面，先回答，再展开对照。
prefix-list 6-SITE-LOCAL 匹配条件，却保留策略项，路由器把全部 BGP 路由以 local-preference 200 导出；本地路由只有 100，流量因此被吸向亚特兰大。
小程序版
微信扫码，随时查命令