先理解抓取时的连接行為
搜尋蜘蛛抓取一個站点时，並不會每次都重新建立一條 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 的梳理，效果會更可控。