搜索蜘蛛要抓一个 URL，第一步并不是发 HTTP 请求，而是先把域名解析成 IP。这一步出问题时，抓取日志里往往看不到任何请求记录，站点后台也不会有 4xx 或 5xx，容易被误判成“蜘蛛没来”。把 DNS 当成抓取链路的第一个环节来看，很多入口丢失的问题会清楚不少。
为什么 DNS 问题容易被忽略
大部分抓取排查工具是从服务器访问日志开始的，而 DNS 失败发生在日志之前。蜘蛛解析不到 IP，请求根本不会到达源站，Nginx 或网关层面自然是干净的。反过来，如果解析到的 IP 不是源站期望的那个，请求可能落在了别处的节点上，日志看起来“有抓取”，但内容对不上。
另外，解析问题常常是间歇性的。缓存、多线路、递归解析器的差异，都会让同一个域名在不同时间、不同出口得到不同结果。单次 dig 看起来正常，不代表蜘蛛那一侧正常。
常见的 DNS 侧入口问题
- 解析超时或间歇失败：权威服务器响应慢、丢包，或存在多个 NS 但其中一个不可用，递归解析器轮询到坏节点时就会失败。表现是抓取量突然下降又恢复。
- 多线路解析结果不一致：为不同运营商或地区配置了不同 IP，其中某条线路的节点已下线但仍留在解析里，蜘蛛恰好落在该线路就会连不上。
- CNAME 链过长：域名指向 CDN，CDN 再指向另一层，层层叠加后解析耗时增加，个别递归解析器可能在中途超时或返回不完整结果。
- TTL 设置不合理：TTL 过长，换 IP 后旧记录长期被缓存；TTL 过短，解析请求频繁，权威服务器压力变大，反而更容易出现超时。
- AAAA 记录缺失或指向错误：只有 A 记录时，双栈环境下的解析行为取决于客户端策略；如果 AAAA 记录指向一个并未真正提供服务的地址，抓取尝试就会直接失败。
- 泛解析与无效子域：泛解析把所有未定义的子域都指向同一个 IP，历史遗留的子域入口可能仍然被引用，蜘蛛访问后得到的是错误页面而不是 404。
排查顺序建议
- 确认域名当前的 NS 记录，逐个测试每个权威服务器是否都能正常应答，而不是只测其中一个。
- 用多个公共递归解析器分别查询 A、AAAA、CNAME，对比返回结果和耗时，找出不一致或明显偏慢的那条路径。
- 把解析到的 IP 与源站实际出口 IP 列表逐一对齐，确认是否存在指向已下线节点的记录。
- 检查 CNAME 层级，尽量收敛到一到两层，避免解析链路被中间环节拖长。
- 核对 AAAA 记录是否与真实可服务的地址一致，不能服务就先不要声明。
- 调整 TTL 后观察一段时间，看抓取量曲线是否随之变化，而不是改完就下结论。
怎么和抓取日志对照
DNS 侧的观察结果需要和抓取行为对上。可以按小时统计源站收到的蜘蛛请求数，与解析失败率、解析耗时做同时间轴对比。如果某个时间段的请求量明显塌陷，而同期解析耗时抬升，就值得优先怀疑解析链路。
同时要注意区分“解析成功但连接失败”和“解析失败”。前者在日志里会留下连接超时或握手失败的痕迹，后者什么都没有。两者混在一起看，很容易把 DNS 问题误判成服务器负载问题。
需要长期关注的几个点
- 换 IP、切 CDN、调整解析线路后，留出观察窗口再判断影响。
- 把 NS、A、AAAA、CNAME 的变更记录和抓取量曲线放在一起存档，方便回溯。
- 对解析耗时设置一个基线，出现持续偏离时提前介入，而不是等抓取量掉下来。
解析层的问题不会给出明确报错，它只表现为“什么都没发生”。所以入口核查要往前推一步，先确认域名能被稳定解析，再谈页面能不能被抓。
把 DNS 纳入日常巡检，成本并不高，但对 URL 发现和抓取稳定性来说，它是最靠前也最容易被跳过的一环。