抓取异常往往被归因到内容层：是不是页面太薄，是不是内链不够。但排查到后面会发现，蜘蛛根本没走到页面这一步。域名解析、边缘节点、回源这几层只要有一层不稳，访问日志里呈现出来的就是超时、5xx，或者反复取到旧版本内容。对站点运营来说，这些配置平时不用天天动，但一旦要动，就必须知道风险在哪。
蜘蛛拿到一个页面要经过几层
大致路径是：解析域名得到 IP，请求打到 CDN 边缘节点，节点判断缓存是否命中，未命中则回源到源站取内容。任何一层出错，最终表现都可能是抓取失败，但原因完全不同。区分清楚层级，才不会在错误的地方反复改内容。
DNS 层容易忽略的几件事
TTL 与变更节奏
- TTL 设得过长，比如 24 小时，换 IP 之后蜘蛛仍可能按旧记录访问，出现一段时间的失败。
- TTL 设得过短会增加解析压力，也可能让缓存频繁失效，通常 300 到 600 秒是比较常见的取值。
- 变更前后留出观察窗口，不要在流量高峰或内容集中更新时切换解析。
记录本身的一致性
- 同一主机名下存在多条互相冲突的 A 记录，或者 CNAME 链拉得很长。
- 配了 AAAA 记录但服务器并未监听 IPv6，部分请求会走到一个不通的地址上。
- 主域名与 www 域名的解析目标不一致，导致两套入口的可用性不同。
NS 与多线路解析
只依赖单一 NS 服务商，一旦解析服务波动，整站入口都会受影响。分线路解析时也要注意，不要给某些线路返回了不可用的节点，尤其是搜索引擎常用的出口线路。
CDN 回源常见的几个坑
回源 Host 与证书
回源 Host 填错，源站可能返回默认站点甚至 404，蜘蛛拿到的是一个完全无关的页面。走 HTTPS 回源时，还需要 SNI 与源站证书匹配，否则握手阶段就断了，表面看是抓取超时。
缓存规则
- HTML 被缓存过久，内容更新后蜘蛛仍取到旧版本，索引跟着滞后。
- 缓存键忽略了影响内容呈现的参数，导致 A 地址返回了 B 地址的内容。
- 错误页被缓存并长期返回，原本临时的故障变成了持续的抓取失败。
回源频次与放行
- 回源限速过严，或者源站 WAF 把回源请求判定为异常流量直接拦截。
- 源站没有放行 CDN 节点 IP 段，导致回源请求被拒。
- 多地节点回源表现不一致，某些地区取到的内容明显更旧。
怎么判断问题出在哪一层
- 先看访问日志里的状态码分布和耗时分布，确认失败是集中的还是零散的。
- 用多地解析查询工具对比，看不同地区拿到的解析结果是否一致。
- 直接带 Host 头请求源站 IP，对比源站响应与通过 CDN 访问的响应是否一致。
- 查看 CDN 的缓存命中率与回源日志，确认失败发生在边缘还是源站。
这一步的价值在于把问题范围缩小。如果源站直连正常、通过 CDN 异常，那大概率是缓存或回源配置；如果直连也失败，才需要回头看源站本身。
变更时的操作建议
- 配置调整尽量小步走，先在小范围或单条线路上验证。
- 更换解析目标时，旧记录先保留一段时间，确认新地址稳定后再收回。
- 变更后的 24 到 72 小时内，重点盯蜘蛛的访问状态码和抓取量变化。
- 把每次解析和缓存规则的变更记录下来，出问题时能快速回溯到时间点。
解析和缓存属于看不见的入口。它们不出问题时没人会想起，一旦出问题，就是整段整段地把抓取挡在半路上。