入口页铺好、程序也跑得正常，蜘蛛却迟迟不来，很多人第一反应是“是不是池子不够大”。但在实际操作里，更常见的原因是请求在到达源站之前就被拦住了：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 段白名单和路径级放宽，往往比反复调整入口页内容更能解决“蜘蛛不来”的问题。