蜘蛛拿到的是边缘副本，不是你的源站
很多入口页挂上 CDN 之后，源站日志里的蜘蛛访问会明显变少。这不是蜘蛛不来了，而是大量请求被边缘节点拦下，只有回源的那部分才落在你的日志里。如果不清楚这一点，很容易把“日志里蜘蛛变少”误判成抓取量下滑。
反过来，如果缓存规则设得不对，蜘蛛可能长期读到一份过期或错误的副本，你在源站怎么改都不生效，排查时又很难想到是缓存层的问题。
先分清哪些内容该缓存、哪些必须绕开
- 内容稳定、短期内不变更的入口页 HTML，适合缓存，TTL 可以给长一些。
- 每次都需要重新生成、带一次性参数或校验逻辑的 URL，不适合缓存，或者在缓存键里把无关参数剔除。
- 会做 301、302 跳转的入口页，跳转结果可以缓存，但要确认目标地址没写错，否则错误会跟着 TTL 一起存活很久。
- 与后台、统计、调试相关的路径，应明确写进例外规则，不要进缓存。
TTL 的取舍：短了伤源站，长了藏问题
短 TTL（几十秒到几分钟）的好处是改动很快生效、出错影响面小，代价是回源次数高，蜘蛛密集抓取时源站压力大。长 TTL（几小时到一天）能明显降低回源，但一旦缓存了错误内容，问题会持续存在，排查时也容易被“我明明已经改了”困住。
比较稳妥的做法是按页面类型分开设：入口页主体给较长 TTL，同时保留主动刷新通道；变更频繁的部分走短 TTL 或不缓存。也可以在 URL 上做版本化，用路径或参数变化让旧缓存自然过期，而不是反复手动刷新。
回源放大：蜘蛛峰值时最容易出问题的地方
命中率低的时候，蜘蛛的每一次访问都可能打到源站。如果入口页数量大，单页还带着若干静态资源，回源请求会被放大数倍。上线新批次入口页之前，先确认源站的并发余量和带宽；蜘蛛抓取往往集中在某个时间段，峰值比平均值更值得关注。
怎么确认缓存有没有按预期工作
- 看响应头：Age、X-Cache、CF-Cache-Status、Via 这类字段能大致判断命中与否。
- 从不同地区或不同节点请求同一个 URL，对比返回内容是否一致，尤其是刚更新过的页面。
- 对照 CDN 报表与源站日志，看命中率与回源量之间的差值是否合理。
- 检查 Vary 头，避免因为不必要的 Vary 把缓存拆得过细，导致命中率被稀释。
几个容易踩的坑
- 把 4xx、5xx 或拦截页缓存下来，蜘蛛之后的访问全都拿到同一份错误页。
- 缓存键包含随机参数，命中率接近零，等于白挂了一层 CDN。
- 内容更新后只刷新了一个节点，其他节点仍然返回旧版本。
- 压缩或移动端适配在缓存层被统一处理，返回了不适合当前 UA 的版本。
上线前的检查顺序
- 列出需要缓存的路径和必须绕开的路径，写成明确规则。
- 按页面类型设置 TTL 和缓存键，剔除无关参数。
- 上线后立刻从多个节点验证响应头与实际内容。
- 观察一到两天的命中率和回源量，再决定是否调整 TTL。
- 建立刷新流程，明确内容变更后由谁触发刷新、多久内完成。
缓存不是“设完就不用管”的环节，它直接决定蜘蛛实际读到什么。定期抽查边缘节点返回的内容，往往比盯着源站日志更有意义。