蜘蛛抓取失敗时，很多人的第一反應是「是不是被屏蔽了」。實际上，日誌里更常见的失敗是服務器自己没答好：5xx、连接超时、响應被中断。這几類問题的處理方式差別很大，方向搞错了容易白折腾。
先把失敗按响應類型拆開
看抓取日誌时，別只盯着一個「失敗率」，按下面三類分開統計更有用。
- 有响應但狀態碼不健康：5xx、403、429。蜘蛛拿到了明确答复，會據此調整自己的节奏。
- 连接层没走通：DNS 解析失敗、TLS 握手失敗、连接被重置。日誌里常表現為超时或 EOF，蜘蛛连内容都没看到。
- 响應太慢：连接建立了，但首字节等太久，最後超时断開。看起来像没抓到，本质是服務器负载問题。
5xx：先把服務器修好，再谈抓取
5xx 是服務器明确表示自己這邊出错了，和 404 不是一回事。404 說明内容不存在，通常不需要處理；5xx 属于暂时性故障，蜘蛛一般會稍後重试，但持續出現时抓取频次會明顯下降。
看日誌时先判断范围：
- 只集中在少數 URL：多半是某個頁面模板或資料查询有問题，比如詳情頁調用外部接口、列表頁參數触發慢查询。
- 集中在某個時間段：可能是定时任務、备份或流量高峰叠加，服務器扛不住。
- 全站铺開：資料库、應用進程池耗尽、内存不足、磁盘寫满，這類要按故障處理流程走。
處理顺序建议是：先看 Web 服務器错誤日誌和應用日誌，定位具体报错；再看資料库慢查询和连接數；最後才检查 CDN 回源配置。不要一上来就改 robots.txt 或加爬虫規則，那解决不了 5xx。
403 與拦截：先確認是谁挡的
403 大多不是蜘蛛主動放弃，而是請求在到達應用之前就被拦下。常见位置有三處：CDN 的防護規則、WAF 的 UA 與频率策略、服務器上的 IP 黑名單。找一個固定 IP 或模拟請求复現，看它在哪一层被拒绝，比在日誌里反复猜要快。
如果确實是安全策略誤伤，驗證方式應该基于搜尋引擎公布的反向解析和 IP 段，而不是简單放行某個 UA 字符串。UA 谁都能改，只靠它做白名單迟早出問题。
超时：慢在哪里比慢多少更重要
超时請求在日誌里常常只有一行，看不出原因。可以临时打開慢日誌，或者用命令行工具记錄各阶段耗时：DNS、连接、首字节、传輸。如果首字节就慢，問题基本在後端；如果传輸阶段慢，多半是頁面体积或带宽。
需要留意的一点是：蜘蛛有自己的超时窗口。服務器响應越慢，同一時間窗口里能完成的請求就越少，抓到的頁面自然變少。這不是蜘蛛變懒，而是预算被慢响應吃掉了。
修复之後怎么確認真的好了
- 观察日誌里 5xx 與超时的比例，连續几天回落到接近零，才算稳定。
- 看抓取频次與成功請求數是否逐步回升。通常不會立刻恢复，需要一個過程。
- 確認抓到的頁面是正常内容，而不是错誤頁返回了 200——這種「软性错誤」比真實错誤更难發現。
- 把這次的触發條件寫進监控告警，而不是等下一次再從日誌里翻。
抓取異常的排查顺序，说到底就是先服務器、再網絡、最後才是抓取策略。顺序反了，改多少規則都没用。