入口页能在浏览器里正常打开，不代表搜索蜘蛛就能抓到。很多蜘蛛池搭好之后，日志里人访问一切正常，蜘蛛却屈指可数，排查半天内容、链接、结构，最后发现问题出在访问控制这一层——CDN、WAF、云安全组或者服务器的限速规则，把蜘蛛挡在了门外。

访问控制管的是「谁能进来」，不是「进来看到什么」

内容模板、URL 结构、内链布局这些，属于「进来之后看什么」的问题；而 CDN、WAF、防火墙、反向代理限速、JS 人机验证这些，决定的是请求能不能到达你的服务器。后者一旦拦错，前面的优化都无从谈起，因为蜘蛛根本没拿到页面。

常见的几种拦截来源

• CDN 的人机验证：部分 CDN 默认对「可疑流量」返回 JS 挑战页，蜘蛛拿到的是一个需要执行脚本的页面，而它通常不会执行。
• WAF 规则：拦截空 UA、非浏览器 UA、特定关键词、异常参数，蜘蛛请求很容易命中。
• 频率限制：limit_req、limit_conn 或者云厂商的速率防护，按 IP、按连接数限流，蜘蛛短时间内连续请求多个入口页就会触发 429 或 503。
• IP 段封禁：把整段机房 IP 拉黑，顺手把蜘蛛也一起封了。
• 地域封禁：只放行某些地区，海外蜘蛛直接 403。
• 证书与协议问题：HTTPS 配置错误、强制跳转成环，同样会让抓取失败。

怎么判断是不是被拦了

• 日志里几乎没有蜘蛛记录，但其他渠道显示确实有抓取动作。
• 响应码大量是 403、429、503，而不是 200。
• 返回的 HTML 是验证页或跳转页，正文长度明显偏短。
• 用 curl 分别带浏览器 UA 和蜘蛛 UA 请求同一个 URL，对比状态码与响应内容。
• 换一个不走 CDN 的直连方式测试，看结果是否不同。

注意不要只看一次结果。有些防护是概率触发的，多测几次、换不同时段测，结论才靠得住。

放行的基本思路

1. 先验证再放行：不要只看 UA 就放行。更稳妥的做法是对来源 IP 做正反查，确认归属后再加入白名单。
2. 给已知蜘蛛 IP 段单独开白名单，与普通访客规则分开，避免互相干扰。
3. 关掉入口页的 JS 挑战，或者把入口页路径排除在挑战规则之外。
4. 放宽限速阈值：蜘蛛并发抓取往往比单个用户猛，按普通访客的阈值限流很容易误伤。
5. 尽量保证返回 200：即使要挡，也尽量别用 403，返回可读内容比返回错误页更可控。

几个容易被忽略的点

• CDN 缓存了错误页：回源失败时返回的 503 或验证页被缓存下来，之后蜘蛛拿到的可能一直是这张错误页，改完规则记得清缓存。
• UA 差异：移动端与桌面端蜘蛛的 UA 不同，规则只测了一种，另一种可能被拦。
• 改完需要观察期：白名单生效后不会立刻反映在日志里，建议至少观察几天再下结论。
• 别只盯首页：入口页路径如果被单独规则覆盖，首页正常不代表入口页正常。

蜘蛛池里最没必要的一种浪费，是内容做得不错，却因为一条限流规则让蜘蛛空手而归。抓取通畅是前提，内容与链接是加分项，顺序别反了。

建议的排查顺序

从外到内一层层剥：先看 CDN 或 WAF 的拦截日志，再看服务器访问日志，最后看应用层有没有异常跳转。确认蜘蛛能稳定拿到 200、并且返回的是有实质内容的 HTML，再去谈入口页的数量、互链和更新节奏。把这一步做在前面，后面很多「蜘蛛不来」的困惑会少掉一大半。