平时看抓取日誌，注意力容易被狀態碼吸引：404 多了、500 多了，一眼就能看见。但真正让 URL 迟迟不被抓取的，往往是那些没有留下完整狀態碼的請求——连接建好又断了，响應头回来了正文没回来，握手阶段就超时了。這些记錄看起来含糊，却直接决定了這次抓取算不算數。

一次抓取請求要走過几段路

把一次抓取拆開，大致會经過：DNS 解析、TCP 建连、TLS 握手（HTTPS）、發送請求、等待响應头、接收响應体、连接复用或關閉。任何一段出問题，结果都可能不是干净的 200 或 5xx，而是日誌里一行难以归類的记錄。

三類常见的“没抓完”

1. 连接被重置

日誌里表現為請求刚發出就中断，或者连接建立後被立即切断。常见原因包括：服務器或中間设备主動断開空闲连接、並發數触發了防護策略、後端進程崩溃重啟、長连接被中間层静默關閉。這類失敗通常不會带狀態碼，或只留下一個极短的訪問時間。

2. 响應传到一半断掉

响應头正常返回，甚至狀態碼是 200，但正文没有传完。此时蜘蛛拿到的是残缺内容：可能缺正文、可能 HTML 结构不閉合、可能連結列表只解析出一部分。對 URL 發現来说，這比直接失敗更麻烦，因為部分連結會凭空消失，而站点侧却以為這一頁已经被抓過了。

3. 握手與首字节慢

TLS 握手超时、首字节迟迟不到，通常出現在服務器负载高、回源鏈路長、證书鏈配置異常的场景。蜘蛛有等待上限，超過就放弃，並把這次记錄為超时。偶發一次影响不大，但如果某個目錄長期如此，抓取频率會明顯降低。

抓取失敗分两種：一種是明确告诉蜘蛛“不行”，另一種是让蜘蛛在等待中耗尽耐心。後者更难排查，也更伤 URL 發現。

蜘蛛遇到失敗之後會怎么做

• 重试：對连接類失敗，通常會在後續排期里再试，但重试次數和間隔不公開，且會受整体抓取压力影响。
• 退避：如果同一主机反复失敗，抓取节奏會放缓，表現為该目錄的抓取量整体下降，而不是某一頁反复重试。
• 减少复用：连接不稳定时，蜘蛛可能更倾向于重新建连，這反過来又增加服務器负担，形成循环。

需要說明的是，這些行為都是推测性描述，不同搜尋引擎、不同時間点的策略並不一致，不必按固定規律去推算。

服務器端優先排查什么

1. 看抓取日誌里的“短請求”：响應時間极短又没狀態碼的记錄，往往就是被重置的那批，按 IP 段和路径聚一下，看是否集中在某個目錄或某台後端。
2. 检查超时配置是否過短：應用层、反向代理、负载均衡各有超时，任何一层比上游短，都可能造成半截响應。
3. 確認長连接與並發策略：连接复用被中間设备提前關閉，是连接重置的常见来源，需要跟运维確認空闲超时和並發上限。
4. 观察發布與重啟窗口：每次都伴随抓取失敗小高峰的時間点，通常對應部署、重啟或缓存刷新。
5. 對比正常與異常路径的耗时：同一個站点里，某些栏目頁明顯慢于其他頁面，說明瓶颈在資料或模板层，不在網絡层。

別把失敗当成“蜘蛛不来了”

抓取量下降时，容易先怀疑内容质量或權重變化，但如果日誌里连接類失敗在同步上升，那更像是通道問题。建议把“抓取成功”單獨定义成一次完整拿到响應体，而不是只要有一條訪問记錄就算數。按這個口径統計，往往會發現真實抓取量比想象中低。

站点运营上能做的，是让每一次抓取都尽量完整：稳定的後端、合理的超时、不随意打断的長连接，再加上對失敗记錄的定期查看。蜘蛛會不會来、来多少，無法保證；但把請求完整送出去，是站点自己可以控制的那部分。