蜘蛛抓取日誌里，狀態碼之外還有一類记錄容易被忽略：连接被重置、响應讀到一半断開、字节數為零或明顯偏小。這類情况不會像 404 或 500 那样给出明确的狀態，但會直接消耗抓取机會。理解它從哪里来，比急着改頁面更重要。

连接重置在日誌里長什么样

不同日誌格式记錄方式不同，常见關鍵詞包括 Connection reset by peer、EOF、upstream timed out、recv() failed 等。蜘蛛侧可能表現為“抓取失敗”“下载中断”，站点侧則可能在 Nginx、Apache 或應用日誌里留下對應记錄。

它和 HTTP 狀態碼错誤有区別：4xx、5xx 通常意味着服務器已经返回了一個响應；连接重置更像是在握手之後、响應完成之前，连接被某一方或中間设备强行切断。因此單看訪問日誌里的狀態碼，往往找不到原因。

常见的几類触發原因

连接被掐断不一定针對蜘蛛，很多时候是服務器安全策略或资源限制的副作用。可以按下面几個方向排查：

• 防火墙與安全组：對短時間高频訪問的 IP 進行拦截，蜘蛛 IP 可能被誤伤。
• WAF 或 CC 防護：規則過嚴时，會直接重置连接，而不是返回 403。
• 並發连接數限制：站点或容器层面的连接上限被占满，新請求被丢弃。
• keepalive 與超时設定：连接空闲時間超過阈值，被服務端主動關閉。
• 應用层超时或進程異常：後端處理過慢、内存溢出、進程重啟，導致连接中断。
• 網絡鏈路抖動：跨机房或跨运营商鏈路不稳定，丢包後连接被重置。

這些原因可能同时存在。排查时不要只看一個指标，最好把時間、来源 IP、User-Agent、請求 URL 和服務器错誤日誌放在一起對照。

排查时先做這几件事

第一步，確認影响范围。是某個栏目、某類 URL，還是全站随机出現？如果集中在動態接口或搜尋參數，可能是應用超时；如果集中在同一 IP 段，更偏向安全策略。

第二步，查看服務器错誤日誌。Nginx 的 error_log、應用日誌、容器事件里，通常能找到 reset by peer 或 timeout 的原始记錄。没有服務端日誌，只靠蜘蛛日誌很难定位。

第三步，检查 WAF、防火墙和限速規則。確認是否有针對爬虫的全局频控、UA 黑名單、IP 黑名單。若使用了 CDN 或云防護，也要看邊缘节点的拦截记錄。

第四步，做低频、小范围的连通性驗證。用正常請求測試目标 URL，观察是否稳定返回完整内容；同时對比不同時間段的抓取成功率。不要用高频請求去“压测”蜘蛛路径，那只會让問题更复杂。

站点侧可以怎么調整

如果確認是安全策略誤伤，優先考虑對已驗證的搜尋蜘蛛 IP 段放行，而不是直接關閉防護。驗證方式可以结合反向 DNS 和官方 IP 列表，避免把伪造 UA 的請求也放進来。

如果确實是资源紧張，建议把“拒绝”改成更明确的信号：返回 429 或 503，並带上 Retry-After。直接重置连接會让蜘蛛不知道要等多久，也不利于後續抓取节奏的稳定。

• 检查 keepalive_timeout、连接队列和後端超时，避免连接被過早關閉。
• 观察抓取高峰是否與业務高峰重叠，必要时错峰或扩容。
• 保持 Sitemap 和内鏈清晰，减少蜘蛛在無效 URL 上的消耗。
• 定期對比抓取成功率，而不是只看單次失敗。

连接重置不會让蜘蛛永久放弃一個站点，但會降低有效抓取量。比起想办法屏蔽蜘蛛，不如先確認服務器是否给出了稳定、可预期的响應。

最後提醒一点：排查连接中断时，一次只改一個變量。防火墙、WAF、超时參數同时調整，後續很难判断是哪一項起了作用。保持观察，给抓取日誌留出足够的样本時間，再决定是否繼續調整。