做蜘蛛池时经常遇到一种情况：入口页日志里能看到搜索蜘蛛来抓，返回码也正常，但目标 URL 在日志里始终没有出现，偶尔出现一次还是 403 或者一段验证码页面。很多人第一反应是入口页没做好，实际上问题往往出在目标站这一侧的拦截上。
先分清：目标站到底返回了什么
入口页被正常抓取，只说明“发现链接”这一步没问题；搜索蜘蛛能不能进入目标 URL，取决于目标 URL 那一次请求的响应。排查时不要只看有没有被抓，要看那一条请求的返回码、响应体积和响应内容。
- 403 / 406：最常见，通常是 WAF 按 UA、IP 或请求特征直接拒绝。
- 429：短时间请求频率超限，多见于同一来源抓得太密。
- 503：可能是站点过载保护，也可能是拦截系统返回的伪装页。
- 200 但内容很小：返回的是验证页面或空壳，日志上看着正常，实际没拿到内容。
WAF 常见的触发条件
- 只放行浏览器 UA，把不认识的 UA 一律当作攻击流量拦截。
- IP 策略过严，把机房 IP 段整段拉黑。
- 单个来源短时间内访问次数过多，触发频率规则。
- 开启了 JS 挑战或 Cookie 校验，而搜索蜘蛛不会执行这些。
- 按地区限制访问，抓取来源地不在允许范围内。
- 入口页集中指向同一目标站，被识别为异常来源。
怎么从日志里确认是拦截，而不是别的问题
- 按目标 URL 过滤日志，看返回码的分布，而不是只看请求总量。
- 对比 UA，看搜索蜘蛛的请求是否稳定对应同一个返回码。
- 看响应体积，几十字节的 200 基本可以判定是拦截页。
- 看时间分布，如果只在某个时间段被拦，多半是频率规则在起作用。
- 用普通浏览器打开同一 URL 做对照，确认服务本身是否正常。
如果浏览器访问正常、只有搜索蜘蛛被拦，基本可以确定是拦截策略的问题；如果浏览器也异常，先查站点自身和 CDN 节点，而不是继续折腾入口页。
处理思路：优先让目标站放行，而不是想办法绕过
合理做法是在目标站侧调整策略：把已知搜索引擎的抓取来源加入白名单，或者关闭针对正常爬虫的 JS 挑战；降低入口页到同一目标站的链接密度，避免短时间内集中触发频率规则；检查 CDN 与 WAF 的规则顺序，确认没有互相覆盖。
不建议通过伪造 UA 或频繁更换来源去绕过拦截。这种做法既不能让目标 URL 稳定被抓到，还可能让目标站把整个来源段拉黑，后续更难恢复。
有一种情况看起来像拦截，其实不是
目标站自己返回 5xx、DNS 解析异常、CDN 节点回源失败，都会让搜索蜘蛛拿不到内容，表现和拦截很像。排查顺序建议是：先确认服务可用性，再确认拦截规则，最后才回头检查入口页和链接结构。
总的来说，入口页负责“被发现”，目标站负责“被抓到”。当发现正常、抓取失败时，把注意力从入口页移到目标站的响应记录上，通常能更快找到真正的原因。