很多站点在接入 CDN 之后，服务器日志里蜘蛛的访问记录会明显变少。有人以为是抓取下降了，其实只是请求被 CDN 节点接走了，没有回到源站。搞清楚蜘蛛的请求落在哪一层，是排查抓取异常的第一步。

一次蜘蛛请求会经过哪些环节

从蜘蛛发出请求到你的源站程序处理，中间通常要穿过 DNS 解析、CDN 边缘节点、WAF 或防火墙、负载均衡，最后才到源站。任何一层做了拦截、缓存或改写，蜘蛛拿到的内容都可能和你本地看到的不一样。

缓存命中时，蜘蛛拿到的是什么

CDN 命中缓存时，源站根本不会收到这次请求，日志自然也不会有记录。这本身不是坏事，响应更快对蜘蛛是好事。但要注意两点：

• 缓存的是旧版本 HTML，页面已经改过，蜘蛛拿到的还是昨天的内容。
• 缓存的是错误响应，比如把一次 5xx 或跳转页面缓存住了，后续蜘蛛持续拿到同样的结果。

检查缓存规则

静态资源长缓存问题不大，HTML 文档的缓存时间建议短一些，改版或批量更新后主动刷新缓存。对返回 4xx、5xx 的响应，一般不要长期缓存。

按 UA 给蜘蛛单独放行，值不值得

有的配置会按 User-Agent 区分，给蜘蛛走一条特殊链路，比如绕过缓存直接回源。这样做的代价是：蜘蛛看到的页面和普通用户不一样，一旦两套逻辑不一致，排查成本会高出很多。UA 可以被伪造，单纯按 UA 放行也不等于安全。更稳妥的做法是让蜘蛛走和普通用户相同的链路，只对明显的异常流量做限速。

日志该在哪一层看

如果只看源站日志，会漏掉所有被 CDN 和 WAF 拦下的请求。判断抓取情况时，建议把 CDN 访问日志和源站日志对照着看，重点确认：

• 蜘蛛 IP 是否真的是搜索引擎的，可用反向解析或官方 IP 段比对。
• 返回的状态码分布，是不是有大量 403、429、5xx。
• 被拦截的请求里，有没有正常的内容页被误伤。

CDN 侧通常会提供实时日志或日志下载，注意日志有延迟，别拿几分钟前的数据下结论。

日常配置的几条建议

1. 确认 CDN 没有对 HTML 文档设置过长缓存，改版后记得刷新。
2. 确认 WAF 规则不会因为路径里的参数或特殊字符误拦内容页。
3. 如果用了 IP 白名单或验证，先核对官方公布的蜘蛛 IP 段，并定期更新。
4. 限速策略要区分开，别把正常的抓取请求和异常爬虫用同一条规则处理。
5. 迁移 CDN 或调整回源配置后，抽查几类页面的实际响应。

怎么自己验证一遍

最简单的办法是用蜘蛛的 UA 请求一个页面，看返回的 HTML 和状态码：

curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -I https://example.com/some-page

先看状态码和响应头，再去掉 UA 参数请求同一个地址，对比两者是否一致。同时观察源站日志里有没有这条请求，就能判断请求停在了哪一层。

蜘蛛拿不到内容，原因常常不在页面本身，而在请求到达源站之前的某一环。先把链路查清，再谈内容优化，顺序才不会反。

CDN 只是整条链路里的一段，但它是最容易被忽略的一段。定期把边缘日志和源站日志对一遍，很多"抓取变少"的疑问都能自己解释清楚。