入口页铺好了，链接也放出去了，但日志里长期只有零星抓取，甚至连一条蜘蛛记录都没有。这时很多人会先怀疑链接质量，却忽略了一个更靠前的环节：请求可能在 CDN 或 WAF 层就被拦掉了，根本没走到源站。
被拦截时常见的几种表现
- 源站日志完全没有蜘蛛记录，但 CDN 日志里有大量 403、405、429；
- 返回 200，内容却是一段人机验证页或跳转脚本，属于“软拦截”；
- 只抓到入口页，站内链接一个没抓，因为静态资源或子路径被规则挡住；
- 白天正常、夜间掉零，通常是频率策略在起作用。
最容易误伤蜘蛛的几类规则
频率与并发阈值
默认的“单 IP 每分钟 N 次”往往按普通访客设定，蜘蛛短时间集中抓取时会被判为异常。限速阈值要留出余量；确实超限时优先返回 429 并带上 Retry-After，而不是直接封 IP。
IP 段与地区封禁
为了挡境外流量而整体封禁某些地区，或把 IDC 机房段一律拉黑，很容易连搜索引擎的抓取段一起封掉。搜索引擎的 IP 段会更新，白名单需要定期核对。
校验方式过于单一
只按 User-Agent 放行，UA 是任何人都能伪造的；反过来，只做反向解析校验，解析失败就拒绝，也会误伤。常见做法是把官方 IP 段、反向解析、正向解析回查三者交叉验证。
一刀切的访问策略
诸如禁止空 Referer、禁止无 Cookie 访问、强制 JS 挑战之类的规则，对爬虫基本等于关站。若必须开启人机验证，应给已确认的蜘蛛单独放行。
一次比较完整的排查顺序
- 先看 CDN 与 WAF 的访问日志，确认请求是否到达这一层；
- 比对搜索引擎官方公布的 IP 段，看被拦的是不是这些地址；
- 查看被拦请求的响应码、响应体和响应时间，区分硬拦截与软拦截；
- 再往下查源站：Nginx 配置、iptables、fail2ban 以及应用层的防爬插件；
- 放行后连续观察几天抓取量与状态码分布，确认不是间歇性触发。
提示：排查时不要只测“能不能访问”，要看清“被拦的到底是哪一层”。同一个 403，可能来自 CDN 边缘节点，也可能来自源站的应用逻辑，处理方式完全不同。
几条实用建议
- 把白名单规则放在所有限速和挑战规则之前，顺序很重要；
- 保留 403、429、5xx 的完整日志，出问题时才有回溯依据；
- 规则变更后做一次模拟抓取验证，别等日志掉零才发现；
- 入口页和目标页用同一套放行策略，避免只放行了入口。
WAF 和 CDN 本身不是问题，问题是规则没有给正常抓取留出通道。把这一层理顺，往往比继续增加入口页更有效。