不少人给蜘蛛池的入口页套上 CDN 和 WAF 之后，会看到一个很直接的变化：页面本身能正常打开，但蜘蛛的访问记录明显变少。这时候容易产生两种极端判断，一是“CDN 会屏蔽蜘蛛”，二是“防护太强必须全关”。实际情况通常介于两者之间——防护层本身不等于拦截，真正让蜘蛛走不进来的，往往是几个具体的配置细节。
CDN 本身很少拦住蜘蛛
CDN 做的是就近分发和缓存回源，对普通 GET 请求一般不会做额外判断。问题多出在这几处：
- 缓存策略过粗。如果入口页被长时间整页缓存，蜘蛛和新访客拿到的是同一份 HTML，页面内容更新后蜘蛛看到的还是旧版本，长期下来抓取频率会自然下降。
- 回源超时太短。源站响应慢一点就回 522、524 之类的错误，蜘蛛拿到的是异常状态码，自然会降低对这个地址的信任。
- 节点与源站地区不匹配。回源链路绕远，TTFB 偏高，抓取队列里的优先级会被压低。
这几项都能通过监控回源耗时、缓存命中率和状态码分布查出来，不需要动防护策略。
WAF 是最常见的误伤现场
人机校验、JS 挑战、滑块验证这些机制，本质上要求客户端执行脚本或完成交互，而绝大多数搜索蜘蛛不会做这两件事。结果就是入口页对人能打开，对蜘蛛返回 403 或一个验证页。
另一类误伤来自规则本身：
- 把包含 bot 的 UA 统一拉黑，顺带把 Googlebot、Bingbot 这类正常爬虫一起挡了。
- 按 IP 请求频率做 CC 防护，阈值设得太低，蜘蛛连续抓取就被判定为攻击。
- 只按 UA 做白名单。UA 可以随意伪造，这种放行方式既挡不住假蜘蛛，也容易在规则调整时误伤真蜘蛛。
接上 CDN 之后，日志里的 IP 已经不是访客 IP
这是很多运营忽略的一点。源站日志里显示的全是 CDN 节点的 IP，你看到的“蜘蛛”，可能只是节点回源。判断真实来源需要做两件事：
- 在源站配置真实 IP 解析（如 Nginx 的 real_ip、Apache 的 RemoteIP），并把 CDN 的节点段加入可信来源。
- 优先读取 CDN 传递的原始 IP 字段，同时保留节点 IP 作为校验，避免头部被伪造。
否则后面所有关于抓取量、抓取频率的分析都是错的，防护策略也无从调整。
比较稳妥的放行思路
- 入口页和目标页分开处理。入口页以可抓取为第一目标，防护做得轻一些；需要重点保护的接口、后台、数据页面再上重防护。
- 用 UA、IP 段、反向 DNS 三重校验放行。只靠其中一项都容易被绕过或误伤。
- 给已知蜘蛛单独放宽频率阈值。不要让它和普通访客共用同一套限速。
- 改动后观察一段时间。看日志里蜘蛛的抓取量、状态码分布和回源耗时，再决定是否继续收紧。
- 保留一份不经防护的回源入口。方便对比排查，也避免规则出错时彻底断掉抓取。
防护层的目标是挡掉无效流量，而不是挡掉所有自动化请求。把蜘蛛和攻击流量放在同一套规则里处理，几乎是必然出问题的做法。
小规模入口页未必需要防护
如果只是几台服务器、几十个入口页，本身没有明显的攻击压力，套 CDN 和 WAF 反而会增加排查难度：日志要多解析一层，故障点从一个变成三个，抓取异常时很难快速定位。这种情况下，把精力放在页面可访问性、响应速度和内容更新上，收益通常比加防护更直接。
反过来说，如果入口页已经频繁被打、被刷或被恶意扫描，防护就是必要的，只是要按上面几条把放行通道留清楚。CDN 和 WAF 都是工具，蜘蛛抓取量下降从来不是“用了防护”这一个原因造成的，更多是配置和验证方式的问题。