搭蜘蛛池的时候，很多人的注意力都在入口页内容、域名历史和服务器上，DNS 解析往往最后随手配一下就完事。但蜘蛛要爬到入口页，第一步是拿到 IP。解析这一环出问题，后面做得再好也是空转。
解析出错时，入口页对蜘蛛等于不存在
蜘蛛拿到一个 URL 后，大致要走：查 DNS → 拿 A 记录或 CNAME → 连服务器 → 请求页面。任何一步失败，抓取就到此为止，日志里可能连一条记录都没有，你只会看到访问量上不去，却找不到原因。
常见的解析问题包括：
- 子域漏配，入口页清单里有一批域名根本解析不到 IP；
- DNS 服务商不稳定，解析超时率高，蜘蛛偶尔能拿到、偶尔拿不到；
- 解析指向的 IP 已经下线或换了机房，但记录没有同步更新；
- 解析记录被误删或过期，批量管理时尤其容易发生。
泛解析和逐条解析，各管一段
泛解析：适合入口页数量大、结构统一的场景
用 *.example.com 一条记录覆盖所有子域，新入口页上线不需要改 DNS，运维成本最低。代价是控制粒度粗——如果某个子域需要单独指向另一台机器，就得为它加一条显式记录。
逐条解析：适合需要精细控制的场景
每条入口页单独配 A 记录或 CNAME，可以按机房、按 IP 段、按业务线分开。缺点是维护量大，域名一多，人工很容易漏，建议配合脚本或 API 批量管理。
比较常见的做法是：主入口用泛解析保证覆盖，少数需要单独调度的入口页用显式记录覆盖。另外别忘记，显式记录的优先级高于泛解析，改之前想清楚哪些子域是被盖住的。
TTL 设多长，取决于你要多久改一次
TTL 决定各地 DNS 缓存这条记录多久。它不是一个越短越好的参数：
- TTL 太短（比如 60 秒）：记录变更生效快，但解析请求量明显上升，遇到服务商限速时反而容易出问题；
- TTL 太长（比如 24 小时）：解析压力小，但换 IP、换机房时要等很久才能全量生效，期间会有一部分请求仍然打到旧地址。
已经稳定运行的域名，取几小时到一天比较省心；还在调试、可能频繁调整的域名，取几分钟到十几分钟更方便。切换 IP 前，先把 TTL 调短，等旧缓存过期再改记录，能少踩很多坑。
如果换 IP 后仍有部分请求落在旧机器上，先别怀疑蜘蛛不听话，多半是 TTL 还没走完。
解析服务商这块，别省过头
解析本身很便宜，但它是整条链路的单点。选服务商时，可以看这几项：
- 是否有多个 NS，且分布在不同网络；
- 是否提供解析线路（电信、联通、移动、海外）与健康检查；
- 是否支持 API 批量增删改，域名多的时候这点很关键；
- 是否有限速策略，超量后是降速还是直接拒绝。
域名规模上百以后，手工在控制台点来点去几乎不可维护，建议提前把 API 接进自己的管理脚本。
几个常见误区
- 只测主域名，不测随机子域。泛解析配置错了，主域名往往还是好的，问题只出现在子域上。抽查时要随机取若干入口页域名，用 dig 或在线工具确认返回值。
- 以为解析生效就等于有人来。解析只是让入口页可达，蜘蛛来不来、来多少，还受域名历史、内容、抓取配额等影响，别把它当成开关。
- 一次改太多。DNS、服务器、入口页内容同时换，出问题时很难判断是哪一步造成的，建议分批分次改。
- 忽略解析和 HTTPS 的配合。解析换了 IP 之后，证书、回源配置没跟着更新，会出现握手失败，蜘蛛同样拿不到页面。
上线前的检查清单
- 随机抽取若干入口页域名，逐一确认解析结果与预期 IP 一致；
- 用不同网络环境（至少两处）验证解析是否一致；
- 确认 TTL 与当前的变更频率匹配；
- 确认解析记录有备份，误删后能快速恢复；
- 确认解析变更后，服务器上的站点配置、证书都已同步。
解析是最底层的一环，做对了不会有额外收益，做错了会让上面所有工作归零。把它当成常规检查项，比出问题后再回头排查省事得多。