入口頁铺好、程序也跑得正常，蜘蛛却迟迟不来，很多人第一反應是“是不是池子不够大”。但在實际操作里，更常见的原因是請求在到達源站之前就被拦住了：CDN 的分线路节点、WAF 的規則、CC 防護的频率限制，甚至源站上的一道防火墙，都可能在蜘蛛面前直接把门關上。這一层不排查清楚，後面怎么調入口頁都是白費力气。
為什么加了防護反而更容易誤伤
安全防護的預設逻辑是“先怀疑”。而搜尋蜘蛛的 UA 是可以随意伪造的，所以不少防護策略干脆不看 UA，只看請求特征：單 IP 高频訪問、没有 Cookie、不加载静態资源、只抓 HTML。這些特征恰恰就是蜘蛛的典型行為，于是真人訪問没事，蜘蛛一進来就被判定成爬虫攻击。
另一個容易忽略的点是承载位置。防護通常挂在主域名上，而入口頁往往挂在子域或者另一批域名上。策略没有跟着迁移過去，就會出現“主站一切正常，入口頁一個抓取都没有”的情况。
常见的几個拦截点
- DNS 與 CDN 层：分线路解析把蜘蛛指到了異常节点、回源失敗，或者境外节点直接返回 403。表現是請求根本没出現在源站日誌里。
- WAF 與 CC 防護：频率阈值设得太低，或者開啟了 JS 挑战、驗證碼、五秒盾。蜘蛛不执行 JS，也不會填驗證碼。
- 源站防火墙：fail2ban、nginx 的 limit_req、云厂商安全组，把蜘蛛的 IP 段誤封了。
- 應用层：入口頁需要 Session 或特定 Cookie 才返回 200，模板报错返回 5xx。蜘蛛抓到一次错誤，就可能明顯降低来訪频率。
先確認是不是被拦了
不要靠猜，几個對比測試就能定位方向：
- 用同一個 URL 分別發两次請求，一次带常见蜘蛛 UA，一次不带，比較返回碼和响應体長度。差別很大，基本可以确定是按 UA 拦截。
- 在源站日誌里搜這個 URL。如果日誌里完全没有记錄，問题就出在到達源站之前，也就是 DNS、CDN 或 WAF 這一段。
- 用搜尋平台的抓取诊断或模拟抓取工具發起一次請求，看返回碼和耗时，比自己 curl 更接近真實抓取情况。
- 看返回碼分布。如果大量出現 403、429、503，說明是拒绝或限流；如果连响應都没有，更可能是解析或回源問题。
放行思路：精准，而不是全關
把防護全部關掉是最省事的做法，也是最危險的做法。更稳妥的是分层處理：
- 按官方 IP 段放行：主流搜尋引擎會公布蜘蛛的 IP 段，用它做白名單判断，再配合 DNS 反查確認，比只看 UA 可靠得多。
- 入口頁路径單獨放宽：在 WAF 里给入口頁路径设更宽松的频率阈值，後台等敏感路径繼續保持嚴格。
- 關掉 JS 挑战和驗證碼：對入口頁這類展示型頁面没有實际意义，只會把蜘蛛挡在外面。
- 入口頁獨立承载：用單獨的子域甚至單獨的服務器承载入口頁，就能和主站的防護策略隔离開。
- 保留訪問日誌：哪怕只留几天，排查时也是唯一能還原現场的證據。
判断一套防護策略是否合理，标准不是“能不能挡住攻击”，而是“挡住攻击的同时，正常抓取和正常用戶都不受影响”。
几個常见的誤区
只看 UA 放行。UA 可以伪造，日誌里出現一堆“百度蜘蛛”並不代表真的被百度抓了，抓取量會嚴重注水，據此做判断容易跑偏。換了 CDN 就以為解决了。新节点同样可能带預設防護，問题只是換了個地方出現。放行之後就不管了。IP 段會更新，規則也需要定期核對，尤其是常年没動過的白名單。
總的来说，CDN 與安全防護是一道必须存在、但需要精细配置的關口。把入口頁的抓取鏈路單獨理出来，做好 IP 段白名單和路径級放宽，往往比反复調整入口頁内容更能解决“蜘蛛不来”的問题。