HTTP 快取到期計算機

輸入回應的 Cache-Control、Expires、Date 與 Age 值、接收的時間以及要檢查的時間。計算機會給出新鮮度存續時間、目前存續時間，以及該回應是否仍然新鮮。

快取類型

Cache-Control（回應標頭的值）

Expires（回應標頭的值；若無則留空）

Date（回應標頭的值；若無則留空）

Age（回應標頭的值，單位為秒；若無則留空）

接收回應的時間（UTC）

要檢查的時間（UTC）

新鮮度判定（在要檢查的時間） —

新鮮度存續時間（回應可保持新鮮的時間長度；不會隨時間經過而改變）
新鮮度存續時間	—
採用的來源	—

目前存續時間（自回應產生起經過的時間；會隨時間經過而增加）
目前存續時間	—
表面存續時間（接收時間 − Date）	—
Age 標頭的值	—
接收時的存續時間（以上兩者中較大者）	—
自接收起經過的時間	—

剩餘新鮮度
剩餘新鮮度（新鮮度存續時間 − 目前存續時間）	—
變為過期的時間	—

這是依據 RFC 9111 的計算。實際的瀏覽器與 CDN 的行為不一定完全符合標準的描述。回應延遲視為 0。

這個計算機的功能

它涵蓋 HTTP 快取標準 RFC 9111 的一部分：新鮮度的計算。也就是決定已儲存的回應能否不經原始伺服器檢查就重複使用的部分。驗證（ETag、If-Modified-Since、304）、Vary 以及請求端的 Cache-Control 不在範圍內。

新鮮度不是重新整理，也不是刪除

回應過期（stale）只表示快取在未先檢查的情況下不可重複使用。這不表示瀏覽器畫面會自動重新整理，也不表示原始伺服器上的檔案已被更改或刪除。同樣地，回應仍然新鮮，也不表示伺服器上的檔案沒有變動。標準指出，Expires 標頭「does not imply that the original resource will change or cease to exist at, before, or after that time」。本計算機只計算快取副本的時間運算。

新鮮度存續時間與目前存續時間

新鮮度存續時間：回應可保持「新鮮」的時間長度。由回應本身（Cache-Control 或 Expires）決定，不會隨時間經過而改變。
目前存續時間：自回應產生起已經過的時間。會隨時間經過而增加。
是否新鮮？只有當新鮮度存續時間大於目前存續時間時，回應才算新鮮（兩者相等時，視為過期）。
剩餘新鮮度 = 新鮮度存續時間 − 目前存續時間。

由哪個值決定新鮮度存續時間

依 RFC 9111 第 4.2.1 節，採用第一個符合的項目：

順序	共用快取（CDN、代理伺服器）	私有快取（瀏覽器）
1	s-maxage	（不使用 s-maxage）
2	max-age	max-age
3	Expires − Date	Expires − Date
4	若都不存在，則沒有明確的到期時間	相同

**若存在 max-age，則忽略 Expires。**在共用快取中，若存在 s-maxage，則忽略 max-age 與 Expires（第 5.3 節）。
如果同一個指令出現多次，採用第一個（標準允許的做法之一）。
不是整數、或帶有引號的 max-age 或 s-maxage（標準規定傳送端不得產生帶引號的形式）會被視為無效，回應會被視為過期（新鮮度存續時間為 0）。大於 2,147,483,648 的值會被視為 2,147,483,648（第 1.2.2 節）。
如果 Expires 是 0 或不存在的日期，該回應會被視為已經過期（第 5.3 節）。
沒有明確的到期時間時，不會計算啟發式新鮮度（例如根據 Last-Modified 推估）。 標準將啟發式的有效期限交由各實作自行決定。

目前存留時間的計算方式

公式出自 RFC 9111 第 4.2.3 節：

表面存留時間 = max(0, 接收時間 − Date)
接收時的存留時間 = max(表面存留時間, Age 標頭 + 回應延遲)
目前存留時間 = 接收時的存留時間 + 接收後經過的時間

