很多人盯蜘蛛池的效果时，习惯先看访问日志：今天蜘蛛来了多少次、抓了哪些页面。但日志只能记录“已经连上服务器”的请求。如果域名根本没解析成功，蜘蛛连门都没进，日志里一片空白，你会误判成“蜘蛛没来”，其实是“根本进不来”。
抓取链路上最靠前、也最容易被忽略的一步
蜘蛛抓取一个 URL 的顺序大致是：解析域名 → 建立连接 → 发送请求 → 收到响应。日志记录的是后三步，第一步发生在你完全看不到的地方。对蜘蛛池这类靠大量子域名铺入口页的玩法来说，解析层出问题的概率并不低，因为域名多、记录多、变更频繁。
常见的解析配置问题
泛解析没配或只配了一半
入口页通常用 *.example.com 这样的泛解析，把成千上万个子域名指到同一台或同一组服务器。要确认通配记录真的生效，而不是在少数几个子域名上单独加了 A 记录。漏配的子域名，在蜘蛛侧就是 NXDOMAIN，抓取直接终止，而且这类失败通常不会给你任何提示。
分线路解析造成的不一致
部分 DNS 服务商支持按电信、联通、移动、海外分线路返回不同 IP。如果海外线路指向了一个对国内请求不友好的节点，百度蜘蛛从国内出口访问时就可能超时。入口页集群如果没有特殊需求，解析线路建议保持简单一致，减少变量。
TTL 过长拖慢切换
TTL 设成 24 小时甚至更长时，换服务器后蜘蛛和中间缓存仍会访问旧 IP。迁移前先把 TTL 调低、等旧记录过期，再改解析，能少掉一段“两边都打不开”的空窗期。
CNAME 与 CDN 叠层带来的连锁问题
泛解析 + CNAME + CDN 三层叠在一起时，任何一层出错，外部表现都是同一句话——“打不开”。常见现象包括：
- CNAME 指向的目标域名自身没有解析记录；
- 回源域名与证书不匹配，HTTPS 握手失败；
- CDN 侧把大量子域名判定为异常接入而拦截；
- 缓存节点缓存的仍是旧 IP 的响应。
排查时不要一上来就动服务器，先把每一层单独验证一遍：解析结果对不对、CNAME 是否指向存在的域名、回源能否直连成功。
一套由外向内的排查顺序
- 用多个公共 DNS 分别查询同一子域名，看返回是否一致；
- 换网络环境（家宽、4G、云主机）再查一次，排除本地缓存干扰；
- 对比同集群里表现正常的域名，快速定位是单域名问题还是整体问题；
- 直接请求服务器 IP 并带上 Host 头，判断问题在解析层还是服务器层；
- 最后才去看服务器与 CDN 的日志。
几个容易踩的坑
解析生效了，但服务器没绑定
DNS 返回了正确 IP，但服务器上的虚拟主机没有配置对应域名，蜘蛛拿到的是默认站点或 404。这种情况在日志里其实有记录，容易被当成正常抓取。
证书没覆盖泛域名
如果用 HTTPS 访问，证书必须覆盖 *.example.com，否则每个新子域名都会触发证书告警，蜘蛛同样拿不到内容。
用免费 DNS 承载大量子域名
免费解析服务在查询频率高时可能限速或间歇性不响应。入口页规模一大，解析层反而成了瓶颈。
抓取链路上最早的一步发生在你看不见的地方，也最容易在排查时被跳过。
日常建议
- 新增域名或子域后，用外部工具验证一轮解析，而不是只看解析商后台的“已生效”；
- 把解析记录纳入版本管理，改了什么、什么时候改的留有记录；
- 迁移或调整线路前先降 TTL，错开抓取高峰；
- 定期抽样同一批子域名，确认解析结果仍然一致。
解析层面的问题不会带来“效果差一点”这种波动，它往往是全有或全无。把这一步纳入日常巡检，能把不少“蜘蛛不来了”的误判直接排除掉。