蜘蛛抓取的第一步不是 HTTP，而是 DNS
很多人调蜘蛛池时盯着状态码、页面体积、内链结构，却忽略了一件事：蜘蛛在发出 HTTP 请求之前，先要把域名解析成 IP。解析失败、超时、返回了错误的 IP，后面所有优化都没有机会被执行。日志里看到的抓取量下滑，有时不是页面问题，而是解析层面的问题。
TTL 决定了换 IP 的过渡速度
TTL（Time To Live）是解析记录在各级 DNS 缓存里的存活时间，单位是秒。它的实际含义是：你改了记录，并不代表所有人立刻看到新记录，最坏情况要等旧的 TTL 到期。
- TTL 设成 86400（一天）时，换 IP 后部分解析节点可能仍把请求送到旧机器上，持续接近一天。
- TTL 设成 60 到 300，切换灵活，但解析请求会更频繁地打到 DNS 服务商，稳定性依赖服务商质量。
- 折中做法：日常用 600 到 3600，计划换 IP 前 24 到 48 小时把 TTL 降到 300 以下，等旧 TTL 全部过期后再切，切换稳定几天后再改回常规值。
不预热 TTL 就直接换 IP，等于让一部分蜘蛛继续访问旧地址。旧机器如果已经关停，它们拿到的是连接超时或 5xx，这类记录对入口页没有好处。
记录类型里的几个坑
AAAA 记录
如果域名同时有 A 和 AAAA 记录，支持 IPv6 的客户端会优先走 IPv6。入口页所在服务器如果没有正确配置 IPv6，或者防火墙只开了 IPv4，就会出现一部分抓取失败、一部分正常的情况，排查起来很费时间。没有 IPv6 环境时，把 AAAA 记录清掉比留着更省事。
CNAME 链
接入 CDN 或第三方服务后，域名常常指向一层甚至多层 CNAME。链条越长，中间任一环节解析异常都会导致整条链路失败；而且每一层的 TTL 可能不同，缓存过期时间以最短的那层为准，行为不好预测。链路尽量控制在两层以内。
泛解析
用 * 泛解析可以省去逐个添加子域名，但副作用是任何拼错的、被外部链接引用的、甚至是扫描器猜出来的子域名都会解析成功，并返回同一个页面。这容易制造出大量内容重复的地址。如果确实需要泛解析，建议在服务端对不在清单内的 Host 返回 404 或直接断开，而不是统一吐首页。
智能解析与多地节点
使用按线路返回不同 IP 的解析服务时，要保证每一条线路指向的机器都能正常响应、内容版本一致。常见问题是只更新了默认线路，电信或海外节点还指向已经被回收的 IP。蜘蛛的出口 IP 分布很广，命中的线路不可控，只要有一条线路不通，抓取成功率就会被拉低。
怎么自查
- 用 dig 或 nslookup 对域名多次查询，看返回的 IP 是否稳定、是否与预期一致。
- 借助第三方多地解析检测工具，确认各区域返回的结果。
- 直接以 IP 访问、带上 Host 头测试，确认机器本身可用，把解析问题和服务器问题分开。
- 对照访问日志，看抓取请求的响应码和耗时，是否存在成片的超时或连接失败。
解析问题不会出现在页面上，只会出现在抓取结果里。排查抓取量异常时，先把 DNS 这一层排除掉，再谈页面和内容。
几条实操建议
- 换 IP 前先降 TTL，切换完成并稳定后再调回，不要长期使用极短的 TTL。
- 裸域和 www 一起检查，两边记录不一致是常见疏漏。
- 把解析服务商本身当作可用性的一部分来评估，不要只看价格。
- 入口页数量较多时，维护一份域名到 IP、TTL、更新时间的清单，避免改漏。
- 不要频繁更换 IP。解析变更越频繁，过渡期越长，抓取越容易在过渡期里踩空。