蜘蛛池搭好之后，最常见的困惑是「入口页明明能打开，蜘蛛就是不来」。很多时候问题不在蜘蛛池本身，而在它前面的那一层：CDN、WAF、云防火墙、负载均衡。这些组件默认把「看起来像自动化访问」的请求当成威胁，而搜索蜘蛛恰好就是自动化访问。
先分清三类不同的拦截
规则拦截
WAF 的默认规则库里，大量条目针对的是扫描器、爬虫框架和异常请求特征。入口页如果带有比较规整的参数、模板化的正文，很容易命中规则，直接返回 403。这种情况在日志里表现为蜘蛛请求根本没到源站。
速率限制
蜘蛛抓取往往在短时间内集中访问，容易触发按 IP 或按 UA 的 QPS 限速。返回码通常是 429，也可能是 503。表面上看蜘蛛「来过」，但它什么内容都没拿到，抓取日志里只会留下一片失败记录。
回源与缓存问题
开了 CDN 之后，入口页可能被缓存成旧版本，或者回源时因为超时、源站证书问题拿到 5xx。有些 CDN 默认开启的 JS 挑战、人机校验，也会让蜘蛛拿不到真正的页面内容。
怎么确认蜘蛛是不是真的被拦了
- 直连源站测试：绕开 CDN，直接用源站 IP 访问入口页，看返回是否正常。
- 指定 UA 复现：用 curl 带百度、Google、必应的 UA 请求一次，记录返回码和响应体长度。
- 对比两层日志：把 CDN 或 WAF 的拦截记录与源站访问日志对照，看请求在哪一层消失了。
- 看返回码分布：如果蜘蛛的访问集中在 403、429、503，基本可以判断不是抓取意愿问题。
放行策略怎么写
原则是「精确放行」，不是「全站放行」。
- 官方 IP 段优先。百度、Google、必应都公布了自己的抓取 IP 段，按 IP 放行比按 UA 放行可靠得多。
- UA 白名单做辅助。UA 可以伪造，单独依赖它等于给所有人开门。
- 反向 DNS 校验。Google 官方建议对声称是 Googlebot 的请求做反向解析验证，其他搜索引擎也有类似机制。
- 给爬虫单独设速率阈值。把蜘蛛的 QPS 上限设得比普通用户宽松一些，但不要取消上限。
- 入口页不要被 CDN 长期缓存。如果入口页需要更新，缓存 TTL 要设短，或者让爬虫请求直接回源。
几个容易踩的坑
- 为了省事直接关掉 WAF。短期抓取是通了，安全风险会一直留在那里。
- 只按 UA 放行，等于没有放行。
- 忽略 CDN 的人机校验。页面返回 200，但内容是验证页，蜘蛛一样拿不到东西。
- 把 429 当成成功。日志里看着有访问，实际抓取量为零。
- 换服务器或换 CDN 之后忘了同步放行规则，抓取量下降却查不到原因。
一个可执行的排查顺序
- 直连源站，确认入口页本身返回 200。
- 带蜘蛛 UA 走完整链路请求一次，记录返回码和响应时间。
- 查 WAF 与 CDN 的拦截、限速记录，定位是规则命中还是频率命中。
- 放行官方 IP 段，观察 24 到 72 小时内的抓取日志变化。
- 如果仍然没有改善，再回头检查入口页的链接结构、robots 与站点地图。
把网络层的问题先排除掉，再看蜘蛛池本身，能省下大量无效调整。
小结
抓取效果是一条链路共同决定的：DNS、CDN、WAF、源站、入口页、链接，任何一环挡住蜘蛛，后面的优化都白费。建议把放行规则和服务器配置一起纳入日常巡检，换机器、换 CDN、改规则之后都重新验证一次，并把验证结果记进台账，方便前后对比。