本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 控制 CloudFront 快取錯誤的時間長度
<a name="custom-error-pages-expiration"></a>

根據預設，CloudFront 會每 10 秒快取錯誤回應。CloudFront 然後將物件的下一個請求提交給您的原始伺服器，以查看導致錯誤的問題是否已解決，並且請求的物件是否可使用。

您可以指定錯誤快取持續時間 **錯誤快取最短 TTL** 給每個 CloudFront 快取的 4xx 和 5xx 狀態碼。(如需詳細資訊，請參閱 [CloudFront 快取的 HTTP 4xx 和 5xx 狀態碼](HTTPStatusCodes.md#HTTPStatusCodes-cached-errors)。) 當您指定持續時間時，請注意以下事項：
+ 如果您指定的錯誤快取持續時間不長，則 CloudFront 轉送到原始伺服器的請求，會比如果您指定較長的持續時間時來的多。針對 5xx 錯誤，這可能會讓原本導致原始伺服器傳回錯誤的問題加劇。
+ 當您的原始伺服器傳回物件的錯誤時，CloudFront 使用錯誤回應或自訂錯誤頁面來回應物件的請求，直到錯誤快取持續時間過後。如果您指定很長的錯誤快取持續時間，則 CloudFront 可能需要很長的時間使用錯誤回應或自訂錯誤頁面來持續回應請求，到物件再次可用之後。

**注意**  
您可以建立自訂錯誤頁面以取得 HTTP 狀態碼 416 (不滿足請求範圍)，當原始伺服器傳回狀態碼 416 給 CloudFront 時，您可以變更 CloudFront 傳回給檢視器的 HTTP 狀態碼 (如需詳細資訊，請參閱「[變更 CloudFront 傳回的回應碼](custom-error-pages-response-code.md)」。) 然而，CloudFront 不會快取狀態碼 416 回應，因此，即使您為狀態碼 416 指定 **Error Caching Minimum TTL** (快取最小 TTL 時發生錯誤) 的值，CloudFront 也不會使用它。

如果您想要控制 CloudFront 快取個別物件錯誤的時間長度，您可以配置原始伺服器新增適用的標頭給該物件的錯誤回應。

如果原始伺服器新增 `Cache-Control: max-age` 或 `Cache-Control: s-maxage` 指示詞，或 `Expires` 標頭：CloudFront 將快取在標頭或 **Error Caching Minimum TTL** (錯誤快取最短 TTL) 中較大值的錯誤回應。

**注意**  
`Cache-Control: max-age` 和 `Cache-Control: s-maxage` 值不得大於為擷取的錯誤頁面所設定之快取行為的 **Maximum TTL** (最大 TTL) 值。

如果原始伺服器新增錯誤代碼 404`Cache-Control: no-store``Cache-Control: no-cache`、410、414 或 501 的 、 或 `Cache-Control: private`指令，CloudFront 不會快取錯誤回應。對於所有其他錯誤代碼，CloudFront 會忽略 `no-store`、 和 `private`指令`no-cache`，並快取錯誤**快取最低 TTL 值的錯誤**回應。

如果原始伺服器新增其他 `Cache-Control` 指示詞或未新增標頭：CloudFront 將快取**Error Caching Minimum TTL** (錯誤快取最短 TTL )值的錯誤回應。

如果物件的 4xx 或 5xx 狀態碼的到期時間超過您想要的時間，且物件可以再次使用，則您可以使用請求的物件 URL 使快取的錯誤碼失效。如果原始伺服器傳回多個物件的錯誤回應，則您需要個別使每一個物件失效。如需有關使物件失效的詳細資訊，請參閱[使檔案失效以移除內容](Invalidation.md)。

如果您已為 S3 儲存貯體原始伺服器啟用快取，且您在 CloudFront 分佈中設定錯誤快取最短 TTL 為 0 秒，則在發生 S3 原始伺服器錯誤的情況下，您仍會看到錯誤快取最短 TTL 為 1 秒。CloudFront 會這麼做是為了保護原始伺服器免受 DDoS 攻擊。這不適用於其他類型的原始伺服器。