MaxAEO

WAF拦截AI爬虫：403定位、身份验证与最小放行指南

WAF拦截AI爬虫时的响应码、挑战页和安全规则诊断流程

作者：

MaxAEO Research Team

在

WAF拦截AI爬虫，是指边缘防火墙、机器人管理或速率规则对AI抓取器返回403、挑战页或429，使其无法取得公开内容。

处理顺序应是：确认该爬虫是否应该被允许 → 判断403产生在哪一层 → 验证真实身份 → 只放行公开路径和必要方法 → 保留攻击检测与速率限制。

不要因为 robots.txt 已允许就认定 WAF 配置错误，也不要直接按 User-Agent 关闭整站防护。

WAF拦截AI爬虫时的响应码、挑战页和安全规则诊断流程

AI爬虫返回403，最快怎样定位？

**先保存客户端响应，再查询边缘裁决，最后确认请求是否到达源站。**如果边缘日志显示 Block 或 Challenge，而源站没有对应请求，拦截发生在 CDN/WAF；如果源站收到请求并返回403，则应检查服务器、应用鉴权或安全插件。

按以下顺序排查：

  1. 确认目标爬虫、目标路径和业务放行策略。
  2. 对同一 URL 发出低频对照请求，保存响应头和响应体。
  3. 记录 UTC 时间、URL、方法、出口 IP、状态码和请求 ID。
  4. 在 CDN/WAF 日志中检索同一请求及终止规则。
  5. 检查源站访问日志中是否存在匹配记录。
  6. 使用厂商官方信息验证真实爬虫的来源 IP。
  7. 仅调整误命中的规则，用原请求做正向和负向复测。

robots.txt 只是抓取指令，不是身份验证或访问授权。RFC 9309并没有赋予 robots.txt 覆盖防火墙策略的能力。即使写了 Allow: /，WAF 仍可拒绝请求。

为什么Googlebot能抓取，AI爬虫却被WAF拦截？

**搜索引擎爬虫与AI爬虫可能命中完全不同的机器人分类、IP信誉和速率规则。**放行 Googlebot 不代表系统会自动信任 OAI-SearchBot、GPTBot 或其他AI抓取器。

常见原因包括：

  • WAF 只信任内置的已验证搜索引擎机器人；
  • 未验证机器人被统一执行 JavaScript 挑战；
  • User-Agent 中的 bot、crawler 或产品名称命中字符串规则；
  • 来源 ASN、云服务商、国家或 IP 信誉被限制；
  • Bot Score 或自动化流量阈值设置过严；
  • 同一出口 IP 抓取过快，触发共享速率限制；
  • GET 可以访问，但 HEAD 被服务器或规则拒绝；
  • 首页放行，深层路径、参数 URL 或重定向后的域名被拦截；
  • 403 被 CDN 缓存，规则修改后仍返回旧响应；
  • WAF 已放行，但 Nginx、ModSecurity、CMS 插件或应用鉴权拒绝请求。

还要先区分误拦截与有意阻止：如果品牌政策不允许某个训练型爬虫使用内容，403可能符合预期，不应当修复。

403、429、挑战页和软拦截有什么区别？

**状态码只是线索，不能单独证明拦截层。**必须同时检查响应头、响应体、边缘动作和源站日志。

观测结果 可能原因 首要证据
403，页面带 CDN 品牌或请求 ID 边缘 WAF 拦截 边缘安全事件、规则 ID
403，含 cf-mitigated: challenge Cloudflare 挑战 Challenge 规则及跳过条件
403，网站自有错误模板 源站或应用拒绝 源站状态码、应用日志
429，含 Retry-After 速率限制 计数窗口、共享出口 IP
503或200，但正文是验证页面 JS挑战或软拦截 Content-Type、正文摘要
200，但正文是登录页、空壳页 应用软错误 标题、正文长度、内容哈希
301/302后变成403 跳转目标受阻 每一跳的 Host、Location
浏览器200，AI标识403 机器人分类或UA规则 同IP、同URL对照结果

Cloudflare 官方说明，挑战响应可以通过 cf-mitigated: challenge 识别，详见挑战页响应检测文档。检测时还应核对 Content-Type 和正文，不能只搜索页面上的品牌文字。

MaxAEO四证据闭环：不要只凭curl判断

MaxAEO建议用四类证据完成归因。至少要有客户端证据和一项服务端证据，才能认定WAF拦截AI爬虫。

