很多人在搭好入口页之后，第一件事就是去看蜘蛛有没有来。结果访问日志里只有零星几条，或者干脆一条都没有，但用浏览器打开又是正常的。这种情况里，相当一部分原因不在入口页本身，而在它前面挡着的那一层：CDN、WAF 或者云厂商自带的安全防护。
为什么会被拦
这类防护产品的默认策略是「像人的才算正常访问」。蜘蛛的请求恰好有几个特征容易被判成异常：UA 固定、访问频率高、路径集中、没有 Referer、不执行 JS、不加载图片和 CSS。对防护系统来说，这和采集脚本的行为高度相似，于是被顺手拦掉。
常见的拦截表现
- 返回 403、405 或 503，源站日志里根本查不到这条请求；
- 返回一个 JS 挑战页或验证码页，蜘蛛拿不到实际内容；
- 只放行了部分蜘蛛 IP，另一些直接超时；
- 回源正常，但 CDN 缓存里存的是错误页，后续请求全部命中缓存；
- 首字节时间拉得很长，蜘蛛等不到响应就断开。
排查顺序
- 先绕过 CDN，用源站 IP 直接请求一次入口页，确认源站本身返回正常。
- 分别看 CDN 日志和源站日志。CDN 有记录、源站没有，问题基本就在防护策略上。
- 用蜘蛛 UA 发一次请求，看返回的是内容页、403 还是挑战页。只看 UA 不够，要结合请求来源 IP 一起看。
- 检查速率限制规则。单 IP 每秒几次、单 URL 每分钟几次这类阈值，对正常用户宽松，对蜘蛛往往偏紧。
- 检查是否开了「人机校验」「JS 挑战」「Cookie 验证」这类默认开关。
- 确认回源 IP 段是否被源站防火墙放行，有些配置会把 CDN 回源当成异常来源。
配置上的几个做法
白名单不要只写 UA
UA 可以伪造，所以多数防护产品不会只看 UA，反过来只靠 UA 放行也容易被绕过。更稳的做法是把已知的蜘蛛 IP 段和反向解析一起用上，同时保留基本的频率限制，避免整套策略形同虚设。
频率阈值留出余量
蜘蛛抓取往往是突发式的，可能几分钟内连来几十次，然后安静很久。阈值设成「每秒一次」这种硬限制，很容易在突发时被拦。可以改成按分钟或按小时统计，给一个相对宽松的上限。
留一条备用通道
如果主域名前面挂了严格的防护，可以把入口页放到另一个未接防护的子域或源站上，做交叉验证。主域抓取异常时，至少能判断是防护问题还是入口页本身的问题。
需要提醒的是，为了放行蜘蛛而把整套防护规则关掉，并不是个好选择。防护的目的是过滤异常流量，规则全关之后，入口页本身也更容易被其他脚本盯上。
两个容易忽略的点
- 缓存污染：错误页一旦被 CDN 缓存，蜘蛛后续再来命中的还是缓存。清理缓存并调整缓存规则，通常比反复改入口页更有效。
- 换 IP 后没同步：蜘蛛池换了出口或回源 IP，防护白名单没跟着更新，表现就是「昨天还好好的，今天全没了」。
入口页抓不到，按「源站 → CDN 日志 → 防护策略 → 蜘蛛侧」的顺序倒着查一遍，通常比直接去改入口页模板更快定位。日志和实际返回是唯一可靠的依据，别凭感觉判断。