给站点做一轮安全加固之后，经常会出现一种很别扭的情况：页面没动、内容照常更新，但服务器日志里蜘蛛的来访次数明显少了。很多人第一反应是去查收录、查内容质量，其实问题很可能出在服务器层——防火墙、WAF 或者限流规则把正常蜘蛛一起挡掉了。
为什么这件事容易被忽略
robots.txt 是明面上的规则，改了什么、拦了谁，打开文件就能看见，也容易回滚。而服务器层的拦截往往分散在几个地方：CDN 后台、Nginx 配置、面板自带的安全插件、云厂商的防护策略。它们通常由运维或一键开启，生效之后不报错，也不影响你自己用浏览器访问，表现只是抓取量悄悄下滑，所以很难第一时间联想到。
更麻烦的是，这类误伤通常是「一段时间内全部 403」或者「高峰期才被限流」，比全站宕机隐蔽得多。
常见的误伤场景
- 按 User-Agent 关键词粗暴拦截。规则里写了 bot、spider、crawl 之类的关键词，本意是挡扫描器，结果搜索引擎蜘蛛的 UA 里正好带这些词，一并被拦。
- 频率限制过严。蜘蛛抓取往往是并发请求，如果限流阈值按「单个访客一分钟几次」来设，很容易触发临时封禁，返回 429 或 503。
- 整段封禁 IP。为了挡某个来源的骚扰，直接把一整个 IP 段拉黑，而蜘蛛的部分出口 IP 恰好落在这个段里。
- 人机校验铺得太广。全站或大范围启用验证码、JS 挑战，普通用户能过，蜘蛛过不去。
- 规则只改了一半。在 CDN 层放行了蜘蛛，源站的 Nginx 或安全插件还留着旧规则，请求到了源站照样被拒。
怎么确认是不是被拦了
不要凭感觉下结论，按下面这个顺序走一遍，基本能定位到是哪一层的问题。
- 先从服务器访问日志里看蜘蛛的返回码分布，重点看有没有成片的 403、429、503，以及是不是集中在某几个时间段。
- 把日志里出现的蜘蛛 IP 做一次反向解析，确认它到底属不属于官方公布的 IP 段，别把伪造 UA 的扫描器当成蜘蛛。
- 在服务器上直接发请求做对比：同一台机器、同一个 URL，分别带普通 UA 和蜘蛛 UA 各请求一次，看返回是否一致。
- 检查 CDN、WAF、主机面板的拦截日志或安全事件列表，很多产品会把触发规则和命中次数列出来。
- 挑一到两个具体 URL 复现，而不是只看总量趋势。总量受很多因素影响，具体 URL 的表现更直接。
处理时守住几条原则
- 白名单优先于黑名单。能用放行官方蜘蛛 IP 段解决，就不要靠改 UA 规则去绕。
- 区分限流和封禁。限流是降低频率，封禁是直接拒绝，两者的影响完全不同。对蜘蛛更适合用较宽松的限流而不是封禁。
- 改完留观察期。调整之后至少要观察一段时间的日志和抓取数据，确认返回码恢复正常，别改完就当结束了。
- 别用封 IP 解决内容问题。如果某个 IP 频繁来抓，先想想是不是自己站内出现了大量可遍历的 URL，而不是先加黑名单。
把规则记成一份可复用的清单
拦截规则散落在多个系统里，最容易出问题的就是「谁在什么时候改了什么」。建议维护一份简单记录，包含：规则内容、生效位置（CDN / 源站 / 面板）、开启时间、放行对象、验证方式。下次抓取量再出现波动时，先翻这份记录，比重新排查一遍快得多。
安全加固的目标是挡住恶意流量，不是把站点变成一个只有真人能进的封闭空间。拦截策略上线前，多想一步「这会不会连带影响到蜘蛛和普通访客」，能省掉后面很多来回排查的时间。
小结
爬虫拦截自查不需要多高深的技术，关键在于把它当成一个固定动作：定期看一眼日志里的返回码分布，确认白名单还在、规则没被覆盖。抓取量下滑时，先排除服务器层的拦截，再去谈内容和结构，往往能少走很多弯路。