蜘蛛到達入口頁之前，第一步並不是發 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 正常的时候几乎感觉不到它存在，一旦出問题，表現却很像“蜘蛛池没效果”。把解析层纳入日常检查清單，後面的日誌分析會少走很多弯路。