做蜘蛛池的人常遇到一种情况：入口页的访问日志里，搜索蜘蛛来访的痕迹很清楚，链接也确实指向了目标URL，但目标URL的日志里只有零星几条抓取记录，状态码还经常是 403、429、503，甚至直接返回一个安全验证页面。抓取链路在最后一跳断掉，前面做得再顺也接不上。

先分清：是蜘蛛没来，还是来了被拦

这两种问题的处理方向完全不同，混在一起排查会浪费很多时间。

• 蜘蛛没来：目标URL的日志里连蜘蛛的 UA 和 IP 都搜不到，说明入口页没把链接有效传出去，或者链接本身不具备可抓取的条件。
• 来了被拦：日志里有对应 IP 或 UA 的请求记录，但状态码是 403、406、429、503，或者响应体是一段 JavaScript 跳转、验证码页面的 HTML。

还有一种容易被忽略的情况：请求根本没到你的源站，在 CDN 或 WAF 那一层就被拦下并直接返回了页面。这时源站日志干干净净，看上去像“蜘蛛没来”，实际是更早的一环出了问题。

常见的三类拦截来源

1. WAF 规则误伤

不少 WAF 的默认规则会把“高频访问同一路径”“缺少常规浏览器指纹”“来源 IP 集中在少数网段”当作攻击特征。搜索蜘蛛的抓取行为恰好符合这些特征：短时间内密集请求、通常不带 cookie、Referer 缺失。

2. CDN 回源被限制

如果目标URL前面挂了 CDN，CDN 回源时使用的 IP 和搜索蜘蛛的 IP 并不是一回事。有些源站防火墙只放行了搜索引擎的 IP 段，结果 CDN 回源请求被拦，源站返回 403 给 CDN，CDN 再原样透传给搜索蜘蛛。

3. 服务器层的防护和速率限制

Nginx 的 limit_req、云主机的安全组、面板类防护插件，都可能对单 IP 的并发连接数或单位时间请求数设上限。当入口页在较短时间内把大量抓取导向同一个目标URL时，很容易触到这个阈值。

排查顺序建议

1. 先在源站日志里按时间筛出目标URL的请求，重点看状态码分布，而不是只看总请求次数。
2. 用带搜索引擎 UA 的请求测试目标URL的响应头，观察返回码。注意这一步只能验证 UA 是否被针对，不能证明搜索蜘蛛本身一定抓得到。
3. 对比不带 UA、带普通浏览器 UA 的两次请求。如果只有搜索引擎 UA 被拒，基本可以锁定是 UA 相关规则在起作用。
4. 检查 CDN 或 WAF 的拦截日志，看是否有回源失败、安全策略命中的记录。
5. 用搜索引擎官方提供的网址检查工具发起实时抓取，看返回的 HTTP 状态和响应内容是什么。

如果连官方实时抓取都返回 403，问题一定在服务端策略上，而不是入口页的链接数量或分布。

放行搜索引擎时的几个注意点

• 不要只放行 UA 字符串。UA 可以随意伪造，只按 UA 放行等于给所有人开门。相对稳妥的做法是 UA 加反向 DNS 校验，或直接使用官方公布的 IP 段。
• IP 段要定期更新。官方会增删 IP 段，白名单长期不维护，某天蜘蛛换了网段又被拦，问题会重新出现。
• 速率限制别设得太紧。把搜索引擎 IP 单独归到一个更宽松的限速组，通常比统一阈值更稳。
• 验证页和 JS 跳转要慎用。这类中间页会让抓取停在半路，蜘蛛拿不到目标URL的实际内容。
• 确认入口页和目标URL是否在同一台服务器上。两者分开部署时，日志要分别看，不要拿入口页的正常状态去推断目标URL也正常。

容易被忽略的细节

有些站点为了防刷，会对疑似爬虫的请求返回 200，但内容为空，或者返回一段混淆过的 HTML。这种“软拦截”在状态码上完全看不出来，只能对比响应体长度和实际内容才能发现。

另外要清楚一点：蜘蛛池能影响的是蜘蛛愿不愿意来、来得多不多，解决不了服务端的拦截问题。抓取链路能不能真正走通，最终取决于目标URL对搜索蜘蛛是否可正常访问。排查时先把这一层理顺，再去调整入口页的链接形式，方向才不容易跑偏。