蜘蛛池的入口页大多不放在目标站同一台服务器上，常见做法是挂在其他域名、其他 IP 甚至其他机房的机器上。这些机器同样可能套着 CDN、WAF 或面板类防护。一旦防护规则把搜索蜘蛛当成攻击流量，蜘蛛看到的页面就和你以为的入口页不是同一份，里面的目标链接也就无从谈起。
拦截不一定表现为抓取失败
很多人以为被拦截就是日志里没有蜘蛛记录。实际情况往往更麻烦：请求确实到了服务器，也返回了 200，但内容被替换掉了。
- 返回 403、406 或自定义拦截页，状态码看起来只是一次普通的错误响应；
- 返回 200，但内容是 JS 挑战页、验证码或“正在验证您的浏览器”；
- 回源正常，CDN 边缘节点却返回缓存的旧版本或错误版本；
- 同一 URL，蜘蛛 UA 拿到 A 页面，普通浏览器 UA 拿到 B 页面；
- 请求被限速、丢包或超时，蜘蛛只抓到一半 HTML，后半部分的链接没被解析到。
这几种情况在服务器日志里都可能呈现为“有访问、有 200”，所以只看有没有抓取记录，很容易误判。
先分清是拦截还是别的环节
入口页里的链接没被跟进，原因不止防护一种。排查时建议按顺序排除。
- 换 UA 回源测试：用 curl 或浏览器插件，分别带上普通 UA 和搜索蜘蛛 UA 请求同一个入口页，对比返回的状态码、Content-Length 以及正文前几百个字符是否一致。
- 绕开 CDN 直连源站：把域名临时解析到源站 IP，或在 CDN 后台使用回源测试，确认源站本身没有被面板拦截。
- 看蜘蛛侧是否真的来过：在服务器日志里匹配蜘蛛 UA 与已知 IP 段，确认请求数、返回码和响应时间。如果连请求都没有，问题在更前面的环节，比如 robots 规则、DNS 解析，或者这个入口页根本没被提交过。
- 确认返回的是完整 HTML：检查 Content-Length 与响应体实际长度是否一致，链接是否正好落在被截断的位置。
调整防护时的几个注意点
确认是拦截造成的问题后，处理方式要克制，不要为了放行而把整站防护关掉。
- 优先按已验证的蜘蛛 IP 段做白名单，而不是只按 User-Agent 放行。UA 可以随便伪造，只认 UA 相当于给恶意爬虫留了后门。
- 如果确实需要按 UA 放行，建议叠加频率限制，避免白名单被滥用。
- 关闭针对入口页的 JS 挑战，或者把入口页路径加入挑战豁免名单。
- CDN 缓存规则要确认不会缓存验证码页或错误状态响应，错误页建议设置不缓存或使用较短的 TTL。
- 改完后隔一段时间再看一次日志和抓取情况，确认拦截页没有再出现，而不是改完就当问题已经解决。
防护需求和抓取需求天然存在冲突，调整时优先精确放行而不是整体关闭；改完要用日志和回源测试验证，而不是凭感觉认为已经放通。
最后提醒一点：入口页能正常返回、蜘蛛也确实抓到了，也不等于里面的目标链接一定会被跟进和收录。抓取只是发现环节，后面的链接解析、去重、质量判断各有各的规则。把“入口页能稳定返回一份包含目标链接的正常 HTML”当作底线目标，比指望某一次防护调整带来收录变化要现实得多。