做蜘蛛池时，注意力通常都放在页面本身：入口页写什么内容、链接怎么放、robots 怎么写。但蜘蛛必须先把域名解析成 IP，才有可能建立连接。这一步出问题，页面做得再规整也没有机会被看到。这篇文章只谈入口页的域名解析这一层，说说哪些设置会影响 URL 发现，以及出问题时怎么排查。
DNS 在抓取链路里的位置
一次抓取大致要经过：从 URL 中取出域名，查询本地或递归解析器缓存，拿到 A 或 AAAA 记录，再建立 TCP 与 TLS 连接，最后才发送 HTTP 请求。DNS 排在最前面，一旦失败，后面的环节全部不会发生。搜索引擎的爬虫一般有自己的解析缓存，缓存时长受域名 TTL 影响；TTL 没到期之前，即便你已经改了记录，蜘蛛可能仍在访问旧 IP。
TTL 该设多长
- TTL 太短，例如几十秒：解析请求数量成倍增加，个别线路偶发超时，抓取成功率会明显抖动。
- TTL 太长，例如一天以上：更换 IP 或切换线路后，蜘蛛会在很长时间里访问旧地址，表现为“服务器都换了，抓取还是失败”。
- 比较稳妥的做法是平时用几十分钟到几小时的 TTL，在计划迁移前一段时间先调短，迁移完成并观察正常后再调回去。
多线路、多 IP 与解析结果
不少蜘蛛池会给同一个入口域名配多条 A 记录，或者按运营商做智能解析。这本身没有问题，但要注意两点：其一，多个 IP 上返回的页面内容应当保持一致，否则同一个 URL 在不同抓取中拿到不同内容，容易被判为异常；其二，不要频繁增删解析记录，解析结果变化太快，蜘蛛侧的缓存和你的预期会对不上。
解析延迟也是一项成本
DNS 查询通常只有几十毫秒，但如果递归层级多、权威服务器响应慢，累积起来会明显推高首次连接耗时。抓取频率较高的入口页对此尤其敏感：同样的抓取配额下，延迟越高，能覆盖到的 URL 就越少。选用响应稳定的权威 DNS 服务、减少不必要的 CNAME 层级，是成本最低的一步优化。
解析失败在日志里长什么样
如果某段时间访问日志里完全没有蜘蛛记录，而其他来源的流量正常，先别急着怀疑页面质量。可以按这个顺序查：同时段服务器是否收到大量陌生 IP 的连接、是否有 TLS 握手失败记录、CDN 或 WAF 是否拦截了蜘蛛 UA。如果服务器端什么请求都没收到，问题大概率在 DNS 或网络链路，而不是页面本身。
排查顺序建议：先确认解析是否正常，再看连接能否建立，最后才去检查响应状态和页面内容。
几个常见误区
- 用泛解析把大量无关子域指向同一台机器。看似省事，但蜘蛛可能顺着解析结果发现一批本不该存在的入口，制造无效抓取。
- CNAME 链拉得过长，中间任意一环异常都会导致解析变慢甚至失败。
- 只在自己所在的网络环境里做测试，忽略了运营商之间的线路差异。
- 切换服务器时直接改掉记录，没有过渡期，抓取失败会集中出现。
实操建议
- 用多个地点的解析工具交叉验证，不要只看本地返回结果。
- 入口页域名尽量与业务主域名分开，避免一方出问题牵连另一方。
- 迁移或换 IP 时，让旧地址在一段时间内继续正常响应，照顾仍在使用旧缓存的请求。
- 把解析异常记录下来，与蜘蛛访问日志放在同一条时间线上对照，定位速度会快很多。
DNS 这一层平时不出问题就没人留意，一旦出问题又很容易被误判成内容或模板问题。把解析稳定性纳入入口页的日常运维，URL 被发现才有基本保障。