蜘蛛抓取一個 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 請求之前就已经决定了一半。域名解析、机房調度、缓存回源這些看不见的环节，值得和頁面内容一样被認真對待。