在抓取日誌里看到成片的超时和连接失敗，很多人的第一反應是服務器扛不住，或者被防火墙拦了。但有一類失敗其實發生在建立连接之前——域名根本没解析成功，或者解析花了太久。這一层平时被 CDN 和缓存遮着，出問题的时候却會成片地影响抓取。
一次抓取在解析环节经歷了什么
蜘蛛訪問一個 URL，先要把域名換成 IP，再建连接、發請求。解析這一步看起来只是一次查询，實际上可能包含好几段：本地缓存、递归解析器、權威服務器，中間還夹着 CNAME 跳轉。任何一段慢下来，蜘蛛看到的就是“连不上”或“响應很慢”，和服務器故障的表現非常像。
CNAME 鏈太長會放大耗时
常见的配置是主域名 CNAME 到 CDN，CDN 再指到某個邊缘服務，有的還叠了一层對象存储或防護。每多一层 CNAME，递归解析器就多一次查询。單次可能只有几十毫秒，但在蜘蛛並發抓取、缓存又刚好過期的时候，這部分耗时會累加到每個請求上。
建议把鏈條压到必要的最短层數，定期用命令行工具看一眼目前的解析路径，確認没有歷史遗留的中間记錄。
多 A 记錄與 TTL 的取舍
多 A 记錄本身是為了容灾，但蜘蛛選中哪個 IP 並不固定。如果其中某一個节点狀態不好，你會在日誌里看到“时好时坏”的抓取结果，很容易被誤判成網絡抖動。
- TTL 设得太短，递归解析器频繁回源，權威服務器压力上升，偶尔會出現解析超时。
- TTL 设得太長，切換 IP 或下线节点之後，蜘蛛還可能繼續訪問舊地址一段時間。
- 多线路智能解析能让不同地区拿到不同 IP，但要確認每個返回的 IP 都能正常服務。
一個容易踩的坑：AAAA 记錄
如果域名配了 AAAA 记錄，但服務器或中間鏈路對 IPv6 支持不完整，就會出現一部分請求直接失敗、一部分正常的情况。排查时不要只看 IPv4 的连通性，也要確認 IPv6 路径是否真的可用，或者暂时不發布 AAAA 记錄，等配置完整再说。
推荐的排查顺序
- 先從日誌確認失敗形態：是解析失敗、连接超时，還是握手之後的错誤，三者指向的問题位置不同。
- 用 dig 或同類工具完整跟踪解析鏈，看每一跳的响應時間和返回记錄。
- 從多個地区、多個递归解析器分別查询，確認解析结果是否一致。
- 检查權威服務器是否有多线路，是否出現過被查询量压垮的情况。
- 確認 CDN 或防護层没有把蜘蛛的請求挡在回源之前。
日常维護上可以做的几件事
把域名、NS、解析服務商的到期時間纳入监控，別等到期了才發現解析失效。解析记錄變更之後，除了自己驗證，也观察一段時間抓取日誌里的失敗率變化。如果站点規模較大，可以在服務器侧记錄請求的解析耗时分布，作為長期參考。
解析层的問题不會天天出現，但一旦出現，影响面往往很广，而且從應用日誌里看不出来。把它纳入日常巡检，比事後猜测要省力得多。