证据 需要保存的字段 能证明什么 不能证明什么
客户端响应 状态码、响应头、正文摘要、耗时 客户端实际收到的结果 403由哪条规则产生
边缘裁决 动作、规则ID、Bot分类、边缘状态码 CDN/WAF如何处理请求 源站最终返回的正文
源站到达 时间、URI、方法、源站状态码 请求是否通过边缘 请求是否为真实厂商爬虫
身份验证 官方IP范围、验证目录、官方UA 请求是否来自目标平台 该请求是否应该访问所有路径

用边缘—源站矩阵确定责任层

边缘日志 源站日志 判断
有终止动作 无请求 CDN/WAF在边缘拦截
显示放行 有请求且源站403 源站、应用或安全插件拒绝
无记录 有请求 日志采样、旁路链路或检索条件错误
无记录 无请求 可能请求了其他域名、DNS链路异常或时间未对齐

“源站无请求”只有在日志完整、时区一致、虚拟主机正确的前提下才有效。使用 CDN 时，源站看到的 TCP 对端通常是 CDN 节点，不能只按连接 IP 搜索；还要检查厂商转发的客户端 IP、URL、时间和请求 ID。

如何设计可复现的对照测试？

**先做低频配对测试，不要一开始连续发送几十次请求。**大量 curl 本身就可能触发限速，从而污染诊断结果。

建议选择以下页面：

  • /robots.txt；
  • 首页；
  • 一篇公开文章；
  • 一个深层内容页；
  • 一个明确受保护的路径，如 /admin/。

每个公开 URL 先执行两次 GET：一次使用普通客户端标识，一次使用待诊断的AI标识。两次请求应使用相同出口 IP，并尽量控制在相近时间。

curl -sS --max-time 20 \
  -D browser.headers \
  -o browser.body \
  -A "Mozilla/5.0" \
  "https://example.com/article"

curl -sS --max-time 20 \
  -D ai-bot.headers \
  -o ai-bot.body \
  -A "GPTBot" \
  "https://example.com/article"

shasum -a 256 browser.body ai-bot.body

这只能验证规则是否区别对待 User-Agent，不能证明第二个请求来自真正的 GPTBot。curl 也不等于真实浏览器，它没有完整的 JavaScript、Cookie和浏览器指纹能力。

首次测试不要使用 curl -I，因为它发送 HEAD 请求，可能命中不同规则。也不要立即加 -L 跟随跳转；先记录每个 Location，再逐个检查跳转目标是否位于另一域名或另一套 WAF 下。

如何判读一组对照记录？

以下是演示记录，不是行业统计：

时间 身份标识 客户端结果 边缘动作 源站记录
10:00:00 Mozilla/5.0 200 Allow 有
10:00:30 GPTBot 403 + Challenge Managed Challenge 无

这组数据只能说明测试 IP 上带有 GPTBot 标识的请求触发了边缘挑战。由于来源 IP 未经验证，它不能证明真实 GPTBot 被拦截，更不能据此创建 User-Agent contains GPTBot → Allow 规则。下一步应检索真实、已验证爬虫的日志。

WAF日志要检查哪些字段？

目标不是找到一条403，而是找到终止请求的具体规则和执行动作。

至少提取以下字段：

  • UTC 时间戳；
  • 客户端 IP、国家和 ASN；
  • Host、URI、查询参数和请求方法；
  • User-Agent；
  • 边缘状态码与源站状态码；
  • Block、Challenge、Rate Limit、Allow 或 Skip 动作；
  • 终止规则 ID、规则组和匹配表达式；
  • Bot Score、已验证机器人标记或机器人类别；
  • 请求 ID、Ray ID或追踪 ID；
  • 响应字节数、缓存状态和处理耗时。

AWS WAF 可重点查看 action、terminatingRuleId、ruleGroupList 和 httpRequest。字段定义见AWS WAF日志字段文档。

推荐持续计算三个运营指标：

  • 已验证爬虫边缘拦截率＝被终止的已验证请求 ÷ 边缘收到的已验证请求；
  • 源站到达率＝源站匹配请求数 ÷ 边缘收到的请求数；
  • 有效内容交付率＝返回有效正文的2xx请求 ÷ 已验证请求数。

“有效正文”应排除挑战页、登录页、空白HTML和自定义软错误页。

如何确认是真实AI爬虫，而不是伪造流量？

**User-Agent 是自报字段，任何客户端都能伪造。**安全放行应以平台官方公布的 IP 范围、CDN已验证机器人信号或厂商明确提供的DNS验证方法为主，User-Agent只能作为附加条件。

