服務器偶尔打嗝是常事。真正让人头疼的是：一次持續几分钟的 5xx，可能让蜘蛛在接下来的一两周里都對你這個站点保持谨慎。理解蜘蛛在服務端错誤面前的處理逻辑，比事後到處找“加速抓取”的办法更有用。

蜘蛛碰上 5xx 时在做什么

5xx 和 404 传递的信号完全不同。404 是明确的“這里没有”，蜘蛛可以較快地接受現實；5xx 是“我也不知道現在有没有”，蜘蛛無法判断頁面是否還存在，所以通常不會立刻刪除已有索引记錄，而是選擇稍後再来。

不同爬虫的重试策略细节不一样，但大致規律是相通的：

• 短時間内對同一 URL 重复請求几次，間隔逐渐拉長；
• 如果整站错誤率偏高，會降低對该站点的整体抓取频率；
• 错誤集中的目錄可能被暂时冷落，正常返回的目錄還能繼續被抓；
• 连接超时、重置和 5xx 都属于“服務端不可用”，處理逻辑接近。

所以服務器故障带来的损失，往往不是丢掉那几個頁面，而是蜘蛛對整站可靠性的判断被下調。

先從日誌里分清抖動和持續故障

不是所有 5xx 都需要紧張。發布时的一两分钟抖動，和資料库连不上導致的半小时雪崩，處理方式完全不同。看日誌时可以把范围压到小时甚至分钟級別，重点看這几件事：

值得關注的几個信号

• 错誤占比：5xx 在整個蜘蛛請求里占多少，是零点几個百分点還是一半以上；
• 時間分布：是集中在某個時間点，還是全天零星出現，後者更麻烦；
• 是否挑頁面：只有带參數的動態頁报错，還是静態頁也一起挂；
• 是否挑来源：只有某個 IP 段或某個机房訪問出問题，可能是鏈路或防護策略的原因；
• 是否與操作重合：错誤時間点是否正好對應發版、扩容、切 CDN。

如果错誤只出現在少數 URL 上且每次都能复現，那更像代碼問题；如果一片 URL 同时报错又同时恢复，更可能是资源耗尽或下游依赖挂掉。

恢复抓取节奏的先後顺序

服務器恢复後，很多人第一反應是赶紧提交、赶紧推連結。顺序错了，反而會在蜘蛛刚恢复訪問时又给它一次糟糕体驗。更稳妥的做法是：

1. 確認源站真的稳了：不是頁面能打開就算好，而是要看一段時間内错誤率是否归零，尤其是原来出错的那批 URL。
2. 把超时和连接數調到合理区間：让服務器在蜘蛛正常並發下不會再次被打穿，而不是等下一次訪問高峰再挂一次。
3. 观察日誌中抓取量的回升：蜘蛛回来通常是從少量 URL 试探開始，逐步放量。這個阶段不用急着催。
4. 用 Sitemap 重新列出重点 URL：帮助蜘蛛確認哪些頁面還活着，特別是故障期間新增或改動過的内容。
5. 检查内鏈有没有断：故障期間如果顺手改過模板或導航，很可能把蜘蛛原本的入口路径掐断了。

這几步做完，剩下的就是等。抓取频率的恢复通常比故障本身慢得多。

這些做法容易把事情弄反

故障之後最常见的错誤操作，是想用“加大入口”来把抓取量拽回去。外鏈轰炸、批量提交、临时搭一批站群入口，在蜘蛛已经判定该站点不稳定的时候，效果往往相反——入口越多，它遇到的错誤越多，判断只會更差。同理，故障刚恢复就上大范围改版、改 URL 结构，也會让蜘蛛在记忆還没更新时再次踩空。

抓取量下降多數是结果，不是原因。先把服務端稳定性做扎實，抓取节奏才有回来的基础。

一份简短的核對清單

• 恢复後连續观察至少一個完整的抓取时段，確認 5xx 不再出現；
• 確認错誤頁返回的是真正的狀態碼，而不是把报错頁伪装成正常頁；
• 確認 robots.txt、Sitemap 地址没有被错誤配置挡在外面；
• 確認關键頁面的内鏈入口仍然可達，没有被临时改動切断；
• 记錄這次故障的時間点和影响范围，下次能在日誌里快速定位。

服務端错誤處理得越干净，蜘蛛對你的信任恢复得越快。這件事没有捷径，能做的就是把稳定性和可核對性做好，剩下的交给時間。