CDN是否兼容HTTP缓存头：关键影响与网站加速优化技巧
深夜調試客戶網站時，看著Chrome開發者工具裡那些灰藍色的「304 Not Modified」狀態碼，突然想起七年前第一次被CDN緩存規則支配的恐懼。那時以為買了CDN服務就能高枕無憂，直到電商客戶的促銷banner全線錯亂——某些地區用戶看到的還是三天前的聖誕活動，而實際早已換成新年折扣。問題根源就出在Cache-Control標頭與CDN的微妙博弈。
多數人知道CDN靠邊緣節點緩存加速，但極少深究它如何「解讀」HTTP緩存頭。去年幫跨境電商做壓力測試時發現：同樣的Cache-Control: public, max-age=3600，在Akamai節點乖乖遵守1小時緩存，某家東南亞CDN卻擅自延長到4小時。事後查文檔才發現，該服務商默認開啟「緩存權重優化」，會根據文件熱度覆寫max-age值。
真正的實戰經驗是：永遠用curl驗證CDN行為。當你設置Cache-Control: no-cache後，別相信控制台圖標變綠就萬事大吉。去年某金融客戶的K線圖API被緩存，就是因為工程師漏了Vary: Cookie標頭。我會這樣測試：
若兩次返回的X-Cache標頭都是HIT，說明CDN無視了Cookie差異，此時必須在CDN配置台手動開啟「根據Vary頭分離緩存」。
更隱蔽的坑在ETag與Last-Modified的優先級。某次客戶的WordPress站點更新文章後，歐洲用戶總看到舊版本。排查發現源伺服器發送的是弱ETag（W/\”xxxx\”），而Cloudflare對弱驗證器有特殊處理邏輯——當客戶端發送If-None-Match時，CDN直接返回304而不回源驗證。最終解決方案是在CDN規則裡強制添加Cache-Control: must-revalidate。
最後分享個反直覺案例：某視頻平台把Cache-Control: no-store用在1080p片源，本意是防盜鏈，結果引發亞太區CDN節點頻繁回源，拖垮源站。解決方案竟是刪除no-store，改用簽名URL+短期緩存。因為no-store會穿透所有CDN層級，而簽名驗證在CDN邊緣即可完成。這正是CDN緩存頭的弔詭之處——有時過度防禦反而自毀長城。
評論: