抓取量突然掉下来，而服务器 CPU、带宽、内存都很正常，日志里也看不到异常请求——这时候有一类原因容易被忽略：请求确实发出去了，但没能到达你的应用。CDN 的 WAF、机房防火墙、云厂商的流量清洗、应用层的限速模块，任何一层把蜘蛛的请求判成可疑流量，站点侧看到的现象就是蜘蛛不来了。
拦截可能发生在哪几层
从搜索引擎到源站，请求通常要穿过好几道关卡，按顺序大致是：
- DNS 与 CDN 调度层：某些解析线路异常，蜘蛛走了不通的节点。
- CDN 或云 WAF：最常见的一层，规则包括 CC 防护、频率限制、UA 黑名单、地域封禁、人机验证。
- 机房或云主机的网络防火墙：对来源 IP 段做限制，或对异常并发直接丢弃。
- Web 服务器与中间件：Nginx 的 limit_req、limit_conn，Apache 的并发上限。
- 应用层：框架自带限流、防爬中间件、验证码挑战页。
每一层被拦，表现都不一样。先确定层，再谈放行，顺序反了容易白折腾。
用日志差异缩小范围
关键思路是拿三份数据对时间轴：源站访问日志、CDN 或 WAF 的请求拦截记录、搜索引擎后台的抓取统计与错误报告。
如果搜索后台显示有抓取尝试、CDN 日志里有对应请求、源站日志里却没有，拦截点就在 CDN 到源站之间；反过来，源站日志里有大量 403 或 503，问题就在服务器或应用层。如果三份数据完全对不上，先怀疑解析和线路。
还有一个笨但有效的办法：取一个确认来自官方的蜘蛛 IP，在 WAF 或防火墙后台做一次模拟测试，看它命中了哪条规则。
常见的误伤类型
- CC 防护把同一 IP 段的密集请求当成攻击。蜘蛛本身就会并发抓取，阈值设低了必然中招。
- UA 黑名单写得过宽，把包含某些关键词的 UA 一并拦掉。
- 只放行了 GET，蜘蛛的 HEAD 请求、条件请求被拒，影响更新判断。
- 并发连接数限制过低，蜘蛛的多线程请求被部分丢弃。
- 人机验证或 JS 挑战页返回 200，蜘蛛拿到的是挑战页而不是正文。
- 地域封禁误伤了蜘蛛所在节点的区域。
核对与放行的顺序
- 先在搜索后台确认抓取是在下降，还是只是你自己日志里的记录变少了。
- 拉取最近一周的 WAF 拦截记录，按状态码和规则名分组统计。
- 确认被拦请求的来源 IP 是否落在搜索引擎官方公布的 IP 段内。
- 对确认过的官方 IP 段做定向放行，而不是全站关闭防护。
- 放宽与蜘蛛相关的限速阈值，单独给一个并发与速率上限。
- 放行后观察 24 到 72 小时日志，确认请求能落到应用层。
放行不等于关闭防护。正确做法是给确认过的来源单独开一条通道，而不是把 UA 关键词加进白名单——UA 可以伪造，只按 UA 放行等于自己开了个口子。
放行时容易踩的坑
- 只放行主站，忘了图片、CSS、JS 所在的静态资源域名。
- 只处理 IPv4 段，漏掉 IPv6。
- 规则改完没确认生效时间，CDN 配置通常有几到几十分钟的下发延迟。
- 放行了抓取，却没同步检查 robots.txt 和验证码策略，蜘蛛依然拿不到内容。
放行之后要看的指标
请求恢复不代表事情结束。接下来几天重点看三件事：官方 IP 段的请求量是否回升、状态码中 5xx 与 403 的比例是否下降、以及这些请求抓到的 URL 是不是你希望被发现的那些。如果请求回来了但抓的多是参数页或旧地址，那就得回到内链结构和 Sitemap 上继续核对。
防护规则是双刃剑，挡住攻击的同时也容易挡掉合法抓取。把拦截层定位当成一个固定排查动作写进日常巡检，比等到抓取量掉了才去翻日志要省事得多。