304不是更新失敗：先分清瀏覽器快取與版本驗證

網站剛改完，你在瀏覽器的Network看到304，畫面卻好像沒變。先別把304當成錯誤，也不要馬上關掉全站快取。304表示這次條件請求被伺服器判定「版本沒有改變」，瀏覽器可以沿用已有內容；接下來要查的是，你收到的版本是否真的符合預期。

先看請求帶了什麼，再看回應

依 MDN的304說明，304常見於帶有If-None-Match或If-Modified-Since的條件式GET或HEAD請求。以ETag為例，伺服器先回傳內容與版本標記；下次瀏覽器帶回這個標記，伺服器核對後，版本相同就可回304而不重送正文。

本文的隔離範例使用同一個/notice網址，內容原本是「週一營業」，後來改成「週二營業」：

第一次GET：200，ETag: "notice-v1"，正文「週一營業」
帶If-None-Match: "notice-v1"再GET：304，沒有正文
內容改版後仍帶舊ETag再GET：200，ETag: "notice-v2"，正文「週二營業」

這個例子說明：304沿用的是已有的版本；內容改變且版本驗證正確時，舊標記應取得新的200回應。不是所有網站都用這些標記值，ETag生成方式由伺服器決定，也不能只看狀態碼就判定整條更新流程正常。

no-cache與no-store，別看名字猜意思

Cache-Control: no-cache不代表「完全不能保存快取」，而是保存的回應再次使用前需要向伺服器驗證，所以仍可能看到304。no-store則指示快取不要儲存這個回應；它也不是清除所有既有快取的按鈕。

若看到max-age=3600，表示符合條件的快取可在一小時的新鮮期內重用，可能根本不發出新的網路請求。因此Network顯示memory cache或disk cache，和伺服器回304是不同情況。完整規則可查 MDN的Cache-Control說明，不要為了消掉304把所有頁面一律改no-store。

改版後仍顯示舊內容，按這個順序查

先選一個有明確變動的資源，記下網址、預期文字或圖片版本。在瀏覽器開啟開發者工具的Network，重新載入，查看它的Request Headers、Response Headers與回應內容。

1. 若是304，核對請求中的If-None-Match與回應的ETag；若有If-Modified-Since，也一併查看。要看的是版本驗證，不只是304數字。
2. 暫時在開發者工具啟用Disable cache，再載入同一網址，觀察是否拿到預期內容；通常須保持開發者工具開啟。這是診斷瀏覽器快取，不是清除CDN或證明來源伺服器內容已更新。
3. 若仍是舊內容，再請維護者查網站快取、反向代理或CDN，以及真正提供該資源的來源。Age、Via等標頭可能提供線索，但缺少這些標頭不能證明沒有中間快取。

測試完恢復瀏覽器的診斷設定。若需調整正式快取策略，先確認受影響頁型與回復方式；會員個人內容與公開圖片不能不加區分地共用同一套快取規則。這篇的範例只驗證單一HTTP伺服器的條件回應，不能代替你的CDN、會員頁或實際效能測試。

資料核對：2026年10月2日。範例版本與文字用於示範；實際網站需核對自己的請求、回應與快取層。

參考資料