抓取的第一步不是 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 自查不需要频繁做，但在迁移前後、节点調整之後，以及發現抓取出現間歇性失敗时，值得花十几分钟核對一遍。把這條鏈路理清楚，後面關于抓取预算、响應時間的優化才有意义。