很多站点把 CDN 放在最外层之後，蜘蛛的請求其實先落在邊缘节点上，源站日誌里看到的只是一部分回源记錄。如果只看源站日誌，很容易得出“蜘蛛来得少了”或者“某個 URL 没被抓過”的结论，而真實情况可能是請求被缓存层接走了，或者被邊缘規則拦下了。理清 CDN 這一层，是判断抓取是否正常的前提。

缓存命中：蜘蛛這次拿到的是哪一份内容

当邊缘节点命中缓存时，蜘蛛不會触發回源，它讀到的就是缓存里存的那份 HTML。多數情况下這没問题，但下面几種情况會让蜘蛛和真實用戶看到不一样的東西：

• 缓存里存的是舊版本頁面，源站已经更新但缓存還没過期；
• 缓存分区按 UA 或 Cookie 拆分，蜘蛛那一份長期停留在舊内容上；
• 邊缘节点做了压缩或 HTML 改寫，與源站结构出現细微差別。

這不是说要為了蜘蛛去缩短缓存時間，而是说頁面更新後，缓存過期策略要能让新鲜内容在合理時間内被讀取。如果某類頁面更新频繁，可以给它們單獨設定較短的缓存時間，而不是全站一刀切。

回源集中在缓存過期的那一刻

大量頁面如果缓存時間设成同样的值，過期時間就會聚成同一個時間点，回源請求也會集中出現。蜘蛛恰好在這個窗口来抓，看到的就是响應變慢甚至超时。對抓取来说，慢响應和失敗响應都會影响後續的抓取节奏。

可以做的几件事：

• 把缓存過期時間打散，避免全站同一秒集体回源；
• 對源站容量做余量估計，留出缓存失效瞬間的並發空間；
• 關注回源請求的排队時間，而不只是平均响應時間。

狀態碼可能来自 CDN，而不是源站

邊缘規則、防護策略或者限速模块都可能直接返回响應，源站根本收不到這條請求。常见的有：

• 403：被 UA 規則或地区策略拦住；
• 429：触發邊缘限速；
• 5xx：回源失敗後由 CDN 给出的兜底頁面。

這些狀態碼如果持續出現，蜘蛛的抓取會明顯减少，但源站监控上却看不出異常。排查抓取問题时，CDN 侧的日誌要單獨看一遍，重点確認蜘蛛 UA 是否被誤拦、是否被限速，以及 5xx 是不是回源超时導致的。

缓存分区與 URL 變体

缓存键通常包含 URL、查询串和部分請求头。如果站点對同一内容存在多種 URL 形式，缓存层會把它們当成多條记錄分別存储，回源次數也跟着翻倍。更麻烦的是，不同變体可能命中的是不同版本的缓存，導致蜘蛛在不同時間点看到的内容不一致。

處理思路和 URL 規范化一致：确定一個主入口，其余形式通過重定向或 canonical 收敛，缓存键尽量简單，不要加入與内容無關的請求头。

缓存预热與蜘蛛的到訪

新頁面發布後，缓存里還没有内容，蜘蛛第一次来必然回源。如果發布瞬間有較多新 URL 同时被推送，比如一次更新了大量列表頁，回源請求會短时增加。把發布時間错開，或者提前對關键頁面做一次预热，能让蜘蛛到来时的响應更稳定。

排查时的检查顺序

1. 先確認蜘蛛請求到達的是 CDN 還是直接從源站進入，两邊日誌按時間戳對照；
2. 看 CDN 日誌里蜘蛛 UA 的命中率、狀態碼分布和回源比例；
3. 检查 UA 規則與限速規則，確認蜘蛛没有被算進普通流量里限流；
4. 抽查几個重要 URL，比對缓存内容與源站目前内容是否一致；
5. 確認缓存過期時間是否過于集中，回源峰值是否與抓取變慢的時間吻合。

缓存和抓取不是對立的两件事。缓存做得合理，蜘蛛能更快拿到頁面；缓存做得粗糙，蜘蛛拿到的可能是過期内容，或者干脆被挡在外面。

把 CDN 当成抓取鏈路里的一环来看，很多“蜘蛛變少了”的判断會變得更容易解释：有时候不是蜘蛛不来了，而是它的請求停在了你没在看的那個日誌文件里。