攻击更多、单次更小：DDoS 防护阈值与告警聚合该怎么调整（Cloudflare 2026 Q3 报告解读）

Cloudflare 2026 Q3 的 DDoS 报告给出了一组对阈值设计很不利的组合：攻击次数大幅上升，单次规模和持续时间却在下降。这意味着以“单次峰值带宽”为唯一触发条件的那套规则，会同时出现两种失效——大量小攻击根本不触发，而一旦放宽阈值，值班又会被高频小事件淹没。需要先说清楚：报告只描述攻击分布，没有给出任何阈值建议；哪些能直接从数字里推出来、哪些必须在自己的流量基线上标定，下面分开写。

报告实际给出了什么#

按 Cloudflare DDoS Threat Report 2026 Q3 的统计口径（该季度 7—9 月，数据来自 Cloudflare 网络自行缓解的攻击）：网络层攻击 1820 万次、HTTP 层 144 万亿次请求，折合约每小时 8226 次、每天约 19.74 万次、每 0.44 秒一次；缓解流量为网络层 272.6 PB、HTTP 层 95.1 PB。

分布形状是这样的：

• 短促攻击：报告称时长低于 10 分钟、带宽低于 1 Gbps 的攻击增长 208%。同一篇正文又在数字段落里把 1820 万次网络层攻击标为相对 2025 年同期的 +208%。这两处是否指同一统计对象，现有正文不足以完全确认，引用时建议保留“同比 2025 年同期”这个基期说明，不要简写成“增长 208%”。
• 短促攻击的占比：96% 在 10 分钟内结束，98% 低于 1 Gbps。
• 超大流量攻击反而减少：超过 1 Tbps 的网络层攻击从 Q2 的 805 次降到 Q3 的 251 次（约 -69%）。报告把它与 2026 年初针对 Aisuru、KimWolf、JackSkid、Mossad 四个 IoT 僵尸网络的执法行动并列讨论，措辞是“可能反映”，并非因果结论。
• 向量结构剧变：CLDAP 环比塌了 99.5%，Q3 只占攻击的 0.05%；DNS 放大涨 215% 至 3.43%；其他 UDP flood 从 14.06% 升到 31.31%。

这份数据有一个必须反复提醒的边界：它是 Cloudflare 网络的观测，不代表全网；也不能据此推断你所在业务的攻击构成与之同形。报告能提供的是“形状”，不是“数值”。

为什么单一峰值阈值不再够用#

把 98% 和 96% 两个数字放进告警链路，结论几乎是直接的：

• 如果阈值设在 1 Gbps，98% 的攻击永远不触发告警。它们仍然消耗连接数、请求解析、日志与上游带宽。
• 即使触发，96% 的攻击在 10 分钟内结束。按常见的“告警—确认—介入”节奏，人看到通知时攻击多半已经停了。报告在谈防御架构时也是这个判断：多数攻击在人看到告警之前就结束了，因此检测与缓解需要自动化。

所以阈值的作用应该重新定位：它主要用来把事件分流到自动化缓解或人工处置，不再只是决定是否发告警。分流正确比触发灵敏更重要。

把阈值拆成三条判据#

下面这张表里的判据结构是建议，具体数值必须来自你自己的基线，报告不提供也不能提供。

第三条是新加的重点。当单次攻击不足以越过强度阈值时，频次是唯一能暴露它的信号。这也意味着告警系统必须能记住“这个目标今天已经被打过多少次”，而不只是判断“现在是否超线”。

告警聚合：聚合键、抑制窗口与明细#

建议的聚合键是三元组：目标 + 攻击向量 + 时间桶。同一个键在一个时间桶内只出一条通知，通知体里带事件计数、累计持续时间和累计字节，并附桶内最严重的若干条明细。

为什么向量维度不能写死：本季度 CLDAP 从上半年的高增长直接塌到 0.05%，UDP 类同时涨到三成以上。任何按“已知向量白名单”设计的聚合规则，都会在下一个季度失效。应当留一个 other 桶兜住未识别的向量，并且允许向量分类器更新而不改聚合逻辑。

另外两点容易忽略：

• 聚合不能替代明细。只发一条汇总会掩盖“某个单点被单独针对”的情况，桶内 top-N 明细是必要的。
• 抑制要有上限。长时间持续的攻击如果被完全抑制，值班会失去对“还没结束”的感知；通常做法是首次通知后每隔固定间隔重发一次状态。

容量规划与值班，用两个不同的口径#

报告里有一组容易被混在一起读的数字：事件数集中在短小攻击上，但字节量并非如此。Mirai 类缓解流量在 8 月达到峰值 57.23 PB，占 Q3 全部网络层缓解字节的 46.5%，其中 8 月 16、19、23、25 日各有单日超过 3 PB；该季度最长的一次持续性 Mirai 攻击从 8 月 19 日持续到 21 日，共 49.7 小时。

这提示两个口径要分开：

• 容量与成本按字节和并发连接算，看的是少数长尾事件；用事件数做容量估算会严重低估。
• 值班负荷按事件数算，看的是高频短促攻击；用字节做值班排班同样会错配。

两条曲线走向相反时，用一条曲线同时驱动两件事，必然有一边是错的。

一个聚合规则的骨架（未执行示例）#

下面的配置未在任何环境中执行，仅用于说明聚合键、抑制窗口与升级条件的组织方式，数值全部是占位值，不可直接上线。

# 未执行示例：仅演示结构，所有阈值与窗口均为占位
alert_policy:
  group_by: [target, vector, bucket_5m]   # 聚合键
  inhibit:
    same_key_window: 5m                    # 同键抑制窗口
    repeat_status_every: 30m               # 长事件的状态重发
  keep_detail:
    top_n_per_bucket: 5
  escalate_to_human_when:
    - continuous_over_threshold: 10m       # 持续时间判据
    - triggers_in_rolling_1h: 6            # 频次判据
  auto_mitigate_when:
    - pps_over_baseline_ratio: 3           # 强度判据（相对自身基线）
  fallback_vector_bucket: other            # 未识别向量的兜底桶

注意 pps_over_baseline_ratio 这类相对量是刻意的：报告给的是 Cloudflare 全网的分布，不是你的业务基线。绝对数值（多少 Gbps、多少 pps）只能从你自己的历史流量里标定。

报告无法回答、需要你自行确认的部分#

• 阈值具体数值：取决于你的正常流量形态、冗余能力与误杀成本，报告不涉及。待核实的是你自己的分位数基线。
• 向量分类能力：你能不能把 DNS 放大、UDP flood、CLDAP 分开统计，决定了聚合键能不能用。若不能，先用 other 单桶跑通流程。
• 自动化缓解的边界：报告描述的是 Cloudflare 的自动化体系，不代表你的网关具备同等能力。如果你的服务前面是自建 API 网关，阈值更应标定在网关自身的连接队列、上游超时和错误率上。
• 报告未覆盖的时段与口径：本次材料只包含该季度报告页面，历史季度对比仅限正文提到的数字；其他口径待核实。

可以落地的结论只有一条：在攻击次数上升、单次规模下降的分布下，把阈值当成分流器、把告警按目标与向量聚合成事件、把容量口径与值班口径拆开，比继续调一个峰值数字更接近问题本身。