讨论蜘蛛抓取时，大家习惯盯着响应码、页面大小和抓取频次，这些都属于请求发出之后的环节。但在蜘蛛真正把 HTTP 请求发到你的服务器之前，还有几毫秒到几百毫秒的路要走：解析域名、建立 TCP 连接、完成 TLS 握手。这几步出问题，服务端日志里往往连一条记录都不会留下。
一次抓取在时间轴上的几个阶段
- DNS 解析：把域名换成 IP，可能要经过本地缓存、递归解析器、权威服务器。
- TCP 连接：三次握手，跨地域时往返时间会叠加。
- TLS 握手：证书校验、密钥协商，通常需要一到两个往返。
- 发送请求并等待首字节：这部分才是服务端日志能看到的开始。
- 传输响应体：页面越大、压缩越差，耗时越明显。
抓取端对超时的判断通常从第一步就开始计时。也就是说，如果 DNS 或 TLS 阶段就慢，请求可能还没到你的应用层就已经被放弃了。
DNS 是最容易出问题的一环
域名解析的耗时和稳定性，直接影响蜘蛛能不能走到你的服务器。几个常见的坑：
- CNAME 链太长：一层套一层，每一层都要额外查询，解析时间被放大。
- 权威 DNS 响应慢或不稳定：解析器要重试，甚至拿到超时结果。
- 多条 A 记录里有不可用 IP：轮询到坏 IP 时表现为连接超时，但问题不在服务器本身。
- 配了 AAAA 记录却没有可用的 IPv6 服务：支持 IPv6 的抓取端会先尝试走这条路。
如果近期做过改 IP、换 CDN 或迁移机房，可以先把 TTL 调低，切换完成后再调回。TTL 设得过短会让解析请求变多，设得过长则切换时旧 IP 会被缓存较久，两者各有权衡。
TLS 握手与证书：失败常常不留日志
证书过期、证书链不完整、只支持老旧协议，这些问题的共同点是连接根本建立不起来。抓取端拿到的是握手失败，而不是 404 或 500，所以服务端访问日志里看不到任何痕迹。
- 检查证书有效期与自动续期是否真的在执行。
- 确认中间证书已下发，而不是只发站点证书。
- 尽量支持 TLS 1.2 与 1.3，避免只留一种老协议。
- 使用 CDN 时，注意源站与边缘节点两侧的证书都要有效。
排查抓取异常时，如果日志里“什么都没有”，先别急着怀疑 robots.txt，先去测一下握手是否成功。
连接复用与 HTTP/2 带来的差异
抓取端通常不会为每个 URL 单独建一条连接。开启 keep-alive 和 HTTP/2 多路复用之后，同一个连接上可以连续请求多个 URL，握手成本被摊薄。反过来，如果服务器频繁主动断开连接，或者把并发连接数压得很低，抓取效率会明显下降。
需要注意的是，复用是按连接来算的。同一 IP 上的多个站点如果共用一个连接池，某个站点响应特别慢，也可能拖累同连接上的其他请求。
怎么观测这几段耗时
- 用 dig 或类似工具反复查询，看解析耗时和返回的 IP 是否稳定。
- 用 curl -w 打印各阶段耗时，例如 DNS、连接、TLS、首字节。
- 用 openssl s_client 检查证书链和协商到的协议版本。
- 在 Web 服务器日志中区分请求总耗时与应用处理耗时，判断慢在哪一段。
- 从不同网络位置测试，避免只从本地看到“一切正常”。
这些调整能改变什么，不能改变什么
把 DNS、TLS 和连接这几层做稳，能减少连接失败、超时与重试，让抓取过程更顺畅，也让服务端日志更干净、更容易分析。它属于基础设施层面的工作，不会直接决定某个 URL 是否被收录，更不涉及排名。真正影响收录的，仍然是内容本身、站点结构是否清晰，以及站点能否长期稳定访问。
如果近期观察到蜘蛛来访量下降，而日志里又找不到对应的失败请求，不妨先从这几毫秒开始查起。