先分清：抓取量下降不一定是服務器扛不住
站点运营中常遇到一種情况：搜尋蜘蛛的抓取量在某天掉了下来，但查看服務器监控，CPU、内存、带宽都很空闲，Nginx 日誌里也没有出現 5xx 或连接被拒的记錄。這類“服務器看起来没問题、蜘蛛却没来”的現象，排查方向往往不在源站，而在更前面的 DNS 解析环节。
蜘蛛要抓取一個 URL，第一步是把這個域名解析成 IP。如果這一步出現波動，後面的连接、响應、日誌统统不會發生，源站自然“看起来什么都没發生”。
蜘蛛訪問一個 URL 的完整鏈路
- DNS 查询：根據域名、CNAME、A 或 AAAA 记錄得到目标地址；
- 建立 TCP 连接，選擇實际可用的地址；
- 握手並發出 HTTP 請求，拿到响應头與正文；
- 解析正文中的連結，進入下一轮抓取。
解析属于第 1 步，一旦失敗，第 2 步之後全部中断。由于爬虫通常會對失敗的主机做退避處理，偶發的解析異常不一定表現為报错，而是表現為抓取频率被悄悄調低。
解析层常见的几類異常
TTL 設定過短
TTL 被设成 60 秒甚至更短，本意是方便切換，但會让公共递归服務器频繁回源查询。如果權威 DNS 本身响應慢或不稳定，递归侧就可能出現超时、返回舊记錄甚至 SERVFAIL。蜘蛛侧看到的是一次“打不開”，而不是“服務器慢”。
多台權威 NS 返回结果不一致
域名挂了两台以上權威服務器，但记錄只在其中一台更新，另一台還留着舊地址；或者两台返回的 CNAME 目标不同。递归服務器會随机選一台询問，于是抓取表現成“有时成功、有时失敗”，源站日誌上則表現為流量忽高忽低。
CNAME 鏈過長或指向已下线地址
為了接入 CDN 或對象存储，域名上可能叠了多层 CNAME。鏈條越長，解析耗时和失敗概率越高；如果鏈條中某一环指向的资源已经刪除，解析會直接失敗，蜘蛛连握手机會都没有。
一套可执行的排查顺序
- 用 dig 或 nslookup 從多個公共 DNS 分別查询，對比返回的 A、AAAA 记錄是否一致；
- 用 dig +trace 顺着根、顶級域、權威域一路走到最终地址，看在哪一环断掉；
- 直接向每台權威 NS 逐個查询，確認记錄内容與 SOA 序列号已同步；
- 检查 CNAME 鏈的長度與最终目标是否有效，能扁平化就扁平化；
- 核對解析耗时，避免權威 DNS 單点响應過慢；
- 把 DNS 解析耗时纳入 TTFB 观测，而不是只統計服務器處理時間。
為什么這件事和 Sitemap、内鏈有關
Sitemap 和内鏈的作用是把入口交给蜘蛛，但入口再多，也要先解析成功才能被打開。当解析出現波動时，蜘蛛的失敗重试會消耗抓取額度，一些本来在内鏈里位置不错的頁面也可能被推後處理。因此排查抓取問题时，把入口供给（Sitemap、内鏈）和入口可達性（DNS、连接、响應）分開看，能少走很多弯路。
日常监控可以關注的几個点
- 解析结果變更告警：记錄集合發生變化时及时人工確認；
- 解析失敗率與解析耗时趋势，按小时观察；
- 權威 NS 的可用性與一致性巡检；
- 把蜘蛛日誌的時間分布和服務端日誌做對照，確認是“没来”還是“来了但没记錄”。
抓取量的波動往往不是單点問题，建议按“解析—连接—响應—内容”的顺序逐层排除：先確認入口能不能被打開，再谈入口有多少。