搜索蜘蛛抓取不到页面时，很多人的第一反应是去看服务器应用日志，翻不到记录就断定“蜘蛛没来”。但抓取链路并不止应用层这一段，DNS 解析、CDN 边缘节点、WAF 规则都可能让请求在到达服务之前就被拦下或改写。按层次从上到下核对，通常比在应用日志里反复搜索更有效率。

一、先确定请求是否真的到达了源站

排查之前先把观察点分开：边缘层日志（CDN、WAF）记录的是“有没有请求进来”，源站日志记录的是“请求有没有被应用处理”。两边对不上，问题大概率在中间层。

• 边缘有记录、源站无记录：多半是缓存命中未回源，或被 WAF 直接返回了拦截页。
• 边缘无记录、源站也无记录：需要往 DNS 与网络可达性方向查。
• 两边都有记录但状态码异常：属于应用层问题，回到 5xx、超时那条线核对。

二、DNS 与解析层核对

蜘蛛抓取前要先解析域名。解析层面出问题，表现往往是某段时间抓取几乎停滞，而且不分页面、不分路径。

• 解析是否长期稳定，是否出现过记录被误删、迁移期间同时存在冲突记录。
• 是否使用按地域或线路分流的解析，部分线路返回的结果是否可达。
• CNAME 链路过长或指向已下线主机，是否造成解析超时。
• DNS 服务商是否存在查询频率限制、查询被拒的情况。

记录一次解析结果快照（域名、返回 IP、TTL）在排查时很有用，至少能先排除“解析变了”这个变量。

三、CDN 与缓存层核对

缓存命中与回源

缓存命中本身是好事，但要注意两类情况：一是把临时的错误状态码缓存住了，二是缓存了旧的跳转规则，导致蜘蛛一直走到错误的地址。

边缘节点的差异

• 不同边缘节点缓存状态不一致，部分节点返回旧内容或验证页。
• 更换 CDN 或切换回源地址期间，是否存在节点仍指向旧源站。
• 是否对特定 User-Agent 做了差别化处理，例如对未知 UA 返回验证页面。

如果边缘层对蜘蛛 UA 返回了验证页或 403，源站日志里是看不到这次访问的，很容易被误判为“蜘蛛不来”。

四、WAF 与 IP、UA 规则核对

WAF 常因为高频访问、可疑路径或未知 UA 触发拦截。蜘蛛抓取的特征恰好是短时间内大量请求，容易被误伤。

• 是否屏蔽了云服务商 IP 段，而蜘蛛出口 IP 正落在其中。
• 是否采用 UA 白名单放行，白名单外的 UA 一律进入挑战验证。
• 拦截规则近期是否调整过，调整时间点与抓取下降的时间点是否吻合。
• 是否有速率限制规则，把正常的并发抓取判定为攻击流量。

不建议只靠 UA 判断“是不是真蜘蛛”，UA 可以伪造，反向解析加 IP 段核对更可靠。但反过来，也不应因为无法百分之百确认真伪，就把整段 IP 全部拒绝。

五、建议的排查顺序

1. 确认现象范围：全站还是部分路径，持续还是间歇。
2. 查看边缘日志是否有对应请求记录。
3. 核对 DNS 解析结果是否与预期一致。
4. 检查 CDN 缓存状态与回源配置。
5. 检查 WAF 拦截记录与近期规则变更。
6. 最后再回到应用层日志与状态码分析。

六、日常可以做的小巡检

与其等到抓取量骤降再排查，不如把几个关键点做成定期检查项：

• 用不同出口网络（不同地区、不同运营商）解析域名，比对返回结果。
• 定期用蜘蛛 UA 请求核心入口 URL，记录状态码与响应时间。
• 保留一份 CDN 与 WAF 的规则变更记录，便于和抓取波动做时间对齐。
• 关注 DNS 与证书到期时间，避免过期引发连锁故障。

网络层排查的价值在于，它能排除掉一大批看起来像内容问题的假象。把这几层核对清楚之后，再去看抓取预算、内链结构、Sitemap 这些环节，判断会准确得多。