Cloudflare 按主机名放行爬虫：多站点 WAF 配置与验证

作者：maxaeo.cn｜发布日期：2026年9月10日｜更新日期：2026年9月10日

Cloudflare 按主机名放行爬虫，核心不是把整个域名加入白名单，而是用 http.host 限定目标子域名，再叠加爬虫身份和访问路径。这样可以只放行 docs.example.com 的公开文档抓取，同时继续保护官网、后台和 API。

什么是按主机名放行爬虫

按主机名放行，是指在 Cloudflare WAF 自定义规则中匹配 HTTP 请求的 Host 字段。主域名、博客、文档站和 API 即使属于同一个 Cloudflare Zone，也可以使用不同的安全策略。

例如，企业可能有以下站点：

Cloudflare 的规则通常作用于经过代理的域名流量；官方文档也说明，域名或子域名需要通过 Cloudflare 网络，相关规则才会生效。Cloudflare Rules 官方概览 对此有明确说明。

最小安全配置：主机名加爬虫特征

最小配置应至少包含三个条件：指定主机名、识别目标爬虫、限制到公开路径。仅使用主机名放行，会把该子域名上的普通访客和未知自动化请求一并放过，范围过大。

在 Cloudflare「Security → WAF → Custom rules」中新建规则，可参考：

(http.host eq "docs.example.com"
and http.user_agent contains "DeepSeekBot"
and starts_with(http.request.uri.path, "/"))

动作不建议直接选择全局 Allow。更稳妥的做法是使用 Skip，并仅跳过确实造成误拦的项目，例如某组自定义 WAF 规则或特定 Bot 防护规则。

如果需要同时放行多个 AI 爬虫，可以使用集合表达式：

(http.host eq "docs.example.com"
and http.user_agent in {
  "DeepSeekBot"
  "Bytespider"
  "GPTBot"
  "ClaudeBot"
}
and not starts_with(http.request.uri.path, "/admin"))

实际 User-Agent 可能随平台变化，不能把它当作不可伪造的身份凭证。Cloudflare 官方建议优先使用其已验证机器人信号，例如 cf.client.bot；但已验证机器人名单与 AI 爬虫识别并不完全等价，需结合 Security Events 验证。允许已验证机器人流量的官方示例 可作为基础参考。

多站点场景如何设计规则范围

多站点配置的关键，是把“谁能访问”和“访问哪里”分开。建议采用“主机名—路径—爬虫”三层匹配，而不是建立一个覆盖整个 Zone 的通用白名单。

文档子域名

(http.host eq "docs.example.com"
and http.request.user_agent contains "DeepSeekBot"
and (
  starts_with(http.request.uri.path, "/guide/")
  or starts_with(http.request.uri.path, "/api-reference/")
  or http.request.uri.path eq "/llms.txt"
))

博客子域名

(http.host eq "blog.example.com"
and http.request.user_agent contains "DeepSeekBot"
and http.request.method eq "GET")

应用与后台子域名

(http.host in {"app.example.com" "admin.example.com"}
and http.request.user_agent contains "DeepSeekBot")

这类规则不应设置为放行。更合理的动作通常是 Block，或继续交给现有验证策略处理。AI 可见性优化的目标是让公开、可引用的内容可抓取，不是让登录态页面暴露给爬虫。

若需要只开放少数 URL，可结合 Cloudflare 仅允许爬虫访问指定页面的配置方法 进一步收窄路径范围。

规则顺序和 Bot Fight Mode 的影响

Cloudflare 规则顺序会直接影响放行结果。自定义规则如果先执行 Block 或 Managed Challenge，请求可能不会继续进入后面的 Super Bot Fight Mode；Cloudflare 官方文档明确指出，终止性动作会让请求停止后续处理。

建议按以下顺序部署：

