抓取量突然下降，或者某個目錄的 URL 長時間只有“發現”没有“抓取”，很多站長第一反應是 Sitemap 或内鏈出了問题。但在實际排查中，還有一類原因是入口本身正常，只是請求在到達源站前後被挡下了：安全策略、频次限制、驗證碼頁面。這几種情况在抓取日誌里往往會留下比較固定的痕迹，值得單獨核對一次。
一、先区分“没来抓”和“来了被挡”
這两種情况的表現很像，處理方向却完全相反。前者要回到 URL 發現和内鏈入口上找原因，後者則要考虑服務器與安全策略。判断方法很简單：看日誌里到底有没有對應的請求记錄。如果连請求行都没有，說明蜘蛛没走到這一步；如果請求存在但狀態碼或响應体異常，問题就在返回环节。
二、三類常见的拦截信号
1. 狀態碼異常且集中在同一時間段
403、429、503 是比較典型的三類。單獨看某一個 403 說明不了什么，但如果同一個 UA 或同一網段在十几分钟内连續出現大量 403，而此前是正常的 200，大概率是触發了频次或規則限制。429 通常带有 Retry-After 头，可以看出對方建议的等待時間；如果這個头由邊缘节点生成而源站日誌里没有，就需要到 CDN 侧的日誌里確認。
2. 内容层被替換
狀態碼仍然是 200，但返回的正文是驗證碼頁、跳轉脚本或一段极短的提示文字。這類情况比 403 更隐蔽，因為狀態碼統計上看不出異常。核對方式是對比同一 URL 在浏览器中的正常返回與日誌中记錄的响應体字节數，如果抓取记錄的体积明顯偏小，例如只有几百字节，基本可以判断内容被替換了。
3. 抓取行為本身的變化
被拦截之後，蜘蛛的表現也會變：對同一目錄的抓取間隔拉長、只拿列表頁不跟進詳情頁、或者干脆放弃该路径。這類變化不會寫在狀態碼里，需要结合抓取频次的時間序列来判断。
三、日誌核對可以做哪几步
- 按小时統計 403、429、503 的數量，找出突變点，與改版、CDN 規則調整、活動上量的時間對齐。
- 把出現異常狀態碼的 URL 按目錄聚類，判断是全站現象還是集中在某個栏目。
- 對比响應体字节數，把明顯偏小的頁面單獨列出来复核。
- 检查 UA 與来源網段：同一 UA 是否在短時間内請求了大量 URL，這更接近频次問题而不是身份問题。
- 確認 robots.txt 與 CDN 規則近期是否被改動，尤其是新增的限速、防爬、地域限制。
四、修复的先後顺序
- 先在 WAF 或 CDN 层放行已驗證的搜尋蜘蛛網段與 UA，而不是直接關掉全部防護。
- 再調整限速阈值，给抓取留出獨立的並發額度，避免和真實用戶共用一個桶。
- 然後處理内容层替換頁，確認驗證碼與跳轉只作用于可疑請求，不覆盖整個目錄。
- 最後回看日誌，確認異常狀態碼回落到正常水平，並观察内頁是否重新被跟進。
拦截比例上升和抓取预算下降经常同时出現，不要只凭一個指标就下结论。
五、几個容易誤判的邊界
第一，偶發的 403 不一定是拦截，也可能是源站權限配置問题，或者不存在的文件被規則改寫成了拒绝。第二，429 有时来自共享出口，站点自己没有限速，但同一出口的其他站点触發了限制。第三，缓存回源失敗也會表現為 5xx，與拦截是两回事，需要看回源日誌。第四，如果站点使用多種来源的入口分發，日誌中的来源會混杂在一起，建议先按来源分组，再看每一组的異常比例，否則很容易把正常的频次波動当成拦截。
把拦截识別清楚之後，再回头核對 URL 發現、Sitemap 與内鏈结构，排查顺序會顺很多：先確認請求能正常到達並拿到完整内容，再讨论抓取路径與覆盖差异。