入口頁自己用浏览器打開一切正常，但抓取量突然掉到几乎為零，連結也没再被繼續發現。這種“人看得见、蜘蛛看不见”的情况，很多时候不是蜘蛛池本身的問题，而是請求在到達源站之前就被拦掉了。
為什么拦截問题容易被誤判
WAF、CDN 的 Bot 管理、云厂商的爬虫挑战，通常工作在源站之前。搜尋蜘蛛拿到的可能是 403、429，或者一個需要执行 JavaScript 的驗證頁，而不是入口頁的真實 HTML。源站日誌里什么都看不到，于是很容易得出“蜘蛛根本没来”的结论，轉头去改蜘蛛池结构，方向從一開始就错了。
常见異常表現
- 抓取日誌中搜尋引擎 UA 的請求大量返回 403、406、429，並且集中在一段時間内。
- 源站訪問日誌里搜尋蜘蛛的 IP 几乎消失，但 CDN 或 WAF 日誌里有對應记錄。
- 入口頁還能被抓，入口頁下面的目标 URL 請求直接被拒，抓取深度明顯變浅。
- 返回的响應体是驗證頁、拦截提示頁，而不是入口頁的正常内容。
- 抓取频率從稳定變成断崖式下降，同时並没有改過 robots 或服務端配置。
排查顺序
- 先對比两层日誌。把源站日誌和 CDN / WAF 日誌按時間對齐，看同一時間点搜尋引擎 IP 的請求去了哪里、被哪條規則命中。
- 驗證 IP 是否真的是搜尋蜘蛛。以 Googlebot 為例，可先反向 DNS 解析到 googlebot.com 或 googleusercontent.com，再正向解析確認一致。只凭 UA 判断並不可靠，UA 可以随便伪造。
- 检查安全規則的触發條件。常见的有爬虫挑战、單 IP 频率限制、地域封禁、UA 黑名單、缺少特定請求头即拦截等。
- 確認 robots 與防火墙不冲突。robots 允许抓取，不代表 WAF 會放行，两者是相互獨立的两层。
- 小范围放行後持續观察。放行後不要立刻下结论，抓取恢复通常有延迟，观察几天再判断效果。
放行时的几個取舍
放行不等于全開。比較稳妥的做法是：按搜尋引擎公布的 IP 段做白名單，同时保留基本的频率上限，避免真實蜘蛛和伪装爬虫一起被放進来；對入口頁這類需要被抓的路径單獨放宽，管理後台和接口路径繼續嚴格限制。
用 UA 字符串做放行條件要格外谨慎。搜尋引擎的 UA 是公開的，任何脚本都能照抄，真正可靠的還是 IP 驗證。如果 CDN 提供了官方的搜尋引擎驗證功能，優先使用它。
常见誤区
- 看到 403 就認為蜘蛛没来過，忽略了被拦截也算一次訪問。
- 為了省事直接關掉整個 WAF，短期抓取可能恢复，但其他風險會一起暴露。
- 只放行了首頁，忘了入口頁下面的目标 URL 路径。
- 放行後马上把入口頁數量翻倍，结果触發新的频率限制。
抓取異常先分层定位：域名解析、CDN、WAF、源站、應用，一层层往下看，比直接改蜘蛛池更省時間。
拦截類問题的排查逻辑其實不复杂：先確認請求到底有没有到源站。分清了這一点，再决定是調整安全策略還是優化入口頁结构，就不至于白折腾。