先理解抓取时的连接行为
搜索蜘蛛抓取一个站点时，并不会每次都重新建立一条 TCP 连接。在多数实现里，它会先与服务器建立连接，然后在这条连接上连续发起多个请求，也就是常说的连接复用（Keep-Alive / 持久连接）。这样做的目的是减少握手开销，让抓取在单位时间内覆盖更多 URL。反过来说，如果服务器对持久连接的处理不稳定，蜘蛛拿到的就不是某一条 URL 出错，而是一批 URL 连续失败，表现上很像站点整体响应异常，但单条 URL 用浏览器访问又是正常的。
所以当抓取量突然下降、日志里出现成片的连接重置或提前断开时，先别急着怀疑内容质量，连接层往往是更靠前的怀疑对象。
几类常见异常表现
- 连接被提前关闭：服务器或中间层在响应头里声明了 Keep-Alive，但实际只服务一两个请求就断开，剩下的请求全部落空。
- 超时设置过短：Keep-Alive 超时配置得很小，蜘蛛还没来得及发下一个请求，连接就已经被回收。
- 并发上限打满：单连接请求数上限设置偏低，导致连接频繁重建，抓取节奏被拖慢。
- 中间层各管一段：CDN、负载均衡、源站三层各自有不同的 Keep-Alive 策略，最短的那一层决定了实际行为。
核对顺序
- 先看服务器访问日志中同一 IP、同一 UA 的请求间隔与连接标识，判断是否出现同一连接内只有一两个请求的模式。
- 检查 Web 服务器与反向代理的 Keep-Alive 相关参数，确认超时、最大请求数、连接池大小是否与站点规模匹配。
- 对比直连源站与经过 CDN 的响应头，看 Connection、Keep-Alive 是否被改写或删除。
- 用支持持久连接的命令行工具连续请求同一主机上的多个 URL，观察第 N 个请求是否稳定成功。
- 在低峰与高峰各测一轮，确认问题是否与并发压力相关，而不是配置本身写错。
一个常见的误判是：把连接层的批量失败当成蜘蛛不喜欢这个站。如果同样的 URL 用浏览器或其他爬虫访问一切正常，问题更可能出在连接的维持方式上。
容易被忽略的细节
HTTP/2 与 HTTP/1.1 在连接管理上差别很大。HTTP/2 使用单连接多路复用，若中间层对 HTTP/2 支持不完整，可能出现部分请求被静默丢弃的情况，而日志里看不到明显的错误码。核对时最好分别固定协议版本测试一次，确认差异来源。
另一个细节是响应体的长度声明。如果 Content-Length 与实际输出不一致，或者用了分块传输却没有正确结束，连接复用就会被打断——客户端无法确定这一条响应到哪里结束，只能选择断开。这类问题往往同时伴随页面截断，容易和前端渲染问题混淆。
修正之后要持续看什么
调整完连接参数，不要只看当天的抓取量。建议观察一到两周的抓取日志，关注三个指标：单位时间内的成功请求数、单连接平均请求数、连接重建的频率。若成功请求数回升且单连接请求数稳定在一个合理区间，说明连接层已经不再是瓶颈。同时留意服务器资源占用，过长的 Keep-Alive 会占用连接槽位，在并发高时反而可能挤掉新的抓取请求。
连接复用属于基础设施层面的调整，它不会直接带来收录变化，但会决定蜘蛛在同样时间内能看到多少 URL。把这一层理顺，再做内链和 Sitemap 的梳理，效果会更可控。