搜尋蜘蛛要抓一個 URL，第一步並不是發 HTTP 請求，而是先把域名解析成 IP。這一步出問题时，抓取日誌里往往看不到任何請求记錄，站点後台也不會有 4xx 或 5xx，容易被誤判成“蜘蛛没来”。把 DNS 当成抓取鏈路的第一個环节来看，很多入口丢失的問题會清楚不少。
為什么 DNS 問题容易被忽略
大部分抓取排查工具是從服務器訪問日誌開始的，而 DNS 失敗發生在日誌之前。蜘蛛解析不到 IP，請求根本不會到達源站，Nginx 或網關层面自然是干净的。反過来，如果解析到的 IP 不是源站期望的那個，請求可能落在了別處的节点上，日誌看起来“有抓取”，但内容對不上。
另外，解析問题常常是間歇性的。缓存、多线路、递归解析器的差异，都會让同一個域名在不同時間、不同出口得到不同结果。單次 dig 看起来正常，不代表蜘蛛那一侧正常。
常见的 DNS 侧入口問题
- 解析超时或間歇失敗：權威服務器响應慢、丢包，或存在多個 NS 但其中一個不可用，递归解析器轮询到坏节点时就會失敗。表現是抓取量突然下降又恢复。
- 多线路解析结果不一致：為不同运营商或地区配置了不同 IP，其中某條线路的节点已下线但仍留在解析里，蜘蛛恰好落在该线路就會连不上。
- CNAME 鏈過長：域名指向 CDN，CDN 再指向另一层，层层叠加後解析耗时增加，個別递归解析器可能在中途超时或返回不完整结果。
- TTL 設定不合理：TTL 過長，換 IP 後舊记錄長期被缓存；TTL 過短，解析請求频繁，權威服務器压力變大，反而更容易出現超时。
- AAAA 记錄缺失或指向错誤：只有 A 记錄时，双栈环境下的解析行為取决于客戶端策略；如果 AAAA 记錄指向一個並未真正提供服務的地址，抓取尝试就會直接失敗。
- 泛解析與無效子域：泛解析把所有未定义的子域都指向同一個 IP，歷史遗留的子域入口可能仍然被引用，蜘蛛訪問後得到的是错誤頁面而不是 404。
排查顺序建议
- 確認域名目前的 NS 记錄，逐個測試每個權威服務器是否都能正常應答，而不是只测其中一個。
- 用多個公共递归解析器分別查询 A、AAAA、CNAME，對比返回结果和耗时，找出不一致或明顯偏慢的那條路径。
- 把解析到的 IP 與源站實际出口 IP 列表逐一對齐，確認是否存在指向已下线节点的记錄。
- 检查 CNAME 层級，尽量收敛到一到两层，避免解析鏈路被中間环节拖長。
- 核對 AAAA 记錄是否與真實可服務的地址一致，不能服務就先不要声明。
- 調整 TTL 後观察一段時間，看抓取量曲线是否随之變化，而不是改完就下结论。
怎么和抓取日誌對照
DNS 侧的观察结果需要和抓取行為對上。可以按小时統計源站收到的蜘蛛請求數，與解析失敗率、解析耗时做同時間轴對比。如果某個時間段的請求量明顯塌陷，而同期解析耗时抬升，就值得優先怀疑解析鏈路。
同时要注意区分“解析成功但连接失敗”和“解析失敗”。前者在日誌里會留下连接超时或握手失敗的痕迹，後者什么都没有。两者混在一起看，很容易把 DNS 問题誤判成服務器负载問题。
需要長期關注的几個点
- 換 IP、切 CDN、調整解析线路後，留出观察窗口再判断影响。
- 把 NS、A、AAAA、CNAME 的變更记錄和抓取量曲线放在一起存档，方便回溯。
- 對解析耗时設定一個基线，出現持續偏离时提前介入，而不是等抓取量掉下来。
解析层的問题不會给出明确报错，它只表現為“什么都没發生”。所以入口核查要往前推一步，先確認域名能被稳定解析，再谈頁面能不能被抓。
把 DNS 纳入日常巡检，成本並不高，但對 URL 發現和抓取稳定性来说，它是最靠前也最容易被跳過的一环。