當 Nginx 使用 proxy cache 的檔案作為響應時，它會更新其中的一些內容，比如 Date 響應頭；但大部分響應頭都不會得到更新，比如 Expires 和 Cache-Control。眾所周知，Cache-Control 可以通過 max-age=xxx 或者 s-maxage=xxx 指令設定快取的有效時間。跟 Expires 響應頭不同，這一時間是相對的。假設上游伺服器返回 Cache-Control: public; max-age=3600，那麼 Nginx 會快取該響應一小時。如果在這一小時到期之前，Client 訪問了 Nginx，它會獲取到同樣的 Cache-Control 響應頭，因此會再快取多一小時。所以總體上該響應會被快取兩小時。
這聽起來很讓人驚訝。但仔細想想，其實也不算什麼嚴重的問題。首先，當我們設定 max-age=3600 時，大多數情況下並不要求其嚴格地在一小時後過期。其次，這個算是一般的多層快取固有的弊端：快取資料的最大過期時間，取決於各級快取 TTL 的總和。如果想要避免，你可以選擇根據外層資料剩下的 TTL 設定當前 TTL；或者提供主動 purge 的操作，從最內層開始逐層清理資料。
當然，某些時候下，這一行為會帶來一些問題。舉個例子，假設我們開啟了 proxy_cache_use_stale，在上游伺服器出問題時使用過期的內容代替正常的響應。這種情況下，快取只是作為一個臨時救急的方案使用，我們並不希望 Client 多快取更多的時間。否則會有上游應用的開發者抱怨，為何上游伺服器已經正常了，使用者重新整理頁面看到的還是舊資料。作為解決辦法，我們可以在 Nginx 的 header filter 階段，通過 Lua 程式碼或者 Nginx C module，把 Cache-Control: max-age=... 修改成 Cache-Control: no-cache。這麼一來，Client 會在使用快取之前先驗證下，如果 Nginx 返回 304 狀態碼，那麼該快取會被繼續使用；如果上游已經 OK 了且更新了響應，那麼 Client 就會重新請求，避免使用過期的內容。
這裡需要強調下，no-cache 並非如字面上的意義表示不快取，而是要求 Client 在使用該快取之前，需要先驗證下被快取的內容是否還是最新的。MDN 的說法是：
Forces caches to submit the request to the origin server for validation before releasing a cached copy.
對應的，RFC 7234 的說法：
The “no-cache” request directive indicates that a cache MUST NOT use
a stored response to satisfy the request without successful
validation on the origin server.
如果要想讓 Client 不快取響應的內容，按 MDN 上的說法，需要用 Cache-Control: no-cache, no-store, must-revalidate（https://developer.mozilla.org…）。
仔細看了下 no-cache / no-store / must-revalidate 這三項指令的介紹，似乎 no-store 就能讓 Client 不用這個快取，因為 no-store 要求：
The cache should not store anything about the client request or server response.
另外 must-revalidate 要求在使用過期快取前驗證下該內容是否是最新的，而 no-cache 也是要求重新驗證的，那為什麼需要兩個都一起用呢？
Google 搜尋把我帶到了這個 SO 問答：https://stackoverflow.com/que…。這個回答裡面解釋了為何不單單用 no-store：因為臭名昭著的 IE6 瀏覽器在處理 no-store 時有 bug。但可惜的是，這個回答沒有給出這一論斷的證據，比如 IE 的 bug report 之類。MDN 在給出 Cache-Control: no-cache, no-store, must-revalidate 這個例子的時候，也沒有提及更多的上下文。這很像沒有任何註釋的老程式碼：我們不知道當初為何這麼寫，而把它刪掉似乎不會帶來什麼問題。