本計算機不會詢問送出請求的時間，因此將回應延遲（從送出請求到收到回應的時間）視為 0。 在延遲較大的連線上，計算出的存留時間可能小於實際值。標準也允許僅使用 Age 標頭加上延遲。

輸入規則

日期請以 IMF-fixdate（例如 Sun, 06 Nov 1994 08:49:37 GMT）或 UTC 時間（例如 2026-10-21 07:28:00）輸入。一律以 UTC（GMT）計算，不處理時區。年份須介於 1900 至 2100，秒數須介於 0 至 59（不接受閏秒 60）。不會檢查星期名稱與日期是否相符。
RFC 850 與 asctime 格式是 HTTP 接收端應當接受的格式，但本計算機不支援。（這不代表它們在 HTTP 中無效。請將值轉換為 IMF-fixdate。）
若 Date 為空白，將以您輸入的「收到回應的時間」代替 Date。RFC 9110 指出，接收到沒有 Date 的回應時，接收端會記錄收到的時間並將其加為 Date。若該時間也是空白，則需要 Date 的計算（Expires − Date 與表面存留時間）無法進行。不會自動使用瀏覽器的目前時間；只有按下「目前時間」按鈕時，才會填入「檢查時間」欄位。
要檢查的時間不得早於收到回應的時間。

其他 Cache-Control 指令

這些指令不用於計算，但會作為重複使用的注意事項顯示。

no-store：不得儲存。private：共用快取不得儲存（瀏覽器可以）。
no-cache（不含參數）：即使仍然新鮮，未經驗證也不能重複使用。
must-revalidate：一旦過期，未經驗證不得使用。proxy-revalidate：相同，但不適用於私有快取。
public：明確允許儲存。
immutable（RFC 8246）、stale-while-revalidate 與 stale-if-error（RFC 5861）不在 RFC 9111 範圍內。本計算機會辨識它們，但不用於計算。

範例

輸入	結果
max-age=3600，沒有 Age，收到後 1,800 秒	新鮮度有效期限 3,600 秒，目前存留時間 1,800 秒，剩餘 1,800 秒（新鮮）
相同條件，剛好 3,600 秒時	目前存留時間 3,600 秒。與新鮮度有效期限相等，因此已過期
max-age=3600，Age=600，剛收到	目前存留時間 600 秒，剩餘 3,000 秒
共用快取，s-maxage=60，max-age=3600	新鮮度有效期限 60 秒（忽略 max-age）

須知

這是依據標準的計算。實際的瀏覽器與 CDN 不一定完全依照標準所述運作。 強制重新載入等操作以及 CDN 專屬設定，可能產生不同的結果。不保證特定產品的行為。
不涵蓋啟發式新鮮度、驗證、Vary、請求指令以及多層快取的疊加。

來源與查證

以下內容已於 2026 年 11 月 1 日對照標準全文確認：

RFC 9111「HTTP Caching」：https://www.rfc-editor.org/rfc/rfc9111（第 1.2.2、4.2.1、4.2.3、5.1、5.2.2 與 5.3 節，包括新鮮度判斷 freshness_lifetime > current_age）
RFC 9110「HTTP Semantics」：https://www.rfc-editor.org/rfc/rfc9110（第 5.6.7 與 6.6.1 節）

本計算機僅就新鮮度依循上述章節。通過此計算並不代表任何產品或伺服器符合標準。

常見問題

max-age 與 Expires 同時存在時會如何？

以 max-age 為優先，忽略 Expires（RFC 9111 第 5.3 節）。

s-maxage 適用於瀏覽器嗎？

s-maxage 是供共用快取使用的指令。私有快取（瀏覽器）不會使用它。

什麼是 Age 標頭？

這是途中某個快取所寫入的秒數，表示自回應在源頭伺服器產生或最後一次檢查以來經過的時間。本計算機用它來求得目前存留時間。

過期的回應會自行消失或更新嗎？

不會。過期只表示快取在重複使用前必須先檢查。它不會重新整理畫面，也不會改變源頭伺服器上的任何內容。

如何確認時間？

Unix 時間戳記換算器與 Cron 運算式計算機或許有幫助。