做蜘蛛池的人常遇到一种情况：前一阵抓取还算稳定，某天开始抓取量突然往下掉，登录服务器翻访问日志，却发现入口页的请求数并没有明显异常——既没有飙升的 5xx，也看不到大量陌生 UA。这种“抓取量掉了，日志却很干净”的现象，很多时候问题不在池子本身，而在请求到达服务器之前就被拦掉了。
请求可能在到服务器之前就结束了
从蜘蛛发出请求到你的入口页返回内容，中间通常要经过好几层：CDN 边缘节点、云厂商的 DDoS 清洗、WAF、负载均衡，最后才是 Nginx 或应用本身。任何一层判定这个请求“不像正常用户”，都可能直接返回 403、429 或一个 JS 挑战页。这些响应不会写进你的站点访问日志，所以从日志上看就是“蜘蛛没来过”。
常见的拦截位置
- CDN 的 Bot 管理：不少 CDN 默认开启爬虫识别，会把来自机房 IP 段的请求降权或直接挑战。
- WAF 规则：入口页如果 URL 里带大量参数、目录结构异常整齐，容易被规则集判定为扫描行为。
- 应用层限速：Nginx 的 limit_req、limit_conn 或框架自带的频率限制，阈值设得偏紧时会误伤蜘蛛的连续抓取。
- 机房防火墙：部分机房对同一 IP 的高频请求做清洗，表现是间歇性超时而非明确拒绝。
怎么判断是不是被拦了
直接在服务器上模拟一次请求，往往比看日志更快定位：
- 用与蜘蛛相近的 UA 请求入口页，观察返回码和响应体。如果拿到的是验证页、挑战跳转或者 403，基本可以确认。
- 换几个不同 UA、不同来源 IP 再请求一次。如果只有某一类请求被拒，说明是规则匹配，而不是全站故障。
- 去 CDN / WAF 控制台看安全日志和拦截统计，这里通常能看到被拦下的请求明细，包括命中哪条规则。
- 确认拦截来源后再动手调整，避免把正常防护也一起关掉。
处理时的几个原则
- 优先加白名单，而不是关防护。把已知的蜘蛛 IP 段或验证方式加入放行列表，比全局关闭 Bot 管理安全得多。
- 限速阈值留出余量。蜘蛛抓取本身带有突发性，阈值按平时均值设置很容易被打满。
- 保留降级路径。即使某个防护层拦了，也让入口页本身在主站上仍可访问，便于对比排查。
- 监控要覆盖“没到服务器”的请求。只看站点日志会漏掉这一整段，建议同时参考 CDN 侧的请求量与状态码分布。
两个容易踩的坑
第一个坑是把“日志空白”直接等同于“蜘蛛不来了”，于是去改内容、换链接、调结构，折腾一圈其实和抓取无关。第二个坑是发现被拦后立刻把 CDN 的 Bot 管理、WAF 规则全部关掉，短期抓取恢复了，但站点同时暴露在扫描和恶意请求里，后续更麻烦。
拦截排查的顺序建议从外到内：先看 CDN / WAF 的拦截日志，再看负载均衡和 Nginx，最后才是应用本身。大部分“抓取量下滑但日志正常”的问题，在第一层就能找到答案。
需要说明的是，解决拦截只是让请求能正常到达，抓取量是否回升，还要看入口页本身的结构与内容。防护配置改完以后，最好观察一段时间的抓取分布和回访情况，再判断是否达到预期。