DDoS 防护：免费计划里哪些是自动的，哪些要你动手
免费计划的 DDoS 防护写的是"不计量（Unmetered）"，这句话容易被理解成"打开就万事大吉"。实际情况分两层：网络层（L3/L4）的流量清洗确实是全自动的，靠的是 Anycast 网络与边缘容量；应用层（L7）的请求洪泛没有通用解法，因为它长得像正常请求，要靠你的规则、限流和缓存命中率去挡。
分清这两层，被打的时候就不会一直刷新控制台等它自己好。这篇讲免费档能用到的手段、被打时的处理顺序，以及哪些动作有副作用。
前置：域名走代理（橙色云）。灰云记录不经过边缘，任何 DDoS 防护都不生效，见 50-dns-records-tutorial.md。
1. 免费档的防护清单
| 层次 | 机制 | 免费档 | 是否需要你配置 |
|---|---|---|---|
| L3/L4 | SYN Flood、UDP 反射、流量型攻击清洗 | 有，自动 | 不需要 |
| L3/L4 | Spectrum（四层代理） | 无 | — |
| L7 | 已知攻击模式的自动缓解 | 有，自动 | 不需要 |
| L7 | 自定义 WAF 规则 | 5 条 | 需要 |
| L7 | 速率限制 | 1 条 | 需要 |
| L7 | Under Attack Mode 开关 | 有 | 需要手动开 |
| L7 | 缓存吸收 | 取决于缓存规则 | 需要 |
| 通知 | DDoS 告警 | 有 | 需要配置收件人 |
自动的那部分：边缘网络在流量到达你的源站之前就把它分散、丢弃或清洗，攻击流量不进入你的带宽，也不计入套餐额度。这也是"不计量"的含义——不会因为被打而收到账单。
需要你动手的那部分集中在 L7。一个每秒十万请求的 HTTP 洪泛，每个请求看起来都合法：正常的 UA、正常的路径、随机的查询参数。Cloudflare 能靠全局基线识别一部分，剩下的靠你的规则。
2. 被打时的处理顺序
第一步，判断是不是攻击。看 Analytics → Traffic 的请求曲线：正常情况下有昼夜波动，攻击是垂直上升。再看三个分布：来源国家是否集中在平时没有流量的地方、ASN 是否集中、UA 是否大量重复或异常。同时看源站负载——如果边缘请求涨了十倍而源站没感觉，说明缓存吸收了大部分，不用急着改配置。
第二步，看缓存命中率。这是最容易被忽略的一招：把可缓存的路径尽量缓存，攻击流量会在边缘被消化，不打到源站也不消耗 Workers 额度。缓存规则见 74-cache-rules.md。一个命中率 90% 的站点，被打时的实际压力只有十分之一。
第三步，开 Under Attack Mode。位置在 Security → Settings → Security Level，选 I'm Under Attack。它对每个请求下发一次 JS 挑战，通过后才放行。副作用很明确：所有非浏览器客户端会失效，包括 API 调用、监控探针、爬虫、支付回调。所以它是应急开关，不是长期状态。
第四步，加规则。按攻击特征写自定义规则，优先级从高到低：
- 路径特征：攻击集中在某个接口时，先给该接口加速率限制。
- UA 与请求头：攻击工具常带固定 UA 或缺失
Accept-Language。 - 国家与 ASN：确认业务不需要该地区流量时直接拦。
- 托管规则：确认 Free Managed Ruleset 已部署（见 77-waf-basics-free-rules.md）。
第五步，记录与复盘。把攻击时间窗、峰值 QPS、主要来源、生效的规则、源站影响记下来。Ray ID 与时间点在同 Cloudflare 支持沟通时是必要信息（免费档没有专属支持，但工单与社区仍需要这些）。
3. 症状对照
| 症状 | 大概率原因 | 先做什么 |
|---|---|---|
| 全站打不开，源站 CPU 100% | L7 请求洪泛打穿缓存 | 开 Under Attack Mode，检查缓存规则 |
| 只有某个接口慢 | 该接口被刷，或缓存未覆盖 | 给该路径加速率限制 |
| 带宽跑满但请求数不高 | L3/L4 流量型攻击 | 通常已自动清洗，确认源站是否暴露了真实 IP |
| 大量 403 出现在事件里 | 规则命中，可能是误伤 | 看 Security Events 的来源分布 |
| 账单/额度异常增长 | 请求打到 Worker 且未被边缘拦截 | 限流 + 缓存 + 检查是否有绕过路径 |
最后一行值得单独注意：被边缘拦下的请求不消耗 Workers 额度，但穿过边缘到达 Worker 的请求会计费。攻击流量如果打在 Worker 路由上且没被规则挡住，免费额度会在几小时内耗尽，然后进入 1027 错误页。额度与超限行为见 56-free-tier-limits-cheatsheet.md。
4. 真实 IP 泄露是免费档最大的漏洞
DDoS 防护的前提是"攻击者只知道 Cloudflare 的 IP"。如果源站的真实 IP 泄露，攻击者可以绕过边缘直接打源站，所有防护失效。
常见的泄露途径：源站曾用其它 DNS 解析过（历史记录可查）、邮件服务器用同一 IP 发信（邮件头带 IP）、直接 IP 访问过站点、证书透明度日志里出现过子域。
处理方式：源站防火墙只放行 Cloudflare 的 IP 段（官方提供 https://www.cloudflare.com/ips-v4 与 ips-v6），其它一律丢弃。这一步做完，即使 IP 泄露，攻击也打不进来。源站如果是家里的机器，用 Tunnel 接入比开放端口更稳。
5. 该不该长期开 Under Attack Mode
不该。它的成本是每个请求一次挑战：
| 影响面 | 表现 |
|---|---|
| API 客户端 | 收到挑战页 HTML，解析失败 |
| 监控探针 | 误报站点宕机 |
| 搜索引擎 | 抓取受阻，索引下降 |
| 首屏性能 | 多一次 JS 执行，LCP 变差 |
| 正常用户 | 老设备上可能出现验证循环 |
攻击结束后立刻关掉。如果攻击长期化（例如持续一周的敲诈型攻击），正确做法是把规则做细：按路径、按 UA、按国家组合，替代全站挑战。
常见问题
免费档能扛多大的攻击？
官方不对具体套餐承诺清洗容量，网络是共享的 Anycast 容量。实际表现取决于攻击类型：流量型攻击基本无感，应用层洪泛取决于你的缓存命中率与规则。别把"不计量"理解成"无限抗"。
被打时 Cloudflare 会主动通知我吗？
不会主动联系，但可以在 Notifications 里配置 DDoS 告警，收件人填自己的邮箱。免费档的告警粒度比付费档粗。
源站 IP 已经泄露了怎么办？
先上防火墙白名单只放行 Cloudflare IP 段，再考虑换 IP。换 IP 要同步改 DNS，切换期间有解析缓存，选低峰期做。长期方案是把源站藏到 Tunnel 后面。
小结
免费档的 DDoS 防护是"网络层全自动、应用层要配置"的组合。流量型攻击基本不用管，请求洪泛要靠缓存命中率、速率限制、WAF 规则三件套，Under Attack Mode 只当应急开关用。
真正决定抗打能力的是两件常被忽略的事：缓存命中率够不够高，源站真实 IP 有没有藏住。前者决定攻击流量能不能被边缘消化，后者决定攻击者有没有捷径。
数据来源与检索时间
检索时间 2026-11-10。
| 来源 | URL | 对应数据 |
|---|---|---|
| Cloudflare 定价页 | https://www.cloudflare.com/plans/ | 免费计划包含不计量 DDoS 防护 |
| WAF 概览 | https://developers.cloudflare.com/waf/ | 免费档托管规则与自定义规则条数、速率限制 1 条 |
| Workers 限额 | https://developers.cloudflare.com/workers/platform/limits/ | 请求额度与超限后的 1027 行为（用于说明攻击流量的计费面） |
核验说明
- 页面为本机抓取（HTTP 200），"不计量"与免费档规则条数取自页面描述。
- 未执行：无 Zone 权限，Under Attack Mode 未开启、DDoS 告警未配置、缓存规则未部署；没有真实攻击样本可复现，症状对照表按公开文档与常见案例整理。
- 未验证：免费档实际可承受的 QPS 与清洗容量没有实测数据，文中只说"取决于攻击类型与缓存命中率"，未给具体数字。