同一條 URL，用浏览器打開一切正常，翻服務器日誌却發現搜尋蜘蛛拿到的是 500、403，或者一個“正在驗證您的浏览器”的中間頁。這種情况並不罕见，問题通常不在蜘蛛本身，而在于同一條地址對不同的請求走了不同的處理鏈路：UA、IP、請求频率、證书、回源节点，任何一個环节都可能把爬虫單獨筛出去。
先分清是“被拦住”還是“真报错”
這两類問题的處理方式完全不同，第一步要先把性质定下来。
- 被拦截：請求在到達應用之前就被 WAF、CDN 或安全插件處理掉了，常见表現是固定返回 403、429、503，或返回一個体积很小、内容高度模板化的驗證頁。
- 真报错：請求确實到了應用层，但因為參數、缓存、資料库或超时抛出了 500。典型特征是同一路径換個參數就正常，或者错誤集中在某個時間段。
判断方法很简單：用日誌里那條记錄的時間点和路径，手工带相同的 UA 复現一次。如果复現出同样的结果，說明可稳定重放；如果浏览器訪問始终正常、只有蜘蛛異常，多半指向拦截規則。
日誌里值得重点看的几個字段
按 UA 分组統計狀態碼
把日誌按 User-Agent 聚合，分別統計 2xx、3xx、4xx、5xx 的占比。如果普通浏览器 UA 的 5xx 占比接近零，而爬虫 UA 的 5xx 占比很高，基本可以鎖定是针對性處理。
响應体大小
驗證頁、拦截頁往往只有几百字节到几 KB，而真實頁面通常明顯更大。把同一路径下“响應大小”這一列排一下序，異常小的那一批就是可疑對象。
响應時間與並發
如果错誤集中在蜘蛛集中抓取的几分钟内，随後自動恢复，更像是限速或连接數打满，而不是永久性屏蔽。
IP 段與訪問路径
爬虫的請求 IP 相對集中。把異常狀態碼對應的 IP 單獨拉出来，看它們是否同时還在請求大量不存在的路径。若同时存在這種情况，先排除是不是被誤伤的正常爬虫，還是有人在用類似 UA 做掃描。
常见原因與對應處理
- UA 規則拦截：部分安全策略會因為 UA 里带爬虫标识就直接拒绝。處理方式是核對規則意图，確認無誤後再考虑放行。
- 频率限制：短時間内請求量超過阈值触發保護。可以先观察抓取日誌的分布，判断是正常抓取還是異常压力，再調整阈值。
- 動態渲染差异：站点對非浏览器請求返回空壳頁或 JS 挑战頁。此时蜘蛛看到的内容和用戶看到的不一致，需要检查渲染策略是否對爬虫生效。
- CDN 回源节点異常：同一 URL 在不同节点上结果不同。可以固定回源驗證，或對比不同节点的响應。
- 應用层错誤：缓存穿透、超时、證书鏈不完整都可能導致 5xx。這類要修應用，加白名單没有用。
放行时要注意什么
- 不要只看 UA。UA 是可以随意伪造的，僅凭它放行等于對所有人開放。
- 優先按搜尋引擎官方公布的 IP 段或反向 DNS 校驗来配置白名單，並定期更新。
- 放行對象尽量限定到具体路径和必要的方法，避免整站無差別放開。
- 修改後保留一段观察期，把改動前後的狀態碼分布做對比，確認問题确實消失。
把拦截問题修好，只是让蜘蛛能正常讀到頁面，並不等于頁面一定會被收錄。抓取顺畅和收錄结果是两件事，後者還取决于内容质量、重复度和站点整体情况。
一個容易忽略的细节
有些站点在修复後，日誌里确實不再出現 500，但蜘蛛的来訪频率反而下降了一段時間。這通常是抓取节奏在重新评估，並不代表被降權。此时不建议立刻做大幅改動，先让日誌稳定執行几天再看趋势，比反复調整規則更容易看出真實變化。