我在我的 CloudFront 分佈上設定了自訂物件快取。為什麼我的分佈使用我的原始伺服器的快取設定?
我的 Amazon CloudFront 分佈具有快取行為,物件快取設定為「自訂」,但我的分佈仍然使用原始伺服器的快取設定。我該如何解決此問題?
簡短描述
當您自訂物件快取時,您可以設定預設 TTL、最小 TTL和最大 TTL。CloudFront 會根據原始伺服器是否傳回快取標頭來使用這些參數:
- 如果原始伺服器不會傳回快取標頭,則分佈會使用預設 TTL。
- 如果原始伺服器傳回的快取標頭小於「最小 TTL」,則分佈會使用「最小 TTL」。
- 如果原始伺服器傳回的快取標頭大於「最大 TTL」,則分佈會使用「最大 TTL」。
**注意:**即使 CloudFront 根據「最小 TTL」或「最大 TTL」快取回應,對用戶端的回應也會包含原始伺服器的快取標頭。原始伺服器的快取標頭可以被任何私有快取 (例如瀏覽器或代理) 使用。
如果 CloudFront 分佈不是根據您在快取行為上設定的自訂值進行快取,請檢查原始伺服器。驗證原始伺服器是否有任何衝突的快取標頭。
解決方法
若要驗證原始伺服器快取標頭是否與分佈的自訂物件快取衝突,請根據您看到的問題遵循以下說明:
「最小 TTL」和「預設 TTL」 設定為 0,但仍有來自 CloudFront 的點擊
如果即使請求 URI 與「最小 TTL」和「預設 TTL」設定為 0 的快取行為路徑相符,也有來自 CloudFront 的點擊,請檢查來自 CloudFront 的回應。驗證回應是否將 X-Cache 標頭顯示為「Hit from cloudfront」或「RefreshHit from cloudfront」:
< HTTP/1.1 200 OK < Content-Type: text/html < Content-Length: 437 < Connection: keep-alive < Date: Sat, 03 Feb 2018 19:26:45 GMT < Last-Modified: Sat, 03 Feb 2018 19:25:24 GMT < ETag: "example12345abcdefghijklmno54321" < Cache-Control: max-age=300, Public < Accept-Ranges: bytes < Server: AmazonS3 < Age: 14 < X-Cache: Hit from cloudfront
如果 X-Cache 標頭是「Hit from cloudfront」或「RefreshHit from cloudfront」,則會從邊緣節點的快取提供請求。
查看 Cache-Control、Expires 和 Age 標頭的其餘回應。Cache-Control 和 Expires 標頭是行為快取標頭,可告知中介 (CloudFront) 或私有 (瀏覽器) 快取如何儲存請求。Age 標頭顯示了回應已被快取的時長。
如果 Cache-Control 的 max-age 值大於 Age 的值,則快取的回應會被視為新的,並從邊緣節點提供。如果 Expires 日期仍然是在未來,那麼快取的回應也被認為是新的。即使快取行為路徑的「最小 TTL」 和「預設 TTL」 設定為 0,也會發生這種情況。
「最大 TTL」和「預設 TTL」 大於 0,但是有來自 CloudFront 的遺漏
如果即使請求 URI 與「最大 TTL」和「預設 TTL」設定為大於 0 的快取行為路徑相符,也有來自 CloudFront 的遺漏,請檢查 CloudFront 的回應。驗證回應是否顯示 X 快取標頭為「Miss from cloudfront」:
< HTTP/1.1 200 OK < Content-Type: text/html < Content-Length: 437 < Connection: keep-alive < Date: Sat, 03 Feb 2018 19:26:45 GMT < Last-Modified: Sat, 03 Feb 2018 19:25:24 GMT < ETag: "example12345abcdefghijklmno54321" < Cache-Control: no-cache, no-store < Accept-Ranges: bytes < Server: AmazonS3 < X-Cache: Miss from cloudfront
如果 X-Cache 標頭是「Miss from cloudfront」,則表示請求是從原始伺服器擷取而不是由快取提供。
檢閱回應中的 Cache-Control 標頭。如果 Cache-Control 的值是「no-store」,則標頭會引導 CloudFront 不快取回應。如果 Cache-Control 的值是「no-cache」,則標頭會引導 CloudFront 在傳回快取回應之前,使用原始伺服器進行驗證。這些指令會取代「最大 TTL」 和「預設 TTL CloudFront」設定。
**注意:**不是來自快取的回應將不會有 Age 標頭。
CloudFront 正在快取錯誤回應
根據預設,CloudFront 會將錯誤回應從原始伺服器轉送到用戶端。此外,CloudFront 預設會快取原始伺服器的錯誤回應 10 秒鐘。
如果原始伺服器的錯誤回應包含 Cache-Control 標頭,CloudFront 會使用相關的 TTL 快取錯誤,而不是預設的 5 分鐘快取錯誤。CloudFront 不會快取自己的錯誤回應,除非在自訂錯誤回應中另有指定。
若要判斷錯誤回應是來自原始伺服器還是 CloudFront,請檢查伺服器標頭。若要判斷錯誤是否為快取回應,請檢查 Age 標頭 (快取的回應包含 Age 標頭)。
下列範例是來自 Amazon Simple Storage Service (Amazon S3) 原始伺服器的錯誤,該伺服器是快取回應:
< HTTP/1.1 403 Forbidden < Content-Type: application/xml < Transfer-Encoding: chunked < Connection: keep-alive < Date: Sat, 03 Feb 2018 21:07:51 GMT < Server: AmazonS3 < Age: 12 < X-Cache: Error from cloudfront
下列範例是來自 CloudFront 的錯誤,該錯誤並非快取回應:
< HTTP/1.1 403 Forbidden < Server: CloudFront < Date: Sat, 03 Feb 2018 21:14:53 GMT < Content-Type: text/xml < Content-Length: 146 < Connection: keep-alive < X-Cache: Error from cloudfront
判斷出衝突的快取標頭之後,請更新原始伺服器
判斷哪些快取標頭會取代分佈的自訂物件快取之後,請依照下列步驟執行:
- 確定在 Web 服務器設定中應用標頭的位置。
- 刪除應用標頭的行。
- 重新啟動伺服器。
- 直接測試您的原始伺服器,以確保在回應中不再傳回快取標頭。
- 在您的整個 CloudFront 分佈上執行無效驗證以套用變更。
相關資訊
相關內容
- 已提問 10 個月前lg...
- AWS 官方已更新 2 年前
- AWS 官方已更新 2 年前
- AWS 官方已更新 3 年前
- AWS 官方已更新 2 年前