在抓取日志里看到成片的超时和连接失败，很多人的第一反应是服务器扛不住，或者被防火墙拦了。但有一类失败其实发生在建立连接之前——域名根本没解析成功，或者解析花了太久。这一层平时被 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、解析服务商的到期时间纳入监控，别等到期了才发现解析失效。解析记录变更之后，除了自己验证，也观察一段时间抓取日志里的失败率变化。如果站点规模较大，可以在服务器侧记录请求的解析耗时分布，作为长期参考。
解析层的问题不会天天出现，但一旦出现，影响面往往很广，而且从应用日志里看不出来。把它纳入日常巡检，比事后猜测要省力得多。