蜘蛛到达入口页之前，第一步并不是发 HTTP 请求，而是先做一次 DNS 解析。这一步发生在前端日志之外，所以很多站长盯着访问日志看不到任何记录，其实是请求根本没走到服务器。
DNS 在抓取链路里的位置
把一次抓取拆开看，顺序大致是这样的：
- 蜘蛛拿到 URL，先解析域名，得到 IP 地址；
- 再建立 TCP 连接、完成 TLS 握手；
- 然后才发出 HTTP 请求，服务器日志里出现记录。
如果解析环节失败或超时，后面几步全部不会发生。日志上表现为“蜘蛛没来”，实际是入口在解析层就断了。
常见的解析层问题
解析生效延迟
新域名或新主机上线后，本地和部分节点还没拿到新记录，蜘蛛可能落在旧 IP 上，返回连接失败或错误页。TTL 设置过长会放大这个问题，迁移后很长时间仍有一部分解析请求指向旧地址。
解析节点不一致
不同地区、不同运营商的递归解析器缓存状态不一样。某些节点解析到旧记录，某些节点已经更新，抓取表现就是时好时坏，很难复现。
泛解析与默认记录
泛解析会把不存在的子域全部指向同一个 IP，蜘蛛访问无效子域时也能拿到响应，结果产生大量内容重复的页面或软 404，白白消耗抓取额度。
解析失败与死链判定
域名过期、NS 配置错误时，解析返回 NXDOMAIN。蜘蛛会把这类 URL 当成失效地址，反复几次之后，对同一批入口的访问意愿会下降。
怎么判断是不是解析层的问题
- 用 dig 或 nslookup 从多个公共解析器查询，看返回结果是否一致；
- 在服务器日志里搜索对应蜘蛛的 UA，完全没有请求时优先怀疑 DNS；
- 用多地检测工具查看各地解析到的 IP 和时间；
- 核对 TTL 设置与最近的解析变更记录。
配置与维护建议
- TTL 不要设得过长，计划换 IP 前先把它调低，切换完成后再调回；
- 更换 IP 时保留旧地址一段时间，避免切换瞬间出现抓取中断；
- 尽量减少多层 CNAME 链，解析跳数越多，中间环节越容易出问题；
- 准备备用解析服务商，主解析异常时可以较快切换；
- 对入口域名做解析监控，出现异常时能第一时间收到告警。
日志里“蜘蛛没来”和“蜘蛛来了又走”是两回事，前者要先查 DNS。
DNS 正常的时候几乎感觉不到它存在，一旦出问题，表现却很像“蜘蛛池没效果”。把解析层纳入日常检查清单，后面的日志分析会少走很多弯路。