入口页自己用浏览器打开一切正常，但抓取量突然掉到几乎为零，链接也没再被继续发现。这种“人看得见、蜘蛛看不见”的情况，很多时候不是蜘蛛池本身的问题，而是请求在到达源站之前就被拦掉了。
为什么拦截问题容易被误判
WAF、CDN 的 Bot 管理、云厂商的爬虫挑战，通常工作在源站之前。搜索蜘蛛拿到的可能是 403、429，或者一个需要执行 JavaScript 的验证页，而不是入口页的真实 HTML。源站日志里什么都看不到，于是很容易得出“蜘蛛根本没来”的结论，转头去改蜘蛛池结构，方向从一开始就错了。
常见异常表现
- 抓取日志中搜索引擎 UA 的请求大量返回 403、406、429，并且集中在一段时间内。
- 源站访问日志里搜索蜘蛛的 IP 几乎消失，但 CDN 或 WAF 日志里有对应记录。
- 入口页还能被抓，入口页下面的目标 URL 请求直接被拒，抓取深度明显变浅。
- 返回的响应体是验证页、拦截提示页，而不是入口页的正常内容。
- 抓取频率从稳定变成断崖式下降，同时并没有改过 robots 或服务端配置。
排查顺序
- 先对比两层日志。把源站日志和 CDN / WAF 日志按时间对齐，看同一时间点搜索引擎 IP 的请求去了哪里、被哪条规则命中。
- 验证 IP 是否真的是搜索蜘蛛。以 Googlebot 为例，可先反向 DNS 解析到 googlebot.com 或 googleusercontent.com，再正向解析确认一致。只凭 UA 判断并不可靠，UA 可以随便伪造。
- 检查安全规则的触发条件。常见的有爬虫挑战、单 IP 频率限制、地域封禁、UA 黑名单、缺少特定请求头即拦截等。
- 确认 robots 与防火墙不冲突。robots 允许抓取，不代表 WAF 会放行，两者是相互独立的两层。
- 小范围放行后持续观察。放行后不要立刻下结论，抓取恢复通常有延迟，观察几天再判断效果。
放行时的几个取舍
放行不等于全开。比较稳妥的做法是：按搜索引擎公布的 IP 段做白名单，同时保留基本的频率上限，避免真实蜘蛛和伪装爬虫一起被放进来；对入口页这类需要被抓的路径单独放宽，管理后台和接口路径继续严格限制。
用 UA 字符串做放行条件要格外谨慎。搜索引擎的 UA 是公开的，任何脚本都能照抄，真正可靠的还是 IP 验证。如果 CDN 提供了官方的搜索引擎验证功能，优先使用它。
常见误区
- 看到 403 就认为蜘蛛没来过，忽略了被拦截也算一次访问。
- 为了省事直接关掉整个 WAF，短期抓取可能恢复，但其他风险会一起暴露。
- 只放行了首页，忘了入口页下面的目标 URL 路径。
- 放行后马上把入口页数量翻倍，结果触发新的频率限制。
抓取异常先分层定位：域名解析、CDN、WAF、源站、应用，一层层往下看，比直接改蜘蛛池更省时间。
拦截类问题的排查逻辑其实不复杂：先确认请求到底有没有到源站。分清了这一点，再决定是调整安全策略还是优化入口页结构，就不至于白折腾。