本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 請求和回應行為
下列主題說明 CloudFront 如何處理請求和回應。
您可以瞭解 CloudFront 如何與 Amazon S3 或自訂原始伺服器互動、處理各種 HTTP 方法和標頭、處理狀態碼，以及管理快取和錯誤回應。
**Topics**
+ [CloudFront 如何處理 HTTP 和 HTTPS 的請求](HTTPandHTTPSRequests.md)
+ [Amazon S3 原始伺服器之請求和回應行為](RequestAndResponseBehaviorS3Origin.md)
+ [為自訂原始伺服器之請求和回應行為](RequestAndResponseBehaviorCustomOrigin.md)
+ [原始伺服器群組的請求和回應行為](RequestAndResponseBehaviorOriginGroups.md)
+ [將自訂標頭新增到原始伺服器請求](add-origin-custom-headers.md)
+ [CloudFront 如何處理物件的部分請求 (範圍 GET)](RangeGETs.md)
+ [CloudFront 如何處理來自原始伺服器的 HTTP 3xx 狀態碼。](http-3xx-status-codes.md)
+ [CloudFront 如何處理來自原始伺服器的 HTTP 4xx 和 5xx 狀態碼](HTTPStatusCodes.md)
+ [產生自訂錯誤回應](GeneratingCustomErrorResponses.md)
# CloudFront 如何處理 HTTP 和 HTTPS 的請求
針對 Amazon S3 原始伺服器，預設情況下，在適用於 CloudFront 分佈中物件的 HTTP 和 HTTPS 通訊協定中 CloudFront 接受請求。然後，CloudFront 使用與請求相同的通訊協定轉送請求到 Amazon S3 儲存貯體。
對於自訂原始伺服器，當您建立分佈時，您可以指定 CloudFront 如何存取原始伺服器：僅限 HTTP，或配合檢視器所使用的通訊協定。如需有關 CloudFront 如何為自訂原始伺服器處理 HTTP 和 HTTPS 請求的詳細資訊，請參閱[通訊協定](RequestAndResponseBehaviorCustomOrigin.md#RequestCustomProtocols)。
如需有關如何限制分佈，讓最終使用者使用 HTTPS 只能存取物件的詳細資訊，請參閱[透過 CloudFront 使用 HTTPS](using-https.md)。
**注意**
HTTPS 請求的費用高過於 HTTP 請求的費用。如需計費費率的詳細資訊，請參閱 [CloudFront 定價](https://aws.amazon.com/cloudfront/#pricing)。
# Amazon S3 原始伺服器之請求和回應行為
若要瞭解您使用 Amazon S3 做為原始伺服器時 CloudFront 如何處理請求和回應，請參閱下列章節：
**Topics**
+ [CloudFront 如何處理和轉送請求至您的 Amazon S3 原始伺服器](#RequestBehaviorS3Origin)
+ [CloudFront 如何處理來自您 Amazon S3 原始伺服器的回應](#ResponseBehaviorS3Origin)
## CloudFront 如何處理和轉送請求至您的 Amazon S3 原始伺服器
瞭解 CloudFront 如何處理檢視器請求和轉送請求至 Amazon S3 原始伺服器。
**Contents**
+ [快取持續時間和最短 TTL](#RequestS3Caching)
+ [用戶端 IP 位址](#RequestS3IPAddresses)
+ [條件式 GET 請求](#RequestS3ConditionalGETs)
+ [Cookie](#RequestS3Cookies)
+ [跨來源資源共享 (CORS)](#RequestS3-cors)
+ [包括本文的 GET 請求](#RequestS3-get-body)
+ [HTTP 方法](#RequestS3HTTPMethods)
+ [CloudFront 移除或更新的 HTTP 請求標頭](#request-s3-removed-headers)
+ [最大請求長度和最大 URL 長度](#RequestS3MaxRequestStringLength)
+ [OCSP 裝訂](#request-s3-ocsp-stapling)
+ [通訊協定](#RequestS3Protocol)
+ [查詢字串](#RequestS3QueryStrings)
+ [原始伺服器連線逾時和嘗試次數](#s3-origin-timeout-attempts)
+ [原始伺服器回應逾時](#RequestS3RequestTimeout)
+ [相同物件之同步請求 (請求折疊)](#request-s3-traffic-spikes)
### 快取持續時間和最短 TTL
若要控制在 CloudFront 將另一個請求轉送到原始伺服器之前，您的物件留存於 CloudFront 快取中的時間長度，您可以：
+ 設定原始伺服器在每個物件中新增 `Cache-Control` 或 `Expires` 標頭欄位。
+ 指定在 CloudFront 快取行為中最短 TTL 的值。
+ 使用預設值為 24 小時。
如需詳細資訊，請參閱 [管理內容保持在快取中達多久時間 (過期)](Expiration.md)。
### 用戶端 IP 位址
如果檢視器將請求傳送到 CloudFront，而且未包含 `X-Forwarded-For` 請求標頭，則 CloudFront 會從 TCP 連線取得檢視器的 IP 位址、加入包含該 IP 位址的 `X-Forwarded-For` 標頭，然後將該請求轉送給原始伺服器。例如，如果 CloudFront 從 TCP 連線取得 IP 位址 `192.0.2.2`，則會將下列的標頭轉送到原始伺服器：
`X-Forwarded-For: 192.0.2.2`
如果檢視器將請求傳送到 CloudFront，並且包含 `X-Forwarded-For` 請求標頭，則 CloudFront 會從 TCP 連線取得檢視器的 IP 位址、將該 IP 位址附加到 `X-Forwarded-For` 標頭的結尾，然後將該請求轉送給原始伺服器。例如，如果檢視器的請求包含 `X-Forwarded-For: 192.0.2.4,192.0.2.3`，而且 CloudFront 從 TCP 連線取得 IP 位址 `192.0.2.2`，則會將下列的標頭轉送到原始伺服器：
`X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2`
**注意**
`X-Forwarded-For` 標頭包含 IPv4 地址 (如 192.0.2.44) 和 IPv6 地址 (如 2001:0db8:85a3::8a2e:0370:7334)。
### 條件式 GET 請求
如果 CloudFront 收到請求，向邊緣快取要求已過期的物件，會將該請求轉送到 Amazon S3 原始伺服器，以取得物件的最新版本，或是從 Amazon S3 取得 CloudFront 邊緣快取已具有最新版本的確認。當 Amazon S3 最初將物件傳送到 CloudFront 時，在回應中加入了 `ETag` 值和 `LastModified` 值。在 CloudFront 轉送到 Amazon S3 的新請求中，CloudFront 會新增下列其中一個或兩個標頭：
+ 含有已過期版本物件 `If-Match` 值的 `If-None-Match` 或 `ETag` 標頭。
+ 含有已過期版本物件 `If-Modified-Since` 值的 `LastModified` 標頭。
Amazon S3 使用此資訊來判斷物件是否已被更新，且因此是否需傳回整個物件至 CloudFront 或只傳回 HTTP 304 狀態碼 (而非修改)。
### Cookie
Amazon S3 不處理 cookie。如果您設定快取行為將 Cookie 轉送到 Amazon S3 原始伺服器，則 CloudFront 會轉送 Cookie，但 Amazon S3 會忽略這些 Cookie。所有相同物件的未來請求，無論是否變更 Cookie，透過快取中的現有物件提供。
### 跨來源資源共享 (CORS)
如果想讓 CloudFront 遵循 Amazon S3 跨來源資源共享設定，請設定 CloudFront 將選取的標頭轉送到 Amazon S3。如需詳細資訊，請參閱 [根據請求標頭快取內容](header-caching.md)。
### 包括本文的 GET 請求
如果檢視器的 `GET` 請求包含本文，CloudFront 會將 HTTP 狀態碼 403 (禁止) 傳回給檢視器。
### HTTP 方法
如果設定 CloudFront 處理其支援的所有 HTTP 方法，CloudFront 會接受從檢視器傳來的下列請求，然後將這些請求轉送到您的 Amazon S3 原始伺服器：
+ `DELETE`
+ `GET`
+ `HEAD`
+ `OPTIONS`
+ `PATCH`
+ `POST`
+ `PUT`
CloudFront 一律會快取 `GET` 與 `HEAD` 請求的回應。您也可以設定 CloudFront 快取 `OPTIONS` 請求的回應。CloudFront 不會快取對使用其他方法之請求的回應。
如果您想要使用分段上傳的方式，將物件新增至 Amazon S3 儲存貯體，您必須將 CloudFront 原始存取控制 (OAC) 新增至分佈，並將所需要的許可授予該 OAC。如需詳細資訊，請參閱[限制對 Amazon S3 原始伺服器的存取](private-content-restricting-access-to-s3.md)。
**重要**
如果設定 CloudFront 接受 CloudFront 支援的所有 HTTP 方法並轉送到 Amazon S3，您必須建立一個 CloudFront OAC，以限制對您 Amazon S3 內容的存取，並將所需要的許可權限授予該 OAC。例如若因為想要使用 `PUT` 方法，而設定 CloudFront 接受和轉送這些方法，則您必須設定 Amazon S3 儲存貯體政策，以適當地處理 `DELETE` 請求，讓檢視器無法刪除您不希望其刪除的資源。如需詳細資訊，請參閱[限制對 Amazon S3 原始伺服器的存取](private-content-restricting-access-to-s3.md)。
如需關於 Amazon S3 支援操作的詳細資訊，請參閱 [ Amazon S3 文件](https://docs.aws.amazon.com/s3/index.html)。
### CloudFront 移除或更新的 HTTP 請求標頭
在將請求轉送到您的 Amazon S3 原始伺服器之前，CloudFront 會先移除或更新一些標頭。對於大多數標頭，這種行為與自訂原始伺服器相同。如需 HTTP 請求標頭的完整清單，以及 CloudFront 處理這些標頭的方式，請參閱 [HTTP 請求標頭和 CloudFront 行為 (自訂和 Amazon S3 原始伺服器)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior)。
### 最大請求長度和最大 URL 長度
請求的長度上限是 32，768 個位元組，包括路徑、查詢字串 （如果有的話） 和標頭。
CloudFront 從請求建構 URL。此 URL 的最大長度為 8192 位元組。
如果 URL 超過長度上限，CloudFront 會將 HTTP 狀態碼 414 (URI 太長） 傳回給檢視器。如果因為超過標頭大小而請求超過長度上限，CloudFront 會將 HTTP 狀態碼 494 傳回給檢視器。在這兩種情況下，CloudFront 會終止與檢視器的 TCP 連線。
### OCSP 裝訂
檢視器提交對物件的 HTTPS 請求時，CloudFront 或檢視器都必須向憑證認證機構 (CA) 確認尚未撤銷網域的 SSL 憑證。OCSP 裝訂藉由讓 CloudFront 從 CA 驗證憑證和快取回應加速憑證驗證，所以用戶端不需要直接向 CA 驗證憑證。
CloudFront 收到針對同一個網域中物件的大量 HTTPS 請求時，OCSP 裝訂的效能提升會更加明顯。每個在 CloudFront 節點的伺服器必須提交單獨的驗證請求。CloudFront 收到針對同一個網域的大量 HTTPS 請求時，在邊緣節點中的每個伺服器很快就會收到來自 CA 的回應，伺服器可將其裝訂到 SSL 交握中的封包。檢視器確認憑證為有效時，CloudFront 即可提供請求的物件。如果您的分佈無法取得在 CloudFront 節點更多的流量，新的請求更有可能被導向至尚未向 CA 驗證憑證的伺服器。在這種情況下，檢視器會單獨執行驗證步驟，而且 CloudFront 伺服器會提供物件。該 CloudFront 伺服器也會提交驗證請求至 CA，所以下一次收到包含相同網域名稱的請求時，會有來自 CA 的驗證回應。
### 通訊協定
CloudFront 會根據檢視器請求的通訊協定 (HTTP 或 HTTPS)，轉送 HTTP 或 HTTPS 請求至原始伺服器。
**重要**
如果設定 Amazon S3 儲存貯體為網站端點，則您無法設定 CloudFront 使用 HTTPS 與原始伺服器進行通訊，因為 Amazon S3 在該組態中不支援 HTTPS 連線。
### 查詢字串
您可以設定 CloudFront 是否轉送查詢字串參數至您的 Amazon S3 原始伺服器。如需詳細資訊，請參閱 [根據查詢字串參數快取內容](QueryStringParameters.md)。
### 原始伺服器連線逾時和嘗試次數
「原始伺服器連線逾時」**是嘗試建立與原始伺服器連線時 CloudFront 所等待的秒數。
「原始伺服器連線嘗試次數」**是 CloudFront 嘗試連線至原始伺服器的次數。
這些設定共同決定了在容錯移轉至次要原始伺服器 (如果是原始伺服器群組) 或將錯誤回應傳回給檢視器之前，CloudFront 嘗試連線到原始伺服器的時間長度。依預設，CloudFront 會等待 30 秒 (嘗試 3 次，每次 10 秒)，然後再嘗試連線至次要原始伺服器或傳回錯誤回應。您可以指定較短的連線逾時、較少的嘗試次數或兩者，以縮短此時間。
如需詳細資訊，請參閱 [控制原始伺服器逾時和嘗試次數](high_availability_origin_failover.md#controlling-attempts-and-timeouts)。
### 原始伺服器回應逾時
「原始伺服器回應逾時」**，也稱為「原始伺服器讀取逾時」**或「原始伺服器請求逾時」**，適用於以下兩個數值：
+ 在將請求轉送到原始伺服器之後，CloudFront 等待回應的時間 (以秒為單位)。
+ CloudFront 在收到來自原始伺服器的回應封包後，並在接收下一個封包前所等待的時間 (以秒為單位)。
CloudFront 行為取決於檢視器請求的 HTTP 方法：
+ `GET` 與 `HEAD` 請求 – 如果原始伺服器未在 30 秒內回應，或是停止回應 30 秒，CloudFront 會結束連線。如果指定的[原始伺服器連線嘗試次數](DownloadDistValuesOrigin.md#origin-connection-attempts)超過 1，CloudFront 會再次嘗試取得完整的回應。CloudFront 最多可嘗試 3 次，由「原始伺服器連線嘗試次數」**設定的值決定。如果原始伺服器在最後一次嘗試時未回應，則 CloudFront 在收到相同原始伺服器上內容的另一個請求之前不會再嘗試。
+ `DELETE`、`OPTIONS`、`PATCH`、`PUT` 與 `POST` 請求 – 如果原始伺服器未在 30 秒內回應，CloudFront 會結束連線，而且不會再嘗試聯絡原始伺服器。用戶端可以視需要重新提交請求。
您無法變更 Amazon S3 原始伺服器 (「非」**使用靜態網站託管所設定的 S3 儲存貯體) 的回應逾時。
### 相同物件之同步請求 (請求折疊)
如果 CloudFront 邊緣節點收到對物件的請求，而且該物件目前不在快取中或快取物件已過期，CloudFront 會立即將該請求傳送到原始伺服器。不過，如果有對相同物件的同步請求，意即：如果在 CloudFront 接收到第一個請求之前，(具有相同快取金鑰) 其他相同物件的請求抵達邊緣節點，則在將其他請求轉送到原始伺服器之前，CloudFront 將暫停。此短暫的暫停有助於減輕原始伺服器的負載。暫停期間，CloudFront 會將原始伺服器請求的回應傳送至接收到的所有請求。這就是所謂的*請求摺疊*。在 CloudFront 日誌中，會將第一個請求識別為 `x-edge-result-type` 欄位中的 `Miss`，而崩潰的請求會識別為 `Hit`。如需有關 CloudFront 日誌的詳細資訊，請參閱 [CloudFront 和邊緣函數記錄](logging.md)。
CloudFront 只會摺疊共用[*快取金鑰*](understanding-the-cache-key.md)的請求。如果其他的請求沒有共用快取金鑰，(例如，因為您設定 CloudFront 根據請求標頭或查詢字串進行快取)，則 CloudFront 會將所有獨特的請求轉送到原始伺服器。
如果您想要防止所有請求摺疊，可使用受管快取政策 `CachingDisabled` (也可防止快取)。如需詳細資訊，請參閱[使用受管快取政策](using-managed-cache-policies.md)。
若您想防止特定物件的請求折疊，您可以將快取行為的最短 TTL 設為 0 *並*設定原始伺服器傳送 `Cache-Control: private`、`Cache-Control: no-store`、`Cache-Control: no-cache`、`Cache-Control: max-age=0` 或 `Cache-Control: s-maxage=0`。這些組態會增加原始伺服器的負載，並於 CloudFront 等待第一個請求的回應時，為暫停的同步請求引入額外的延遲。
**重要**
目前如果您在[快取政策](controlling-the-cache-key.md)、[原始伺服器請求政策](controlling-origin-requests.md)或舊版快取設定中啟用 Cookie 轉送，CloudFront 不支援請求摺疊。
## CloudFront 如何處理來自您 Amazon S3 原始伺服器的回應
瞭解 CloudFront 如何處理來自您 Amazon S3 原始伺服器的回應。
**Contents**
+ [已取消請求](#response-s3-canceled-requests)
+ [CloudFront 移除或更新的 HTTP 回應標頭](#response-s3-removed-headers)
+ [可快取檔案大小上限](#ResponseS3MaxFileSize)
+ [重新引導](#ResponseS3Redirects)
### 已取消請求
如果物件不在邊緣快取中，而且在 CloudFront 從原始伺服器取得物件之後，但尚未傳送請求的物件之前，檢視器就終止了工作階段 (例如，關閉瀏覽器)，則 CloudFront 不會在節點快取物件。
### CloudFront 移除或更新的 HTTP 回應標頭
在將 Amazon S3 原始伺服器傳來的回應轉送給檢視器之前，CloudFront 會移除或更新下列的標頭欄位：
+ `X-Amz-Id-2`
+ `X-Amz-Request-Id`
+ `Set-Cookie` – 如果設定 CloudFront 轉送 Cookie，此服務會將 `Set-Cookie` 標頭欄位轉送給用戶端。如需詳細資訊，請參閱 [根據 Cookie 快取內容](Cookies.md)。
+ `Trailer`
+ `Transfer-Encoding` – 如果 Amazon S3 原始伺服器傳回此標頭欄位，CloudFront 會將此值設定為 `chunked`，再將回應傳回給檢視器。
+ `Upgrade`
+ `Via` – CloudFront 在對檢視器的回應中將值設為以下值：
`Via: `*http-版本* *英數-字串*`.cloudfront.net (CloudFront)`
值的範例如下所示：
`Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)`
### 可快取檔案大小上限
CloudFront 在快取中儲存的回應內文大小上限為 50 GB。此包含未指定 `Content-Length` 標頭值的區塊傳輸回應。
使用範圍請求方法來請求每個部分為 50 GB 或更小的多部分物件，即可使用 CloudFront 快取大於此大小的物件。CloudFront 會快取這些部分，因為每個部分皆為 50 GB 或更小。檢視器擷取物件的所有部分之後，就可以重建原始、較大的物件。如需詳細資訊，請參閱 [使用範圍請求快取大物件](RangeGETs.md#cache-large-objects-with-range-requests)。
### 重新引導
您可以設定 Amazon S3 儲存貯體，將所有的請求重新引導到另一個主機名稱，這可以是另一個 Amazon S3 儲存貯體或 HTTP 伺服器。如果設定儲存貯體，將所有的請求重新引導，而且如果儲存貯體是 CloudFront 分佈的來源，則我們建議您設定該儲存貯體，使用分佈的網域名稱 (例如，d111111abcdef8.cloudfront.net)，或使用與分佈具有關聯的替代網域名稱 (CNAME) (例如，example.com)，來將所有的請求重新引導到 CloudFront 分佈。否則，檢視器會略過 CloudFront 請求，並從新的原始伺服器直接提供物件。
**注意**
如果您重新引導請求到備用網域名稱，您必須藉由新增 CNAME 記錄，為您的網域更新 DNS 服務。如需詳細資訊，請參閱 [透過新增備用網域名稱 (CNAME) 使用自訂 URL](CNAMEs.md)。
以下是當您設定儲存貯體重新引導所有請求時，發生的情況：
1. 檢視器 (例如，瀏覽器) 自 CloudFront 請求物件。
1. CloudFront 會將請求轉送到做為您分佈來源的 Amazon S3 儲存貯體。
1. Amazon S3 傳回 HTTP 狀態碼 301 (永久移動) 以及新的位置。
1. CloudFront 快取重新引導狀態碼和新的位置，並傳回值給檢視器。CloudFront 不遵循重新引導，以從新位置取得物件。
1. 檢視器傳送物件的另一個請求，但這次檢視器指定從 CloudFront 取得的新位置：
+ 如果 Amazon S3 儲存貯體使用 CloudFront 分佈的網域名稱或替代網域名稱，來將所有的請求重新引導到分佈，則 CloudFront 會向 Amazon S3 儲存貯體或新位置中的 HTTP 伺服器請求物件。當新的位置傳回物件時，CloudFront 會將其傳回至檢視器並在節點快取。
+ 如果 Amazon S3 儲存貯體將請求重新引導至另一個位置，則第二個請求會略過 CloudFront。Amazon S3 儲存貯體或新位置中的 HTTP 伺服器，會將物件直接傳回給檢視器，因此一律不會在 CloudFront 邊緣快取中快取物件。
# 為自訂原始伺服器之請求和回應行為
若要瞭解 CloudFront 如何在您使用自訂原始伺服器時處理請求和回應，請參閱下列章節：
**Topics**
+ [CloudFront 如何處理和轉送請求至您的自訂原始伺服器](#RequestBehaviorCustomOrigin)
+ [CloudFront 如何處理來自您的自訂原始伺服器的回應](#ResponseBehaviorCustomOrigin)
## CloudFront 如何處理和轉送請求至您的自訂原始伺服器
瞭解 CloudFront 如何處理檢視器請求和轉送請求至您的自訂原始伺服器。
**Contents**
+ [身分驗證](#RequestCustomClientAuth)
+ [快取持續時間和最短 TTL](#RequestCustomCaching)
+ [用戶端 IP 位址](#RequestCustomIPAddresses)
+ [用戶端 SSL 身分驗證](#RequestCustomClientSideSslAuth)
+ [壓縮](#RequestCustomCompression)
+ [條件式請求](#RequestCustomConditionalGETs)
+ [Cookie](#RequestCustomCookies)
+ [跨來源資源共享 (CORS)](#request-custom-cors)
+ [加密](#RequestCustomEncryption)
+ [包括本文的 GET 請求](#RequestCustom-get-body)
+ [HTTP 方法](#RequestCustomHTTPMethods)
+ [HTTP 請求標頭和 CloudFront 行為 (自訂和 Amazon S3 原始伺服器)](#request-custom-headers-behavior)
+ [HTTP 版本](#RequestCustomHTTPVersion)
+ [最大請求長度和最大 URL 長度](#RequestCustomMaxRequestStringLength)
+ [OCSP 裝訂](#request-custom-ocsp-stapling)
+ [持久性連線](#request-custom-persistent-connections)
+ [通訊協定](#RequestCustomProtocols)
+ [查詢字串](#RequestCustomQueryStrings)
+ [原始伺服器連線逾時和嘗試次數](#custom-origin-timeout-attempts)
+ [原始伺服器回應逾時](#request-custom-request-timeout)
+ [相同物件之同步請求 (請求折疊)](#request-custom-traffic-spikes)
+ [`User-Agent` 標頭](#request-custom-user-agent-header)
### 身分驗證
如果您將 `Authorization` 標頭轉送至原始伺服器，則可以設定原始伺服器，以針對下列請求類型請求用戶端身分驗證：
+ `DELETE`
+ `GET`
+ `HEAD`
+ `PATCH`
+ `PUT`
+ `POST`
對於 `OPTIONS` 請求，*只有*在您使用下列 CloudFront 設定時才能設定用戶端身分驗證：
+ CloudFront 設定為將 `Authorization` 標頭轉送到您的原始伺服器。
+ CloudFront 設定為*不*快取對 `OPTIONS` 請求的回應。
如需詳細資訊，請參閱[設定 CloudFront 以轉送 `Authorization` 標頭](add-origin-custom-headers.md#add-origin-custom-headers-forward-authorization)。
您可以使用 HTTP 或 HTTPS 將請求轉送至原始伺服器。如需詳細資訊，請參閱[透過 CloudFront 使用 HTTPS](using-https.md)。
### 快取持續時間和最短 TTL
若要控制在 CloudFront 將另一個請求轉送到原始伺服器之前，您的物件留存於 CloudFront 快取中的時間長度，您可以：
+ 設定原始伺服器在每個物件中新增 `Cache-Control` 或 `Expires` 標頭欄位。
+ 指定在 CloudFront 快取行為中最短 TTL 的值。
+ 使用預設值為 24 小時。
如需詳細資訊，請參閱 [管理內容保持在快取中達多久時間 (過期)](Expiration.md)。
### 用戶端 IP 位址
如果檢視器將請求傳送到 CloudFront，而且未包含 `X-Forwarded-For` 請求標頭，則 CloudFront 會從 TCP 連線取得檢視器的 IP 位址、加入包含該 IP 位址的 `X-Forwarded-For` 標頭，然後將該請求轉送給原始伺服器。例如，如果 CloudFront 從 TCP 連線取得 IP 位址 `192.0.2.2`，則會將下列的標頭轉送到原始伺服器：
`X-Forwarded-For: 192.0.2.2`
如果檢視器將請求傳送到 CloudFront，並且包含 `X-Forwarded-For` 請求標頭，則 CloudFront 會從 TCP 連線取得檢視器的 IP 位址、將該 IP 位址附加到 `X-Forwarded-For` 標頭的結尾，然後將該請求轉送給原始伺服器。例如，如果檢視器的請求包含 `X-Forwarded-For: 192.0.2.4,192.0.2.3`，而且 CloudFront 從 TCP 連線取得 IP 位址 `192.0.2.2`，則會將下列的標頭轉送到原始伺服器：
`X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2`
某些應用程式，例如負載平衡器 (包括 Elastic Load Balancing)、Web 應用程式防火牆、反向代理伺服器、入侵防護系統和 API Gateway，會針對轉送請求的 CloudFront 邊緣伺服器，將該伺服器的 IP 位址附加到 `X-Forwarded-For` 標頭的結尾。例如，如果 CloudFront 在轉送給 ELB 的請求中加入 `X-Forwarded-For: 192.0.2.2`，而且 CloudFront 邊緣伺服器的 IP 位址為 192.0.2.199，則您的 EC2 執行個體所收到的請求，會包含下列的標頭：
`X-Forwarded-For: 192.0.2.2,192.0.2.199`
**注意**
`X-Forwarded-For` 標頭包含 IPv4 地址 (如 192.0.2.44) 和 IPv6 地址 (如 2001:0db8:85a3::8a2e:0370:7334)。
另請注意，目前伺服器 (CloudFront) 路徑上的每個節點都可以修改 `X-Forwarded-For` 標頭。如需詳細資訊，請參閱 [RFC 7239](https://datatracker.ietf.org/doc/html/rfc7239) 的第 8.1 節。您也可以使用 CloudFront 邊緣運算函數修改標頭。
### 用戶端 SSL 身分驗證
CloudFront 支援交互 TLS (mTLS) 身分驗證，其中用戶端和伺服器都會使用憑證互相驗證。設定 mTLS 後，CloudFront 可以在 TLS 交握期間驗證用戶端憑證，並選擇性地執行 CloudFront Functions 以實作自訂驗證邏輯。
對於未設定 mTLS 時請求用戶端憑證的原始伺服器，CloudFront 會捨棄請求。
如需設定 mTLS 的詳細資訊，請參閱 [關聯 CloudFront 連線函數](connection-functions.md)。
CloudFront 不支援使用用戶端 SSL 憑證之用戶端身分驗證。如果原始伺服器請求用戶端憑證，CloudFront 會放棄請求。
### 壓縮
如需詳細資訊，請參閱 [提供壓縮檔案](ServingCompressedFiles.md)。
### 條件式請求
如果 CloudFront 收到請求，向邊緣快取要求已過期的物件，會將該請求轉送到原始伺服器，以取得物件的最新版本，或是從原始伺服器取得 CloudFront 邊緣快取已具有最新版本的確認。一般而言，當原始伺服器最後將物件到傳送到 CloudFront 時，會在回應中加入 `ETag` 值、`LastModified` 值，或是這兩個值。在 CloudFront 轉送到原始伺服器的新請求中，CloudFront 會加入下列其中一個或兩個項目：
+ 含有已過期版本物件 `If-Match` 值的 `If-None-Match` 或 `ETag` 標頭。
+ 含有已過期版本物件 `If-Modified-Since` 值的 `LastModified` 標頭。
原始伺服器使用此資訊來判斷物件是否已被更新，且因此是否需傳回整個物件至 CloudFront 或只傳回 HTTP 304 狀態碼 (而非修改)。
**注意**
若 CloudFront 設為轉送 Cookie (所有或子集)，則不支援 `If-Modified-Since` 和 `If-None-Match` 條件請求。
如需詳細資訊，請參閱[根據 Cookie 快取內容](Cookies.md)。
### Cookie
您可以設定 CloudFront 轉送 Cookie 至您的原始伺服器。如需詳細資訊，請參閱 [根據 Cookie 快取內容](Cookies.md)。
### 跨來源資源共享 (CORS)
如果想讓 CloudFront 遵循跨來源資源共享設定，請設定 CloudFront 將 `Origin` 標頭轉送到您的原始伺服器。如需詳細資訊，請參閱 [根據請求標頭快取內容](header-caching.md)。
### 加密
您可以要求檢視器使用 HTTPS 來將請求傳送至 CloudFront，並要求 CloudFront 使用檢視器所使用的通訊協定，將請求轉送給您的自訂原始伺服器。如需詳細資訊，請參閱下列分佈設定：
+ [檢視器通訊協定政策](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy)
+ [通訊協定 (僅限自訂原始伺服器)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy)
CloudFront 使用 SSLv3、TLSv1.0、TLSv1.1、TLSv1.2 和 TLSv1.3 通訊協定，轉送 HTTPS 請求至原始伺服器。對自訂原始伺服器，您可以選擇您希望 CloudFront 在與原始伺服器通訊時要使用的 SSL 通訊協定：
+ 如果使用 CloudFront 主控台，請透過勾選 **Origin SSL Protocols (原始伺服器 SSL 通訊協定)** 核取方塊，來選擇通訊協定。如需詳細資訊，請參閱 [建立分發](distribution-web-creating-console.md)。
+ 如果使用 CloudFront API，請利用 `OriginSslProtocols` 元素來指定通訊協定。如需詳細資訊，請參閱《Amazon CloudFront API 參考》**中的 [OriginSslProtocols](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginSslProtocols.html) 和 [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html)。
如果該原始伺服器是 Amazon S3 儲存貯體，則 CloudFront 預設使用 TLSv1.3。
**重要**
其他 SSL 和 TLS 的版本不支援。
如需有關使用 CloudFront 搭配 HTTPS 的詳細資訊，請參閱[透過 CloudFront 使用 HTTPS](using-https.md)。針對檢視器與 CloudFront 之間，以及 CloudFront 與原始伺服器之間的 HTTPS 通訊，如需 CloudFront 支援密碼的清單，請參閱[檢視器和 CloudFront 之間支援的通訊協定和密碼](secure-connections-supported-viewer-protocols-ciphers.md)。
### 包括本文的 GET 請求
如果檢視器的 `GET` 請求包含本文，CloudFront 會將 HTTP 狀態碼 403 (禁止) 傳回給檢視器。
### HTTP 方法
如果設定 CloudFront 處理其支援的所有 HTTP 方法，CloudFront 會接受從檢視器傳來的下列請求，然後將這些請求轉送到您的自訂原始伺服器：
+ `DELETE`
+ `GET`
+ `HEAD`
+ `OPTIONS`
+ `PATCH`
+ `POST`
+ `PUT`
CloudFront 一律會快取 `GET` 與 `HEAD` 請求的回應。您也可以設定 CloudFront 快取 `OPTIONS` 請求的回應。CloudFront 不會快取對使用其他方法之請求的回應。
如需有關設定您的自訂原始伺服器是否處理這些方法的詳細資訊，請參閱您的原始伺服器的文件。
**重要**
如果設定 CloudFront 接受 CloudFront 支援的所有 HTTP 方法，並將這些方法轉送到原始伺服器，請設定您的原始伺服器，來處理所有的方法。例如，如果因為想要使用 `POST`，而設定 CloudFront 接受和轉送這些方法，則您必須設定原始伺服器，以適當地處理 `DELETE` 請求，讓檢視器無法刪除您不希望其刪除的資源。如需詳細資訊，請參閱您的 HTTP 伺服器文件。
### HTTP 請求標頭和 CloudFront 行為 (自訂和 Amazon S3 原始伺服器)
下表列出可以轉送到自訂和 Amazon S3 原始伺服器的 HTTP 請求標頭 (已指明例外狀況)。對於每個標頭，該表包含下列資訊：
+ 未設定 CloudFront 將標頭轉送到原始伺服器時，CloudFront 的行為，此行為會讓 CloudFront 根據標頭值來快取物件。
+ 您是否可以設定 CloudFront 根據該標頭的標頭值來快取物件。
您可以設定 CloudFront 根據 `Date` 與 `User-Agent` 標頭中的值來快取物件，但我們不建議這麼做。這些標頭有許多可能的值，且根據其值進行快取可能導致 CloudFront 轉送更多請求到原始伺服器。
如需有關根據標頭值快取的詳細資訊，請參閱[根據請求標頭快取內容](header-caching.md)。
| 標頭 | 未設定 CloudFront 根據標頭值進行快取時的行為 | 支援根據標頭值進行快取 |
| --- | --- | --- |
| 其他定義的標頭 | **舊版快取設定** – CloudFront 轉送標頭至原始伺服器。 | 是 |
| `Accept` | CloudFront 移除標頭。 | 是 |
| `Accept-Charset` | CloudFront 移除標頭。 | 是 |
| `Accept-Encoding` | 如果該值包含 `gzip` 或 `br`，CloudFront 會將標準化 `Accept-Encoding` 標頭轉送給您的原始伺服器。 如需詳細資訊，請參閱 [壓縮支援](cache-key-understand-cache-policy.md#cache-policy-compressed-objects) 及 [提供壓縮檔案](ServingCompressedFiles.md)。 | 是 |
| `Accept-Language` | CloudFront 移除標頭。 | 是 |
| `Authorization` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html) | 是 |
| `Cache-Control` | CloudFront 轉送標頭至原始伺服器。 | 否 |
| `CloudFront-Forwarded-Proto` | CloudFront 在轉送請求至您的原始伺服器之前，不會加入標頭。 如需詳細資訊，請參閱 [根據請求的通訊協定設定快取](header-caching.md#header-caching-web-protocol)。 | 是 |
| `CloudFront-Is-Desktop-Viewer` | CloudFront 在轉送請求至您的原始伺服器之前，不會加入標頭。 如需詳細資訊，請參閱 [根據裝置類型設定快取](header-caching.md#header-caching-web-device)。 | 是 |
| `CloudFront-Is-Mobile-Viewer` | CloudFront 在轉送請求至您的原始伺服器之前，不會加入標頭。 如需詳細資訊，請參閱 [根據裝置類型設定快取](header-caching.md#header-caching-web-device)。 | 是 |
| `CloudFront-Is-Tablet-Viewer` | CloudFront 在轉送請求至您的原始伺服器之前，不會加入標頭。 如需詳細資訊，請參閱 [根據裝置類型設定快取](header-caching.md#header-caching-web-device)。 | 是 |
| `CloudFront-Viewer-Country` | CloudFront 在轉送請求至您的原始伺服器之前，不會加入標頭。 | 是 |
| `Connection` | CloudFront 在轉送請求至您的原始伺服器之前，以 `Connection: Keep-Alive` 取代此標頭。 | 否 |
| `Content-Length` | CloudFront 轉送標頭至原始伺服器。 | 否 |
| `Content-MD5` | CloudFront 轉送標頭至原始伺服器。 | 是 |
| `Content-Type` | CloudFront 轉送標頭至原始伺服器。 | 是 |
| `Cookie` | 如果設定 CloudFront 轉送 Cookie，此服務會將 `Cookie` 標頭欄位轉送給您的原始伺服器。如果未如此設定，CloudFront 會移除 `Cookie` 標頭欄位。如需詳細資訊，請參閱 [根據 Cookie 快取內容](Cookies.md)。 | 否 |
| `Date` | CloudFront 轉送標頭至原始伺服器。 | 可以，但不建議 |
| `Expect` | CloudFront 移除標頭。 | 是 |
| `From` | CloudFront 轉送標頭至原始伺服器。 | 是 |
| `Host` | CloudFront 將值設定為與請求的物件相關聯之原始伺服器的網域名稱。 您無法根據 Amazon S3 或 MediaStore 原始伺服器的主機標頭進行快取。 | 是 (自訂) 否 (S3 和 MediaStore) |
| `If-Match` | CloudFront 轉送標頭至原始伺服器。 | 是 |
| `If-Modified-Since` | CloudFront 轉送標頭至原始伺服器。 | 是 |
| `If-None-Match` | CloudFront 轉送標頭至原始伺服器。 | 是 |
| `If-Range` | CloudFront 轉送標頭至原始伺服器。 | 是 |
| `If-Unmodified-Since` | CloudFront 轉送標頭至原始伺服器。 | 是 |
| `Max-Forwards` | CloudFront 轉送標頭至原始伺服器。 | 否 |
| `Origin` | CloudFront 轉送標頭至原始伺服器。 | 是 |
| `Pragma` | CloudFront 轉送標頭至原始伺服器。 | 否 |
| `Proxy-Authenticate` | CloudFront 移除標頭。 | 否 |
| `Proxy-Authorization` | CloudFront 移除標頭。 | 否 |
| `Proxy-Connection` | CloudFront 移除標頭。 | 否 |
| `Range` | CloudFront 轉送標頭至原始伺服器。如需詳細資訊，請參閱 [CloudFront 如何處理物件的部分請求 (範圍 GET)](RangeGETs.md)。 | 是，根據預設。 |
| `Referer` | CloudFront 移除標頭。 | 是 |
| `Request-Range` | CloudFront 轉送標頭至原始伺服器。 | 否 |
| `TE` | CloudFront 移除標頭。 | 否 |
| `Trailer` | CloudFront 移除標頭。 | 否 |
| `Transfer-Encoding` | CloudFront 轉送標頭至原始伺服器。 | 否 |
| `Upgrade` | 除非您已建立 WebSocket 連線，否則 CloudFront 會移除標頭。 | 否 (WebSocket 連線除外) |
| `User-Agent` | CloudFront 以 `Amazon CloudFront` 取代此標頭欄位的值。如果您希望 CloudFront 根據使用者所使用的裝置來快取內容，請參閱[根據裝置類型設定快取](header-caching.md#header-caching-web-device)。 | 可以，但不建議 |
| `Via` | CloudFront 轉送標頭至原始伺服器。 | 是 |
| `Warning` | CloudFront 轉送標頭至原始伺服器。 | 是 |
| `X-Amz-Cf-Id` | CloudFront 在轉送請求至您的原始伺服器之前，將標頭加入檢視器。此標頭值包含可唯一識別請求的加密字串。 | 否 |
| `X-Edge-*` | CloudFront 會移除所有的 `X-Edge-*` 標頭。 | 否 |
| `X-Forwarded-For` | CloudFront 轉送標頭至原始伺服器。如需詳細資訊，請參閱 [用戶端 IP 位址](#RequestCustomIPAddresses)。 | 是 |
| `X-Forwarded-Proto` | CloudFront 移除標頭。 | 否 |
| `X-HTTP-Method-Override` | CloudFront 移除標頭。 | 是 |
| `X-Real-IP` | CloudFront 移除標頭。 | 否 |
### HTTP 版本
CloudFront 使用 HTTP/1.1 轉送請求到您的自訂原始伺服器。
### 最大請求長度和最大 URL 長度
請求的長度上限是 32，768 個位元組，包括路徑、查詢字串 （如果有的話） 和標頭。
CloudFront 從請求建構 URL。此 URL 的最大長度為 8192 位元組。
如果 URL 超過長度上限，CloudFront 會將 HTTP 狀態碼 414 (URI 太長） 傳回給檢視器。如果因為超過標頭大小而請求超過長度上限，CloudFront 會將 HTTP 狀態碼 494 傳回給檢視器。在這兩種情況下，CloudFront 會終止與檢視器的 TCP 連線。
### OCSP 裝訂
當檢視器提交對物件的 HTTPS 請求時，CloudFront 或檢視器都必須向憑證授權單位 (CA) 確認尚未撤銷網域的 SSL 憑證。OCSP 裝訂藉由讓 CloudFront 從 CA 驗證憑證和快取回應加速憑證驗證，所以用戶端不需要直接向 CA 驗證憑證。
當 CloudFront 收到針對同一個網域中物件的大量 HTTPS 請求時，OCSP 裝訂的效能提升會更加明顯。每個在 CloudFront 節點的伺服器必須提交單獨的驗證請求。當 CloudFront 收到針對同一個網域的大量 HTTPS 請求時，在節點中的每個伺服器很快就會收到來自 CA 的回應，伺服器可將此回應「裝釘」到 SSL 交握中的封包；當檢視器確認憑證為有效時，CloudFront 即可提供請求的物件。如果您的分佈無法取得在 CloudFront 節點更多的流量，新的請求更有可能被導向至尚未向 CA 驗證憑證的伺服器。在這種情況下，檢視器會單獨執行驗證步驟，而且 CloudFront 伺服器會提供物件。該 CloudFront 伺服器也會提交驗證請求至 CA，所以下一次收到包含相同網域名稱的請求時，會有來自 CA 的驗證回應。
### 持久性連線
當 CloudFront 從您的原始伺服器獲得回應時，會嘗試維持幾秒鐘連線，以確保在該段期間內另一個請求送達。維護持久性連線可節省重新建立 TCP 連線所需的時間，並為後續請求執行另一個 TLS 交握。
如需包括如何設定持續連線時間的詳細資訊，請參閱[保持連線逾時 (僅限自訂與 VPC 原始伺服器)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginKeepaliveTimeout)一節的[所有分佈設定參考](distribution-web-values-specify.md)。
### 通訊協定
CloudFront 根據下列項目轉送 HTTP 或 HTTPS 請求到原始伺服器：
+ 檢視器傳送請求到 CloudFront 的通訊協定 (HTTP 或 HTTPS)。
+ CloudFront 主控台中 **Origin Protocol Policy** (原始伺服器通訊協定政策) 欄位的值，或者，如果使用 CloudFront API，則為 `OriginProtocolPolicy` 複雜類型中的 `DistributionConfig` 元素。在 CloudFront 主控台中，選項為 **HTTP Only (僅限 HTTP)**、**HTTPS Only (僅限 HTTPS)** 與 **Match Viewer (配合檢視器)**。
如果指定 **HTTP Only (僅限 HTTP)** 或 **HTTPS Only (僅限 HTTPS)**，則無論檢視器請求中的通訊協定為何，CloudFront 都會使用指定的通訊協定，來將請求轉送到原始伺服器。
如果指定 **Match Viewer (配合檢視器)**，CloudFront 會使用檢視器請求中的通訊協定，來將請求轉送到原始伺服器。請注意 CloudFront 僅會在檢視器使用 HTTP 和 HTTPS 通訊協定發出請求時，快取物件一次。
**重要**
如果 CloudFront 使用 HTTPS 通訊協定來將請求轉送到原始伺服器，而且原始伺服器傳回無效的憑證或自簽憑證，CloudFront 會結束 TCP 連線。
如需有關如何使用 CloudFront 主控台更新分佈的詳細資訊，請參閱[更新分佈](HowToUpdateDistribution.md)。如需有關如何使用 CloudFront API 更新分佈的詳細資訊，請移至《Amazon CloudFront API 參考》**中的 [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)。
### 查詢字串
您可以設定 CloudFront 是否轉送查詢字串參數至您的原始伺服器。如需詳細資訊，請參閱 [根據查詢字串參數快取內容](QueryStringParameters.md)。
### 原始伺服器連線逾時和嘗試次數
「原始伺服器連線逾時」**是嘗試建立與原始伺服器連線時 CloudFront 所等待的秒數。
「原始伺服器連線嘗試次數」**是 CloudFront 嘗試連線至原始伺服器的次數。
這些設定共同決定了在容錯移轉至次要原始伺服器 (如果是原始伺服器群組) 或將錯誤回應傳回給檢視器之前，CloudFront 嘗試連線到原始伺服器的時間長度。依預設，CloudFront 會等待 30 秒 (嘗試 3 次，每次 10 秒)，然後再嘗試連線至次要原始伺服器或傳回錯誤回應。您可以指定較短的連線逾時、較少的嘗試次數或兩者，以縮短此時間。
如需詳細資訊，請參閱 [控制原始伺服器逾時和嘗試次數](high_availability_origin_failover.md#controlling-attempts-and-timeouts)。
### 原始伺服器回應逾時
「原始伺服器回應逾時」**，也稱為「原始伺服器讀取逾時」**或「原始伺服器請求逾時」**，適用於以下兩個數值：
+ 在將請求轉送到原始伺服器之後，CloudFront 等待回應的時間 (以秒為單位)。
+ CloudFront 在收到來自原始伺服器的回應封包後，並在接收下一個封包前所等待的時間 (以秒為單位)。
CloudFront 行為取決於檢視器請求的 HTTP 方法：
+ `GET` 與 `HEAD` 請求 – 如果原始伺服器在回應逾時期間未回應或是停止回應，CloudFront 會結束連線。如果指定的[原始伺服器連線嘗試次數](DownloadDistValuesOrigin.md#origin-connection-attempts)超過 1，CloudFront 會再次嘗試取得完整的回應。CloudFront 最多可嘗試 3 次，由「原始伺服器連線嘗試次數」**設定的值決定。如果原始伺服器在最後一次嘗試時未回應，則 CloudFront 在收到相同原始伺服器上內容的另一個請求之前不會再嘗試。
+ `DELETE`、`OPTIONS`、`PATCH`、`PUT` 及 `POST` 請求 – 如果在讀取逾時期間原始伺服器未回應，CloudFront 將會結束連線，並且不再嘗試聯絡原始伺服器。用戶端可以視需要重新提交請求。
如需詳細資訊，包括如何設定原始伺服器回應逾時，請參閱[回應逾時](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout)。
### 相同物件之同步請求 (請求折疊)
如果 CloudFront 邊緣節點收到對物件的請求，而且該物件目前不在快取中或快取物件已過期，CloudFront 會立即將該請求傳送到原始伺服器。不過，如果有對相同物件的同步請求，意即：如果在 CloudFront 接收到第一個請求之前，(具有相同快取金鑰) 其他相同物件的請求抵達邊緣節點，則在將其他請求轉送到原始伺服器之前，CloudFront 將暫停。此短暫的暫停有助於減輕原始伺服器的負載。暫停期間，CloudFront 會將原始伺服器請求的回應傳送至接收到的所有請求。這就是所謂的*請求摺疊*。在 CloudFront 日誌中，會將第一個請求識別為 `x-edge-result-type` 欄位中的 `Miss`，而崩潰的請求會識別為 `Hit`。如需有關 CloudFront 日誌的詳細資訊，請參閱 [CloudFront 和邊緣函數記錄](logging.md)。
CloudFront 只會摺疊共用[*快取金鑰*](understanding-the-cache-key.md)的請求。如果其他的請求沒有共用快取金鑰，(例如，因為您設定 CloudFront 根據請求標頭或查詢字串進行快取)，則 CloudFront 會將所有獨特的請求轉送到原始伺服器。
如果您想要防止所有請求摺疊，可使用受管快取政策 `CachingDisabled` (也可防止快取)。如需詳細資訊，請參閱[使用受管快取政策](using-managed-cache-policies.md)。
若您想防止特定物件的請求折疊，您可以將快取行為的最短 TTL 設為 0 *並*設定原始伺服器傳送 `Cache-Control: private`、`Cache-Control: no-store`、`Cache-Control: no-cache`、`Cache-Control: max-age=0` 或 `Cache-Control: s-maxage=0`。這些組態會增加原始伺服器的負載，並於 CloudFront 等待第一個請求的回應時，為暫停的同步請求引入額外的延遲。
**重要**
目前如果您在[快取政策](controlling-the-cache-key.md)、[原始伺服器請求政策](controlling-origin-requests.md)或舊版快取設定中啟用 Cookie 轉送，CloudFront 不支援請求摺疊。
### `User-Agent` 標頭
如果您希望 CloudFront 根據使用者使用以檢視內容的裝置來快取不同的物件版本，我們建議您設定 CloudFront，以將下列其中一或多個標頭轉送至自訂原始伺服器：
+ `CloudFront-Is-Desktop-Viewer`
+ `CloudFront-Is-Mobile-Viewer`
+ `CloudFront-Is-SmartTV-Viewer`
+ `CloudFront-Is-Tablet-Viewer`
根據 `User-Agent` 標頭值，CloudFront 將這些標頭值設定為 `true` 或 `false`，然後將請求轉送至原始伺服器。如果裝置屬於多個類別，一個以上的值可能是 `true`。例如，針對一些平板電腦裝置，CloudFront 可能將 `CloudFront-Is-Mobile-Viewer` 與 `CloudFront-Is-Tablet-Viewer` 同時設定為 `true`。如需有關如何設定 CloudFront 根據請求標頭進行快取的詳細資訊，請參閱[根據請求標頭快取內容](header-caching.md)。
您可以設定 CloudFront 根據 `User-Agent` 標頭中的值來快取物件，但我們不建議這麼做。`User-Agent` 標頭有許多可能的值，且根據這些值進行快取可能導致 CloudFront 轉送更多請求到原始伺服器。
如果未設定 CloudFront 根據 `User-Agent` 標頭中的值來快取物件，CloudFront 會在轉送請求到您的原始伺服器之前，加入具有下列值的 `User-Agent` 標頭：
`User-Agent = Amazon CloudFront`
無論檢視器所傳來的請求是否包含 `User-Agent` 標頭，CloudFront 都會加入此標頭。如果檢視器所傳來的請求包含 `User-Agent` 標頭，CloudFront 會移除此標頭。
## CloudFront 如何處理來自您的自訂原始伺服器的回應
瞭解 CloudFront 如何處理來自您的自訂原始伺服器的回應。
**Contents**
+ [`100 Continue` 回應](#Response100Continue)
+ [快取](#ResponseCustomCaching)
+ [已取消請求](#response-custom-canceled-requests)
+ [內容議價](#ResponseCustomContentNegotiation)
+ [Cookie](#ResponseCustomCookies)
+ [捨棄 TCP 連線](#ResponseCustomDroppedTCPConnections)
+ [CloudFront 移除或取代的 HTTP 回應標頭](#ResponseCustomRemovedHeaders)
+ [可快取檔案大小上限](#ResponseCustomMaxFileSize)
+ [原始伺服器無法使用](#ResponseCustomOriginUnavailable)
+ [重新引導](#ResponseCustomRedirects)
+ [`Transfer-Encoding` 標頭](#ResponseCustomTransferEncoding)
### `100 Continue` 回應
您的原始伺服器無法傳送一個以上的 100-Continue 回應給 CloudFront。在第一個 100-Continue 回應之後，CloudFront 會預期 HTTP 200 OK 回應。如果您的原始伺服器在第一個 100-Continue 回應之後傳送另一個回應，CloudFront 將傳回錯誤。
### 快取
+ 確保原始伺服器集為有效且為 `Date` 和 `Last-Modified` 標頭欄位準確的值。
+ CloudFront 通常會遵循原始伺服器回應中的 `Cache-Control: no-cache` 標頭。如需例外，請參閱[相同物件之同步請求 (請求折疊)](#request-custom-traffic-spikes)。
### 已取消請求
如果物件不在邊緣快取中，而且在 CloudFront 從原始伺服器取得物件之後，但尚未傳送請求的物件之前，檢視器就終止了工作階段 (例如，關閉瀏覽器)，則 CloudFront 不會在節點快取物件。
### 內容議價
如果您的原始伺服器在回應中傳回 `Vary:*`，而且對應快取行為的 **Minimum TTL (最短 TTL)** 值為 **0**，則 CloudFront 會快取物件，但仍會將對於該物件的每個後續請求，轉送到原始伺服器，以確認快取包含物件的最新版本。CloudFront 不包含任何條件式標頭，例如 `If-None-Match` 或 `If-Modified-Since`。因此，您的原始伺服器傳回物件至 CloudFront 以回應每個請求。
如果您的原始伺服器在回應中傳回 `Vary:*`，而且對應快取行為的 **Minimum TTL (最短 TTL)** 值是任何其他的值，則 CloudFront 會根據 `Vary`中的說明，來處理 [CloudFront 移除或取代的 HTTP 回應標頭](#ResponseCustomRemovedHeaders) 標頭。
### Cookie
如果您為快取行為啟用 Cookie，而且如果原始伺服器依物件傳回 Cookie 時，CloudFront 會快取物件和 Cookie。請注意，這可減少物件的快取能力。如需詳細資訊，請參閱 [根據 Cookie 快取內容](Cookies.md)。
### 捨棄 TCP 連線
如果在您的原始伺服器將物件傳回 CloudFront 時，CloudFront 與原始伺服器之間的 TCP 連線中斷，則 CloudFront 行為取決於您的原始伺服器是否在回應中包含 `Content-Length` 標頭：
+ **Content-Length 標頭** – CloudFront 會在從您的原始伺服器取得物件時，將物件傳回給檢視器。不過，如果 `Content-Length` 標頭的值不符合物件的大小，CloudFront 不會快取物件。
+ **Transfer-Encoding: Chunked** – CloudFront 會在從您的原始伺服器取得物件時，將物件傳回給檢視器。不過，如果區塊回應不完整，CloudFront 不會快取物件。
+ **沒有 Content-Length 標頭** – CloudFront 會將物件傳回給檢視器並進行快取，但物件可能會不完整。如果沒有 `Content-Length` 標頭，CloudFront 就無法判斷 TCP 連線中斷是意外的或刻意的。
我們建議您設定 HTTP 伺服器加入 `Content-Length` 標頭，來防止 CloudFront 只快取部分物件。
### CloudFront 移除或取代的 HTTP 回應標頭
在將原始伺服器傳來的回應轉送給檢視器之前，CloudFront 會移除或更新下列的標頭欄位：
+ `Set-Cookie` – 如果設定 CloudFront 轉送 Cookie，此服務會將 `Set-Cookie` 標頭欄位轉送給用戶端。如需詳細資訊，請參閱 [根據 Cookie 快取內容](Cookies.md)。
+ `Trailer`
+ `Transfer-Encoding` – 如果原始伺服器傳回此標頭欄位，CloudFront 會將此值設定為 `chunked`，再將回應傳回給檢視器。
+ `Upgrade`
+ `Vary` – 請注意以下各項：
+ 如果設定 CloudFront 將任何裝置特定的標頭，轉送到您的原始伺服器 (`CloudFront-Is-Desktop-Viewer`、`CloudFront-Is-Mobile-Viewer`、`CloudFront-Is-SmartTV-Viewer`、`CloudFront-Is-Tablet-Viewer`)，而且設定原始伺服器將 `Vary:User-Agent` 傳回給 CloudFront，則 CloudFront 會將 `Vary:User-Agent` 傳回給檢視器。如需詳細資訊，請參閱 [根據裝置類型設定快取](header-caching.md#header-caching-web-device)。
+ 如果設定原始伺服器，在 `Accept-Encoding` 標頭中加入 `Cookie` 或 `Vary`，則 CloudFront 會在給檢視器的回應中加入這些值。
+ 如果您設定 CloudFront 將標頭轉送到原始伺服器，並且設定原始伺服器將 `Vary` 標頭中的標頭名稱傳回給 CloudFront (例如，`Vary:Accept-Charset,Accept-Language`)，則 CloudFront 會將 `Vary` 標頭及這些值傳回給瀏覽者。
+ 如需有關 CloudFront 如何處理 `*` 標頭中 `Vary` 值的詳細資訊，請參閱[內容議價](#ResponseCustomContentNegotiation)。
+ 如果設定原始伺服器在 `Vary` 標頭中加入其他任何值，CloudFront 會移除這些值，再將回應傳回給檢視器。
+ `Via` – CloudFront 在對檢視器的回應中將值設為以下值：
`Via: `*http-版本* *英數-字串*`.cloudfront.net (CloudFront)`
值的範例如下所示：
`Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)`
### 可快取檔案大小上限
CloudFront 在快取中儲存的回應內文大小上限為 50 GB。此包含未指定 `Content-Length` 標頭值的區塊傳輸回應。
使用範圍請求方法來請求每個部分為 50 GB 或更小的多部分物件，即可使用 CloudFront 快取大於此大小的物件。CloudFront 會快取這些部分，因為每個部分皆為 50 GB 或更小。檢視器擷取物件的所有部分之後，就可以重建原始、較大的物件。如需詳細資訊，請參閱 [使用範圍請求快取大物件](RangeGETs.md#cache-large-objects-with-range-requests)。
### 原始伺服器無法使用
如果您的原始伺服器無法使用，而且 CloudFront 收到了請求，要求邊緣快取中已過期的物件 (例如，因為 `Cache-Control max-age` 指令中所指定的期間已過)，則 CloudFront 會提供該物件已過期的版本，或是提供自訂的錯誤頁面。如需有關已設定自訂錯誤頁面時 CloudFront 行為的詳細資訊，請參閱[當您已設定自訂錯誤頁面時，CloudFront 如何處理錯誤](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages)。
在某些情況下，很少請求的物件會被移出並在節點快取中不可再用。CloudFront 無法提供已移出的物件。
### 重新引導
如果您在原始伺服器中變更物件的位置，您可以設定您的 Web 伺服器重新引導請求至新的位置。在您設定重新引導之後，檢視器第一次提交對物件的請求時，CloudFront 會傳送請求到原始伺服器，而原始伺服器會以重新引導回應 (例如 `302 Moved Temporarily`)。CloudFront 會快取此重新引導並傳回給檢視器。CloudFront 不會遵循重新引導。
您可以設定您的 Web 伺服器重新引導請求以下其中一個位置：
+ 在原始伺服器中物件的新 URL。當檢視器遵循重新引導到新 URL 時，檢視器會略過 CloudFront 並直接至原始伺服器。因此，我們建議您不要重新引導請求到原始伺服器中物件的新 URL。
+ 物件的新 CloudFront URL。如果檢視器提交請求，其中包含新的 CloudFront URL，CloudFront 會從原始伺服器上的新位置取得物件、在節點快取該物件，然後將物件傳回給檢視器。物件的後續請求會被節點提供。這可避免與從原始伺服器檢視器請求的物件有關的延遲和負載。然而，物件的每個新請求將會產生為兩個請求至 CloudFront 的費用。
### `Transfer-Encoding` 標頭
CloudFront 只支援 `chunked` 標頭的 `Transfer-Encoding` 值。如果您的原始伺服器傳回 `Transfer-Encoding: chunked`，CloudFront 會在節點收到物件時，將物件傳回到用戶端，並以區塊格式快取物件，來回應後續的請求。
如果檢視器提出 `Range GET` 請求，而原始伺服器傳回 `Transfer-Encoding: chunked`，CloudFront 會將整個物件 (而非請求的範圍) 傳回至檢視器。
如果您無法預定回應內容的長度，我們建議您使用區塊編碼。如需詳細資訊，請參閱 [捨棄 TCP 連線](#ResponseCustomDroppedTCPConnections)。
# 原始伺服器群組的請求和回應行為
請求原始群組的運作方式與請求未設為原始群組的原始伺服器的運作方式相同，但存在原始伺服器容錯移轉時例外。與任何其他原始伺服器相同，當 CloudFront 收到請求且內容已在節點遭到快取時，會從快取將內容提供給檢視器。當發生命中遺漏時，會將檢視器請求轉送到原始伺服器群組中的主要原始伺服器。
主要原始伺服器的請求和回應行為是相同的，因為它是針對不在原始伺服器群組中的原始伺服器。如需詳細資訊，請參閱 [Amazon S3 原始伺服器之請求和回應行為](RequestAndResponseBehaviorS3Origin.md) 及 [為自訂原始伺服器之請求和回應行為](RequestAndResponseBehaviorCustomOrigin.md)。
以下描述當主要原始伺服器傳回特定 HTTP 狀態碼時，原始伺服器容錯移轉的行為：
+ HTTP 2xx 狀態碼 (成功)：CloudFront 快取檔案並傳回給檢視器。
+ HTTP 3xx 狀態碼 (重新引導)：CloudFront 將狀態碼傳回給檢視器。
+ HTTP 4xx 和 5xx 狀態碼 (用戶端/伺服器錯誤)：如果已針對容錯移轉設定傳回的狀態碼，則 CloudFront 會傳送相同的請求到原始伺服器群組中的次要原始伺服器。
+ HTTP 4xx 和 5xx 狀態碼 (用戶端/伺服器錯誤)：如果未針對容錯移轉設定傳回的狀態碼，則 CloudFront 會將錯誤傳回給檢視器。
只有當檢視器請求的 HTTP 方法為 `GET`、`HEAD` 或 `OPTIONS` 時，CloudFront 才會容錯移轉至次要原始伺服器。當檢視器傳送不同的 HTTP 方法 (例如，`POST`、`PUT` 等等) 時，CloudFront 不會容錯移轉。
當 CloudFront 將請求傳送到次要原始伺服器時，回應行為與不在原始伺服器群組中的 CloudFront 原始伺服器相同。
如需原始伺服器群組的詳細資訊，請參閱[透過 CloudFront 原始伺服器容錯移轉最佳化高可用性](high_availability_origin_failover.md)。
# 將自訂標頭新增到原始伺服器請求
您可以將 CloudFront 配置為將自訂標頭新增到傳送給您原始伺服器的請求。您可以使用自訂標頭傳送並收集來自原始伺服器的資訊，該資訊無法透過一般檢視器請求取得。您甚至可以針對每個原始伺服器自訂標頭。CloudFront 支援自訂原始伺服器和 Amazon S3 原始伺服器的自訂標頭。
**Contents**
+ [使用案例](#add-origin-custom-headers-use-cases)
+ [設定 CloudFront 以將自訂標頭新增到原始伺服器請求](#add-origin-custom-headers-configure)
+ [CloudFront 無法新增到原始伺服器請求的自訂標頭](#add-origin-custom-headers-denylist)
+ [設定 CloudFront 以轉送 `Authorization` 標頭](#add-origin-custom-headers-forward-authorization)
## 使用案例
您可以使用自訂標頭，例如下列範例：
**識別來自 CloudFront 的請求**
您可以識別原始伺服器從 CloudFront 收到的請求。如果您想知道使用者正繞過 CloudFront，還是您正使用多個 CDN，並且想知道來自每個 CDN 的請求的資訊，這會是很實用的方法。
如果您使用的是 Amazon S3 原始伺服器，並且啟用 [Amazon S3 伺服器存取記錄](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)，則日誌不包含標頭資訊。
**判斷哪些請求是來自特定分發**
如果您將多個 CloudFront 分發配置為使用同一個原始伺服器，您可以在每個分發中新增不同的自訂標頭。然後，您可以使用來自原始伺服器的日誌，判斷哪些請求來自哪個 CloudFront 分發。
**啟用跨來源資源分享 (CORS)**
如果某些檢視器不支援跨原始伺服器資源分享 (CORS)，您可以將 CloudFront 配置為一律將 `Origin` 標頭新增到傳送給您原始伺服器的請求。接著，您可以將原始伺服器設定為針對每個請求傳回 `Access-Control-Allow-Origin` 標頭。您也必須[配置 CloudFront ，才能遵循 CORS 設定](header-caching.md#header-caching-web-cors)。
**控制內容的存取**
您可以使用自訂標頭來控制內容的存取。您可以將原始伺服器配置為只有在包含 CloudFront 所新增的自訂標頭時才回應請求，藉此防止使用者繞過 CloudFront 並直接在原始伺服器上存取您的內容。如需詳細資訊，請參閱[在自訂原始伺服器上限制存取檔案](private-content-overview.md#forward-custom-headers-restrict-access)。
## 設定 CloudFront 以將自訂標頭新增到原始伺服器請求
若要將分佈設定為將自訂標頭新增到傳送給您原始伺服器的請求，請使用下列其中一種方法來更新原始伺服器設定：
+ **CloudFront 主控台** – 當您建立或更新分佈時，請在**新增自訂標頭**設定中，指定標頭的名稱和值。如需詳細資訊，請參閱[新增自訂標頭](DownloadDistValuesOrigin.md#DownloadDistValuesOriginCustomHeaders)。
+ **CloudFront API** – 針對您要為其新增自訂標頭的每個原始伺服器，在 `Origin` 內的 `CustomHeaders` 欄位中指定標頭名稱和值。如需詳細資訊，請參閱《Amazon CloudFront API 參考》**中的 [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) 或 [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)。
如果您指定的標頭名稱和值尚未出現在檢視器請求中，CloudFront 會將它們新增到原始伺服器請求中。如果存在標頭，則在將請求轉送到原始伺服器之前，CloudFront 將覆寫標頭值。
如需套用至原始伺服器自訂標頭的配額，請參閱 [標頭的配額](cloudfront-limits.md#limits-custom-headers)。
## CloudFront 無法新增到原始伺服器請求的自訂標頭
您無法將 CloudFront 配置為將任何以下標頭新增到傳送給您原始伺服器的請求：
+ `Cache-Control`
+ `Connection`
+ `Content-Length`
+ `Cookie`
+ `Host`
+ `If-Match`
+ `If-Modified-Since`
+ `If-None-Match`
+ `If-Range`
+ `If-Unmodified-Since`
+ `Max-Forwards`
+ `Pragma`
+ `Proxy-Authenticate`
+ `Proxy-Authorization`
+ `Proxy-Connection`
+ `Range`
+ `Request-Range`
+ `TE`
+ `Trailer`
+ `Transfer-Encoding`
+ `Upgrade`
+ `Via`
+ 以 `X-Amz-` 做為開頭的標頭
+ 以 `X-Edge-` 做為開頭的標頭
+ `X-Real-Ip`
## 設定 CloudFront 以轉送 `Authorization` 標頭
當 CloudFront 將檢視器請求轉送至您的原始伺服器時，CloudFront 預設會移除某些檢視器標頭，包括 `Authorization` 標頭。為了確保您的原始伺服器始終收到原始伺服器請求中的 `Authorization` 標頭，您有以下選項：
+ 使用快取政策將 `Authorization` 標頭新增至快取金鑰。快取金鑰中的所有標頭都會自動包含在原始伺服器請求中。如需詳細資訊，請參閱[使用政策控制快取金鑰](controlling-the-cache-key.md)。
+ 使用將所有檢視器標頭轉寄至原始伺服器的原始伺服器請求政策。您無法在原始伺服器請求政策中個別轉寄 `Authorization` 標頭，但當您轉寄所有檢視器標頭時，CloudFront 會在檢視器請求中包含 `Authorization` 標頭。CloudFront 為此使用案例提供受管的原始伺服器請求政策，稱為 **Managed-AllViewer**。如需詳細資訊，請參閱[使用受管原始伺服器請求政策](using-managed-origin-request-policies.md)。
# CloudFront 如何處理物件的部分請求 (範圍 GET)
針對大型物件，檢視器 (Web 瀏覽器或用戶端) 可能提出多個 `GET` 請求，並使用 `Range` 請求標頭下載分為多個較小部分的物件。這些位元範圍的請求，有時稱為 `Range GET` 請求，改善部分下載的效率與從部分失敗的傳輸復原。
當 CloudFront 收到 `Range GET` 請求時，會檢查收到請求之節點中的快取。如果節點中的快取已包含整個物件或物件的請求部分，則 CloudFront 會立即從快取提供請求的範圍。
如果快取不包含請求的範圍，則 CloudFront 會轉送請求到原始伺服器。(若要最佳化效能，CloudFront 請求的範圍可能會比用戶端在 `Range GET` 中請求的更大。) 接下來，會發生什麼狀況取決於原始伺服器是否支援 `Range GET` 請求：
+ **如果原始伺服器支援 `Range GET` 請求**：會傳回請求的範圍。CloudFront 會提供請求的範圍，並同時進行快取來回應未來的請求。(如同許多 HTTP 伺服器一樣，Amazon S3 支援 `Range GET` 請求。)
+ **如果原始伺服器不支援 `Range GET` 請求**：會傳回整個物件。CloudFront 會針對目前的請求傳送整個物件，並同時進行快取來回應未來的請求。CloudFront 在邊緣快取中快取整個物件之後，會提供請求的範圍以回應新的 `Range GET` 請求。
在這兩種情況下，只要第一位元組從原始伺服器送達，CloudFront 就會立即開始提供請求的範圍或物件給最終使用者。
**注意**
如果檢視器提出 `Range GET` 請求，而原始伺服器傳回 `Transfer-Encoding: chunked`，CloudFront 會將整個物件 (而非請求的範圍) 傳回至檢視器。
一般來說，CloudFront 遵循適用於 `Range` 標頭的 RFC 規格。但是，如果您的 `Range` 標頭未遵循下列要求，CloudFront 會傳回包含完整物件的 HTTP 狀態碼 `200`，而非包含指定範圍的狀態碼 `206`：
+ 必須以遞增順序列出的範圍。例如，`100-200,300-400` 是有效的，`300-400,100-200` 是無效的。
+ 範圍不得重疊。例如，`100-200,150-250` 是無效的。
+ 所有範圍規格必須有效。例如，您無法指定負值為範圍的一部分。
如需 `Range` 請求標頭的更多資訊，請參閱 RFC 7233 中的[範圍請求](https://httpwg.org/specs/rfc7233.html#range.requests)，或者參閱 MDN Web 文件中的[範圍](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range)。
## 使用範圍請求快取大物件
啟用快取時，CloudFront 不會擷取或快取大於 50 GB 的物件。當原始伺服器指出物件大於此大小時 (在 `Content-Length` 回應標頭中)，CloudFront 會關閉與原始伺服器的連線，並傳回錯誤給檢視器。(停用快取時，CloudFront 可以從原始伺服器擷取大於此大小的物件，並將其傳遞給檢視器。但是，CloudFront 不會快取物件。)
然而，藉助範圍請求，您可以使用 CloudFront 來快取大於[可快取檔案大小上限](cloudfront-limits.md#limits-web-distributions)的物件。
**Example 範例**
1. 考慮具有 100 GB 物件的原始伺服器。啟用快取時，CloudFront 不會擷取或快取如此大的物件。不過，檢視器可以傳送多個範圍請求，以擷取多個部分的物件，其中每個部分都小於 50 GB。
1. 檢視器可以請求包含 20 GB 部分的物件，方法是傳送帶有標頭 `Range: bytes=0-21474836480` 的請求來擷取第一個部分，然後傳送帶有標頭 `Range: bytes=21474836481-42949672960` 的另一個請求來擷取下一個部分，依此類推。
1. 檢視器收到所有的部分之後，它可以將這些部分組合起來建構原始的 100 GB 物件。
1. 在此情況下，CloudFront 會快取物件的每個 20 GB 部分，並且可以回應快取中相同部分的後續要求。
對於壓縮物件的範圍請求，位元組範圍請求是根據壓縮大小，而不是物件的原始大小。如需壓縮檔案的相關資訊，請參閱 [提供壓縮檔案](ServingCompressedFiles.md)。
# CloudFront 如何處理來自原始伺服器的 HTTP 3xx 狀態碼。
當 CloudFront 向您的 Amazon S3 儲存貯體或自訂原始伺服器請求物件時，原始伺服器有時會傳回 HTTP 3xx 狀態碼。這通常代表下列其中一項：
+ 物件的 URL 已變更 (例如，狀態碼 301、302、307 或 308)
+ 自上次 CloudFront 請求該物件以來，該物件不曾變更過 (狀態碼 304)
CloudFront 會根據您的 CloudFront 分佈中的設定和回應中的標頭來快取 3xx 回應。只有在您將 `Cache-Control` 標頭包含在原始伺服器回應中時，CloudFront 才會快取 307 和 308 回應。如需詳細資訊，請參閱[管理內容保持在快取中達多久時間 (過期)](Expiration.md)。
如果您的原始伺服器傳回重新引導狀態碼 (例如，301 或 307)，CloudFront 就不會遵循重新引導。CloudFront 會沿著 301 或 307 回應傳遞至檢視器，而檢視器可以透過傳送新的請求來遵循重新引導。
# CloudFront 如何處理來自原始伺服器的 HTTP 4xx 和 5xx 狀態碼
當 CloudFront 向您的 Amazon S3 儲存貯體或自訂原始伺服器請求物件時，您的原始伺服器有時會傳回 HTTP 4xx 或 5xx 狀態碼，這表示錯誤已發生。CloudFront 行為取決於：
+ 您是否已設定自訂錯誤頁面
+ 您是否已設定讓 CloudFront 快取原始伺服器錯誤回應的時間長度 (錯誤快取最短 TTL)
+ 狀態碼
+ 對於 5xx 狀態碼，請求的物件目前是否在 CloudFront 邊緣快取
+ 對於某些 4xx 狀態代碼，原始伺服器是否傳回 `Cache-Control max-age` 或 `Cache-Control s-maxage` 標頭
CloudFront 一律會快取 `GET` 與 `HEAD` 請求的回應。您也可以設定 CloudFront 快取 `OPTIONS` 請求的回應。CloudFront 不會快取對使用其他方法之請求的回應。
如果原始伺服器未回應，原始伺服器的 CloudFront 請求則會逾時，而此逾時會被視為是原始伺服器的 HTTP 5xx 錯誤，即使原始伺服器未以該錯誤回應。在這種情況下，CloudFront 會繼續提供快取內容。如需詳細資訊，請參閱 [原始伺服器無法使用](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomOriginUnavailable)。
如果您已啟用記錄日誌，則不論 HTTP 狀態碼為何，CloudFront 都會將結果寫入日誌。
如需與從 CloudFront 傳回之錯誤訊息相關的詳細功能和選項資訊，請查看以下內容：
+ 如需有關 CloudFront 主控台中自訂錯誤頁面設定的詳細資訊，請參閱[自訂錯誤頁面和錯誤快取](DownloadDistValuesErrorPages.md)。
+ 如需有關 CloudFront 主控台中錯誤快取最短 TTL 的詳細資訊，請參閱[錯誤快取最短 TTL (秒)](DownloadDistValuesErrorPages.md#DownloadDistValuesErrorCachingMinTTL)。
+ 如需 CloudFront 快取的 HTTP 狀態碼清單，請參閱 [CloudFront 快取的 HTTP 4xx 和 5xx 狀態碼](#HTTPStatusCodes-cached-errors)。
**Topics**
+ [當您已設定自訂錯誤頁面時，CloudFront 如何處理錯誤](#HTTPStatusCodes-custom-error-pages)
+ [您尚未設定自訂錯誤頁面時 CloudFront 如何處理錯誤](#HTTPStatusCodes-no-custom-error-pages)
+ [CloudFront 快取的 HTTP 4xx 和 5xx 狀態碼](#HTTPStatusCodes-cached-errors)
## 當您已設定自訂錯誤頁面時，CloudFront 如何處理錯誤
如果您已設定自訂錯誤頁面，CloudFront 行為取決於請求的物件是否在邊緣快取中。
### 請求的物件不在邊緣快取中
CloudFront 會在下列所有情況皆成立時，繼續嘗試從您的原始伺服器取得請求的物件：
+ 一個檢視器請求了一個物件。
+ 該物件未在節點快取中。
+ 您的原始伺服器會傳回 HTTP 4xx 或 5xx 狀態碼，且下列其中一項為真：
+ 您的原始伺服器會傳回 HTTP 5xx 狀態碼，而不傳回 304 狀態碼 (未修改) 或物件的更新版本。
+ 您的原始伺服器會傳回 HTTP 4xx 狀態碼，且不限於快取控制標頭，並包含在以下狀態碼清單中：[CloudFront 快取的 HTTP 4xx 和 5xx 狀態碼](#HTTPStatusCodes-cached-errors)。
+ 您的原始伺服器會傳回包含 `Cache-Control max-age` 標頭或 `Cache-Control s-maxage` 標頭的 HTTP 4xx 狀態碼，且該狀態碼包含在以下狀態碼清單中：控制 [CloudFront 根據 `Cache-Control` 標頭快取的 HTTP 4xx 狀態碼](#HTTPStatusCodes-cached-errors-with-cache-control)。
**CloudFront 會執行下列作業：**
1. 在收到檢視器請求的 CloudFront 邊緣快取中，CloudFront 會檢查您的分佈設定，並取得自訂錯誤頁面的路徑，此頁面對應於原始伺服器所傳回的狀態碼。
1. CloudFront 在有相符自訂錯誤頁面路徑的路徑模式之分佈中找到第一個快取行為。
1. CloudFront 節點將自訂錯誤頁面的請求傳送到快取行為中指定的原始伺服器。
1. 原始伺服器傳回自訂錯誤頁面至節點。
1. CloudFront 將自訂錯誤頁面傳回至提出請求的檢視器，並同時快取自訂錯誤頁面達以下最大值：
+ 由錯誤快取最短 TTL (預設為 10 秒) 指定的時間數
+ 當第一個請求產生錯誤時，由原始伺服器傳回，並由 `Cache-Control max-age` 標頭或 `Cache-Control s-maxage` 標頭指定的時間量
1. 在快取時間 (於步驟 5 中決定) 經過之後，CloudFront 會藉由將另一個請求轉送到您的原始伺服器，再次嘗試取得請求的物件。CloudFront 會根據錯誤快取最短 TTL 指定的間隔，繼續進行重試。
**注意**
如果您也為相同的自訂錯誤頁面設定快取行為，CloudFront 會改用快取行為 TTL。在此情況下，CloudFront 會針對步驟 5 和 6 執行下列動作：
CloudFront 將自訂錯誤頁面傳回給提出請求的檢視器後，CloudFront 會檢查快取行為 TTL (例如您將預設 TTL 設定為 5 秒)。然後 CloudFront 會快取自訂錯誤頁面至該上限。
經過 5 秒後，CloudFront 會再次從原始伺服器擷取自訂錯誤頁面。CloudFront 會根據快取行為 TTL 指定的間隔繼續進行重試。
如需更多詳細資訊，請參閱 [TTL 設定](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL)中的快取行為。
### 請求的物件在邊緣快取中
當下列所有情況皆成立時，CloudFront 會繼續提供目前在邊緣快取中的物件：
+ 一個檢視器請求了一個物件。
+ 物件在節點快取但已過期
+ 您的原始伺服器會傳回 HTTP 5xx 狀態碼，而不傳回 304 狀態碼 (未修改) 或物件的更新版本。
**CloudFront 會執行下列作業：**
1. 如果您的原始伺服器傳回 5xx 狀態碼，即使物件已過期，CloudFront 仍會提供物件。在錯誤快取最短 TTL 期間，CloudFront 會藉由從邊緣快取提供物件來繼續回應檢視器的請求。
如果您的原始伺服器傳回 4xx 狀態碼，CloudFront 會將狀態碼 (而非請求的物件) 傳回給檢視器。
1. 在錯誤快取最低 TTL 經過之後，CloudFront 會藉由將另一個請求轉送到您的原始伺服器，再次嘗試取得請求的物件。請注意，如果未經常請求物件，CloudFront 可能會在您的原始伺服器仍然傳回 5xx 回應時，將該物件從邊緣快取移出。如需有關物件在 CloudFront 邊緣快取中留存時間長度的詳細資訊，請參閱[管理內容保持在快取中達多久時間 (過期)](Expiration.md)。
## 您尚未設定自訂錯誤頁面時 CloudFront 如何處理錯誤
如果您沒有設定自訂錯誤頁面，CloudFront 行為取決於請求的物件是否在邊緣快取中。
**Topics**
+ [請求的物件不在邊緣快取中](#HTTPStatusCodes-no-custom-error-pages-not-in-cache)
+ [請求的物件在邊緣快取中](#HTTPStatusCodes-no-custom-error-pages-in-cache)
### 請求的物件不在邊緣快取中
CloudFront 會在下列所有情況皆成立時，繼續嘗試從您的原始伺服器取得請求的物件：
+ 一個檢視器請求了一個物件。
+ 該物件未在節點快取中。
+ 您的原始伺服器會傳回 HTTP 4xx 或 5xx 狀態碼，且下列其中一項為真：
+ 您的原始伺服器會傳回 HTTP 5xx 狀態碼，而不傳回 304 狀態碼 (未修改) 或物件的更新版本。
+ 您的原始伺服器會傳回 HTTP 4xx 狀態碼，且不限於快取控制標頭，並包含在以下狀態碼清單中：[CloudFront 快取的 HTTP 4xx 和 5xx 狀態碼](#HTTPStatusCodes-cached-errors)
+ 您的原始伺服器會傳回包含 `Cache-Control max-age` 標頭或 `Cache-Control s-maxage` 標頭的 HTTP 4xx 狀態碼，且該狀態碼包含在以下狀態碼清單中：控制 [CloudFront 根據 `Cache-Control` 標頭快取的 HTTP 4xx 狀態碼](#HTTPStatusCodes-cached-errors-with-cache-control)。
CloudFront 會執行下列作業：
1. CloudFront 會將 4xx 或 5xx 狀態碼傳回給檢視器，並同時在收到請求的邊緣快取中快取狀態碼達以下最大值：
+ 由錯誤快取最短 TTL (預設為 10 秒) 指定的時間數
+ 當第一個請求產生錯誤時，由原始伺服器傳回，並由 `Cache-Control max-age` 標頭或 `Cache-Control s-maxage` 標頭指定的時間量
1. 在快取時間 (於步驟 1 中決定) 期間，CloudFront 會以快取的 4xx 或 5xx 狀態碼，回應對相同物件的後續檢視器請求。
1. 在快取時間 (於步驟 1 中決定) 經過之後，CloudFront 會藉由將另一個請求轉送到您的原始伺服器，再次嘗試取得請求的物件。CloudFront 會根據錯誤快取最短 TTL 指定的間隔，繼續進行重試。
### 請求的物件在邊緣快取中
當下列所有情況皆成立時，CloudFront 會繼續提供目前在邊緣快取中的物件：
+ 一個檢視器請求了一個物件。
+ 物件在節點快取但已過期 這表示物件已*過時*。
+ 您的原始伺服器會傳回 HTTP 5xx 狀態碼，而不傳回 304 狀態碼 (未修改) 或物件的更新版本。
CloudFront 會執行下列作業：
1. 如果您的原始伺服器傳回 5xx 錯誤碼，即使物件已過期，CloudFront 仍會提供物件。在錯誤快取最短 TTL (預設 10 秒) 期間，CloudFront 會藉由從邊緣快取提供物件來繼續回應檢視器的請求。
如果您的原始伺服器傳回 4xx 狀態碼，CloudFront 會將狀態碼 (而非請求的物件) 傳回給檢視器。
1. 在錯誤快取最低 TTL 經過之後，CloudFront 會藉由將另一個請求轉送到您的原始伺服器，再次嘗試取得請求的物件。如果未經常請求物件，CloudFront 可能會在您的原始伺服器仍然傳回 5xx 回應時，將該物件從邊緣快取移出。如需詳細資訊，請參閱[管理內容保持在快取中達多久時間 (過期)](Expiration.md)。
**提示**
如果您設定 `stale-if-error` 或 `Stale-While-Revalidate` 指令，可以指定過時物件在邊緣快取中可用的時間長度。這可讓您繼續為檢視器提供內容，即使您的原始伺服器無法使用。如需相關資訊，請參閱[提供過時 (過期) 內容](Expiration.md#stale-content)。
CloudFront 只會提供已過時達到指定[最大 TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) 值的物件。在此持續時間之後，物件將無法從邊緣快取使用。
## CloudFront 快取的 HTTP 4xx 和 5xx 狀態碼
視傳回的特定狀態碼，以及您的原始伺服器是否在回應中傳回特定標頭而定，CloudFront 會快取您的原始伺服器所傳回的 HTTP 4xx 和 5xx 狀態碼。
CloudFront 會快取您原始伺服器所傳回的下列 HTTP 4xx 和 5xx 狀態碼。如果您為 HTTP 狀態碼設定了自訂錯誤頁面，CloudFront 會快取自訂錯誤頁面。
**注意**
如果您使用的是 [CachingDisabled](using-managed-cache-policies.md#managed-cache-policy-caching-disabled) 受管快取政策，CloudFront 不會快取這些狀態碼或自訂錯誤頁面。
| | |
| --- |--- |
| 404 | 找不到 |
| 414 | URI 請求過大。 |
| 500 | 內部伺服器錯誤 |
| 501 | 未導入 |
| 502 | 無效的閘道 |
| 503 | 服務無法使用 |
| 504 | 閘道逾時 |
### CloudFront 根據 `Cache-Control` 標頭快取的 HTTP 4xx 狀態碼
如果您的原始伺服器傳回 `Cache-Control max-age` 或 `Cache-Control s-maxage` 標頭，則 CloudFront 只會快取您原始伺服器所傳回的下列 HTTP 4xx 狀態碼。如果您為其中一個 HTTP 狀態碼設定了自訂錯誤頁面 (而且您的原始伺服器傳回其中一個快取控制標頭)，則 CloudFront 會快取自訂錯誤頁面。
| | |
| --- |--- |
| 400 | 錯誤的請求。 |
| 403 | 禁止 |
| 405 | 方法不允許 |
| 412¹ | 先決條件失敗 |
| 415¹ | 不支援的媒體類型 |
¹CloudFront 不支援為這些 HTTP 狀態碼建立自訂錯誤頁面。
# 產生自訂錯誤回應
如果透過 CloudFront 提供的物件出於某些原因無法使用，則 Web 伺服器通常會傳回相關的 HTTP 狀態碼到 CloudFront，以指明此情形。例如若檢視器請求無效的 URL，則 Web 伺服器會傳回 HTTP 404 (找不到) 狀態碼到 CloudFront，然後 CloudFront 會傳回該狀態碼給檢視器。您可以建立 CloudFront 傳回給檢視器的自訂錯誤回應，而不是使用此預設錯誤回應。
如果您設定 CloudFront 傳回 HTTP 狀態碼的自訂錯誤頁面，但自訂錯誤頁面不可用，則 CloudFront 傳回 CloudFront 從包含自訂錯誤頁面的原始伺服器接收到的狀態碼給檢視器。例如，假設您的自訂原始伺服器會傳回一個 500 狀態碼且您已配置 CloudFront 以從 Amazon S3 儲存貯體取得 500 狀態碼的自訂錯誤頁面。不過有人不小心從 Amazon S3 儲存貯體刪除了自訂錯誤頁面。CloudFront 會傳回 HTTP 404 狀態碼 (找不到) 到請求物件的檢視器。
當 CloudFront 傳回自訂錯誤頁面給檢視器時，您支付自訂錯誤頁面的標準 CloudFront 費用，而非請求的物件費用。如需 CloudFront 費用的詳細資訊，請參閱 [Amazon CloudFront 定價](https://aws.amazon.com/cloudfront/pricing/)。
**Topics**
+ [設定錯誤回應行為](custom-error-pages-procedure.md)
+ [針對特定的 HTTP 狀態碼建立自訂錯誤頁面](creating-custom-error-pages.md)
+ [將物件和自訂錯誤頁面存放在不同位置](custom-error-pages-different-locations.md)
+ [變更 CloudFront 傳回的回應碼](custom-error-pages-response-code.md)
+ [控制 CloudFront 快取錯誤的時間長度](custom-error-pages-expiration.md)
# 設定錯誤回應行為
您可透過幾種選項來管理 CloudFront 在發生錯誤時的回應方式。若要設定自訂錯誤回應，您可以使用 CloudFront 主控台、CloudFront API 或 CloudFormation。無論您選擇如何更新組態，請考慮下列提示和建議：
+ 在 CloudFront 可存取的位置中儲存自訂錯誤頁面。我們建議您將它們存放在 Amazon S3 儲存貯體中，並且[不要將它們儲存在與網站或應用程式內容之其餘部分相同的位置](custom-error-pages-different-locations.md)。如果您將自訂錯誤頁面儲存在與您的網站或應用程式相同的原始伺服器，且原始伺服器開始傳回 5xx 錯誤，則 CloudFront 無法取得自訂錯誤頁面，因為原始伺服器無法使用。如需詳細資訊，請參閱 [將物件和自訂錯誤頁面存放在不同位置](custom-error-pages-different-locations.md)。
+ 請確定 CloudFront 具有取得自訂錯誤頁面的許可。如果自訂錯誤頁面存放於 Amazon S3 中，頁面必須可以公開存取，或者您必須設定 CloudFront [原始存取控制 (OAC)](private-content-restricting-access-to-s3.md)。如果自訂錯誤頁面存放在自訂原始伺服器中，則必須可以公開存取頁面。
+ (選用) 如果需要，請設定您的原始伺服器以新增 `Cache-Control` 或 `Expires` 標頭以及自訂錯誤頁面。您也可以使用 **Error Caching Minimum TTL** (快取最小 TTL 時發生錯誤) 設定來控制 CloudFront 快取自訂錯誤頁面的時間長度。如需詳細資訊，請參閱[控制 CloudFront 快取錯誤的時間長度](custom-error-pages-expiration.md)。
## 設定自訂錯誤回應
若要在 CloudFront 主控台中設定自訂錯誤回應，您必須擁有 CloudFront 分發。在主控台中，自訂錯誤回應的組態設定僅適用於現有分發。若要了解如何建立分發，請參閱[開始使用 CloudFront 標準分佈](GettingStarted.SimpleDistribution.md)。
------
#### [ Console ]
**若要設定自訂錯誤回應 (主控台)**
1. 登入 AWS 管理主控台 ，並在位於 的 CloudFront 主控台中開啟**分佈**頁面[https://console.aws.amazon.com/cloudfront/v4/home#distributions](https://console.aws.amazon.com/cloudfront/v4/home#distributions)。
1. 在分發清單中，選擇要更新的分發。
1. 選擇 **Error Pages** (錯誤頁面) 標籤，然後選擇 **Create Custom Error Response** (建立自訂錯誤回應)。
1. 輸入適用的值。如需詳細資訊，請參閱[自訂錯誤頁面和錯誤快取](DownloadDistValuesErrorPages.md)。
1. 輸入所需的值後，選擇 **Create** (建立)。
------
#### [ CloudFront API or CloudFormation ]
若要使用 CloudFront API 或 設定自訂錯誤回應 CloudFormation，請在分佈中使用 `CustomErrorResponse`類型。如需詳細資訊，請參閱下列內容：
+ *AWS CloudFormation 使用者指南*中的 [AWS::CloudFront::Distribution CustomErrorResponse](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-customerrorresponse.html)
+ *《Amazon CloudFront API 參考》*中的 [CustomErrorResponse](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CustomErrorResponse.html)
------
# 針對特定的 HTTP 狀態碼建立自訂錯誤頁面
若您想要顯示自訂錯誤訊息而非預設訊息，比方與您的網站其餘部分使用相同格式設定的頁面，則可以讓 CloudFront 向檢視器傳回包含自訂錯誤訊息的物件 (如 HTML 檔案)。
若要指定您想要傳回的檔案，以及指明檔案應該傳回的錯誤，您可以更新 CloudFront 分發以指定這些值。如需詳細資訊，請參閱 [設定錯誤回應行為](custom-error-pages-procedure.md)。
例如，以下是自訂錯誤頁面：
![\[custom AWS 404 頁面範例的螢幕擷取畫面。\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudFront/latest/DeveloperGuide/images/custom-error-page-aws-404-example.png)
您可以為每個支援的 HTTP 狀態碼指定不同的物件，或您可以為所有支援的狀態碼使用相同的物件。您可以選擇為某些狀態碼指定自訂錯誤頁面，而不是為其他狀態碼指定。
由於各種原因，透過 CloudFront 提供的物件無法使用。這些分為兩大類：
+ *用戶端錯誤*顯示請求有問題。例如，有指定名稱的物件不可用，或使用者沒有在 Amazon S3 儲存貯體中取得物件所需的許可。當用戶端發生錯誤，原始伺服器會在 4xx 範圍中傳回 HTTP 狀態碼給 CloudFront。
+ *伺服器錯誤*顯示原始伺服器有問題。例如，HTTP 伺服器是忙碌或不可用。當伺服器發生錯誤，您的原始伺服器會在 5xx 範圍中傳回 HTTP 狀態碼至 CloudFront，或特定期間內 CloudFront 不從您的原始伺服器取得回應並假設一個 504 狀態碼 (閘道逾時)。
針對 HTTP 狀態碼，CloudFront 可以傳回自訂錯誤頁面，其中包含下列項目：
+ 400, 403, 404, 405, 414, 416
+ 500、501、502、503、504
**備註**
如果 CloudFront 偵測到請求可能不安全，CloudFront 會傳回 400 (錯誤請求) 錯誤，而不是自訂錯誤頁面。
您可以建立自訂錯誤頁面以取得 HTTP 狀態碼 416 (不滿足請求範圍)，當原始伺服器傳回狀態碼 416 給 CloudFront 時，您可以變更 CloudFront 傳回給檢視器的 HTTP 狀態碼 如需詳細資訊，請參閱[變更 CloudFront 傳回的回應碼](custom-error-pages-response-code.md)。然而，CloudFront 不會快取狀態碼 416 回應，因此，即使您為狀態碼 416 指定 **Error Caching Minimum TTL** (快取最小 TTL 時發生錯誤) 的值，CloudFront 也不會使用它。
在某些情況下，CloudFront 不會傳回 HTTP 503 狀態碼的自訂錯誤頁面，即使您將 CloudFront 設定為此。如果 CloudFront 錯誤碼為 `Capacity Exceeded` 或 `Limit Exceeded`，則 CloudFront 會將 503 狀態碼傳回給檢視器，而不使用您的自訂錯誤頁面。
如果您建立了自訂錯誤頁面，CloudFront 將針對下列回應代碼傳回 `Connection: close` 或 `Connection: keep-alive`：
CloudFront 會對以下狀態碼傳回 `Connection: close`：400、405、414、416、500、501
CloudFront 會對以下狀態碼傳回 `Connection: keep-alive`：403、404、502、503、504
如需 CloudFront 如何從原始伺服器處理錯誤回應的詳細說明，請參閱 [CloudFront 如何處理來自原始伺服器的 HTTP 4xx 和 5xx 狀態碼](HTTPStatusCodes.md)。
# 將物件和自訂錯誤頁面存放在不同位置
如果您要在不同位置存放物件和自訂錯誤頁面，則您的分佈必須包含下列為屬實的快取行為：
+ **Path Pattern (路徑模式)** 的值與自訂錯誤訊息的路徑相符。例如，假設您已在 Amazon S3 儲存貯體名為 `/4xx-errors` 的目錄中儲存了 4xx 錯誤的自訂錯誤頁面。您的分佈必須包含路徑模式路由自訂錯誤頁面請求至該位置的快取行為，例如 `/4xx-errors/*`。
+ **Origin (原始伺服器)** 的數值將 **Origin ID (原始伺服器 ID)** 的數值指定給包含自訂錯誤頁面的原始伺服器。
如需詳細資訊，請參閱[快取行為設定](DownloadDistValuesCacheBehavior.md)。
# 變更 CloudFront 傳回的回應碼
您可以將 CloudFront 設定為傳回不同 HTTP 狀態碼給檢視器，而非 CloudFront 從原始伺服器接收的狀態碼。例如，如果您的原始伺服器傳回 500 狀態碼到 CloudFront，您可能會希望 CloudFront 傳回自訂錯誤頁面和 200 狀態碼 (OK) 給檢視器。基於各種原因，您想要讓 CloudFront 傳回狀態碼到檢視器，該檢視器與原始伺服器傳回到 CloudFront 的檢視器不同：
+ 有些網際網路裝置 (例如，一些防火牆和公司代理) 會攔截 HTTP 4xx 和 5xx 狀態碼並禁止回應傳回給檢視器。在此案例中，如果您替換 `200`，回應不會攔截。
+ 如果您不在意區別不同的用戶端錯誤或伺服器錯誤，您可以指定 `400` 或 `500` 作為 CloudFront 為所有 4xx 或 5xx 狀態碼傳回的值。
+ 您會希望傳回 `200` 狀態碼 (OK) 與靜態網站，如此您的客戶便不會知道您網站已關閉。
如果您啟用 [CloudFront 標準日誌](AccessLogs.md)並設定 CloudFront 來變更回應中的 HTTP 狀態碼，則日誌中的 `sc-status` 欄位值會包含您指定的狀態碼。不過，`x-edge-result-type` 資料行的值不會受到影響。它包含來自原始伺服器回應的結果類型。例如，當原始伺服器傳回 `200` (找不到) 給 CloudFront 時，假設您配置 CloudFront 傳回 `404` 的狀態碼給檢視器。當原始伺服器回應 `404` 狀態碼的請求時，在日誌中 `sc-status` 資料行的值會是 `200`，但 `x-edge-result-type` 資料行的值則會是 `Error`。
您可以配置 CloudFront 傳回下列任何 HTTP 狀態碼以及自訂錯誤頁面：
+ 200
+ 400, 403, 404, 405, 414, 416
+ 500、501、502、503、504
# 控制 CloudFront 快取錯誤的時間長度
根據預設，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 攻擊。這不適用於其他類型的原始伺服器。