很多站長看抓取日誌只關注狀態碼，但有一類抓取失敗不會留下 200、404 或 5xx，而是請求開始後连接被中断，或者蜘蛛等待超时後自己离開。這類問题不解决，頁面可能長期處于“抓過但没抓全”的狀態。
先分清抓取失敗的几種形態
- 响應超时：服務器在蜘蛛等待窗口内没有返回首字节或完整响應。
- 连接重置：TCP 连接被服務器、防火墙或中間设备强制断開。
- 传輸中断：响應已经開始，但 body 没有传完。
- 连接被拒绝：並發已满、端口未监听或安全策略拦截。
這些情况在服務器日誌里可能表現為 408、499、502 或 504，也可能只有一條没有响應碼的請求记錄。單看狀態碼分布，很容易漏掉它們。
服務器端能看到哪些线索
如果用的是 Nginx、Apache 或带訪問日誌的 CDN，可以重点看几個字段：請求總耗时、上游响應時間、發送字节數。若某個 URL 的發送字节數明顯小于頁面正常大小，說明传輸中途断了；若日誌里频繁出現 499，通常表示客戶端在服務器响應前關閉了连接，蜘蛛超时离開时並不少见。
還可以看连接队列和並發數。服務器连接數打满时，新来的抓取請求可能连不上，或者排队到超时。此时日誌里未必有對應 URL 的完整记錄，但系統监控會顯示连接數飙升。
常见的几個原因
後端處理太慢
動態查询、外部接口調用、同步寫日誌等操作，會把首字节時間拉長。蜘蛛的等待窗口有限，超過之後就會断開。给蜘蛛常抓的列表頁和詳情頁加缓存、把非關键逻辑改成异步，通常比反复提交 URL 更有效。
keep-alive 與並發配置不匹配
连接复用本身是好事，但如果服務器、负载均衡或 CDN 的空闲超时不一致，连接可能在复用前被中間设备先關掉。蜘蛛再次使用這條连接时就會遇到重置。把各层的 keep-alive 和空闲超时調成一致，能减少這類偶發中断。
並發限制與安全策略
WAF 或防火墙可能把蜘蛛 IP 当成異常流量，触發限速、驗證或直接拦截。合法蜘蛛的 UA 和 IP 可以做校驗，但不建议整段封禁。CDN 回源超时、源站限速也需要單獨確認。
响應体與传輸方式
頁面過大、未压缩、chunked 配置異常、gzip 與代理冲突，都可能導致传輸中断。控制 HTML 体积，确保压缩正常，避免在传輸過程中插入額外脚本或重定向。
排查顺序
- 確認抓取方 IP 與 UA，排除誤判。
- 用 curl 带蜘蛛 UA 請求同一 URL，观察连接、首字节和總耗时。
- 對比訪問日誌中该 URL 的請求耗时與發送字节數。
- 检查 WAF、CDN、负载均衡的超时與限速日誌。
- 在低峰和高峰各测一次，確認是否與並發相關。
可以落地的調整
- 给蜘蛛常抓的頁面加缓存，减少後端压力。
- 统一各层 keep-alive 與空闲超时，避免连接被中間设备先断。
- 给合法蜘蛛設定合理的並發上限，而不是完全放開或一律拦截。
- 确保 gzip、chunked 與代理配置兼容，响應体能完整传輸。
- 在抓取高峰期避免跑全站生成、大报表等重任務。
服務器稳定的目标不是永遠不波動，而是蜘蛛每次来都能在可接受時間内拿到完整、一致的响應。
抓取中断往往不是單一原因，先從日誌里的耗时和传輸字节數入手，再结合並發與安全策略排查，通常比盲目調整 robots.txt 或反复提交 Sitemap 更有效。調整後观察一段時間，看回訪是否更完整，再决定下一步。