站点更新之後迟迟看不到抓取動静，很多人會先去改内鏈、調 Sitemap，但排查到後面才發現，請求根本没到達源站——它們被 CDN、WAF 或者服務器上的安全模块挡在了外面。抓取路径的第一环不是 URL 發現，而是請求能不能進来。這一环被切断，後面所有的調整都没有意义。
抓取被拦时，會看到哪些信号
拦截往往不是“全断”，而是部分、間歇地發生，所以很容易被誤判成抓取频率低。可以先看几個特征：
- 源站日誌里完全没有蜘蛛 UA 的請求记錄，但抓取統計工具顯示有訪問；
- 日誌里出現集中的 403、406、429，且時間段比較規律；
- 用同一台服務器直接請求頁面正常，換成抓取来源的 IP 段就被拒；
- 抓取量在某個時間点明顯下滑，站内结构和内容却没有變化；
- CDN 或防火墙後台的“已拦截請求”數量突然上升。
出現两條以上，就值得把排查方向從頁面层移到網絡层。
拦截通常發生在哪一层
CDN 與邊缘节点
邊缘节点上的机器人防護、频次限制、地区策略，都可能把抓取請求提前拦掉。源站日誌很干净，是因為請求在邊缘就結束了，压根没有回源。這類情况最容易被誤認為“内容没被收錄”。
WAF 規則
WAF 的預設規則集偏向拦截可疑流量。抓取請求如果短時間内集中訪問大量 URL、带上較長的參數，或者触發了注入、路径穿越之類的誤报特征，就可能被判定為攻击。抓取速率越高，越容易踩到频次阈值。
源站防火墙與安全插件
iptables、云主机安全组，以及部分 CMS 自带的防護插件，也會按 IP 或請求特征做拦截。它們的特点是日誌分散，需要分別查看，容易在排查时被漏掉。
限速與並發限制
Nginx 的 limit_req、limit_conn，或者應用层的连接上限，會让並發的抓取請求被直接丢弃。表現出来是响應時間忽長忽短，或者一部分請求干脆超时。
按什么顺序排查
- 先確認請求有没有到達源站。對比源站日誌與 CDN 日誌，看抓取請求是在邊缘消失，還是回源之後才被拒。
- 如果請求没有回源，检查邊缘节点的机器人規則、频次限制和地区策略。
- 如果回源後被拒，看狀態碼分布。403 多為規則拦截，429 多與限速有關，406 常與請求头校驗相關。
- 用測試工具模拟抓取請求，逐個關閉防護模块，把問题定位到具体規則，而不是停在“可能是 WAF”。
- 確認是規則問题後，按最小范围放行，而不是整体關掉防護。
放行时的几個原則
- 不要只按 UA 放行。UA 可以伪造，只認 UA 既不能保證真實蜘蛛一定通過，也等于给攻击者留了一扇门。
- 優先用 IP 段或反向 DNS 驗證。把官方公布的抓取 IP 段加入白名單，或做反向解析校驗，可靠性更高。
- 频次阈值要留余量。限速卡得太紧，正常抓取也會被丢包，可以對已驗證的来源單獨放宽。
- 区分不同路径的防護强度。登入、搜尋、表單提交等路径保持嚴格，正文頁和列表頁可以适度放宽。
放行的目标是让正常抓取稳定通過，而不是让防護失效。每次調整後记錄改動時間與規則编号，出問题时能快速回退。
放行之後要观察什么
規則改完不等于問题解决，還要看恢复情况：源站日誌里抓取請求是否重新出現、狀態碼是否轉為 200、抓取频率是否逐步回升。如果請求回来了但抓取量仍然偏低，那才需要回到 Sitemap、内鏈结构、抓取预算這些层面繼續查。
把網絡层和頁面层的排查分開，能少走很多弯路。抓取請求先要進得来，URL 發現和抓取路径才有讨论的空間。