入口頁能在浏览器里正常打開，不代表搜尋蜘蛛就能抓到。很多蜘蛛池搭好之後，日誌里人訪問一切正常，蜘蛛却屈指可數，排查半天内容、連結、结构，最後發現問题出在訪問控制這一层——CDN、WAF、云安全组或者服務器的限速規則，把蜘蛛挡在了门外。
訪問控制管的是「谁能進来」，不是「進来看到什么」
内容模板、URL 结构、内鏈布局這些，属于「進来之後看什么」的問题；而 CDN、WAF、防火墙、反向代理限速、JS 人机驗證這些，决定的是請求能不能到達你的服務器。後者一旦拦错，前面的優化都無從谈起，因為蜘蛛根本没拿到頁面。
常见的几種拦截来源
- CDN 的人机驗證：部分 CDN 預設對「可疑流量」返回 JS 挑战頁，蜘蛛拿到的是一個需要执行脚本的頁面，而它通常不會执行。
- WAF 規則：拦截空 UA、非浏览器 UA、特定關鍵詞、異常參數，蜘蛛請求很容易命中。
- 频率限制：limit_req、limit_conn 或者云厂商的速率防護，按 IP、按连接數限流，蜘蛛短時間内连續請求多個入口頁就會触發 429 或 503。
- IP 段封禁：把整段机房 IP 拉黑，顺手把蜘蛛也一起封了。
- 地域封禁：只放行某些地区，海外蜘蛛直接 403。
- 證书與协议問题：HTTPS 配置错誤、强制跳轉成环，同样會让抓取失敗。
怎么判断是不是被拦了
- 日誌里几乎没有蜘蛛记錄，但其他渠道顯示确實有抓取動作。
- 响應碼大量是 403、429、503，而不是 200。
- 返回的 HTML 是驗證頁或跳轉頁，正文長度明顯偏短。
- 用 curl 分別带浏览器 UA 和蜘蛛 UA 請求同一個 URL，對比狀態碼與响應内容。
- 換一個不走 CDN 的直连方式測試，看结果是否不同。
注意不要只看一次结果。有些防護是概率触發的，多测几次、換不同时段测，结论才靠得住。
放行的基本思路
- 先驗證再放行：不要只看 UA 就放行。更稳妥的做法是對来源 IP 做正反查，確認归属後再加入白名單。
- 给已知蜘蛛 IP 段單獨開白名單，與普通訪客規則分開，避免互相干扰。
- 關掉入口頁的 JS 挑战，或者把入口頁路径排除在挑战規則之外。
- 放宽限速阈值：蜘蛛並發抓取往往比單個用戶猛，按普通訪客的阈值限流很容易誤伤。
- 尽量保證返回 200：即使要挡，也尽量別用 403，返回可讀内容比返回错誤頁更可控。
几個容易被忽略的点
- CDN 缓存了错誤頁：回源失敗时返回的 503 或驗證頁被缓存下来，之後蜘蛛拿到的可能一直是這張错誤頁，改完規則记得清缓存。
- UA 差异：移動端與桌面端蜘蛛的 UA 不同，規則只测了一種，另一種可能被拦。
- 改完需要观察期：白名單生效後不會立刻反映在日誌里，建议至少观察几天再下结论。
- 別只盯首頁：入口頁路径如果被單獨規則覆盖，首頁正常不代表入口頁正常。
蜘蛛池里最没必要的一種浪費，是内容做得不错，却因為一條限流規則让蜘蛛空手而归。抓取通畅是前提，内容與連結是加分項，顺序別反了。
建议的排查顺序
從外到内一层层剥：先看 CDN 或 WAF 的拦截日誌，再看服務器訪問日誌，最後看應用层有没有異常跳轉。確認蜘蛛能稳定拿到 200、並且返回的是有實质内容的 HTML，再去谈入口頁的數量、互鏈和更新节奏。把這一步做在前面，後面很多「蜘蛛不来」的困惑會少掉一大半。