抓取不是从 GET 请求开始的
讨论蜘蛛抓取时，很多人盯着 HTTP 状态码和响应时间。但从蜘蛛决定访问一个 URL 到真正拿到内容，中间还有一段容易被忽略的路：DNS 解析、TCP 连接、TLS 握手。任何一步失败，蜘蛛看到的都不是 200，而是连接错误、超时或者握手失败。日志里可能只留下一条“抓取失败”，具体原因需要往前看。
对站点来说，这些环节属于基础设施层。它们不直接决定内容质量，却会影响蜘蛛能不能稳定地把 URL 抓完。
DNS 解析：第一步就可能卡住
蜘蛛在请求前要先把域名解析成 IP。解析时间过长、解析结果不稳定，或者不同地区返回不同 IP，都可能让抓取表现不一致。
常见问题包括：
- DNS 服务商响应慢，解析耗时波动大；
- TTL 设置过短，蜘蛛每次抓取都要重新解析；
- 多 IP 轮询时，个别 IP 已经不可用但仍在返回；
- 域名同时解析到 CDN 和源站，导致连接目标混乱。
这些问题的表现往往不是大面积失败，而是零星超时、间歇性连接失败。如果蜘蛛抓取量本身不大，这种波动很容易被当成偶发情况忽略。
TLS 握手：证书和协议版本都会影响抓取
现在大多数站点走 HTTPS。TCP 连接建立后，还要完成 TLS 握手。证书过期、证书链不完整、SNI 配置错误、TLS 版本过旧，都会让蜘蛛在握手阶段断开。
有些站点在浏览器里访问正常，是因为浏览器对某些问题有兼容或缓存机制；蜘蛛不一定有同样的容忍度。比如：
- 证书链缺少中间证书，部分客户端直接失败；
- 只支持较老的 TLS 版本，新爬虫可能无法协商；
- 多域名共用证书时，某个域名不在证书覆盖范围内；
- OCSP 装订或吊销检查超时，拖长握手时间。
建议定期检查证书有效期和链完整性，并保持服务端 TLS 配置处于受支持的主流版本。这不是为了“讨好蜘蛛”，而是让所有正常的 HTTP 客户端都能稳定连接。
连接超时与连接复用
蜘蛛通常会复用连接，也就是在一个 TCP 连接上连续请求多个 URL。这样做能减少握手开销，但也对服务器的连接保持时间和并发处理提出要求。
如果服务器把空闲连接超时设得太短，蜘蛛刚准备发下一个请求，连接已经被关闭，它就要重新建连。反复如此，抓取节奏会明显变慢。反过来，如果服务器长时间不回收连接，也可能占用资源。
比较稳妥的做法是：
- 让连接保持时间与站点实际抓取频率大致匹配；
- 不要在网关层随意注入过短的超时；
- 关注源站并发连接数，避免高峰期把蜘蛛请求排到队尾。
连接超时设置没有统一标准，关键是不要因为过短或过严，让正常的抓取请求在建立阶段就被切断。
这些损耗怎么排查
从服务器日志和监控里，可以重点看几类信号：
- 连接失败记录：蜘蛛 IP 的请求是否在建立连接阶段就中断；
- TLS 错误日志：是否有握手失败、证书告警；
- DNS 解析耗时：解析时间是否明显高于日常水平；
- 连接复用率：同一蜘蛛是否频繁新建连接。
如果日志只记录了成功请求，这些前置失败可能看不到。必要时可以在网关或负载均衡层保留连接错误日志，至少确认失败发生在哪一步。
日常检查清单
- 证书有效期和证书链是否完整；
- DNS 解析是否稳定，TTL 是否合理；
- 多 IP 或多 CDN 节点是否存在不可用实例；
- 服务器连接超时和 keep-alive 设置是否过短；
- 高峰期源站是否出现连接排队或拒绝；
- 蜘蛛抓取日志里是否出现集中性的连接错误。
这些检查不能保证页面一定被收录，但能减少蜘蛛在“还没看到内容”之前就失败的情况。抓取稳定是后续一切工作的前提。
抓取路径看起来是从 URL 到页面，实际上前面还有一段基础设施路径。把 DNS、TLS 和连接阶段的损耗控制住，蜘蛛才有机会走到真正的内容面前。