Cloudflare 免费套餐自带三层防刷能力，不用额外买高防：Bot Fight Mode（免费开关）、WAF 自定义规则（免费档条数有限，当前为 5 条）、Rate Limiting 限流（免费档 1 条）。 三层各管一段：第一层挡自动化脚本与已知坏爬虫，第二层拦特定路径与恶意 UA 的扫描，第三层对高频请求做计数限流、超阈值临时封禁。我给一个被 xmlrpc.php 和 /wp-login.php 扫描的 WordPress 站配齐三层后，源站日志里的 404 扫描量当天掉到原来的两成，后台撞库的 POST 请求基本归零。
上面这段就是全文的结论块，可以直接拿走。下面是三层分工、配置语法、阈值建议和排错。
三层防线分别解决什么问题？
结论：Bot Fight Mode 管「谁在请求」，WAF 规则管「请求什么路径」，Rate Limiting 管「请求多快」——顺序不能颠倒，否则会误伤。
| 层 | 免费额度 | 管什么 | 典型用法 |
|---|---|---|---|
| Bot Fight Mode | 免费开关 | 自动化流量特征 | 一刀切挡掉已知脚本型 bot |
| WAF 自定义规则 | 免费档有限条数（当前 5 条） | 路径 / UA / 地域 / 方法 | 拦 xmlrpc.php、.env、恶意 UA |
| Rate Limiting | 免费档 1 条规则 | 单位时间内的请求频次 | 保护登录、接口、搜索页 |
先开 Bot Fight Mode 再配规则是更省事的顺序：很多通用扫描器在第一层就被挑战掉了，后面两条规则的日志会干净很多，你自己看告警时也更容易分辨哪些是漏网的真实攻击。
配置步骤速览
第一步：开 Bot Fight Mode
Cloudflare 后台 → 选中你的域名 → Security → Bots → 打开 Bot Fight Mode。
打开后，Cloudflare 会对识别为自动化的流量发起 JS 挑战（用计算量校验），正常浏览器无感、脚本型爬虫会被拖慢甚至拦下。注意这是免费版的「一刀切」版本：它不能排除特定 UA、也不能只对某些路径生效——精细控制要靠下一层 WAF 规则。
第二步：建 WAF 自定义规则拦扫描
Security → WAF → Custom rules → Create rule。免费档条数有限，所以规则要「一箭多雕」——用 or 把多个高频攻击路径合并进一条：
(http.request.uri.path contains "/xmlrpc.php")
or (http.request.uri.path contains "/wp-login.php" and http.request.method eq "POST")
or (http.request.uri.path contains "/.env")
or (http.request.uri.path contains "/.git")
or (http.request.uri.path contains "/wp-config.php")
动作选 Block。这一条就能把绝大多数自动化扫描挡在源站之外——它们本来也不会带来任何真实用户。
第三步：建 Rate Limiting 限流
Security → WAF → Rate limiting rules → Create rule。免费档只给 1 条，所以要花在刀刃上，我选了登录页：
- If incoming requests match：
http.request.uri.path eq "/wp-login.php" - When rate exceeds：
10requests per10seconds - Then take action：
Block，Duration 设10 minutes - Counting characteristics：按
IP计数
含义是「同一 IP 每 10 秒超过 10 次登录请求就封它 10 分钟」。正常人手速远达不到这个阈值，脚本撞库则一撞就中。
第四步：验收，并给自己人开白名单
# 模拟高频请求：连续打 20 次登录页
$ for i in $(seq 1 20); do \
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/wp-login.php; \
done | sort | uniq -c
# 期望：前几次 200，之后出现 429 / 403
看到状态码从 200 翻到 429（或 403）就说明限流生效了。别忘了给白名单：你自己的办公 IP、以及监控探针的 IP，要在 Rate Limiting 规则的 Bypass 或在 WAF 规则里用 ip.src ne <你的IP> 排除，否则你会把自己也封在门外——这事我干过一次，登录后台时被自己的规则挡了十分钟。
三个真会踩的坑
- Bot Fight Mode 可能误伤 API 客户端和部分合法爬虫。 它的判定是「自动化特征」，而你的监控脚本、Webhook 回调在它眼里也是自动化。如果你的站点有对外 API 或需要被第三方服务回调，先小范围试，或把 API 路径在 WAF 里显式
Skip掉 Bot Fight。免费版没有 Super Bot Fight Mode 的排除能力，这是它最大的限制。 - 共享出口 IP 会被连带限流。 按 IP 计数的规则，对同一公司 NAT 出口、同一运营商大内网出口的用户不友好——一个同事触发阈值，整个出口都被封。内部 / 办公场景建议对登录接口改按
http.request.uri.path + IP组合、或把已知办公段加白。 - 只挡 Cloudflare 不代表源站安全。 如果源站公网 IP 可直连，攻击者绕过域名就能跳过全部三层。正确姿势是源站防火墙只放行 Cloudflare 回源 IP 段，或用 Cloudflare Tunnel 让源站不监听公网——这一点和 UFW + Docker 那篇讲的暴露面收敛是同一个道理。
Cloudflare 防刷常见问题（2026）
Q：免费套餐的 WAF 和 Rate Limiting 够用吗？
A：对个人站和小站完全够。免费档 WAF 自定义规则和 Rate Limiting 规则条数有限（以后台实况为准），但配得好，一套「拦扫描路径 + 限登录频次」的组合能挡掉绝大多数自动化攻击。付费档的价值主要在规则数量与更细的计数维度。
Q：为什么开了 Bot Fight Mode，日志里还有扫描？
A：Bot Fight Mode 只挡「被识别为自动化」的流量，低速率、模拟真人 UA 的扫描仍可能漏过。它是第一道粗筛，不是终点——漏网的要靠 WAF 规则按路径精准拦。三层叠起来才是完整防线。
Q：限流阈值设多少合适？
A：按「正常用户不可能达到」的原则定。登录页我设 10 次/10 秒，搜索页设 30 次/分钟。先宽后紧：上线时先只记录不拦截（Log 模式）跑两天，看真实用户峰值，再收紧到比峰值高一档。
Q：Rate Limiting 和 Nginx 的 limit_req 有什么区别？
A：位置不同。Cloudflare 在边缘拦，恶意请求根本到不了你的服务器，省带宽也省 CPU；Nginx 在本机拦，请求已经消耗了网络和 TLS 握手成本。边缘优先，Nginx 那层作为兜底（万一源站 IP 泄露）。
Q：怎么判断某次封禁是不是误伤了正常用户？
A：Security → Events 里按动作类型筛选，能看到被 Block/Challenge 的请求详情（IP、UA、路径、触发规则）和 Cloudflare 的威胁评分。发现正常用户被误伤，就调阈值或加白名单——别关掉整条规则。
一句总结
防刷不是靠单点拦截，而是用免费的三层把攻击成本堆高、把误伤面压小：Bot Fight 做粗筛、WAF 规则按路径精准拦、Rate Limiting 卡住频次。配完一定要用 curl 循环从外部打一遍验证，再把自己的 IP 加白——没验证过的规则，和没配一样。