蜘蛛抓取失敗时，很多人第一反應是查源站：是不是服務挂了、是不是返回了 5xx。但在實际排查中，相当一部分抓取異常並不是源站的問题，而是請求還没到源站，就在 CDN、WAF 或者主机层面的防護規則里被拦下了。對于依赖 URL 被持續發現的站点来说，這類問题更隐蔽：源站日誌干干净净，看起来像是“没被訪問過”，其實請求早就被中間层挡回去了。
一、被中間层拦截时，日誌會呈現什么样子
拦截不一定留下明顯的错誤，常见的表現有：
- 源站日誌里完全看不到對應 URL 的請求，但頁面在搜尋结果里的缓存長期不更新。
- 訪問日誌大量出現 403、406、429，且 UA 與蜘蛛一致。
- 返回 200，但内容是一個校驗頁或跳轉頁，蜘蛛拿不到正文。
- 不同地区、不同 CDN 节点行為不一致：有的节点放行，有的节点拦截。
- 同一時間批量 URL 全挂，随後又自行恢复，像是触發了某種速率規則。
二、常见的誤伤来源
1. CDN 的 Bot 管理與速率限制
不少 CDN 預設開啟“已知机器人”识別，但規則库更新有滞後，或者把非主流蜘蛛一並归入可疑爬虫。另外，如果站点設定了單 IP 請求频率阈值，而蜘蛛在短時間内集中抓取，很容易被判定為攻击流量。
2. WAF 的規則集與自定义拦截
WAF 對 URL 中的特殊字符、參數與编碼非常敏感。带大量查询參數的列表頁、含中文或百分号编碼的路径，偶尔會被規則誤判。自定义拦截里如果寫了過宽的關鍵詞匹配，也會誤伤正常頁面地址。
3. 源站防火墙與自動封禁脚本
fail2ban 一類的工具會根據短時間内的高频請求自動封 IP。蜘蛛抓取本身就具备高频特征，如果阈值設定得過低，封禁几乎是必然的。
三、建议的排查顺序
- 從日誌里挑一條抓取失敗的 URL，记錄完整時間点、UA 和返回碼。
- 確認請求是否到達源站。用 curl 带上相同 UA，分別直连源站與走 CDN 域名測試。
- 對比两组响應：狀態碼、响應头、返回内容是否一致。
- 查看 CDN 與 WAF 的拦截日誌，確認是否有匹配记錄以及命中的規則编号。
- 检查主机防火墙與自動封禁列表，確認相關 IP 段是否在名單里。
- 定位到具体規則後做最小范围放行，而不是整段關閉防護。
四、放行时要注意的几点
- 不要只按 UA 放行。UA 可以随意伪造，僅凭 UA 放行等于给防護開了一個口子。
- 配合反向解析或公開 IP 段校驗。先確認来源确實是蜘蛛，再决定放行規則。
- 優先放行必要路径。如果只是列表頁被拦，就针對列表頁的路径特征放行，而不是放開整站。
- 保留日誌。放行之後仍要能追溯，方便下次出問题时快速定位。
五、放行之後還要观察什么
解除拦截不等于問题結束。接下来几天值得關注：源站日誌里對應 URL 的請求量是否回升、返回碼是否以 200 為主、抓取是否覆盖到更深层的頁面，以及同一时段服務器负载的變化。如果請求量明顯上升，要提前確認带宽和資料库连接數是否扛得住，避免刚放開拦截，又因為响應超时产生新的抓取失敗。
提示：拦截規則與抓取策略都會随時間變化，今天合适的放行設定，過一段時間可能需要复核。把這類检查纳入固定的运维节奏，比临时救火更省事。