很多人排查“蜘蛛不来”时，第一反應是頁面内容、狀態碼、robots，却忽略了一個更前置的問题：蜘蛛在抓取之前，先要完成一次 DNS 查询。域名解析不通、解析到了错誤的机器，或者 AAAA 记錄指向一個不可達的地址，入口頁做得再規范也没有意义。
解析是入口頁的第一跳
蜘蛛拿到一個 URL 後，處理顺序大致是：解析域名、建立 TCP/TLS 连接、發送 HTTP 請求。DNS 這一步失敗，日誌里什么都不會留下，你看到的只是“完全没有訪問记錄”。所以当入口頁長期零抓取时，先用外部工具從多個节点做一次解析驗證，通常比反复改頁面更有效率。
泛解析：蜘蛛池里最常见的做法
蜘蛛池通常靠大量子域名作為入口，逐個添加解析记錄不現實，所以多半使用泛解析（* 记錄），让所有子域名都指向同一台或同一组服務器，再由程序按 Host 头分配不同的入口頁。
- 好處：新增入口域名不需要再改 DNS，扩展速度快，适合批量生成。
- 代價：任意随机子域名都會解析成功，掃描器和探测程序很容易發現“這個域名下所有子域都活着”，日誌里會混入大量無關請求。
- 建议：對明顯不属于自己业務的 Host，返回统一的 404 或 410，而不是也吐一個入口頁。让無效子域和有效子域在响應上有区別，日誌會干净很多。
A 记錄、CNAME 與多 IP
A 记錄直接指向 IP，CNAME 指向另一個域名。入口頁數量多的时候，用一條 CNAME 指向统一目标，後面換 IP 只需要改一處，比逐個改 A 记錄省事。
如果同一域名配置了多個 A 记錄做轮询，要注意蜘蛛侧也會轮询，某個 IP 出問题时會表現為“部分抓取失敗、部分正常”。這種間歇性故障最难排查，建议在換 IP 或下线机器前，先把该 IP 從解析里移除，並留出足够的 TTL 等待期。
TTL 设多長
TTL 决定解析结果被缓存多久。设短（比如 300 秒）方便快速切換 IP，但解析請求更频繁；设長（几小时）可以减少查询压力，代價是出問题时切換很慢。蜘蛛自己有 DNS 缓存，TTL 短不等于立即生效，切換後仍可能有一段時間訪問的是舊 IP。稳妥的做法是：日常用中等 TTL，計划切換前先調短，切換完成後再調回去。
解析相關的常见故障
- IPv6 可達性問题：只配了 IPv6，或 AAAA 指向一個没有监听的地址，部分蜘蛛優先走 IPv6，结果连接失敗。检查时不要只看 A 记錄。
- 解析到了預設站点：子域名解析到服務器，但服務器没有對應的虚拟主机，返回的是服務商預設頁。這種頁面同样會被抓，但内容與预期完全不符。
- 防火墙只放行特定 Host：泛解析带来了大量 Host，如果 Web 服務器或 WAF 只允许已知域名，其余請求會被拦在前面，蜘蛛拿到的是一串错誤响應。
- 域名本身狀態異常：未實名、過期、被註冊商暫停解析，表現和“解析没配好”很像，但需要去註冊商後台確認。
日常维護建议
- 保留一份解析清單：域名、解析方式、指向的 IP 或目标、TTL、用途。入口頁多的时候，這份清單比记忆可靠。
- 換 IP、下线机器、迁移服務器，都按“先加後减”的顺序操作，避免出現解析指向空机器的窗口期。
- 定期用外部节点抽查一部分域名的解析结果，尤其是最近改動過的那批。
DNS 只负责把蜘蛛送到门口。解析做得再顺，能不能繼續往下走，仍然取决于入口頁返回什么，以及頁面本身有没有值得抓的内容。