蜘蛛来抓取入口页之前，做的第一件事不是发 HTTP 请求，而是解析域名。这一步在大多数运营者的视野之外，因为它平时几乎不出问题。但一旦 DNS 或 IP 层面出现抖动，表现会相当隐蔽：日志里看不到 404 或 503，只有连接失败、超时，或者干脆什么都没有。
蜘蛛有自己的 DNS 缓存
蜘蛛不会每次抓取都重新做一次完整解析。它和浏览器一样，会把域名对应的 IP 缓存一段时间，缓存的依据就是 DNS 记录的 TTL。这意味着你改了 A 记录，蜘蛛不一定马上知道。
如果 TTL 是 3600 秒，那最坏情况下，蜘蛛可能在一个小时内仍然去访问旧 IP。旧 IP 已经下线的情况下，这段时间的抓取全部落空。
多 A 记录：方便，但也可能让蜘蛛踩空
给一个域名配多条 A 记录，本意是做负载或冗余，但蜘蛛拿到的地址可能是其中的某一条。
- 如果其中一台机器响应慢或者已经下线，蜘蛛可能正好拿到它，这次抓取就失败了。
- 多台机器返回的内容不一致，蜘蛛可能把它当成不同的页面，造成内容判断上的混乱。
- 其中一台只监听 HTTPS 而另一台只有 HTTP，还会牵扯到跳转和证书的问题。
如果要用多 A 记录，至少要保证每一条记录指向的服务器都能独立、完整地响应蜘蛛的请求，并且内容一致。否则不如只留一条稳定的记录。
TTL 的取舍
TTL 太长，迁移时切换慢；TTL 太短，解析请求变多，对权威 DNS 是压力，对蜘蛛也不是好事。一个折中的做法是：
- 平时用 600 到 3600 秒之间的值，够稳定也够灵活。
- 计划迁移前，提前一天把 TTL 降到 300 秒甚至更低。
- 等旧 TTL 完全过期之后，再正式切换。
- 切换完成后，观察一段时间再考虑把 TTL 调回去。
CNAME 与 CDN：蜘蛛解析到的是节点，不是源站
接入 CDN 后，蜘蛛解析到的是 CDN 节点的 IP。它并不知道源站在哪，也不关心。所以你在源站上做的很多调整，蜘蛛看到的是节点返回的结果。
常见的解析层问题包括：某些地区的节点回源失败，返回的页面和源站不一致；节点缓存了错误的响应；或者节点在源站不可达时返回了一个默认的错误页。这些问题在日志里往往表现为大面积失败，而不是单条记录。
排查时不要只看源站日志，也要看 CDN 的命中情况。如果源站日志里没有对应请求，说明请求根本没到源站。
IPv6 与双栈
部分蜘蛛支持 IPv6，也可能优先尝试。如果你的服务器只有 IPv6 地址，而蜘蛛所在环境只能走 IPv4，那么这次抓取会直接失败。反过来，只监听 IPv4 通常是安全的。
建议的做法是保证 IPv4 始终可达，IPv6 作为补充。不要为了赶技术潮流，把唯一的入口放在 IPv6 上。
解析抖动与超时
DNS 解析本身也可能超时。在蜘蛛的视角里，这表现为连接失败，或者拿到一个 0 字节的响应。日志里可能只留下一条含混的记录，看不出是解析的问题。
如果你用的是自建 DNS 或者一些小众的解析服务，稳定性值得专门观察一下。权威解析的可用性，往往决定了蜘蛛能不能走到你的服务器门口。
换 IP 的实操顺序
- 新 IP 先部署好，用命令行工具或浏览器确认页面能正常返回。
- 提前降低 TTL，并等待至少一个完整的旧 TTL 周期。
- 切换 A 记录，观察解析是否已经生效。
- 旧 IP 不要立刻释放，继续保留一段时间并保持服务可用。
- 翻看蜘蛛日志，确认访问已经落到新 IP，再考虑下线旧机器。
几个常见误区
- 以为改了解析就立刻生效。蜘蛛的缓存和运营者本地的不一样，生效时间取决于 TTL。
- 把 TTL 设成 0 或极短。这会给解析服务和蜘蛛都增加不必要的负担，未必换来更快的收敛。
- 用泛解析把所有子域都指过去。蜘蛛一旦抓到大量相似页面，容易当成重复内容。
- 多 A 记录里混入了测试机或废弃机器。这类地址迟早会拖垮某一次抓取。
DNS 是蜘蛛访问的起点。这里出的问题，在后面的页面层面完全看不出来，但结果是一样的：蜘蛛没进来。
把 DNS 和 IP 当成入口站基础设施的一部分来维护，不需要多复杂，但需要有意识。记录 TTL、保留旧 IP、保证多记录的一致性，这几件事做到位，就已经避开了大部分因解析导致的抓取损失。