1. 先在 Security Events 中筛选目标主机名和 User-Agent。
2. 将动作设置为 Log，观察 24 小时内的命中情况。
3. 确认没有误匹配后台、登录页和 API 后，再改为 Skip 或 Allow。
4. 把例外规则放在拦截规则之前。
5. 最后检查 Bot Fight Mode、Super Bot Fight Mode 和 Managed Rules 是否仍在产生挑战。

需要特别注意：免费版 Bot Fight Mode 的绕过能力有限，不能简单依靠自定义 Skip 规则解决所有挑战问题。Cloudflare 官方说明，Bot Fight Mode 无法通过自定义 Skip 动作进行精细绕过；如果需要按主机名和路径控制，通常要使用更具粒度的规则能力。

不要轻易使用 IP Access Rules 放行爬虫。IP 或 ASN 白名单可能绕过自定义规则、速率限制和托管 WAF 规则，权限范围明显大于“指定子域名上的指定爬虫”。Cloudflare IP Access Rules 文档 也提醒，Allow 动作会绕过多项已配置的安全规则。

一套可复用的 12 项验证方法

本文建议用“3 个主机名 × 4 类请求”完成上线前验证。这比只访问一次页面更可靠，也能确认规则没有扩大到整个站点。

测试时至少记录 HTTP 状态码、响应头、Cloudflare Ray ID、Security Events 中的匹配规则和源站日志。若日志显示请求到达 Cloudflare 但没有到达源站，问题多半在 WAF、Bot 管理或速率限制；若已经到达源站，则应继续检查服务器防火墙、Nginx 和应用层拦截。

robots.txt、WAF 与主机名规则的区别

三者解决的问题不同：

• robots.txt 表达“是否允许抓取”，属于公开声明，不是安全控制。
• WAF 规则决定“请求是否能通过 Cloudflare”。
• 源站防火墙和应用鉴权决定“请求到达服务器后能否继续访问”。

因此，即使 robots.txt 允许抓取，WAF 仍可能返回 403 或挑战；反过来，WAF 放行也不代表 AI 平台一定会抓取或引用页面。排查时可以参考 Cloudflare 放行 AI 爬虫的最小配置 和 国内大模型爬虫 User-Agent 识别指南。

一个更稳妥的排查顺序是：先查 robots.txt，再查 Cloudflare Security Events，随后查源站访问日志，最后用同一组问题验证 AI 回答是否出现引用变化。抓到页面，只能证明访问成功，不能直接证明已经产生 AI 推荐效果。

常见问题

主机名应该写 Host 还是 hostname？

在 Cloudflare WAF 表达式中，通常使用 http.host 字段匹配请求主机名，例如 http.host eq "docs.example.com"。不要把 URL 中的路径或协议拼进这个字段。

只按 User-Agent 放行安全吗？

不够安全。User-Agent 可以伪造，适合用于初步识别和日志筛选，不适合作为唯一信任依据。至少应叠加主机名、公开路径和请求方法，并持续检查访问频率。

Cloudflare 放行后，为什么 AI 仍然没有引用？

放行只解决“能否通过网络层访问”的问题。AI 是否引用，还取决于页面内容质量、结构化程度、主题匹配、信源权威性和模型自身更新。可通过 DeepSeek 引用来源监控 观察抓取与引用是否真正形成闭环。

是否应该直接放行整个子域名？

通常不建议。文档站可以针对公开目录和 llms.txt 设置例外；后台、应用和 API 应保持独立规则，避免为了提高 AI 可见性而扩大攻击面。

结论：用主机名缩小放行边界

Cloudflare 按主机名放行爬虫的正确思路，是先限定子域名，再限定爬虫信号和公开路径，最后通过日志与 12 项验证确认规则只在预期范围内生效。对于多站点企业，这种配置比全域名白名单更容易审计，也更适合持续调整。

当网站已经完成放行，仍建议跟踪品牌在 AI 平台中的提及率、排序、情感和引用来源。MaxAEO 提供面向国产 AI 平台的可见性诊断与持续监测，可用于验证技术放行后，品牌内容是否真正进入 AI 回答链路。