蜘蛛抓取一个 URL，第一步不是请求页面，而是把域名解析成 IP。解析结果决定它连到哪台服务器、命中哪份缓存、看到哪个版本的页面。抓取异常时，很多人先查页面内容和 robots 规则，其实解析与连接这一段更值得优先排查。
DNS 解析：抓取的第一跳
抓取器一般会缓存解析结果，缓存时长受记录 TTL 控制。把站点迁到新 IP 后，如果 TTL 设得很长，部分抓取节点可能仍指向旧地址，出现“有的能抓、有的抓不到”的现象。改解析前把 TTL 调短，是迁移的常规操作。
解析环节的常见问题包括：
- 解析失败或超时：抓取器在建立连接之前就放弃，日志里表现为解析错误，而不是 4xx 或 5xx。
- AAAA 记录不通：同时配置 IPv4 与 IPv6 时，若 IPv6 链路不通，抓取可能先在 AAAA 上等待再回退，整体变慢。
- 解析结果来回跳：多个权威服务器返回不一致的记录，会让不同抓取节点落到不同机房。
多机房与负载均衡：蜘蛛这次连到了哪台机器
如果站点使用多台后端或按地域调度，蜘蛛每次抓取可能落到不同机器。只要内容一致，这没有问题；真正麻烦的是版本不一致：A 机器返回 200、B 机器返回 503，或者两台机器上的 canonical、robots meta 写得不同。蜘蛛会把这些当作同一 URL 的不同反馈，抓取与收录的判断就会摇摆。
建议至少保证三点：状态码一致、canonical 一致、页面主体内容一致。发布新版本时按机器分批上线，并尽量缩短不一致的时间窗口。
CDN 与回源：蜘蛛拿到的是缓存还是源站
蜘蛛请求的是 CDN 边缘节点。节点命中缓存就直接返回，不回源；未命中或缓存过期才回源。这里有两个常见坑：
- 回源超时导致边缘返回 5xx，蜘蛛把这此失败记在这个 URL 上；
- 错误的缓存规则把 404 或维护页缓存很久，之后即使源站恢复，蜘蛛短期内仍拿到旧结果。
检查 CDN 配置时，重点关注回源超时、错误页缓存策略，以及是否对不同 User-Agent 返回不同内容。如果确实如此，要确保每种情况返回的都是完整、可解析的 HTML。
同一 IP 上的其他站点
共享主机上，几百个域名可能共用一个出口 IP。蜘蛛通常按主机名区分站点，邻居站点不会直接决定你的抓取结果。真正需要留意的是服务器资源：邻居占满带宽或 CPU，你的页面响应变慢、超时增多，抓取自然受影响。判断方法是看响应时间是否随时间波动，而不是只看自己的代码。
可以做的基础排查
- 用多个网络环境解析域名，确认返回的 IP 集合符合预期。
- 对比不同机器或边缘节点的响应码、标题与 canonical 是否一致。
- 在服务器日志里对照蜘蛛的访问记录与解析结果，看是否存在长期连不上的节点。
- 检查 TTL 设置，迁移前调短，迁移稳定后再调回常规值。
蜘蛛能不能顺利抓取，往往在它发出第一个 HTTP 请求之前就已经决定了一半。域名解析、机房调度、缓存回源这些看不见的环节，值得和页面内容一样被认真对待。