抓取的第一步不是 GET 请求，而是把域名解析成 IP。这一步出问题，后面的 robots.txt、状态码、响应时间都无从谈起。DNS 层面的故障往往表现为“间歇性抓取失败”：自己用浏览器访问一切正常，因为本地有缓存；蜘蛛却在某些时段、某些地区解析失败，或者解析到了旧 IP。下面把 DNS 相关的自查点逐项列出来，方便对照排查。
一、先确认解析结果与实际指向一致
最常见的隐患是解析记录没有跟着架构调整同步更新。换过服务器、上过 CDN、加过负载均衡之后，旧记录残留很常见。
- 用多个公共 DNS 分别查询 A / AAAA 记录，看返回结果是否一致；
- 把解析到的 IP 反查一遍，确认它确实是你当前的源站或 CDN 节点，而不是早已下线的旧机器；
- 检查是否存在通配符解析（* 记录）。通配符会让拼错的子域名、废弃的子域名都解析成功，蜘蛛可能因此抓到一份本不该存在的镜像内容。
二、TTL 该设多长
TTL 决定了各地递归 DNS 缓存这条记录多久。设得太短，解析请求量上升，对小站点或按查询计费的 DNS 服务并不划算；设得太长，切换 IP 时要等很久才全网生效，期间蜘蛛可能一直访问旧地址。
- 日常运行期可以把 TTL 设成中等偏长（例如 1 小时到 24 小时），减少无谓查询；
- 计划迁移或切换节点前，提前一天把 TTL 降到几分钟，让旧缓存尽快过期；
- 切换完成后观察一段时间，确认抓取日志里不再出现旧 IP 的访问，再逐步调回。
需要注意，TTL 只是“允许缓存多久”，并不意味着到点必然刷新，部分递归服务器会滞后于这个时间。
三、别让解析链路拉得太长
CNAME 嵌套过多会拉长解析时间，也会增加某一环失效的风险。自查时可以关注：
- CNAME 是否指向了另一条 CNAME，链路上到底有几跳；
- 第三方托管（建站平台、CDN、邮件服务）是否顺手改动了主域名的解析；
- 是否存在多条互相冲突的 A 记录，把流量随机分到不同机器上——如果其中一台没有部署同样的站点，蜘蛛就会随机拿到 404 或旧版本。
判断标准很简单：从任意一个节点出发，解析结果都应当指向你能控制的、内容一致的服务器。
四、多地解析与 IPv6
如果用了智能解析，不同地区返回的 IP 本就不同，这属于正常现象。但要确认每个返回的节点都提供了完整内容，而不是只有首页、没有内页。IPv6 同理：如果 AAAA 记录指向的机器没有正确配置站点，支持 IPv6 的蜘蛛可能优先走 IPv6 并拿到错误页面。若不打算长期维护 IPv6，不发布 AAAA 记录，通常比发布了却放着不管更稳妥。
五、可执行的自查清单
- 多 DNS、多地区查询主域名与常用子域名的解析结果，做一次横向对比；
- 记录当前 TTL 值，标注计划迁移的时间点，提前下调；
- 检查通配符解析与废弃子域名，能清理的及时清理；
- 确认每个解析目标上的站点内容一致，尤其是 404 页面和跳转规则；
- 订阅 DNS 服务商的状态页或告警通知，解析故障时能第一时间知道；
- 定期翻抓取日志里的解析类错误（无法解析主机、连接超时），而不是只看状态码分布。
DNS 自查不需要频繁做，但在迁移前后、节点调整之后，以及发现抓取出现间歇性失败时，值得花十几分钟核对一遍。把这条链路理清楚，后面关于抓取预算、响应时间的优化才有意义。