網站快取有沒有生效怎麼檢測？快取命中與載入速度分析
本文介紹網站快取是否生效的檢測方法，結合 Cache-Control、HIT/MISS、瀏覽器快取和 TTFB，分析快取命中情況及其對網站載入速度的實際影響。
網站已經配置了 CDN、瀏覽器快取或者頁面快取，但存取速度似乎沒有明顯變化，這種情況不能只看後台裡的快取規則有沒有開啟。真正需要確認的是：使用者發起請求以後，資源到底有沒有從快取中返回。
判斷網站快取是否生效，通常可以從 Cache-Control、Age、HIT/MISS 狀態、重複請求結果以及 TTFB 等幾個方面入手。只有把「有沒有快取」「有沒有命中」和「命中後有沒有變快」這幾個問題分開看，才能判斷快取配置究竟有沒有發揮作用。
本文就從實際檢測角度，講清楚網站快取怎麼查、HIT 和 MISS 分別代表什麼，以及快取已經命中但網站仍然很慢時應該繼續檢查哪些地方。
一、網站快取怎樣才算是生效？
平時說的網站快取，其實並不只有一種，從使用者存取網站的整個鏈路來看，快取可能存在於瀏覽器、CDN 邊緣節點、Web 伺服器甚至網站應用內部。
例如：
瀏覽器快取圖片、CSS、JavaScript 等靜態檔案；
CDN 將來源站資源快取到離使用者更近的邊緣節點；
Nginx、Varnish 等伺服器快取頁面或介面回應；
WordPress 等 CMS 使用頁面快取外掛；
Redis、Memcached 快取資料庫查詢結果。
對於一般站長來說，實際檢測時最常關注的是兩件事。
第一，瀏覽器是不是還在重複下載相同的資源。
第二，使用 CDN 後，請求有沒有真正命中 CDN 快取，而不是每次都重新回源。
這兩個問題雖然都屬於「快取」，但檢測方式並不完全一樣。
另外需要注意，網站開啟速度變快，並不能單獨證明快取已經命中；反過來，某個資源顯示 HIT，也不代表整個網頁一定很快。
快取只是網站效能鏈路中的一個環節，所以檢測時最好把快取狀態和真實載入時間放在一起看。
二、網站快取有沒有生效？先看回應標頭
最直接的檢測方法，是查看網站資源返回的 HTTP Response Headers。
以 Chrome 為例，可以開啟需要測試的網頁，然後按下 F12 進入開發者工具，切換到：
Network → 選擇一個資源 → Headers → Response Headers
建議先查看圖片、CSS、JavaScript 這類靜態資源，因為它們通常最容易配置快取。
1. 查看 Cache-Control
Cache-Control 是判斷快取策略時最常見的回應標頭之一。
例如：
Cache-Control: public, max-age=86400其中：
public 表示這個回應允許被共享快取保存；
max-age=86400 表示快取有效期為 86400 秒，也就是 24 小時。
這說明伺服器已經明確告訴瀏覽器或中間快取節點：這個資源可以在一定時間內快取。
另外還可能看到：
Cache-Control: no-cache或者：
Cache-Control: no-store這兩個經常被混在一起理解，但實際上含義並不一樣。
no-cache 並不等於完全禁止保存快取，而是再次使用快取內容之前，通常需要先向伺服器驗證資源是否仍然有效。
no-store 則更加嚴格，一般表示不應該保存該回應內容。
所以檢查快取時，不能看到 no-cache 就直接判斷「網站沒有快取」，還要結合其他回應標頭以及實際請求狀態一起分析。
2. 查看 Age
如果網站使用 CDN，可以繼續留意回應標頭中有沒有 Age。
例如：
Age: 328通常可以理解為，這個資源已經在某個共享快取中保存了 328 秒。
過一段時間重新請求同一個資源，如果看到：
Age: 356數值仍然在增加，說明該資源很可能一直保存在快取節點中，並沒有重新從來源站完整取得。
不過，不是所有 CDN 都會返回 Age，也不能只憑 Age 一個欄位判斷整個快取系統是否正常。
不同 CDN 的快取狀態欄位、規則以及返回方式都有差異，所以最好繼續結合 HIT、MISS 等結果來看。
三、HIT 和 MISS 怎麼看？
對於 CDN 快取來說，HIT 和 MISS 是最常見、也最容易理解的兩個狀態。
不同服務商使用的 Header 名稱可能不一樣，例如：
X-Cache: HIT或者：
CF-Cache-Status: HIT雖然欄位不同，但判斷思路基本一致。
HIT
HIT 一般表示當前請求已經命中快取。
也就是說，CDN 節點上已經存在可用的資源副本，請求可以直接從快取返回，不需要重新向來源站取得完整內容。
對於圖片、CSS、JavaScript、下載檔案等靜態資源來說，正常命中快取以後，通常可以明顯減少來源站壓力。
MISS
MISS 表示當前快取節點暫時沒有可直接使用的快取內容，因此通常需要向來源站取得。
不過，一次 MISS 並不能說明快取配置失敗。
例如某個 CDN 節點第一次收到這個 URL 的存取請求時，本地本來就可能沒有快取。第一次存取先回源，資源被快取下來以後，第二次請求才可能變成 HIT。
所以真正值得關注的是：
相同資源連續存取多次以後，仍然一直 MISS。
這種情況才需要進一步檢查快取規則。
除了 HIT 和 MISS，還可能看到一些其他狀態。
快取狀態 | 常見含義 |
|---|---|
HIT | 已經命中快取 |
MISS | 當前沒有可用快取，需要回源 |
EXPIRED | 原有快取已經過期 |
BYPASS | 當前請求繞過快取 |
DYNAMIC | 動態內容，通常沒有按照一般靜態資源方式快取 |
需要注意的是，不同 CDN 對這些狀態的定義可能存在差異。如果要精確判斷，最好同時查看對應服務商的快取規則。
四、連續請求兩次，比只看一次結果更有意義
實際檢測網站快取時，我一般不建議只請求一次資源就下結論。
假設測試的是：
https://www.example.com/static/app.js第一次存取時看到：
X-Cache: MISS
TTFB: 186ms這時候並不能馬上認為快取沒有生效。
重新請求一次相同 URL，如果結果變成：
X-Cache: HIT
TTFB: 38ms這種情況反而說明快取工作得比較正常。
第一次請求時，CDN 節點沒有該檔案，需要回源讀取；資源被保存以後，第二次存取直接從邊緣快取返回，因此首位元組回應時間明顯降低。
如果連續重新整理多次以後依然是：
X-Cache: MISS這時候再重點檢查：
資源是否允許快取；
CDN 快取規則有沒有涵蓋這個 URL；
TTL 是否設定得太短；
Cookie 是否導致繞過快取；
URL 參數是否一直發生變化。
「第一次 MISS、第二次 HIT」是很正常的情況，不能把一次 MISS 當成快取異常。
五、怎麼判斷瀏覽器快取有沒有生效？
CDN 快取和瀏覽器快取不是一回事：CDN 快取發生在網站伺服器和使用者之間，而瀏覽器快取發生在使用者本機，即使 CDN 已經 HIT，如果瀏覽器每次重新整理仍然重新下載大量靜態資源，頁面載入效率依然可能受到影響。
在 Chrome 中開啟：
F12 → Network
然後正常重新整理網頁，查看圖片、CSS、JavaScript 等資源，在 Size 或 Transferred 一欄中，有時會看到：(memory cache) 或者：(disk cache)。
memory cache 一般表示資源直接從瀏覽器記憶體中讀取；disk cache 則表示瀏覽器從本機磁碟快取中讀取。這種情況下，瀏覽器通常不需要重新完整下載該檔案。
檢測時還有一個很容易被忽略的細節：Chrome 開發者工具的 Network 面板中有一個：Disable cache，如果這個選項被勾選，只要開發者工具保持開啟狀態，瀏覽器快取就可能被暫時停用。
很多人在測試快取時一邊勾著 Disable cache，一邊反覆重新整理，然後發現資源始終重新請求，最後誤以為快取沒有生效。
所以測試瀏覽器快取之前，最好先確認這個選項的狀態。
六、快取命中以後，還要看 TTFB 有沒有變化
判斷快取有沒有價值，不能只停留在「顯示 HIT 了」。
真正需要觀察的是：HIT 以後，請求速度有沒有改善。
比如同一個靜態檔案第一次測試：
Cache: MISS
TTFB: 220ms再次請求：
Cache: HIT
TTFB: 42ms這種變化比較典型。
說明第一次存取需要經過 CDN 回源，第二次已經可以直接從快取節點返回，減少了回源鏈路，所以 TTFB 明顯下降。
但如果實際結果是：
MISS：TTFB 180ms
HIT：TTFB 165ms雖然快取狀態已經從 MISS 變成 HIT，但對這次存取來說，實際回應時間並沒有改善多少。
這種情況下就不能繼續把注意力全部放在快取配置上，而應該檢查其他因素。
例如：
CDN 節點距離使用者是不是太遠；
當前電信業者線路品質是否較差；
DNS 解析是否合理；
HTTPS/TLS 建連是否耗時；
靜態檔案是不是過大；
頁面本身是不是還有大量第三方請求。
所以檢測快取最好遵循一個原則：
先看是否 HIT，再看 HIT 以後到底快了多少。
只有這兩個結果同時成立，才能說明快取不只是「配置上生效」，而是在真實存取中發揮了作用。
七、快取調整以後，可以重新測試網站整體速度
瀏覽器開發者工具更適合分析某個具體資源有沒有快取，而網站測速則更適合觀察快取調整以後，整體存取效能是否真的發生變化。
例如修改了以下配置：
延長圖片快取時間；
調整 CSS、JS 的 Cache-Control；
修改 CDN 快取規則；
增加靜態資源快取範圍；
清理舊快取後重新建立快取。
調整完成後，可以使用 Chahu 對網站重新進行測速，觀察實際網站回應和不同網路環境下的存取速度變化。
這時候重點不是單獨看一次測速數字，而是對比調整前後的結果。
例如原來部分地區網站回應時間較高，快取策略調整以後明顯下降，說明這次優化確實對真實存取產生了效果。
如果快取已經正常 HIT，但測速時部分地區仍然明顯偏慢，那麼問題可能並不在快取。
接下來就應該繼續檢查：DNS解析、網路線路、CDN節點、源站回應以及頁面資源本身。
這種方式比單純盯著一個 HIT 狀態更有意義，因為最終使用者感受到的是網頁載入速度，而不是後台裡的某個快取欄位。
八、網站快取可以按照這個順序檢測
如果只是想快速判斷網站快取有沒有真正生效，可以按照下面這個順序檢查。
第一步：看 Cache-Control
先確認需要快取的資源有沒有合理的快取策略。
第二步：看快取狀態
查看 CDN 回傳的 HIT、MISS、Age、BYPASS 等資訊。
第三步：連續請求同一個 URL
不要只根據第一次存取判斷快取是否正常。
第四步：比較 TTFB
觀察從 MISS 變成 HIT 以後，實際回應時間有沒有明顯下降。
第五步：檢查瀏覽器快取
確認靜態資源有沒有從 memory cache 或 disk cache 中讀取。
第六步：重新測試網站整體速度
快取策略調整以後，再觀察不同地區和網路環境下的網站存取速度是否改善：如果快取已經正常 HIT，但網站仍然很慢，就不要繼續反覆修改快取規則，而應該把排查範圍擴展到 DNS、網路線路、CDN節點、源站回應以及頁面資源。
結語
判斷網站快取有沒有生效，不能只看後台有沒有打開「快取」開關，也不能只憑網頁感覺比以前快了一點。更可靠的方法，是從實際請求入手：先確認 Cache-Control 等快取策略有沒有正確回傳，再觀察 CDN 請求是 HIT 還是 MISS；連續測試相同資源後，再比較快取命中前後的 TTFB 和實際載入時間。
如果資源已經正常 HIT，而且命中後的回應時間明顯下降，基本可以確認快取正在發揮作用。如果快取狀態正常，但網站整體依然很慢，問題往往已經不在快取本身。繼續檢查源站回應、網路線路、DNS、檔案大小以及第三方資源，通常比反覆調整快取規則更容易找到真正的效能瓶頸。
相關問答
1. 為什麼網站在 CDN 設定了強快取，透過 Python 腳本或 Curl 抓取時依然頻繁回傳 MISS？
這通常是因為自動化腳本在發起 HTTP 請求時，預設帶上了與真實瀏覽器不同的 Request Headers（如缺少Accept-Encoding: gzip, br，或者包含了特殊的User-Agent和Cookie）。很多 CDN 節點在處理快取鍵時，會將請求標頭中的壓縮支援情況或 Query String 計算在內。當腳本發起的請求特徵與邊緣節點已快取的版本不匹配時，CDN 會認定為全新的請求並觸發回源。測試時建議使用curl -I -H "Accept-Encoding: gzip, deflate, br"模擬標準瀏覽器的 HTTP 請求標頭。
2. 開啟了 Nginx 的proxy_cache後，明明設定了靜態資源快取，為什麼日誌裡總是出現EXPIRED？
EXPIRED意味著 CDN 或反向代理節點上確實存在該資源的快取檔案，但它的生存時間（TTL）已經超過了規則指定的有效期。產生這一現象通常有兩個原因：一是 Nginx 設定中的proxy_cache_valid設定的時間過短；二是源站 HTTP 回應標頭中自帶的Cache-Control: max-age或Expires數值較小，覆蓋了代理伺服器的本地預設快取策略。此時節點會帶上驗證標頭回源，如果源站內容未變則重新刷新該快取區塊的生命週期。
3. 頁面使用了 HTML 頁面級快取（如 Edge Page Cache），發布新內容後如何做到讓特定頁面瞬間失效？
全頁快取雖然能極大降低首位元組回應時間（TTFB），但更新不及時會引發業務問題。純靠等待 TTL 自然過期效率太低，行業內通用做法是透過 API 觸發主動快取 Purge或 Invalidate。Purge 會直接刪除節點上的實體檔案，下一次存取強制回源；Invalidate 則將快取標記為過期，在後台非同步回源更新的同時，仍可選擇性地向使用者回應舊版本（Stale-While-Revalidate 機制），以保證頁面無縫載入。
4. 為什麼 HTTP/2 或 HTTP/3 協定下，即使沒有命中瀏覽器本地快取，首屏載入速度也可能沒有明顯延遲？
在 HTTP/1.1 時代，瀏覽器對同一網域的並行連線數有限制（通常為 6 個），如果靜態資源未命中本地快取，很容易引發隊頭阻塞（Head-of-Line Blocking）。而在 HTTP/2 和 HTTP/3 中，引入了多路複用（Multiplexing）和 QUIC 協定，所有請求可以在同一個 TCP/UDP 連結中並行傳輸。即便資源觸發了 CDN 節點回應而非瀏覽器本地磁碟讀取，極低的傳輸建連開銷也會在視覺體驗上掩蓋掉部分未命中的延遲。
5. 源站在回應標頭中設定了Set-Cookie，為什麼會導致 CDN 節點直接跳過快取？
為了防止使用者的敏感私密資料（如登入態 Session、個人購物車資訊）被 CDN 錯誤地快取並分發給其他訪客，大部分 CDN 供應商都設定了嚴格的安全防護機制：只要偵測到源站回應標頭裡帶有Set-Cookie欄位，該請求就會被強制標記為BYPASS或PRIVATE，絕不寫入公共節點儲存。如果圖片或 CSS 等靜態資源被錯誤地注入了 Cookie，需要檢查源站伺服器或 CMS 外掛，剝離靜態資源的Set-Cookie回傳。