Cloudflare 2025年8月21日 事故解析

图0:Cloudflare 2025年8月21日 事故解析

2025年8月21日,涌向亚马逊网络服务(AWS)us-east-1区域托管客户的流量激增,导致Cloudflare与AWS us-east-1区域间的链路严重拥塞。此事件影响了众多通过AWS us-east-1区域服务器连接至Cloudflare或接收Cloudflare连接的用户,表现为高延迟、数据包丢失及源站连接失败。

位于AWS us-east-1区域的源站客户自协调世界时16:27开始受到影响。至协调世界时19:38,影响已大幅缓解,但间歇性延迟上升现象持续至协调世界时20:18。

此次为Cloudflare与AWS us-east-1区域间的局部问题,全球Cloudflare服务未受影响。性能下降仅限于Cloudflare与AWS us-east-1之间的流量传输。事件起因是某单一客户流量激增,导致Cloudflare与AWS us-east-1的链路过载。此为网络拥塞事件,并非攻击或BGP劫持。

对此事件我们深表歉意。本文将阐明故障性质、发生原因及我们采取的预防措施。

背景说明

Cloudflare致力于帮助用户构建、连接、保护并加速其互联网网站。多数客户将网站托管在Cloudflare未运营的源服务器上,为提升网站速度与安全性,他们将Cloudflare部署为反向代理

元素周期表

当访客请求页面时,Cloudflare会首先检查请求。若内容已在Cloudflare全球网络中缓存,或客户配置了直接提供内容,Cloudflare将立即响应并交付内容,无需联系源服务器。若内容无法从缓存获取,我们会从源服务器获取内容,提供给访客,并在过程中进行缓存(若符合缓存条件)。当后续用户请求相同内容时,我们可直接从缓存中提供,无需再次往返源服务器。

当 Cloudflare 通过缓存内容响应请求时,响应流量将通过内部数据中心互连(DCI)链路,经由一系列网络设备传输,最终抵达代表我们网络边缘的路由器(即“边缘路由器”),如下图所示:

图1:Cloudflare 2025年8月21日 事故解析

我们的内部网络容量设计始终高于特定区域的实际流量需求,以应对冗余链路故障、跨区域故障转移、网络内部/跨网络流量工程,甚至用户流量激增等情况。尽管Cloudflare绝大多数网络链路运行正常,但部分边缘路由器连接至AWS对等交换机的链路容量不足,无法处理此次突发流量。

事件始末

2025年8月21日协调世界时16:27左右,某客户从AWS us-east-1区域向Cloudflare发起大量缓存对象请求。这些请求产生的响应流量耗尽了Cloudflare与AWS之间所有可用直接对等连接的带宽。为缓解拥塞,AWS撤销了部分拥塞链路上向Cloudflare发送的BGP通告,导致初始饱和状况恶化。此举将流量重新路由至通过异地网络互连交换机连接Cloudflare的另一组对等链路,该链路随后同样饱和,引发严重性能下降。影响加剧有两大原因:其一,某条直接对等链路因既有故障仅以半容量运行;其二,连接Cloudflare边缘路由器与外部交换机的数据中心互连(DCI)正处于容量升级周期。下图通过近似容量估算展示了该情况:

图2:Cloudflare 2025年8月21日 事故解析

为此,我们的事件响应团队立即与AWS合作伙伴展开协作处理该问题。通过紧密配合,我们成功缓解了网络拥塞状况,并为所有受影响客户全面恢复了服务。

时间线

