蜘蛛池入口頁接入 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 本身不會帮助頁面被發現，它只是改變了蜘蛛訪問时经過的路径。把缓存策略、回源行為和日誌對照做扎實，才能保證蜘蛛看到的是你希望它看到的那一版。