搜索蜘蛛抓取入口页前，要先过 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 只是抓取链路的起点。解析稳定之后，仍然要回到入口页的可访问性、响应时间和链接结构上继续看。把问题按层拆开，比笼统地说“蜘蛛不抓”更容易找到真正的原因。