CDN是否支持Last-Modified头？全面解析与配置实战指南
上週幫客戶調優電商平台時，發現商品圖片明明沒更新，CDN卻頻繁回源抓檔案。用curl一查才驚覺Last-Modified頭被邊緣節點忽略了，這問題至少吃掉他們30%頻寬成本。今天這篇就來解剖這個常被低估的HTTP頭，實測六大CDN平台行為差異。
多數人以為啟用CDN緩存就萬事大吉，其實魔鬼藏在頭部協定裡。當瀏覽器帶著If-Modified-Since請求命中邊緣節點時，CDN要不要向源站驗證檔案新鮮度？這取決於三個關鍵：CDN廠商的預設行為、你的緩存規則配置、甚至作業系統時區設定。去年某金融APP就因Last-Modified時間戳未同步，導致用戶端載入混亂。
實測主流CDN平台發現有趣現象：Cloudflare預設會透傳Last-Modified，但若自訂緩存規則裡勾選\”Origin Cache-Control\”，它反而會覆寫源站設定；AWS CloudFront則需手動啟用\”Based on Headers\”緩存策略，否則直接無視Last-Modified。最麻煩的是Akamai，得透過Property Manager設定caching.ignoreOriginNoCache參數才能強制尊重源站頭。
分享我的Nginx實戰配置模板，重點在add_header Last-Modified $date_gmt這行：
曾遇過客戶源站用PHP動態輸出的Last-Modified帶有逗號（如：Wed, 21 Aug 2024 12:34:56 GMT），導致CDN節點解析失敗。建議用date(\"D, d M Y H:i:s T\", time())確保格式合規，必要時在CDN側配置Header Normalization功能自動修正。
行動端適配是另一個深坑。某些舊版Android Webview對Last-Modified的毫秒級差異異常敏感，我們在CDN配置層加入trim_modified_timestamp = 1s參數（邊緣節點自動捨去毫秒位），才解決了隨機性304失效問題。這案例讓我深刻體會：緩存協定從來不只是技術議題，更是用戶體驗的生死線。
評論: