很多人排查蜘蛛抓取问题，第一反应是看日志、看状态码、看页面内容，却忽略了在 HTTP 请求发生之前还有一跳：域名解析。蜘蛛拿到一条 URL，先要把它变成 IP 地址，才能发起连接。这一跳如果慢或者不稳定，后面的入口页做得再细致也没有机会被看到。
DNS 解析是抓取链路的第一跳
对蜘蛛来说，解析耗时是算在整体等待时间里的。解析超时或返回异常，爬虫通常会直接放弃这次抓取，服务器日志里甚至不会留下记录，只在你自己手动测试时才偶尔复现。所以遇到“明明没封、就是不来”的情况，DNS 值得优先排查一次。
- NS 至少两个，且分布在不同的网络或服务商，避免单点。
- 尽量减少 CNAME 跳转层数，部分递归解析器对多层 CNAME 处理较慢。
- 解析结果要稳定，同一地区多次查询应返回一致或就近的地址。
TTL 该设长还是设短
TTL 决定了解析结果被缓存多久。设得短，出故障时切换快，但递归服务器会更频繁地回源查询，解析压力和抖动都会上升；设得长，解析更平稳，但真要更换 IP 时，旧记录可能在缓存里停留很久。
比较常见的做法是把 TTL 设在几百秒到一小时之间：平时取偏长的值保持稳定，计划切换前再提前调短。不要今天 60 秒、明天 86400 秒来回改，蜘蛛侧和各地递归缓存的行为会变得难以预测。
IP 段与同 IP 多站的影响
把大量入口页放在同一台服务器、同一个 IP 上，是最常见也最容易被察觉的部署方式。蜘蛛并不需要“识别站群”，它只要发现一批域名解析到同一个地址、内容结构又相似，行为特征自然就集中了。这不一定直接导致不抓，但会让整批站点共享同一个判断结果。
- 入口页数量较多时，尽量分散到不同 IP，而不是只换域名。
- 同一 IP 上不要挂过多同模板、同业务的页面。
- 留意反向解析记录，空白或与实际用途明显不符的 PTR 不一定是问题，但也谈不上加分。
IPv6 与双栈部署
部分爬虫已经支持 IPv6。双栈本身是好事，可以在一定程度上分担压力，但前提是两条链路都真的可用。只加了 AAAA 记录、IPv6 路由却不通，会让支持 IPv6 的爬虫先尝试失败再回落，白白增加延迟。
如果暂时没有稳定的 IPv6 环境，只保留 A 记录完全够用，不必为了“看起来先进”而强行开启。
常见误区
- 只看能不能 ping 通：连通不等于解析快，解析耗时需要单独测量。
- 频繁改解析做“测试”：每次改动都会被各地缓存放大，反而更难判断。
- 指望靠改 IP 轮换入口页：这种方式不可控，效果也很难复盘。
- 忽略解析失败的记录：服务器日志里看不到的请求，往往就死在这一层。
一份可执行的检查清单
- 用多个地区的公共解析服务测试解析结果与耗时，记录波动范围。
- 确认 NS 有冗余，并了解所用解析商是否存在查询频率限制。
- 为域名设置合理的 TTL，把当前值记录下来，切换前再调整。
- 统计入口页与 IP 的对应关系，避免一个 IP 承载过多同类站点。
- 做一次切换演练：改解析、观察生效时间、确认回滚路径。
DNS 和 IP 属于“平时没感觉、出事很难查”的一层。把解析耗时、TTL 和 IP 分布记录下来，很多抓取异常会变得可以解释。
入口页的优化大多围绕内容和链接展开，但对蜘蛛而言，能不能连上、连得快不快，是排在更前面的事。定期回头看一眼解析这一层，成本不高，却是整条链路里回报比较直接的一段。