蜘蛛池入口页接入 CDN 之后：缓存策略、回源与蜘蛛拿到的版本

CDN 解决的是访问速度，不是 URL 发现

蜘蛛池入口页的数量上去之后，很多人会顺手给入口页套一层 CDN：一是分摊源站压力，二是让不同地区的蜘蛛访问都快一点。这个思路本身没问题，但 CDN 会在源站和蜘蛛之间加一层缓存，蜘蛛拿到的可能不是源站当下的版本。如果不注意，排查抓取问题时会一直盯着源站，而问题其实出在缓存上。

Cache-Control 的 max-age 直接决定蜘蛛多久能看到新内容。入口页内容更新不频繁的话，可以设得长一些，减少回源；但如果入口页上的链接列表经常调整，缓存时间过长会让蜘蛛一直爬到旧列表，新加的 URL 迟迟发现不了。常见做法是给入口页设置中等长度的缓存，同时保留主动刷新的手段。

有些 CDN 默认忽略 URL 上的查询参数，或者只保留白名单里的参数。入口页如果靠参数区分不同列表，比如分页参数、分类参数，这些页面在缓存层可能被合并成同一份内容。蜘蛛抓到的第二页其实是第一页，翻页等于没翻。上线前确认缓存键是否覆盖了影响内容的参数，是必要的。

Vary: User-Agent 会让 CDN 按 UA 分别缓存。如果源站对不同 UA 返回的内容不一致，蜘蛛很可能被分到一份不完整的缓存上。不少站点为了让移动端体验更好，对移动 UA 返回不同模板，结果蜘蛛拿到的版本里链接少了很多。要么保证不同版本的核心链接一致，要么干脆不给蜘蛛做差异化。

CDN 节点是各自回源的，不同节点回源的时刻不同，缓存里的内容也会有先后。蜘蛛在短时间内访问多个入口页，可能从不同节点拿到新旧混杂的版本。内容差异太大时，容易让蜘蛛判定页面不稳定。缓解方式是把入口页的核心结构做成静态的、变化少的部分，把频繁变动的部分缩小，或者用主动刷新让各节点尽快对齐。

接了 CDN 之后，源站日志里能看到的蜘蛛请求会变少，因为大部分请求被缓存拦截了。这时候判断蜘蛛行为，不能只看源站日志，还要看 CDN 侧的访问日志。两边对照才能知道：蜘蛛来过几次、命中缓存的比例有多高、有没有因为节点问题返回异常状态码。

如果源站日志里几乎看不到搜索引擎蜘蛛，但 CDN 日志里有，说明缓存生效正常；反过来，如果两边都没有，才需要去查 DNS、robots、封禁策略这些更前面的环节。

很多 CDN 自带 WAF 和 Bot 管理。默认策略下，频率较高的抓取容易被判定为异常流量，返回 403、429，或者弹一个 JS 验证。这类拦截对正常用户的体验影响不大，但对蜘蛛来说等于入口被切断。可以做的事情是把已知的搜索引擎 IP 段加白，或者对静态的入口页路径放宽频率限制。

入口页数量不多、源站本身带宽充足、访问量也不大的时候，直接走源站反而更省事：缓存带来的不确定因素没有了，排查问题时链路也短。CDN 的价值在规模和地域分布上体现得比较明显，如果只是几十个入口页，可以先不急着加这一层。

CDN 本身不会帮助页面被发现，它只是改变了蜘蛛访问时经过的路径。把缓存策略、回源行为和日志对照做扎实，才能保证蜘蛛看到的是你希望它看到的那一版。