很多站点把 CDN 放在最外层之后，蜘蛛的请求其实先落在边缘节点上，源站日志里看到的只是一部分回源记录。如果只看源站日志，很容易得出“蜘蛛来得少了”或者“某个 URL 没被抓过”的结论，而真实情况可能是请求被缓存层接走了，或者被边缘规则拦下了。理清 CDN 这一层，是判断抓取是否正常的前提。
缓存命中：蜘蛛这次拿到的是哪一份内容
当边缘节点命中缓存时，蜘蛛不会触发回源，它读到的就是缓存里存的那份 HTML。多数情况下这没问题，但下面几种情况会让蜘蛛和真实用户看到不一样的东西：
- 缓存里存的是旧版本页面，源站已经更新但缓存还没过期；
- 缓存分区按 UA 或 Cookie 拆分，蜘蛛那一份长期停留在旧内容上；
- 边缘节点做了压缩或 HTML 改写，与源站结构出现细微差别。
这不是说要为了蜘蛛去缩短缓存时间，而是说页面更新后，缓存过期策略要能让新鲜内容在合理时间内被读取。如果某类页面更新频繁，可以给它们单独设置较短的缓存时间，而不是全站一刀切。
回源集中在缓存过期的那一刻
大量页面如果缓存时间设成同样的值，过期时间就会聚成同一个时间点，回源请求也会集中出现。蜘蛛恰好在这个窗口来抓，看到的就是响应变慢甚至超时。对抓取来说，慢响应和失败响应都会影响后续的抓取节奏。
可以做的几件事：
- 把缓存过期时间打散，避免全站同一秒集体回源；
- 对源站容量做余量估计，留出缓存失效瞬间的并发空间；
- 关注回源请求的排队时间，而不只是平均响应时间。
状态码可能来自 CDN，而不是源站
边缘规则、防护策略或者限速模块都可能直接返回响应，源站根本收不到这条请求。常见的有：
- 403：被 UA 规则或地区策略拦住；
- 429：触发边缘限速；
- 5xx：回源失败后由 CDN 给出的兜底页面。
这些状态码如果持续出现，蜘蛛的抓取会明显减少，但源站监控上却看不出异常。排查抓取问题时，CDN 侧的日志要单独看一遍，重点确认蜘蛛 UA 是否被误拦、是否被限速，以及 5xx 是不是回源超时导致的。
缓存分区与 URL 变体
缓存键通常包含 URL、查询串和部分请求头。如果站点对同一内容存在多种 URL 形式，缓存层会把它们当成多条记录分别存储，回源次数也跟着翻倍。更麻烦的是，不同变体可能命中的是不同版本的缓存，导致蜘蛛在不同时间点看到的内容不一致。
处理思路和 URL 规范化一致：确定一个主入口，其余形式通过重定向或 canonical 收敛，缓存键尽量简单，不要加入与内容无关的请求头。
缓存预热与蜘蛛的到访
新页面发布后，缓存里还没有内容，蜘蛛第一次来必然回源。如果发布瞬间有较多新 URL 同时被推送，比如一次更新了大量列表页，回源请求会短时增加。把发布时间错开，或者提前对关键页面做一次预热，能让蜘蛛到来时的响应更稳定。
排查时的检查顺序
- 先确认蜘蛛请求到达的是 CDN 还是直接从源站进入，两边日志按时间戳对照；
- 看 CDN 日志里蜘蛛 UA 的命中率、状态码分布和回源比例；
- 检查 UA 规则与限速规则，确认蜘蛛没有被算进普通流量里限流；
- 抽查几个重要 URL，比对缓存内容与源站当前内容是否一致；
- 确认缓存过期时间是否过于集中，回源峰值是否与抓取变慢的时间吻合。
缓存和抓取不是对立的两件事。缓存做得合理，蜘蛛能更快拿到页面；缓存做得粗糙，蜘蛛拿到的可能是过期内容，或者干脆被挡在外面。
把 CDN 当成抓取链路里的一环来看，很多“蜘蛛变少了”的判断会变得更容易解释：有时候不是蜘蛛不来了，而是它的请求停在了你没在看的那个日志文件里。