📌 Cloudflare Firewall 规则设计备忘录

主题：Rule 01（白名单 / Skip 规则）的设计原则与最终定稿

---

一、背景与问题起点

在 Begoodtex 外贸 B2B 网站的实际运行中，持续发现大量异常访问请求，具备以下特征：

• 伪装成 Googlebot / Bingbot / SEO 工具
• 实际来源为 Hostinger、公有云、中国云厂商
• 高频访问 WooCommerce 分类页，携带 filter_ 等筛选参数
• 明确目的为：
  • 参数枚举
  • 产品矩阵抓取
  • 竞品数据分析

因此，问题的本质并不是「是否允许爬虫」，而是：

如何在 Cloudflare 中，只放行“真正可信”的搜索引擎 / 社媒 Bot，同时彻底阻断伪装 Bot 与中国云厂商来源？

---

二、总体设计目标（不可妥协）

在规则设计阶段，明确以下 硬性目标：

1. 唯一信任根：Cloudflare 验证结果
   • 不信任 User-Agent
   • 不信任自称 Googlebot / Bingbot
2. 中国云厂商必须作为全局否决条件
   • 不论是否为 Bot
   • 不论是否声称官方
3. 仅允许极少量“业务必要”的第三方 Bot
   • 只能通过 ASN
   • 且必须排除中国云厂商
4. 避免 Skip 短路问题
   • 不允许出现「先 Skip，后 Block 永远不执行」的逻辑
5. 长期可维护
   • 半年或一年后回看，无需重新分析即可理解
   • 扩展时不容易误放流量

---

三、Rule 01 的核心设计思想

1️⃣ 核心原则（一句话）

先定义谁“永远不可信”，再在剩余范围内谈放行。

结论是：

• ❌ 中国云厂商：永远不在信任边界
• ✅ Cloudflare 已验证 Bot：最高可信
• ⚠️ 少量第三方 Bot：只能通过 ASN 白名单

---

2️⃣ 为什么 Rule 01 不使用 User-Agent

• User-Agent 可 100% 伪造
• 实际攻击日志中，大量伪装 Bot 正是通过 UA 绕过低级规则
• 仅依赖 UA 等同于给爬虫开后门

结论：Rule 01 中严禁使用 UA 作为放行依据。

---

3️⃣ 为什么不能“先 Skip 再 Block”

Cloudflare Firewall 的执行机制为：

一旦命中 Skip，后续所有 Firewall / WAF 规则将不再执行

因此：

• 若先写 cf.client.bot → Skip
• 再写 中国云 ASN → Block

则 中国云上的 Bot 会被提前 Skip，Block 永远无法生效。

最终采用的设计是：在同一条规则中，通过 and not 实现全局否决。

---

四、Rule 01 最终定稿（生产环境版本）

✅ 规则用途

• 作为 第一条 Firewall 自定义规则
• 动作：Skip
• 用于放行可信 Bot，使其免疫后续防爬 / WAF 规则

---

✅ 最终可保存的表达式（无注释版）

(
  cf.client.bot
  or ip.geoip.asnum in {32934 8075 23033 396982 13414 13238 54113}
)
and not ip.geoip.asnum in {45102 37963 45090 132203 136907}

---

🧠 规则的人话翻译（快速理解版，非常重要）

只要是：

• Cloudflare 已验证过的 Bot
  （如 Google、Bing、Meta、OpenAI 等，cf.client.bot = true）
  或
• 来自明确列入白名单 ASN 的官方社媒 / 搜索生态 Bot
  （如 Facebook、Microsoft、Pinterest、X、Yandex、DuckDuckGo）

并且：

• 不来自任何中国云厂商（阿里 / 腾讯 / 华为）

👉 才允许直接放行（Skip），不再进入后续 Firewall 与 WAF 规则。

📌 中国云厂商 = 全局否决条件
无论是否为 Bot、是否自称官方、是否被 Cloudflare 识别，都不在信任边界内。

---

🔍 ASN 含义说明（仅用于备忘，不写入表达式）

允许放行（S / A 级）：

• 32934 — Meta / Facebook
• 8075 — Microsoft（Bing / LinkedIn / OpenAI）
• 23033 — Moz（DotBot）
• 396982 — Pinterest
• 13414 — X / Twitter
• 13238 — Yandex（A 级，业务取舍）
• 54113 — DuckDuckGo（A 级，业务取舍）

全局否决（X 级）：

• 45102 / 37963 — 阿里云体系
• 45090 / 132203 — 腾讯云体系
• 136907 — 华为云

---

五、关于 A 级 ASN（13238 / 54113）的说明

• 放行 Yandex、DuckDuckGo 属于 业务曝光层面的权衡
• 并非安全必需
• 已达成共识：
  • 若后续发现其大量访问带 filter_ 参数
  • 或行为明显偏离搜索引擎特征
    👉 可直接从白名单中移除，降级为 Challenge

Rule 01 的结构支持这种“随时降级”，无需重构整体规则。

---

六、明确的禁忌事项（防误改清单）

以下行为 明确禁止：

1. ❌ 在 Rule 01 中加入 User-Agent 判断
2. ❌ 将 AWS / GCP / Azure / Cloudflare 等公有云 ASN 加入白名单
3. ❌ 将中国云 ASN 从 and not 中移除
4. ❌ 将 Rule 01 拆分为「先 Skip / 后 Block」
5. ❌ 将 Ahrefs / Semrush / MJ12bot 等 SEO 工具加入 Skip 白名单

---

七、Rule 01 与后续规则的分工关系

• Rule 01：只解决“身份是否可信”
• 行为层（如 filter_、参数枚举）交由：
  • Managed Challenge
  • Bot Score / Threat Score
• 结果：
  • 搜索引擎完全不受影响
  • 可疑爬虫持续被消耗成本

---

八、长期维护原则（给未来的你）

Rule 01 是“信任边界”，不是“放行名单”。

任何一个来源，只要开始表现得像爬虫，就不应继续享受 Skip 特权。

---

九、最终总结（一句话版本）

Rule 01 以 Cloudflare 的 Bot 验证为唯一信任根，结合极小化 ASN 白名单，并通过 and not 中国云 ASN 作为全局否决条件，从逻辑与执行层面彻底避免 Skip 短路与 Bot 伪装问题，是一条可长期运行、可审计、可交接的生产级白名单规则。

---