聊抓取时，注意力通常放在内容、链接和 Sitemap 上。但蜘蛛真正拿到一个 URL 之前，还有一段看不见的路要走：域名解析、建立连接、加密握手。这一段走不通，页面再干净也不会被读到。
DNS 解析：抓取链路的第一道门槛
蜘蛛拿到 URL 后先要把它换成 IP 地址。这一步的耗时和稳定性，取决于域名解析服务本身，而不是你的服务器。
- TTL 设置：TTL 太短，解析记录频繁变动，抓取端的缓存命中率低，每次都要重新问一遍；TTL 太长，迁移 IP 后旧地址还会被继续用上一段时间。
- CNAME 层级：为了接入 CDN 或第三方服务，不少人叠了三四层 CNAME。每多一层就多一次查询，解析失败的窗口也更大。
- 解析一致性：不同地区、不同解析节点返回的 IP 可能不同。如果其中某个节点返回了已经下线的 IP，抓取就会表现为间歇性失败，而不是全站挂掉。
连接与握手：还没发请求就已经花了时间
解析完成后是 TCP 三次握手，HTTPS 站点还要再加一轮 TLS 握手。这两步都发生在服务器真正处理请求之前。
- TLS 版本：TLS 1.3 完成握手通常比 TLS 1.2 少一个往返，在高频抓取的场景下，累积起来是可见的差距。
- 证书链：中间证书缺失时，部分客户端需要额外去取，握手时间被拉长，个别情况下直接失败。
- 吊销状态检查：配置不当会让握手多一次外部请求，而这个请求本身也可能超时。
- 协议选择：HTTP/2 可以在同一连接上复用多个请求，对密集抓取更友好；但如果服务端配置不稳，反而容易出现连接被重置。
首字节之前的时间，都算在抓取成本里
很多站长只盯着服务器执行脚本的耗时，实际蜘蛛感知到的等待是从解析域名那一刻开始的。解析、握手、排队、处理、返回，任何一段变慢，抓取节奏都会跟着变。抓取频率的高低，不只看内容质量，也看这条链路稳不稳。
连接层的开销为什么会拖慢整体抓取量
蜘蛛和浏览器不同，它同时挂着大量待抓 URL。如果每个连接都要重新解析、重新握手，抓取端的连接池就被这些“准备工作”占住了。表现就是：日志里抓取条数下降，但服务器负载看起来并不高。
抓取变慢时，先分清是“内容处理慢”还是“连接建立慢”，两者的排查方向完全不同。
可以顺着做的检查
- 用命令行工具拆解耗时，看解析、连接、握手各阶段分别占了多少。如果域名解析阶段就很高，问题不在服务器。
- 检查 CNAME 链有几层，能合并的合并，别为了省事一层层往上套。
- 核对证书链是否完整。浏览器能访问，不代表所有客户端都能顺利握手。
- 确认服务器在连接层没有做限制，例如防火墙对同一来源的并发连接做了裁剪。
- 看日志里失败请求的分布：如果集中在某个时间段或某类解析结果上，多半指向解析或网络链路，而不是页面本身。
小结
URL 发现、内链和 Sitemap 解决的是“蜘蛛知不知道该来”，DNS、连接和握手解决的是“蜘蛛来了能不能顺畅拿到”。后者平时不出问题就不显眼，一旦出问题，前面的优化都会被抵消。把这条链路纳入日常巡检，比事后追查要省事得多。