蜘蛛访问一个入口页，第一步不是发 HTTP 请求，而是把域名解析成 IP。解析这一环出问题，后面的状态码、内容质量、链接结构都无从谈起。很多“蜘蛛抓取量突然下滑”的案例，最后查到的原因是 DNS 解析不稳定或解析结果不一致。
DNS 解析在抓取链路中的位置
一次完整的抓取通常包含：域名解析、TCP 连接、TLS 握手、HTTP 请求与响应。蜘蛛会缓存解析结果，缓存时间受 TTL 影响。TTL 没到期前，它一般沿用旧 IP；TTL 到期后重新解析。这意味着你改了解析，蜘蛛不一定立刻跟着变。
TTL：切换灵活性与解析稳定性的平衡
TTL 决定解析记录被缓存多久。设得太长，故障切换慢；设得太短，解析请求变多，权威 DNS 压力上升，也可能因为偶发超时导致蜘蛛拿到空结果。
- 常规运行阶段，入口页 TTL 可以设在 300 到 600 秒，兼顾稳定与可调整。
- 计划迁移或备用池切换前，提前把 TTL 降到 60 到 120 秒，等旧 TTL 过期后再改记录。
- 不要频繁在极短 TTL 和长 TTL 之间反复切换，解析缓存状态混乱时，排查成本会明显上升。
切换完成后不要马上把 TTL 调回去，至少观察一个完整的抓取周期，确认蜘蛛已经解析到新 IP。
解析线路与多 IP：别让不同来源的蜘蛛走到不同结果
部分 DNS 服务商支持按运营商或地域返回不同 IP。对普通用户是加速，对蜘蛛池入口页则要谨慎：如果某些线路指向的服务器不可用，来自该线路的蜘蛛就会持续抓取失败，而你在主线路的日志里看不到异常。
- 入口页建议保持默认线路与主要线路解析一致，减少“部分蜘蛛能抓、部分抓不到”的情况。
- 多 IP 轮询可以分散压力，但每个 IP 都要能正常响应，不能有“只挂名不服务”的记录。
- 改解析后，用多个地区的递归 DNS 实测一遍，确认返回结果符合预期。
CNAME 与 CDN：链路越长，失败点越多
入口页接入 CDN 时，通常会配置 CNAME。CNAME 本身没问题，但多层 CNAME 叠加、回源配置错误、证书与域名不匹配，都会让蜘蛛在解析或握手阶段失败。
解析异常的排查顺序
- 本地直接查询权威 DNS，确认记录是否已生效。
- 换多个公共递归 DNS 查询，看结果是否一致。
- 检查 CNAME 链是否过长，是否有指向已停用域名的记录。
- 确认解析到的 IP 能正常建立连接，而不是只 ping 通但端口不通。
- 查看 CDN 回源日志，确认请求是否到达源站。
日常维护建议
- 把入口页域名的 TTL、解析线路、CNAME 目标记录在案，变更时对照检查。
- 监控解析可用性，不要只监控 HTTP 状态码；解析失败时 HTTP 监控往往也报错，但定位不到根因。
- 备用池的域名解析提前配置好并保持可用，避免切换时临时加记录。
- 服务器迁移、换 CDN、改 IP 时，先确认蜘蛛抓取日志中的来源 IP 是否已更新。
DNS 解析是入口页最底层的一环，平时不出问题容易被忽略，出问题时又很难从内容或链接层面找到原因。把 TTL、线路和 CNAME 链路管理清楚，能减少一类“看起来像内容问题，实际是解析问题”的抓取异常。