搜尋蜘蛛抓取入口頁前，要先過 DNS 這一關
搜尋蜘蛛訪問一個 URL 的大致流程是：解析域名、建立连接、發送請求、拿到响應。DNS 解析排在第一步，它出問题的时候，服務端日誌里往往一條訪問记錄都没有，很多人會誤判成“蜘蛛不来”。所以排查抓取異常时，把 DNS 和服務器狀態、robots.txt 放在同一层前置检查項里，比事後逐條翻日誌更省時間。
DNS 異常时的几種典型表現
- 完全没有日誌：入口頁的 Web 日誌、CDN 或 WAF 日誌都是空白，但用第三方工具從几個地区探测又能看到請求。
- 解析超时或直接失敗：權威 DNS 响應慢、NS 记錄配置错誤、域名忘记續費，都會让抓取停在解析阶段。
- 解析结果不一致：不同递归解析器拿到不同 IP，抓取表現就會时好时坏，看起来像“蜘蛛情绪不稳定”。
TTL 设大還是设小
TTL 决定递归解析器把這條记錄缓存多久。它不是抓取快慢的直接開關，但會影响改動生效的速度和故障传播的范围。
- TTL 设得很長，比如 24 小时：切換服務器或修好故障之後，部分解析器仍會把請求送到舊 IP，抓取恢复看起来明顯滞後。
- TTL 设得很短，比如 60 秒：變更生效快，但解析請求量随之上升，權威 DNS 压力變大，配置不够稳时反而更容易出現解析失敗。
- 相對稳妥的做法是日常使用中等 TTL（大约 300 到 3600 秒），計划迁移前再临时調短。
多 A 记錄與轮询
入口頁域名挂了多個 A 记錄时，搜尋蜘蛛通常只會選其中一個 IP 建立连接，而不是把所有 IP 都试一遍。這意味着一台机器不可用，抓取就會随机失敗，表現為“有时抓得到、有时抓不到”。定期確認每個 A 记錄對應的机器都能正常返回入口頁，比只看解析结果更有意义。
CNAME、CDN 與回源
入口頁接了 CDN 後，域名一般 CNAME 到服務商地址，最终解析到就近节点。這里常见的坑有两個：一是 CNAME 鏈條過長或中間记錄失效；二是 CDN 的回源地址指向了已经下线的源站，抓取拿到的是 5xx。检查时建议顺着解析鏈一路查到回源响應，而不是只確認域名能不能 ping 通。
DNS 正常不代表抓取一定正常，但 DNS 異常时，後面所有排查都在做無用功。先確認能解析到正确的 IP，再谈响應碼和頁面内容。
實际排查时建议的顺序
- 用多個公共解析器分別查询入口頁域名，比對返回的 IP 是否一致、有没有 SERVFAIL。
- 直接指定 IP 訪問入口頁，確認服務本身是否正常，把 DNS 問题和服務器問题拆開。
- 查看權威 DNS 服務商的查询量曲线，異常尖峰或断崖式下跌都值得看一眼。
- 核對域名到期時間，確認 NS 记錄近期没有被誤改。
- 如果刚做過迁移，先等 TTL 過期，再判断抓取是否恢复。
需要提醒的是，DNS 只是抓取鏈路的起点。解析稳定之後，仍然要回到入口頁的可訪問性、响應時間和連結结构上繼續看。把問题按层拆開，比笼统地说“蜘蛛不抓”更容易找到真正的原因。