验证步骤如下：

  1. 从边缘日志取得真实客户端 IP，而不是源站看到的 CDN 节点 IP。
  2. 查询对应AI平台的官方爬虫文档。
  3. 将来源 IP 与官方、可更新的地址范围匹配。
  4. 同时核对完整 User-Agent，不使用宽泛的关键词包含规则。
  5. 检查 IPv4、IPv6 和官方地址列表是否已过期。
  6. 若平台提供反向DNS验证，再按其指定域名执行反查和正向复核。
  7. 无法验证时，不创建永久白名单，只允许受控测试或保持拦截。

Google的反向DNS验证流程适用于 Googlebot，具体步骤见Googlebot验证文档。不能在没有官方说明时，把同一方法和Google域名规则套用到其他AI爬虫。

OpenAI在官方爬虫说明中区分了不同用途：

标识 主要用途 策略建议
OAI-SearchBot 支持内容出现在ChatGPT搜索结果中 若希望获得搜索可见度，可放行公开内容
GPTBot 用于模型改进相关抓取 按内容授权和数据使用政策独立决策
ChatGPT-User 用户操作触发的页面访问 与自动化索引流量分开记录和限速

不要因为希望进入ChatGPT搜索，就自动放行所有OpenAI机器人。搜索发现、训练抓取和用户触发访问是三个不同的策略问题。

同样，Google-Extended 是 robots.txt 中的控制标记，并不是一个需要在 WAF 中放行的独立 User-Agent；其设置不影响网页在Google搜索中的收录或排名。具体定义见Google常用抓取工具说明。

如何最小范围放行AI爬虫？

最安全的方案不是“允许某个UA”，而是只跳过一条已确认误命中的机器人规则，同时保留SQL注入、跨站脚本、路径穿越和速率防护。

最小放行规则应同时约束五个维度：

维度 推荐条件 不推荐做法
身份 官方IP或已验证机器人信号 仅匹配User-Agent关键词
路径 /blog/、/docs/等公开内容 放行整个域名
方法 GET；确有需要时加入HEAD 允许POST、PUT、DELETE
规则范围 只跳过误命中的挑战或Bot规则 跳过全部WAF阶段
速率 按平台、Host和路径单独限速 所有机器人共用一个无限额度

可将厂商无关的策略表达为：

如果：
  来源属于目标平台的官方地址范围
  且 User-Agent 与该平台官方标识一致
  且方法为 GET 或 HEAD
  且路径属于公开内容目录
  且路径不属于登录、后台、结算、账户或 API
那么：
  仅跳过已确认误命中的机器人挑战规则
  继续执行攻击检测与独立速率限制
  记录规则标签、请求 ID、来源和处理结果
否则：
  按现有安全策略继续评估

敏感路径至少应包括：

/admin/
/login/
/account/
/checkout/
/cart/
/api/
/graphql/
带预览令牌或私密查询参数的 URL

AI 爬虫最小权限放行规则的条件、保留防护项与回滚开关

Cloudflare与AWS WAF的实施注意点

在 Cloudflare 中，应先用 Ray ID 找到具体安全事件，再让 Skip 只覆盖相关机器人挑战或指定规则。不要因为一条误判而跳过所有托管规则。

在 AWS WAF 中，应根据 terminatingRuleId 定位规则组，再为该规则建立窄范围例外。位于规则链前部的终止型 Allow 可能使后续规则不再评估，因此不能把“官方IP集合”简单放到最前面全量允许。

无论使用哪家厂商，规则都应包含：

  • 负责人和变更工单；
  • 生效时间与复查日期；
  • 命中日志标签；
  • 一键回滚方式；
  • 官方IP列表更新机制；
  • 修改前后的规则版本。

速率限制应该设置多少？

**没有适用于所有网站的固定每分钟请求数。**阈值应同时受真实抓取基线、缓存命中率和源站剩余容量约束。

建议先收集7至14天日志，并按“平台 × Host × 路径组”统计：

  • 每分钟请求数的中位数、P95和峰值；
  • 最大并发请求数；
  • 缓存命中率；
  • 429比例；
  • 源站P95响应时间；
  • 5xx错误率。

把历史 P95 作为观察起点，而不是直接当作硬上限。阈值必须低于源站可承受的增量；页面生成成本高、缓存命中率低时，应进一步收紧。

如果只是频率过高，优先返回429并提供合理的 Retry-After，不要把限速问题伪装成永久403。不同平台应使用独立计数器，避免一个爬虫耗尽所有机器人额度。

修复后怎样验收？

验收必须同时证明目标内容恢复、敏感路径仍受保护、真实爬虫身份有效且源站负载可控。

