蜘蛛拿到的是邊缘副本，不是你的源站
很多入口頁挂上 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。
- 建立刷新流程，明确内容變更後由谁触發刷新、多久内完成。
缓存不是“设完就不用管”的环节，它直接决定蜘蛛實际讀到什么。定期抽查邊缘节点返回的内容，往往比盯着源站日誌更有意义。