做蜘蛛池的人常遇到一種情况：入口頁的訪問日誌里，搜尋蜘蛛来訪的痕迹很清楚，連結也确實指向了目标URL，但目标URL的日誌里只有零星几條抓取记錄，狀態碼還经常是 403、429、503，甚至直接返回一個安全驗證頁面。抓取鏈路在最後一跳断掉，前面做得再顺也接不上。
先分清：是蜘蛛没来，還是来了被拦
這两種問题的處理方向完全不同，混在一起排查會浪費很多時間。
- 蜘蛛没来：目标URL的日誌里连蜘蛛的 UA 和 IP 都搜不到，說明入口頁没把連結有效传出去，或者連結本身不具备可抓取的條件。
- 来了被拦：日誌里有對應 IP 或 UA 的請求记錄，但狀態碼是 403、406、429、503，或者响應体是一段 JavaScript 跳轉、驗證碼頁面的 HTML。
還有一種容易被忽略的情况：請求根本没到你的源站，在 CDN 或 WAF 那一层就被拦下並直接返回了頁面。這时源站日誌干干净净，看上去像“蜘蛛没来”，實际是更早的一环出了問题。
常见的三類拦截来源
1. WAF 規則誤伤
不少 WAF 的預設規則會把“高频訪問同一路径”“缺少常規浏览器指纹”“来源 IP 集中在少數網段”当作攻击特征。搜尋蜘蛛的抓取行為恰好符合這些特征：短時間内密集請求、通常不带 cookie、Referer 缺失。
2. CDN 回源被限制
如果目标URL前面挂了 CDN，CDN 回源时使用的 IP 和搜尋蜘蛛的 IP 並不是一回事。有些源站防火墙只放行了搜尋引擎的 IP 段，结果 CDN 回源請求被拦，源站返回 403 给 CDN，CDN 再原样透传给搜尋蜘蛛。
3. 服務器层的防護和速率限制
Nginx 的 limit_req、云主机的安全组、面板類防護插件，都可能對單 IP 的並發连接數或單位時間請求數设上限。当入口頁在較短時間内把大量抓取導向同一個目标URL时，很容易触到這個阈值。
排查顺序建议
- 先在源站日誌里按時間筛出目标URL的請求，重点看狀態碼分布，而不是只看總請求次數。
- 用带搜尋引擎 UA 的請求測試目标URL的响應头，观察返回碼。注意這一步只能驗證 UA 是否被针對，不能證明搜尋蜘蛛本身一定抓得到。
- 對比不带 UA、带普通浏览器 UA 的两次請求。如果只有搜尋引擎 UA 被拒，基本可以鎖定是 UA 相關規則在起作用。
- 检查 CDN 或 WAF 的拦截日誌，看是否有回源失敗、安全策略命中的记錄。
- 用搜尋引擎官方提供的網址检查工具發起實时抓取，看返回的 HTTP 狀態和响應内容是什么。
如果连官方實时抓取都返回 403，問题一定在服務端策略上，而不是入口頁的連結數量或分布。
放行搜尋引擎时的几個注意点
- 不要只放行 UA 字符串。UA 可以随意伪造，只按 UA 放行等于给所有人開门。相對稳妥的做法是 UA 加反向 DNS 校驗，或直接使用官方公布的 IP 段。
- IP 段要定期更新。官方會增删 IP 段，白名單長期不维護，某天蜘蛛換了網段又被拦，問题會重新出現。
- 速率限制別设得太紧。把搜尋引擎 IP 單獨归到一個更宽松的限速组，通常比统一阈值更稳。
- 驗證頁和 JS 跳轉要慎用。這類中間頁會让抓取停在半路，蜘蛛拿不到目标URL的實际内容。
- 確認入口頁和目标URL是否在同一台服務器上。两者分開部署时，日誌要分別看，不要拿入口頁的正常狀態去推断目标URL也正常。
容易被忽略的细节
有些站点為了防刷，會對疑似爬虫的請求返回 200，但内容為空，或者返回一段混淆過的 HTML。這種“软拦截”在狀態碼上完全看不出来，只能對比响應体長度和實际内容才能發現。
另外要清楚一点：蜘蛛池能影响的是蜘蛛愿不愿意来、来得多不多，解决不了服務端的拦截問题。抓取鏈路能不能真正走通，最终取决于目标URL對搜尋蜘蛛是否可正常訪問。排查时先把這一层理顺，再去調整入口頁的連結形式，方向才不容易跑偏。