时间 描述
2025-08-21 16:27 UTC 单客户流量激增开始,Cloudflare至AWS总流量翻倍
2025-08-21 16:37 UTC AWS开始从拥塞的PNI(私有网络互连)BGP会话中撤销Cloudflare前缀
2025-08-21 16:44 UTC 网络团队收到阿什本(IAD)区域内部拥塞警报
2025-08-21 16:45 UTC 网络团队评估应对方案,但因AWS撤回前缀,非拥塞路径亦无法获取AWS前缀
2025-08-21 17:22 UTC AWS BGP前缀撤回导致丢包量激增 影响扩大
2025-08-21 17:45 UTC 阿什本(IAD)区域客户影响事件升级
2025-08-21 19:05 UTC 对单一客户实施速率限制缓解流量激增,拥塞状况改善
2025-08-21 19:27 UTC 网络团队采取额外流量工程措施,完全消除拥塞
2025-08-21 19:45 UTC AWS按Cloudflare要求开始撤销BGP撤回操作
2025-08-21 20:07 UTC AWS完成通过IAD PNI向Cloudflare的BGP前缀公告正常化
2025-08-21 20:18 UTC 影响结束

影响开始时,我们观察到某客户相关流量激增导致网络拥塞:

图3:Cloudflare 2025年8月21日 事故解析

此次故障由Cloudflare和AWS双方通过手动流量操作处理。通过观察停机期间AWS向Cloudflare通告的IP前缀数量,可看到AWS为缓解拥塞所做的部分尝试。不同颜色的曲线对应每个BGP会话向我们通告的前缀数量。曲线中的下降点表明AWS通过从BGP会话中撤回前缀来引导流量至其他路径:

图4:Cloudflare 2025年8月21日 事故解析

网络拥塞导致路由器上的网络队列显著增长并开始丢弃数据包。如下图所示,在故障期间我们的边缘路由器持续丢弃高优先级数据包,该图表展示了受影响期间阿什本路由器的队列丢包情况:

图5:Cloudflare 2025年8月21日 事故解析

此次拥塞对客户的主要影响表现为延迟、丢包(超时)或低吞吐量。我们定义了一套延迟服务级别目标(SLO),通过模拟客户请求返回源端来衡量可用性和延迟。可见在影响期间,请求延迟未达标的比例与故障期间的包丢失率同步跌破可接受阈值:

图6:Cloudflare 2025年8月21日 事故解析

拥塞缓解后,AWS与Cloudflare曾短暂尝试将为缓解拥塞而调整的前缀广告恢复至正常状态。此举导致延迟出现长尾效应,可能影响部分客户——这正是您观察到数据包丢失问题解决后,客户延迟仍未恢复的原因。

补救措施与后续步骤

本次事件凸显了加强防护机制的必要性,以确保单个客户的使用模式不会对整个生态系统造成负面影响。我们的核心经验包括:必须通过架构设计实现更优的客户隔离,防止任何单一实体垄断共享资源并影响平台其他用户的稳定性;同时需扩充网络基础设施容量以满足需求。

为防止问题重演,我们正实施多阶段缓解策略。短期及中期措施包括:

  • 开发机制,当客户流量拥塞程度影响其他用户时,可选择性降低其流量优先级。
  • 加速数据中心互连(DCI)升级,将提供远超当前水平的网络容量。
  • 我们正与AWS协作,确保双方未来的BGP流量工程措施不会相互冲突。

展望未来,我们的长期解决方案是构建一套全新的增强型流量管理系统。该系统将按客户分配网络资源,建立流量预算机制——一旦超出预算,该客户的流量将不会影响平台其他用户的体验。此系统还将实现自动化处理,取代本次事件中为缓解拥塞而采取的诸多手动干预措施。

结论

由于网络拥塞管理机制在异常高流量事件中应对不足,通过Cloudflare访问AWS us-east-1区域的客户遭遇了服务中断。

我们对此次事件给客户造成的干扰深表歉意。目前正积极推进改进措施,以确保未来系统稳定性提升,并防止此类问题再次发生。