正向测试

  • /robots.txt 可正常取得，内容类型和正文正确；
  • 首页、文章页和深层公开页面返回预期的200、304或正常重定向；
  • 真实、已验证AI爬虫的请求能在源站日志中匹配；
  • 返回正文包含预期标题和主要内容，不是挑战页或登录页；
  • 403、429和5xx没有异常升高。

负向测试

  • /admin/、/login/、/account/和/api/仍被拒绝或要求认证；
  • 伪造相同 User-Agent、但来源IP未经验证的请求不会获得例外；
  • POST、PUT、DELETE等非必要方法不会因爬虫规则绕过防护；
  • SQL注入、跨站脚本和路径穿越规则仍正常执行；
  • 超过限速阈值的请求仍会被控制。

跨时间复查

规则修改后应至少完成即时、24小时和7天三次复查。重点检查官方IP变化、IPv6遗漏、规则优先级、缓存旧响应和多个域名使用不同WAF配置等问题。

WAF放行后，Google排名和AI可见度会提升吗？

不一定。WAF放行只是恢复可访问性，不是排名加分项。

如果 Googlebot 一直可以正常抓取，仅拦截 GPTBot 通常不会直接降低Google自然搜索排名。反之，如果同一条WAF规则也误伤 Googlebot、页面资源或渲染请求，则可能影响抓取、渲染和索引。

对AI搜索而言，页面可访问只是必要条件。是否被引用还取决于：

  • 页面是否直接回答目标问题；
  • 内容是否有明确实体、作者和更新时间；
  • 是否提供可核验的数据、定义和方法；
  • 是否获得其他可信网站引用；
  • 内容是否足够新且与查询相关；
  • 对应平台是否使用该爬虫建立搜索索引。

修复后应分别监测：

  1. 已验证爬虫请求量和有效内容交付率；
  2. 目标页面是否出现在AI答案引用中；
  3. 固定问题集下的品牌提及率、引用URL和答案位置；
  4. Google Search Console中的抓取、索引、展示和点击变化。

抓取恢复后，可通过定义与术语页建立可摘录答案，通过年度基准报告提供一手数据，并用主题统计页集中维护可验证来源。这些内容资产比单纯增加可抓取URL更可能形成长期引用价值。

常见问题

robots.txt已经允许，为什么AI爬虫仍然返回403？

robots.txt 只表达抓取偏好，不负责身份验证和网络访问。请求仍需经过 CDN、WAF、反向代理、服务器和应用鉴权；任何一层都可以返回403。

可以直接把GPTBot或OAI-SearchBot加入UA白名单吗？

不建议。User-Agent可以伪造。至少应组合官方IP或已验证机器人信号、完整UA、公开路径、安全方法和独立速率限制。

403和429应该采用同一种修复方式吗？

不应该。403通常对应策略拒绝、权限限制或挑战；429表示请求超过速率阈值。前者重点查终止规则和身份，后者重点查时间窗口、并发量及共享出口IP。

为什么curl返回200，真实AI爬虫仍然收到403？

WAF可能同时评估来源IP、ASN、TLS特征、请求频率、Cookie和机器人分类。curl只能模拟部分请求字段，无法复制真实爬虫的网络来源和访问节奏。

CDN显示放行，但AI爬虫仍然抓不到怎么办？

检查源站访问日志、反向代理规则、ModSecurity、CMS安全插件、应用鉴权和重定向链。即使状态码为200，也要确认正文不是登录页、挑战页、空白HTML或软错误页。

是否需要放行所有AI平台？

不需要。应根据搜索可见度目标、内容授权、服务器成本和数据使用政策分别决定。允许搜索型抓取不等于必须允许训练型抓取。

修改规则后为什么仍然返回旧的403？

403或挑战页可能被边缘缓存，也可能由另一域名、IPv6链路或不同安全规则产生。核对缓存状态、Host、DNS解析、重定向链和规则部署范围后再复测。

最终诊断清单

  • 已明确目标爬虫是否应该被允许；
  • 已保存状态码、响应头、正文摘要、时间和请求ID；
  • 已区分403、429、挑战页和200软拦截；
  • 已定位具体终止规则，而不是只凭User-Agent猜测；
  • 已确认请求是否到达源站；
  • 已使用厂商官方信息验证爬虫来源；
  • 放行范围仅覆盖公开路径和必要方法；
  • 仅跳过误命中的规则，未关闭核心攻击防护；
  • 已设置独立速率限制、日志标签和回滚方式；
  • 已完成公开页面正向测试和敏感路径负向测试；
  • 已检查缓存、IPv6、重定向和多域名配置；
  • 已建立抓取、索引与AI引用的独立监测基线。

更多文章