DNS 解析那段被忽略的时间：TTL、多线解析和爬虫的解析缓存

解析是每次抓取的第一步，也是最容易白送的一步

蜘蛛来取一个页面，顺序是：解析域名拿到 IP → 建连 → 发请求 → 收响应。第一步走的是递归 DNS，如果缓存没中，要往权威 DNS 跑一趟。国内多运营商环境下，这一步跨网绕一次，多出几十毫秒很正常。

单个页面看不出来。但目录站是几万次的抓取叠加，几十毫秒乘上几万次，就变成了当天抓取额度的差别。谷歌的抓取预算文档里写过，站点响应越快越稳定，它的抓取能力上限会往上抬——解析时间就在这个「响应快慢」里。

图片来源：网络，版权归原作者所有，侵权请联系删除

默认线路是给爬虫兜底的那条

用 DNSPod、阿里云 DNS 这类支持智能多线路的服务，一般会给电信、联通、移动各配一条 A 记录。问题在于搜索引擎爬虫的来源网络常常识别不出具体运营商，系统只能回退到「默认」线路。

于是默认线路配得好不好，直接决定了蜘蛛从哪个 IP 进来。三条实操原则：

• 永远留默认线路。只建细分线路不建默认，识别不出来的请求会拿不到结果，这是最危险的配置失误。
• 默认线路指向你最稳的那个入口。上了 CDN 就指向 CDN，不要指向某个只有单线带宽的源站 IP。
• 各线路 TTL 保持一致。电信 60 秒、联通 600 秒这种混搭，会让不同来源的切换行为完全对不上，出问题时极难排查。

TTL 不是越小越好，也不是越大越省心

TTL 决定解析结果在递归 DNS 里活多久。它是在「改配置后多久生效」和「缓存命中率」之间做取舍。

场景	建议 TTL	原因
服务器 IP 固定	600 秒左右	多数查询命中缓存，需要调线路时十分钟内生效
动态解析 + 多 IP 冗余	60–300 秒	故障切换要快，慢了会有用户和爬虫持续打到失效节点
准备迁站 / 换 IP	提前降到 60 秒	先降 TTL，等一个旧 TTL 周期过去，再改记录，顺序反了会有一段时间的访问黑洞
长期不动的记录	3600 秒也可用	但别上 86400，出故障时你要等一天

TTL 极短也不是没代价。30 秒甚至 10 秒意味着几乎每个用户都要重新查权威 DNS，高峰期容易解析超时，多线调度还会抖动，用户短时间内被切到不同节点。稳定性反而不如高 TTL。

IPv6 的坑：A 和 AAAA 必须线路对齐

开了双栈的站点，如果只在默认线路配了 AAAA（指向 CDN 的 IPv6），而搜索引擎线路只配了 IPv4 的 A 记录，就会踩进 Happy Eyeballs 的深水区。爬虫会并发查 A 和 AAAA：

• 查 A：命中搜索引擎线路，返回源站 IPv4。
• 查 AAAA：搜索引擎线路没有这条，各家权威 DNS 处理不同——有的回落到默认线路返回 CDN 的 IPv6，有的直接回 NODATA。

返回了 CDN 的 IPv6 会怎样？爬虫优先用 IPv6 建连，结果流量又打进了没放行爬虫的 CDN WAF。这条排查起来特别费劲，因为现象是「收录突然掉」，谁也想不到是 DNS 记录没对齐。

做法很简单：要么搜索引擎线路同样配齐可达的 IPv6，要么那条线路上干脆不要 AAAA，并确保权威 DNS 的 NODATA 响应符合规范。两条路都行，混着来不行。

改完之后怎么验证

别在自己的网络里 ping 一下就下结论。用站长工具的全国多节点探测，分别从电信、联通、移动测解析延迟和连通时间，重点看跨网节点的降幅。命令行可以 dig 你的域名 +short 看当前解析到哪，再 dig 你的域名 AAAA +short 确认 IPv6 那条。

之后去搜索资源平台看抓取频次有没有变化。这个反馈慢，通常要一两周，别指望今天改明天见效。

DNS 是基础设施层的事，不写一行代码，但配错了会让上面所有优化白做。花半小时检查一次，比多买一年 CDN 值。