给服务器加防护和限速，本来是为了挡住恶意抓取和突发流量；但如果阈值、规则、验证方式配得含糊，最先被挡住的往往是搜索蜘蛛和正常用户。这类问题不会在页面上直接暴露，只会体现在抓取量下滑、收录变慢、日志里一串 403 和 429。定期做一次爬虫放行自查，比事后猜原因要省事得多。

先分清三类拦截

排查时先把拦截按来源分开，不然容易在一个方向上反复调参：

• 网络层：CDN、云防护、防火墙按 IP 或 IP 段封禁，常见于机房段被整段拉黑。
• 应用层：Nginx、WAF 的速率限制，按每秒请求数或并发连接数触发，返回 429 或 503。
• 页面层：JS 挑战、验证码、人机校验，蜘蛛拿不到完整 HTML，抓到的是空壳页。

常见误伤场景

• 限速按“单 IP”设置，而搜索蜘蛛常从少量 IP 高频访问，直接被判定为异常。
• UA 黑名单里写了包含“bot”的关键词，把正规蜘蛛一起匹配进去。
• 为了挡采集，把整段 IDC 机房 IP 封掉，结果搜索蜘蛛的出口也在其中。
• 全站开启 JS 挑战，蜘蛛拿到的是等待跳转的中间页。
• 被拦时默认返回 403，而不是 429，让蜘蛛误判为永久拒绝。

自查怎么做

1. 看日志里的状态码分布

把最近 7 天的访问日志按 UA 和状态码分组，重点看蜘蛛 UA 对应的 403、429、503 占比。如果某一时段集中出现，对照同一时间的限速规则改动记录，基本能定位到是哪条策略。

2. 确认蜘蛛身份验证方式

不要只看 UA 字符串。正规蜘蛛提供了反向解析再加正向确认的验证办法，可以把验证通过的请求放进白名单，跳过通用限速。白名单要按需维护，而不是长期全放开。

3. 检查限速的维度与阈值

• 限速按 IP、按 UA、按接口分别设置，避免一条规则覆盖全站。
• 给抓取类请求单独留一档更宽松的额度，静态资源可以比动态接口更松。
• 触发后优先返回 429 并带上重试时间，而不是直接 403。
• 对短时突发做排队或降速，而不是一次性拒绝。

4. 确认页面层没有被挑战拦下

用命令行工具直接请求一个普通内容页，看返回的 HTML 里有没有正文内容。如果只有一段脚本和跳转，说明人机校验对抓取请求也生效了，需要给已确认的蜘蛛放行。

自建抓取程序要避开的行为

如果你自己也在跑蜘蛛池或采集任务，同样要注意别把目标站点逼到必须加严防护：

• 控制单站点并发，别用几十个线程同时打同一个域名。
• 遵守对方的 robots 与抓取间隔，抓到 429 就退避，不要立刻重试。
• 标注可识别的 UA，并留下可联系的方式，出问题时对方能直接沟通而不是直接封段。
• 区分“需要频繁回访的入口页”和“只需偶尔复查的存量页”，把请求量花在有变化的地方。

改完之后怎么确认

调整规则后，别只看当天的抓取量，建议连续观察 3 到 7 天：

1. 蜘蛛 UA 的 2xx 占比是否回升。
2. 日志里 429 与 403 是否降到可解释的范围。
3. 重点栏目和新增内容是否重新出现抓取记录。
4. 是否有正常用户被误伤的反馈。

防护策略的目标是区分“谁在抓”和“怎么抓”，而不是一律拒绝。把验证做在前面，把白名单做窄做准，比事后从日志里刨原因要轻松得多。

最后提醒一句：限速和拦截规则属于会随业务变化的配置，建议把每次改动记在同一个地方，包括改动时间、影响范围和回滚方式。出现抓取异常时，第一件事是对照改动记录，而不是先去改内容。