蜘蛛来访量突然下降，服务器监控却一切正常——这类情况里，相当一部分原因不在站点本身，而是请求在到达服务器之前就被 CDN 或 WAF 拦掉了。站长在日志里看到的可能是 403、429，也可能什么都看不到，因为请求在边缘节点就已经结束。
先分清拦截发生在哪一层
一个请求从蜘蛛发出到你的源站，大致会经过 DNS、CDN 边缘节点、WAF 规则、限流模块，最后才到 Web 服务器。任何一层返回 403 或 429，源站日志里通常都不会留下记录。所以第一步不是改代码，而是确认日志的覆盖范围：源站日志、CDN 日志、WAF 拦截日志要能对应得上。
三类最常见的误拦
1. WAF 规则命中
带参数的 URL 最容易触发规则，比如查询串里出现 select、union 之类的关键词，或连续的特殊符号。蜘蛛抓取这些 URL 时，请求会被当成攻击直接拦下。
2. 频率限制过严
有些限流按 IP 计数，阈值设得很低。蜘蛛一般从多个 IP 分散抓取，但在同一时间对同一目录的请求仍可能集中出现，从而触发 429。
3. 节点或地域策略
部分 CDN 默认屏蔽机房 IP 段，或者对某些地域做了拦截。蜘蛛的出口 IP 属于数据中心，很容易被一并处理掉。
排查顺序
- 在日志里按状态码分组，看 403、429 的占比和出现时间，确认是持续存在还是短时突发。
- 反查这些 IP 的归属，和搜索引擎官方公布的 IP 段比对，不要只依赖 UA，UA 是很容易被伪造的。
- 打开 WAF 与限流模块的拦截记录，看被拦的 URL 有什么共同点，是路径、参数还是访问频率。
- 临时把确认过的 IP 段加入白名单，观察抓取是否恢复，再决定长期规则怎么写。
- 把结论固化下来：白名单定期更新，限流对蜘蛛单独设一个阈值。
容易被忽略的两个连带问题
- robots.txt 或 Sitemap 被拦：这两个文件如果返回 403，蜘蛛读不到规则或 URL 清单，后续的判断都会走偏。
- CSS、JS 等静态资源被拦：资源加载失败会影响页面解析和链接提取，表现出来却像是内容层面的问题。
排查抓取异常时，先确认请求有没有真正到达源站，再谈页面和内容层面的优化。
白名单怎么维护更稳妥
搜索引擎会公布各产品的 IP 段，建议按官方来源定期同步，而不是手工维护零散 IP。放行方式最好是按 IP 段和按路径组合：对 robots.txt、Sitemap、详情页放行，对后台、登录、站内搜索接口继续严格拦截。
限流方面，可以给已验证的蜘蛛 IP 单独设一个较宽松的阈值，同时保留峰值保护，避免抓取把带宽占满、影响真实用户。
恢复之后的观察
解封不代表抓取立刻回到原来的量级，蜘蛛的抓取节奏会受历史响应质量影响，恢复往往需要一段时间。这段时间里可以持续观察日志中蜘蛛的访问频次、状态码分布，以及新 URL 被发现的速度，再判断是否真的回到正常轨道。