搭建蜘蛛池时，很多人把精力放在入口页的数量、模板和内容上，却忽略了最前面的一环：域名解析。蜘蛛要访问一个入口页，第一步不是发 HTTP 请求，而是把域名解析成 IP。这一步出问题，后面的配置做得再细也很难体现出来。
为什么 DNS 值得单独拿出来说
解析失败和页面 404 不是一回事。页面返回 404，蜘蛛至少完成了访问，知道这个地址存在过；而解析失败时，蜘蛛连服务器都没碰到。它通常不会像浏览器那样立刻重试，而是记录一次失败，可能降低该域名的抓取优先级，甚至在一段时间内不再回访。
常见的几种情况包括：解析生效比预期慢，入口页已经上线但蜘蛛拿到的还是旧 IP；解析结果不稳定，同一个域名在不同时间返回不同地址；解析指向了一台已经下线的机器。这些问题的共同点是，从页面本身完全看不出来。
常见记录类型与选择
- A 记录：指向 IPv4 地址，最直接，也是大多数入口页会用到的类型。
- AAAA 记录：指向 IPv6。如果服务器没有稳定的 IPv6 出口，不建议随手添加，蜘蛛走 IPv6 失败会白白消耗一次抓取机会。
- CNAME：多个子域名指向同一个目标，适合批量管理，但要注意解析链路不要太长。
- 泛解析：批量生成子域名入口页时很方便，但任何拼错的子域名都会解析到你的服务器，产生大量无效请求。
TTL 设置：太短和太长都有代价
TTL 决定解析结果在递归 DNS 里的缓存时间，设置时需要权衡两端。
- TTL 太短，比如 60 秒，解析请求会变得频繁，权威 DNS 压力上升，遇到服务商抖动时，蜘蛛拿到的结果反而更容易不稳定。
- TTL 太长，比如 24 小时，换服务器或换 IP 之后，旧地址还会被缓存很久，蜘蛛可能持续访问已经下线的机器。
比较常见的做法是：日常使用 300 到 600 秒；计划迁移前提前一天降到 60 到 300 秒，切换完成并观察一段时间稳定后，再调回原值。
多条 A 记录与负载分配
给同一个域名配多条 A 记录，解析会轮流返回不同 IP。这本身没有问题，但前提是每台机器都能正常响应。如果其中一台宕机，蜘蛛有一定概率拿到那个坏地址，表现就是有时候能抓、有时候抓不到。
这种间歇性失败在日志里很难识别，排查成本很高。要么保证所有 IP 都处于可用状态，要么干脆只保留一条记录，把负载分配放到更靠后的环节处理。
解析变更时的几个细节
- 先确认新服务器已经能正常返回入口页，再修改解析，不要反过来操作。
- 改完解析后，等过完整的 TTL 时长再开始统计蜘蛛日志，否则新旧数据会混在一起。
- 如果入口页用泛解析批量生成，注意排除不需要的子域名，或者用一条兜底规则返回 404。
- 不要在同一时间批量修改大量域名的解析，出问题时很难定位是哪一步造成的。
- 域名上原有用于邮箱验证、CDN 接入的 TXT 或 CNAME 记录，迁移时别顺手删掉，可能影响其他正在使用的服务。
关于 DNS 服务商
免费与付费 DNS 的差别，主要体现在稳定性承诺、解析速度、抗攻击能力和 API 支持上。入口页数量不多时，免费服务通常够用；域名规模上来以后，一次解析异常带来的损失可能超过服务成本。如果需要批量下发记录，优先选支持 API 的服务商，方便把配置纳入自动化流程，也便于随时核对每条记录的实际状态。
一份简单的检查清单
- 域名解析是否正常，从不同地区查询的结果是否一致；
- 解析到的 IP 是否就是实际提供入口页的那台机器；
- 是否存在指向当前并不支持的地址的 AAAA 记录；
- 泛解析是否会产生大量无效子域名请求；
- DNS 服务商本身是否稳定，是否有可切换的备用 NS。
DNS 不是蜘蛛池里最显眼的部分，但它是最靠前的一环。解析不稳，后面做得再好，蜘蛛也很难顺利进来。