很多人排查蜘蛛抓取問题，第一反應是看日誌、看狀態碼、看頁面内容，却忽略了在 HTTP 請求發生之前還有一跳：域名解析。蜘蛛拿到一條 URL，先要把它變成 IP 地址，才能發起连接。這一跳如果慢或者不稳定，後面的入口頁做得再细致也没有机會被看到。

DNS 解析是抓取鏈路的第一跳

對蜘蛛来说，解析耗时是算在整体等待時間里的。解析超时或返回異常，爬虫通常會直接放弃這次抓取，服務器日誌里甚至不會留下记錄，只在你自己手動測試时才偶尔复現。所以遇到“明明没封、就是不来”的情况，DNS 值得優先排查一次。

• NS 至少两個，且分布在不同的網絡或服務商，避免單点。
• 尽量减少 CNAME 跳轉层數，部分递归解析器對多层 CNAME 處理較慢。
• 解析结果要稳定，同一地区多次查询應返回一致或就近的地址。

TTL 该设長還是设短

TTL 决定了解析结果被缓存多久。设得短，出故障时切換快，但递归服務器會更频繁地回源查询，解析压力和抖動都會上升；设得長，解析更平稳，但真要更換 IP 时，舊记錄可能在缓存里停留很久。

比較常见的做法是把 TTL 设在几百秒到一小时之間：平时取偏長的值保持稳定，計划切換前再提前調短。不要今天 60 秒、明天 86400 秒来回改，蜘蛛侧和各地递归缓存的行為會變得难以预测。

IP 段與同 IP 多站的影响

把大量入口頁放在同一台服務器、同一個 IP 上，是最常见也最容易被察觉的部署方式。蜘蛛並不需要“识別站群”，它只要發現一批域名解析到同一個地址、内容结构又相似，行為特征自然就集中了。這不一定直接導致不抓，但會让整批站点共享同一個判断结果。

• 入口頁數量較多时，尽量分散到不同 IP，而不是只換域名。
• 同一 IP 上不要挂過多同模板、同业務的頁面。
• 留意反向解析记錄，空白或與實际用途明顯不符的 PTR 不一定是問题，但也谈不上加分。

IPv6 與双栈部署

部分爬虫已经支持 IPv6。双栈本身是好事，可以在一定程度上分担压力，但前提是两條鏈路都真的可用。只加了 AAAA 记錄、IPv6 路由却不通，會让支持 IPv6 的爬虫先尝试失敗再回落，白白增加延迟。

如果暂时没有稳定的 IPv6 环境，只保留 A 记錄完全够用，不必為了“看起来先進”而强行開啟。

常见誤区

• 只看能不能 ping 通：连通不等于解析快，解析耗时需要單獨测量。
• 频繁改解析做“測試”：每次改動都會被各地缓存放大，反而更难判断。
• 指望靠改 IP 轮換入口頁：這種方式不可控，效果也很难复盘。
• 忽略解析失敗的记錄：服務器日誌里看不到的請求，往往就死在這一层。

一份可执行的检查清單

1. 用多個地区的公共解析服務測試解析结果與耗时，记錄波動范围。
2. 確認 NS 有冗余，並了解所用解析商是否存在查询频率限制。
3. 為域名設定合理的 TTL，把目前值记錄下来，切換前再調整。
4. 統計入口頁與 IP 的對應關系，避免一個 IP 承载過多同類站点。
5. 做一次切換演练：改解析、观察生效時間、確認回滚路径。

DNS 和 IP 属于“平时没感觉、出事很难查”的一层。把解析耗时、TTL 和 IP 分布记錄下来，很多抓取異常會變得可以解释。

入口頁的優化大多围绕内容和連結展開，但對蜘蛛而言，能不能连上、连得快不快，是排在更前面的事。定期回头看一眼解析這一层，成本不高，却是整條鏈路里回报比較直接的一段。