很多站点排查抓取問题时只盯着頁面和連結，却忽略了中間那一层：CDN 與缓存。蜘蛛請求的往往不是源站，而是离它最近的邊缘节点。节点返回缓存還是回源结果，會直接影响响應時間、狀態碼，甚至决定它看到的是哪一版頁面。這层配置没問题时几乎没人注意，一旦有偏差，抓取日誌里的表現就會顯得很反常。
蜘蛛拿到的是缓存，還是回源结果
對搜尋引擎来说，它只關心這次請求有没有在合理時間内拿到正确内容，至于内容由缓存還是源站提供，它並不知情。但對站点来说，這两條路径的成本差別很大：缓存命中时响應通常在几十毫秒，回源則要经過網絡往返、應用處理和資料库查询。如果蜘蛛抓取的 URL 恰好都落在未命中的部分，源站压力會被放大，抓取變慢、超时、5xx 都可能跟着出現。
更需要注意的是缓存可能把错誤一起缓存住。如果某次回源时源站返回了 500 或一個空頁面，而缓存把它当成正常响應存了下来，後續蜘蛛在有效期内拿到的都會是這個错誤结果。這類問题看源站日誌很正常，只有看邊缘节点才看得出来。
哪些配置會悄悄影响蜘蛛看到的頁面
Vary 與 Cookie
如果响應头里带了 Vary: Cookie 或 Vary: User-Agent，缓存會被切成很多份，命中率急剧下降，甚至等于没有缓存。有些站点為了做訪問統計或語言判断，對每個訪客下發不同的 Cookie，蜘蛛請求时也带上一份，于是每次都回源，抓取体驗和普通用戶完全不同。
缓存键與查询串
缓存键通常包含完整 URL，也包含查询串。带參數的 URL 會各占一份缓存，命中率被稀释。反過来，如果缓存键忽略了查询串，那么 /list?page=1 和 /list?page=5 可能返回同一份缓存，蜘蛛抓到的分頁内容就會重复或错乱。两種做法都會让抓取结果和预期不一致。
缓存過期與半新半舊
較短的 TTL 意味着蜘蛛每次来訪都可能触發回源，抓取越频繁，源站越紧張。較長的 TTL 則可能让蜘蛛反复看到舊版本，新内容迟迟不被感知。没有绝對正确的值，但内容更新频率和缓存時間要對得上，列表頁和詳情頁通常不该用同一套策略。
和抓取节奏配合的几個做法
- 對静態资源和變化不频繁的頁面設定較長 TTL，把回源压力留给真正需要實时計算的頁面。
- 避免缓存键被無意义的參數打散，比如跟踪參數、會话 ID、時間戳。
- 明确哪些响應可以被缓存：只缓存 200，屏蔽 4xx 與 5xx，避免错誤被固化。
- 在源站压力可控的前提下，對搜尋引擎来源的請求保持稳定的响應能力，不要因為單獨限速造成大批超时。
- 頁面更新後按需刷新相關缓存，而不是等 TTL 自然過期。
如何判断問题出在缓存层
- 用相同 URL 连續請求几次，观察响應头中的缓存命中标识、Age、X-Cache 等字段是否變化。
- 對比邊缘节点與直接回源源站的响應時間、狀態碼和正文長度。
- 查看抓取日誌中同一 URL 的狀態碼是否出現周期性波動，比如每隔一段時間集中出現 5xx。
- 检查响應头里是否存在 Vary: Cookie 之類的字段。
- 確認缓存規則是否把參數、UA 或 Cookie 纳入了缓存键。
缓存层不是抓取的外部因素，它决定了蜘蛛實际拿到什么。配置上的小偏差，往往比内容問题更容易造成抓取波動。
把 CDN 和缓存当成抓取鏈路的一部分来看：它既影响蜘蛛能否在合理時間内拿到頁面，也影响它拿到的是不是正确的版本。定期對照邊缘节点日誌和抓取日誌，比只看源站狀態碼更容易發現那些看起来正常、實际不正常的問题。