先分清：抓取量下降不一定是服务器扛不住
站点运营中常遇到一种情况：搜索蜘蛛的抓取量在某天掉了下来，但查看服务器监控，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 的可用性与一致性巡检；
- 把蜘蛛日志的时间分布和服务端日志做对照，确认是“没来”还是“来了但没记录”。
抓取量的波动往往不是单点问题，建议按“解析—连接—响应—内容”的顺序逐层排除：先确认入口能不能被打开，再谈入口有多少。