做抓取排查时，多数人第一反应是看 URL 能不能打开、Sitemap 有没有提交。但蜘蛛的每一次抓取，在真正拿到 HTML 之前还有一段很长的路：解析域名、建立 TCP 连接、完成 TLS 握手、发出请求、等待服务器返回第一个字节。这段路走得不顺，表现往往不是抓取失败，而是抓取量慢慢往下掉，很难被察觉。
一次抓取请求的完整链路
把蜘蛛当成一个普通的 HTTP 客户端，它的单次请求大致经过下面几步：
- DNS 解析：把域名换成 IP，涉及本地缓存、递归解析器和权威服务器。
- TCP 连接：三次握手，跨地域时这一步的耗时就很明显。
- TLS 握手：证书校验、密钥协商，HTTPS 站点必走。
- 发送请求并等待首字节：也就是常说的 TTFB，服务器真正开始处理的时间。
- 传输正文：HTML 越大、带宽越紧，这一步越慢。
蜘蛛通常会复用连接，在一个连接上连续抓多个页面。但如果站点分布在多个 IP、使用多个子域，或者连接被中途断开，上面这套流程就得重走一遍。
DNS 解析：第一道容易被忽略的延迟
DNS 出问题的常见表现是：同一条 URL，你本地打开很快，蜘蛛却经常超时。原因可能是权威服务器响应慢、递归解析器在部分地区解析失败，或者返回的 IP 里混进了已经下线的节点。
- 域名的 NS 是否有多地冗余，单点故障会直接掐断抓取。
- TTL 设得过短，解析器频繁回源，高峰期容易丢包。
- 解析结果是否稳定，多机房返回的 IP 是否都真实可用。
这些检查用 dig 或在线多地点解析工具几分钟就能做，但很多站点从来没做过。
TLS 握手：证书链与协议细节
HTTPS 站点在 DNS 之后还有一轮开销。证书链不完整时，部分客户端需要额外回源补证书，时间会被拉长；服务器没开启会话复用，蜘蛛每次新连接都要重新协商；OCSP 校验如果走的是外部地址且响应慢，也会拖后腿。
- 确认证书链完整，中间证书已部署。
- 尽量启用 TLS 1.3 与会话票据，减少重复握手。
- 开启 OCSP Stapling，避免客户端自己去查吊销状态。
首字节时间：服务器真正干活的部分
TTFB 高，通常不是网络问题，而是服务器端的问题：数据库慢查询、缓存未命中后穿透到后端、页面渲染依赖同步调用外部接口，都会让蜘蛛在连接上干等。抓取量在流量高峰期下滑，很多时候就是 TTFB 被业务请求挤上去了。
可以按抓取来源单独统计响应时间，看看蜘蛛请求的 P95 是否明显高于普通用户。
连接复用与并发限制
长连接和 HTTP/2 能让蜘蛛在同一连接上连续取多个资源，减少握手开销。反过来，如果服务器因为防护策略把同一 IP 的并发压得很低，或者频繁主动断开连接，蜘蛛就会反复重连，单位时间能拿到的页面数量自然下降。
- 检查 WAF 或限流规则是否把蜘蛛的并发压到极低。
- 确认 keep-alive 超时不要太短。
- 避免在抓取高峰期做全站发布、重启等操作。
自查顺序
- 用带计时输出的 curl 请求几个代表性 URL，拆出 DNS、连接、TLS、TTFB 各段耗时。
- 换几个不同地域的节点重复一次，确认不是单点问题。
- 在服务器访问日志里筛选蜘蛛的 UA，统计响应时间和 5xx 比例。
- 对照抓取量曲线，看波动是否和服务器指标同步。
连接阶段的故障很少以抓取错误的形式报出来，它更像一种慢性损耗：蜘蛛来得了，但拿得慢，于是来得越来越少。
小结
抓取不是从 HTML 开始的，而是从 DNS 开始的。把解析、握手、首字节这几段拆开看，很多抓取量无缘无故下滑的问题就有了解释。这类优化不需要改动页面内容，收益却直接体现在蜘蛛单位时间能覆盖的 URL 数量上。