共有 42 条讨论

  1. > 本系统将按客户分配网络资源,建立预算额度。一旦超出预算,该客户的流量将被限制,避免其影响平台上其他用户的体验

    实际操作中如何实现?若单个客户端已导致边缘路由器队列溢出,系统是否已陷入困境?即使丢弃该客户端所有数据包,仍需先解析数据包所属客户端才能执行丢弃操作?

    或许可采用随机分片机制:将单个客户端分配至多个IP前缀,当该客户端异常时,通过BGP撤销其前缀,实质上将该客户端的网络路由置于黑洞。若分片机制设计得当,仅问题客户端会受影响,同一前缀的其他客户端将被分片到不同前缀。

    1. 本案中造成过载的并非客户端请求,而是请求响应。因此Cloudflare只需停止发送响应即可解决问题。

      您说得对,这并非万能解,但本可避免此类事件。

    2. 这是负载卸载机制,但通常会优先针对超额使用配额的用户(基于滚动加权平均值)。其优势在于能在边缘节点立即丢弃流量,而非占用套接字或消耗计算资源。该机制通常在30秒至1分钟内生效。

    3. > 即使丢弃该客户端的所有数据包,仍需先处理数据包以确定所属客户端才能丢弃?

      在现代Linux中,可编写BPF-XDP程序在驱动程序底层直接丢弃流量,完全无需进行任何计算。驱动程序在接收环形缓冲区的新数据包后,几乎第一件事就是运行你的程序处理这些数据包。

      1. 假设你有一个BPF-XDP程序,通过处理数据包来确定其来源客户端并选择性丢弃。这真的比直接从边缘路由器转发数据包到下一跳更快吗?我难以置信:当边缘路由器仅执行转发时,运行此类程序真能缓解队列满溢问题?

    4. 或许他们在主机端就丢弃了该客户端的数据流。

      1. 我不明白?问题在于云端之外的客户对某条网络链路实施了DOS攻击。云端难道无法控制客户端实施速率限制?

        1. 你可能误解了流量流向。数据流由AWS us-east-1发起的请求驱动,方向是从云端流向AWS,而非反向。Cloudflare完全能够控制其出站流量到达目的地的路径(只要存在多条通往目标的路径),并将其流量限制在合理水平。

          1. 啊,现在明白了。这种情况下他们可以直接返回429状态码,或者干脆不作响应。

    5. 我觉得你过度思考了。只要设置每个(Cloudflare)客户的速率限制,就能解决大部分问题。

  2. 结果很可能就是某个人在一台配备100Gbps上行链路的高速机器上执行“pnpm install”命令。

    1. 能别再拿2015年的梗开玩笑了?

      1. 我确实遇到过在本地ISP失败、但通过Cloudflare VPN成功的npm安装案例,楼主评论基本解释了原因。

      2. 2015年这叫“npm install”

        (感谢Rauch)

  3. AWS确实存在反复出现的模式:单个客户触发潜在缺陷/容量不足导致服务中断。事后分析常建议建立客户级可观测性与缓解机制。

  4. 单个租户的缓存命中流量竟能压垮Cloudflare的互联带宽,实在离谱

    1. 许多互联网链路的带宽之低会让你大吃一惊。中小型网络普遍采用10Gbps——更准确地说,中小型ISP与多数对等伙伴的连接带宽可能仅有10Gbps。通常流量会分散流向不同目的地,来自不同来源,每条链路都处于部分利用状态。但异常流量模式可能填满某条特定链路。

      如今10Gbps已是老技术,任何正规ISP都能负担40G或100G链路——每条链路仅需数百美元。不过他们会优先在高负载链路上部署,且需满足两个条件:对等伙伴同样具备财力,且双方交换流量足够大以证明投资合理。因此最小连接规格通常仍是10Gbps(低于10Gbps的链路规模根本不值得建立点对点对等连接)。

      若你家中铺设了10Gbps光纤,完全可能独自堵塞其中一条链路。

      现在Cloudflare正与aws-east-1区域通信,该区域理应拥有海量带宽,至少达到8×100Gbps甚至更高。但考虑到AWS这种环境下,用户随时能调配800台服务器运行数小时来执行大规模并行任务,最终有人成功向同一区域制造出800Gbps流量(或其等效带宽)也就不足为奇了。实际上更令人惊讶的是这种情况竟未频繁发生。或许因为AWS对数据传输收取天价费用——800Gbps流量每秒需支付5至9美元。

      1. 针对不可避免的未来趋势进行前瞻性规划值得深入探讨。

        例如当人们逐步理解AI运作机制时,数据抓取行为将呈现“加速增长”态势。我们不妨制定标准化的训练数据包,由所有数据源/行业共同提供公共种子资源,以此缓解此类问题。

        [我明白这个提议目前尚不现实,但它可作为谈判的起点。]

      2. 通过互联网网关从Cloudflare下载缓存数据至AWS对下载方是免费的

      3. 犀利观点。40Gbps并非真实速率,不过是四条10Gbps链路堆叠的伪装!

        1. 其他速率同样如此。第一代100GE是10×10GbE,第二代是4×25GbE。200GE初代版本基于25GbE技术,以此类推。

    2. 这正是事件的导火索。

      事态持续恶化的原因在于:Cloudflare未能正确响应主要对等方撤销的BGP路由,次要路由因未解决的问题导致容量不足,基本流量限制措施不得不手动执行。

      他们似乎只顾铺设巨型对等管道,基本抱持侥幸心理。或许因长期依赖这种模式,导致性能下降的“次要”链路持续运行远超应有时限。这正是典型的“瑞士奶酪式”故障模式。

      1. 撤销BGP链路是否恰恰加剧了问题?毕竟所有相同流量都被迫挤过更少的物理链路。

  5. AWS us-east-1区域正拖垮其他服务商。

  6. 真正的长期解决方案是迁移至其他AWS区域;us-east-1似乎饱受各种扩展性挑战困扰。

    1. 没有任何迹象表明Cloudflare与其他AWS区域间的链路容量更大,或者那些区域没有更多干扰性强的Cloudflare客户。

      1. 但绝对有迹象表明“若仅为某些任务支持单一区域,你将面临他人不会遭遇的问题”。

  7. 谁来告诉Cloudflare:AWS的BGP通告是自动化的,他们拥塞的网络直接导致BGP撤销——因为自动化系统检测到拥塞后会减少流量来缓解?

    1. DCI PNI中的BGP路由很可能手动配置——毕竟这是最直接关键的连接之一。真要说意外,反倒是Cloudflare竟对AWS此次事件毫无第一手认知。

      AWS的撤销策略本应有效,此举本可缓解连接饱和。可惜这次导致路由被迫通过半负荷链路传输。

    2. 从博客内容看,他们显然对此心知肚明。

      我猜想Cloudflare和AWS在事件发生时正通过Chime桥接沟通,双方在此事中都牵涉重大利益。

  8. > 此次事件源于某单一客户流量激增,导致Cloudflare与AWS us-east-1区域的链路过载。这是网络拥塞事件,而非攻击或BGP劫持。

    且在事件发生前无人知晓任何迹象。这正是当前网络管理的尖端水平——让Cloudflare来处理吧。

  9. 真好奇是哪位客户引发了这场风波…

    1. 我猜是Braze。他们允许客户对用户数据进行大量推送和拉取操作,我推测每个客户都处于沙盒环境中。他们同样受到了此次事件的影响。

      1. 听起来所有依赖Cloudflare和AWS us-east-1区域的用户都受到了影响。不确定这是否如你暗示的那样是确凿证据

        1. 我发现受影响且可能引发问题的正是那家公司。他们向来不愿与他人合作,文档里都写着呢。我们曾考虑采购其服务。他们还曾在其他云平台引发负载问题。但这只是猜测,实际原因可能多种多样。

    2. 同样好奇这究竟是正常流量、配置错误还是攻击流量。

  10. 我难以理解文章中的第二张图。有向图我还能看懂,但这张图里有细长的水平线,两端都延伸出箭头。这些线看起来像分隔符而非节点,因此我不确定该如何解读。

    1. 我认为图示意图是展示亚马逊与Cloudflare在连接双方网络设备的纤光缆段上的责任分界。若将线条延伸并用虚线分隔会更清晰明了。

  11. 缺少的y轴标签若能补全会很有参考价值

  12. 拜托了,CF内部人士快用临时账号告诉我们是哪位客户吧 🙂

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的: