本文教你如何在一个下午内把 Cloudflare 的 Bot Fight Mode、Super Bot Fight Mode 与 WAF 托管规则集组合起来，挡住绝大多数撞库、抢购脚本与漏洞扫描器，同时不误伤真实用户与合作爬虫。为什么要把这三层一起谈？因为它们解决的是同一个问题的不同切片：Bot Fight 看客户端指纹，WAF 看请求载荷，自定义规则补业务语义。读完你会拿到三份可落地的产出：开启顺序与动作选择清单、覆盖登录与下单接口的自定义规则模板，以及一套误伤排查 SOP。
一、为什么先看清各层职责再点按钮
很多人打开 Cloudflare 的 Security 面板第一反应是把所有开关推到顶，结果当天就接到客服电话说支付回调全挂了。先把各层职责说清楚再决定开什么。
Bot Fight Mode 是基础版的客户端行为识别，针对的是已知数据中心 IP 段、伪造 User-Agent、明显非浏览器的 TLS 指纹。它的动作只有 challenge 一种，触发后会要求客户端完成 JavaScript 挑战，对合规浏览器几乎无感。Super Bot Fight Mode 是 Pro 套餐起的增强版，把 bot 流量分成”明确恶意””自动化工具””可能是 bot”三档，每一档允许独立选择动作。
WAF 托管规则集走的是另一条路：它对请求 URL、Header、Body 做特征匹配，识别 SQL 注入、命令注入、XSS、已知 CVE 利用串。Cloudflare 现在主推的是 Managed Ruleset 与 OWASP Core Ruleset 两套，前者是 Cloudflare 维护的精选规则，误伤率低；后者覆盖广但需要按业务调灵敏度。
自定义规则（Custom Rules，旧称 Firewall Rules）是业务语义层。它能写出”未登录用户在 60 秒内 POST 登录接口超过 5 次”这种 Bot Fight 与托管规则集都看不出来的逻辑。
二、开启顺序与动作选择清单
不要一次性把所有开关推到顶。下面这个顺序在大量站点上验证过，能把误伤窗口控制在每一步 24 小时内。
第一步，先开 Bot Fight Mode（或 Super Bot Fight Mode 的”明确恶意”那一档），动作选 Block。Cloudflare 对”明确恶意”的判定非常保守，几乎不会误伤。
第二步，启用 Managed Ruleset，动作保持默认。先观察 24 小时，在 Security Events 里筛选 action=managed_challenge 的日志，看是否打到了正常用户。
第三步，把 OWASP Core Ruleset 灵敏度先设为 Low，paranoia level 设为 PL1。这一组规则改动最大，建议在测试环境对一遍业务接口再上生产。
第四步，加自定义规则覆盖业务关键路径，下面给模板。
下面这张表是常见动作的语义对比：
- Block：直接 403，请求不会到源站
- Managed Challenge：Cloudflare 自动选 JS 挑战或 Turnstile，对真人几乎无感
- Interactive Challenge：强制点击式验证码，对真人有摩擦，仅对疑似 bot 用
- JS Challenge：纯浏览器执行 JS，老旧浏览器可能失败
- Log：只记录不动作，灰度阶段用
三、覆盖登录与下单接口的自定义规则模板
下面三条规则覆盖了 80% 的业务防护需求，可以直接抄进 Custom Rules。
规则一，限制登录接口的高频请求。表达式：(http.request.uri.path eq “/wp-login.php” and http.request.method eq “POST”)，动作选 Managed Challenge，速率限制设为 60 秒内 5 次。WordPress 站点强烈建议加这条，能挡掉绝大多数撞库脚本。
规则二，挡掉常见漏洞扫描路径。表达式：(http.request.uri.path contains “/.env” or http.request.uri.path contains “/.git/” or http.request.uri.path contains “/wp-config.php.bak”)，动作选 Block。这类请求 100% 是恶意扫描，没有任何合规来源。
规则三，保护下单与支付回调。表达式：(http.request.uri.path contains “/checkout” and not http.referer contains “yourdomain.com”)，动作选 Managed Challenge。Referer 检查不是绝对可靠，但能挡住大量直接 POST 的脚本。
如果站点用 WordPress 并启用了 W3 Total Cache，前置 Cloudflare 与缓存层的协作要格外注意，建议参考 WordPress W3 Total Cache 调优实战 里关于缓存键与 cookie 透传的章节，避免被 challenge 的请求污染缓存。
四、误伤排查 SOP
误伤分两类：搜索引擎爬虫被挡、真实用户被反复挑战。
第一类好处理。在 Cloudflare 仪表板的 Bots → Verified Bots 列表里确认 Googlebot、Bingbot、Baiduspider 都在白名单内（默认就在）。然后在 Security Events 里筛 user-agent contains “Googlebot” and action eq “block”，如果有命中，看是哪条规则触发，通常是 OWASP Core Ruleset 的某条误伤，把对应 rule ID 加到该规则的 Skip 例外里。
第二类要看 ray id。让用户截图被拦截页面，记下 ray id，到 Security Events 里搜这个 ID，能看到完整的触发链：哪一层、哪条规则、什么动作。最常见的根因是用户 IP 落在某个数据中心 ASN（家用代理、企业出口、VPN）。这种情况建议把对应规则的动作从 Block 改成 Managed Challenge，给一次自证机会。
如果防护链路前置了反向代理或者源站本身有 Nginx 层，记得在源站的访问日志里启用 CF-Connecting-IP 透传，否则排查时只能看到 Cloudflare 边缘 IP，定位不到真实客户端。详细的反代日志配置可以看 Nginx 反向代理与负载均衡配置 里的 X-Forwarded-For 段落。源站 SSH 层面如果还没做爆破防护，可以同时配上 Linux SSH 与 Fail2ban 加固 形成双层防线。
五、与 CDN 加速与上游主机的协同
Cloudflare 的安全能力建立在所有流量先到边缘节点的前提下。如果站点同时还在用其他 CDN 做静态资源分发，要确认动态路径（登录、API、下单）确实进了 Cloudflare 的 WAF，否则 Bot Fight 形同虚设。这一点在 Cloudflare CDN 中国大陆访问优化 里专门讲过路由分流的判断方法。
部署在海外 VPS 上的源站，建议把 origin firewall 配成只接受 Cloudflare IP 段。这一步是 Bot Fight 真正生效的前提，否则攻击者绕过 Cloudflare 直接打源站 IP，前面所有规则都白配。完整的源站加固流程参考 美国 VPS 部署完整教程。
六、总结与下一步
防护策略不是一次性配完就完事，建议每月看一次 Security Events 的 Top Rules 并调整阈值。促销窗口前一天可把所有规则动作临时改为 Log 模式跑半天，确认无误再切回 Block。如果你需要更深度的爬虫识别，可以考虑 Cloudflare 的 Bot Management 付费产品，它额外提供 bot score 字段，能在自定义规则里做更细的判断。综合来看，Bot Fight 加 WAF 托管再加三条自定义规则这套组合已经能满足绝大多数中小站点的防护需求，推荐先按本文顺序灰度上线再按业务流量调整。如果你需要在 Hostease 主机上做这套部署，工单提交后可由我们协助。