Cloudflare 三季度报告怎样描述分布式攻击规模变化

Cloudflare 在 2026 年 10 月 29 日发布的第三季度 DDoS 威胁报告，给出的核心判断不是“攻击整体变大”或“攻击整体变小”这么简单，而是出现了明显的规模分化：短促、频繁、单次带宽不高的攻击明显增多；超过 1 Tbps 的超大流量攻击则比第二季度少了很多。

官方报告：https://blog.cloudflare.com/ddos-threat-report-2026-q3

把这份报告读成架构决策时，最重要的结论是：防护不能只按最高峰值买带宽。面对大量短突发请求，要重视边缘侧的自动吸收、连接与请求速率控制；面对协议向量变化，则要持续观察 DNS、UDP 和反射放大流量的比例。

先把总量和单次规模分开

报告覆盖 2026 年第三季度，也就是 7 月、8 月和 9 月。Cloudflare 表示，其网络在这段时间自动缓解了 1820 万次网络层 DDoS 攻击和 14.4 万亿次 HTTP DDoS 请求；网络层缓解流量为 272.6 PB，HTTP 层为 95.1 PB。换算后，网络层攻击约为每小时 8226 次，约每 0.44 秒出现一次。

但“次数很多”不等于“每次都是巨型洪峰”。报告把网络层攻击中超过 1 Tbps 的流量归为超大攻击，这类攻击在第三季度有 251 次，而第二季度是 805 次，按报告的表述接近下降 69%。同一季度，短促的中等规模高频攻击却同比增长 208%；其中 96% 持续时间少于 10 分钟，98% 的带宽低于 1 Gbps。

因此，报告标题中的“更多蜂群、较少巨人”可以这样理解：攻击面更像许多小波峰不断试探，而不是只等待一座最高的流量山峰。对云上服务来说，这会把保护重点从单纯的带宽冗余，推向边缘自动化、突发控制和可观测性。

攻击向量已经从 CLDAP 明显转向 UDP 相关流量

第二个变化是攻击手法的迁移。Cloudflare 报告称，CLDAP 反射攻击在第三季度只占网络层攻击的 0.05%；与之相对，DNS 放大攻击环比增长 215%，占网络层攻击的 3.43%，其他 UDP 洪泛则从 14.06% 上升到 31.31%。这里的重点不是记住某个百分比，而是理解：攻击者会从一种反射或放大路径转到另一种无连接协议路径。

这会影响监控设计。若告警只盯着某一个协议名称，规则很容易在向量迁移后失去代表性；更稳妥的方式是把协议、端口、包速率、放大特征、来源分布和回源压力放到同一张观测面里。报告还提到，Mirai 归类的缓解流量在 8 月达到 57.23 PB，占该季度网络层缓解字节的 46.5%，说明“超大攻击次数下降”也不代表 IoT 僵尸网络风险消失。

对网络和平台团队而言，这意味着策略要从“针对一个已知向量写一条规则”，升级为“持续识别反射、放大和无连接洪泛的共同特征”。这样才能在下一次协议占比变化时，保留检测能力。

把报告数字翻译成四个架构选择

如果正在设计或复查云上服务，可以按下面四个问题落地，而不是直接拿报告里的某个峰值替换容量表。

1. 边缘是否先于回源承压：让流量在尽可能靠近入口的位置完成基础识别、限速和丢弃，避免短突发请求先消耗应用服务器连接池、线程或队列。
2. 短时峰值是否有独立预算：把连接建立速率、并发连接数、每秒请求数和回源队列长度单独设阈值。它们和带宽峰值不是同一个指标，不能只用一个总流量阈值代替。
3. 协议迁移是否可见：监控 DNS 放大、UDP 洪泛、反射源分布和端口变化，保留按协议、地区、自治系统和服务入口切片的时间序列，方便判断是流量变大还是向量换了。
4. 自动化是否能覆盖人工响应窗口：报告中的大量攻击持续不到 10 分钟，人工确认天然可能滞后。应优先让自动化策略承担第一轮缓解，再把摘要、样本和误报反馈交给人工复盘。

这四个选择对应不同的工程约束：边缘防护解决入口容量，短时预算解决资源耗尽，协议观测解决规则失配，自动化则解决攻击持续时间短于人工响应的问题。它们比单纯增加回源机器更贴近这份季度报告反映的风险形态。

别把季度报告当成全网精确普查

Cloudflare 的数据来自其自身网络和缓解系统，适合观察经过该网络的攻击趋势，不等于全球互联网所有攻击的完整普查。报告把美国列为第三季度受攻击最多的地点，中国第二，印度尼西亚进入前三并占 2.93%；加拿大从第 16 位升到第 6 位，以色列升到第 10 位。这些排名可以帮助团队理解地理分布变化，但不能直接推导某个地区所有业务的实际风险。

复查时至少保留三个上下文：统计对象是网络层还是 HTTP 层，比较基线是同比还是环比，数字来自哪类网络观测。尤其是“超大攻击减少”这一结论，必须和短突发攻击数量、协议分布以及自家入口日志一起看，不能单独作为降低防护预算的依据。

如果需要持续跟踪趋势，可以把官方报告作为季度基线，把 https://radar.cloudflare.com/ 作为公开趋势入口，再与自有边缘、负载均衡、DNS 和回源指标对齐。这样得到的是面向自身业务的风险画像，而不是把别人的观测结果直接当成容量结论。

相关问题

攻击次数增加但超大攻击减少，算不算风险下降？

不能直接这样判断。短突发攻击次数增加后，连接池、请求处理和回源队列仍可能先被消耗；风险只是从“单次超大洪峰”部分转向“高频资源扰动”。

为什么要同时监控 DNS 和 UDP？

报告显示 DNS 放大和其他 UDP 洪泛都在上升，它们共享无连接传输和反射、放大等特征，但观测字段和缓解策略并不完全相同，合并成一个模糊指标会丢失定位信息。

Cloudflare 报告的数字能直接代表我的网站吗？

不能。它反映的是 Cloudflare 网络的观测范围。应将报告当作外部趋势信号，再用自己的入口、协议、回源和资源指标校准。