為什么 5xx 比 404 更值得警惕
404 只是告诉蜘蛛“這個地址没有内容”，而 5xx 说的是“服務器這次没能完成任務”。前者是内容层面的答案，後者是服務层面的故障。蜘蛛遇到 5xx 通常不會立刻放弃，而是降低抓取频率、稍後再来。問题在于：如果故障持續存在，抓取预算會被反复消耗在失敗的請求上，正常頁面的抓取节奏也跟着變慢；時間拉長，收錄與更新都可能受影响。
先分清几種常见狀態碼
- 500：應用内部报错，常见于未捕获異常、資料库连接失敗。
- 502 / 504：反向代理联系不上上游或上游超时，多见于服務重啟、進程假死、接口阻塞。
- 503：服務暂时不可用，通常配合 Retry-After 使用，适合計划内维護。
- 507 / 509：磁盘寫满或带宽、配額超限，属于资源類故障，容易被忽略。
自查清單：從日誌開始
- 統計訪問日誌里 5xx 的占比與集中路径，判断是整站故障還是個別頁面出错。
- 翻看 Nginx、PHP 與應用错誤日誌，按時間對齐，找出第一次出現的时刻。
- 用 curl -I 带上蜘蛛 UA 請求首頁、栏目頁、詳情頁，確認返回碼是否稳定。
- 检查磁盘空間、内存、進程數、資料库连接數，排除资源耗尽。
- 排查是否有同步調用第三方接口且未设超时時間，把整個請求拖死。
- 確認健康检查地址不是返回 200 的静態文件——它並不反映真實业務狀態。
處理时的几個原則
計划内维護尽量用 503 加 Retry-After，而不是直接砍掉服務、返回 502；永久移除的頁面應该给 404 或 410，不要用 5xx 代替，那會让蜘蛛反复回来重试。發布环节上，滚動重啟、灰度發布比一次性重啟更能压缩 502 的時間窗口。對重要栏目可以做静態兜底，即使動態服務挂了，核心頁面仍能返回正常内容。
別用返回 200 的“出错啦”頁面糊弄蜘蛛。它讀到的是正常内容，用戶看到的是故障，两邊都被誤導。
监控與恢复後的回归
把 5xx 比例做成监控指标並設定阈值告警，比事後翻日誌高效得多。故障恢复後，留意抓取频率是否回升，必要时通過 Sitemap 和内部連結把重点頁面重新推给蜘蛛。定期回看故障记錄，把每次 5xx 的成因沉淀成检查項，比單次修复更有價值。