本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 對 CloudFront 中的錯誤回應狀態碼進行疑難排解
如果 CloudFront 從原始來源請求一個物件，且原始來源傳回 HTTP 4xx 或 5xx 狀態碼，則 CloudFront 與原始來源之間的通訊會有問題。
本主題也包含使用 Lambda@Edge 或 CloudFront Functions 時這些狀態碼的疑難排解步驟。
下列主題提供這些錯誤回應背後潛在原因的詳細說明，並提供如何診斷和解決基礎問題的逐步指引。
**Topics**
+ [HTTP 400 狀態碼 (錯誤的請求)](http-400-bad-request.md)
+ [HTTP 401 狀態碼 (未授權)](http-401-unauthorized.md)
+ [HTTP 403 狀態碼 (方法無效)](http-403-invalid-method.md)
+ [HTTP 403 狀態碼 (許可遭拒)](http-403-permission-denied.md)
+ [HTTP 404 狀態碼 (找不到)](http-404-not-found.md)
+ [HTTP 412 狀態碼 (先決條件失敗)](http-412-precondition-failed.md)
+ [HTTP 500 狀態碼 (內部伺服器錯誤)](http-500-internal-server-error.md)
+ [HTTP 502 狀態碼 (無效的閘道)](http-502-bad-gateway.md)
+ [HTTP 503 狀態碼 (服務無法使用)](http-503-service-unavailable.md)
+ [HTTP 504 狀態碼 (閘道逾時)](http-504-gateway-timeout.md)
# HTTP 400 狀態碼 (錯誤的請求)
當用戶端在請求中傳送一些無效資料時，CloudFront 會傳回 400 錯誤的請求，例如承載或參數中的遺失或不正確的內容。這也可以代表一般用戶端錯誤。
## Amazon S3 原始伺服器傳回 400 錯誤
如果您使用 Amazon S3 原始伺服器搭配 CloudFront 分佈，分佈可能會傳送錯誤回應，其中包含 HTTP 狀態碼 400 錯誤的請求，以及類似下列的訊息：
*授權標頭格式錯誤；區域 '**' 錯誤；預期 '**'*
例如：
*授權標頭格式不正確；區域 'us-east-1' 是錯誤的；應該是 'us-west-2'*
在下列情況下可能會發生這個問題：
1. 您的 CloudFront 分佈的來源是 Amazon S3 儲存貯體。
1. 您已將 S3 儲存貯體從一個 AWS 區域移至另一個區域。也就是說，您刪除了 S3 儲存貯體，稍後您建立了一個具有相同儲存貯體名稱的新儲存貯體，但位於與原始 S3 儲存貯體所在位置不同的 AWS 區域中。
若要修正此錯誤，請更新您的 CloudFront 分佈，以便在儲存貯體的目前 AWS 區域中尋找 S3 儲存貯體。
**更新您的 CloudFront 分佈**
1. 登入 AWS 管理主控台 ，並在 開啟 CloudFront 主控台[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)。
1. 選擇產生此錯誤的分佈。
1. 選擇 **Origins and Origin Groups (原始伺服器和原始伺服器群組)**。
1. 尋找您所移動 S3 儲存貯體的原始來源。選取此原始來源旁邊的核取方塊，然後選擇 **Edit (編輯)**。
1. 請選擇 **Yes, Edit (是，編輯)**。在選擇 **Yes, Edit (是、編輯)** 之前，不需要變更任何設定。
當您完成這些步驟時，CloudFront 會重新部署您的分佈。在部署分佈時，您會在**上次修改**的資料欄下看到**部署中**狀態。部署完成過一段時間後，您應該不會再收到 `AuthorizationHeaderMalformed` 錯誤回應。
## Application Load Balancer 原始伺服器傳回 400 錯誤
如果您使用 Application Load Balancer 原始伺服器搭配 CloudFront 分佈，400 錯誤的可能原因包括下列項目：
+ 用戶端傳送不符合 HTTP 規格的格式錯誤請求。
+ 請求標頭超過每個請求行 16 KB、每個單一標頭 16 KB，或整個請求標頭 64 KB 的限制。
+ 用戶端在傳送完整請求內文之前關閉了連線。
# HTTP 401 狀態碼 (未授權)
401 未經授權的回應狀態碼表示用戶端請求尚未完成，因為其缺少所請求資源的有效身分驗證憑證。此狀態碼會與 HTTP `WWW-Authenticate` 回應標頭一起傳送，其中包含用戶端在提示使用者進行身分驗證憑證後如何再次請求資源的相關資訊。如需詳細資訊，請參閱 [401 未授權](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401)。
在 CloudFront 中，如果您的原始伺服器預期 `Authorization` 標頭會驗證請求，CloudFront 需要將 `Authorization` 標頭轉送到原始伺服器，以避免 401 未經授權的錯誤。當 CloudFront 將檢視器請求轉送至您的原始伺服器時，CloudFront 預設會移除某些檢視器標頭，包括 `Authorization` 標頭。為了確保您的原始伺服器始終收到原始伺服器請求中的 `Authorization` 標頭，您有以下選項：
+ 使用快取政策將 `Authorization` 標頭新增至快取金鑰。快取金鑰中的所有標頭都會自動包含在原始伺服器請求中。如需詳細資訊，請參閱[使用政策控制快取金鑰](controlling-the-cache-key.md)。
+ 使用將所有檢視器標頭轉寄至原始伺服器的原始伺服器請求政策。您無法在原始伺服器請求政策中個別轉寄 `Authorization` 標頭，但當您轉寄所有檢視器標頭時，CloudFront 會在檢視器請求中包含 `Authorization` 標頭。CloudFront 提供此使用案例的受管 `AllViewer` 原始伺服器請求政策。如需詳細資訊，請參閱[使用受管原始伺服器請求政策](using-managed-origin-request-policies.md)。
如需詳細資訊，請參閱[如何設定 CloudFront 將授權標頭轉送至原始伺服器？](https://repost.aws/knowledge-center/cloudfront-authorization-header)
# HTTP 403 狀態碼 (方法無效)
如果您嘗試使用 CloudFront 分佈中未指定的 HTTP 方法，CloudFront 會傳回 403 (方法無效) 錯誤。您可以為分佈指定下列其中一個選項：
+ CloudFront 只轉送 `GET` 和 `HEAD` 請求。
+ CloudFront 只轉送 `GET`、`HEAD` 和 `OPTIONS` 請求。
+ CloudFront 轉送 `GET`、`HEAD`、`OPTIONS`、`PUT`、`PATCH`、`POST` 和 `DELETE` 請求。(如果您選擇此選項，您可能需要限制存取 Amazon S3 儲存貯體或自訂的原始伺服器，以避免使用者執行您不希望他們執行的操作。例如，您可能不希望使用者具有刪除您原始伺服器物件的許可。
# HTTP 403 狀態碼 (許可遭拒)
HTTP 403 錯誤表示用戶端未獲授權存取請求的資源。用戶端了解請求，但無法授權檢視器存取。以下是 CloudFront 傳回此狀態碼時的常見原因：
**Topics**
+ [替代 CNAME 設定不正確](#alternate-cname-incorrectly-configured)
+ [AWS WAF 在 CloudFront 分佈或原始伺服器設定](#aws-waf-configured-on-distribution-origin)
+ [自訂原始伺服器傳回 403 錯誤](#custom-origin-returning-403)
+ [Amazon S3 原始伺服器傳回 403 錯誤](#s3-origin-403-error)
+ [地理限制傳回 403 錯誤](#geolocation-403)
+ [已簽署 URL 或已簽署 Cookie 組態傳回 403 錯誤](#signed-URLs-cookies-403)
+ [堆疊分佈導致 403 錯誤](#stacked-distributions-403)
## 替代 CNAME 設定不正確
確認您已為分佈指定正確的 CNAME。若要使用替代 CNAME 而非預設 CloudFront URL：
1. 在 DNS 中建立 CNAME 記錄，將 CNAME 指向 CloudFront 分佈 URL。
1. 在 CloudFront 分佈組態中新增 CNAME。
如果您建立 DNS 記錄，但未在 CloudFront 分佈組態中新增 CNAME，則請求會傳回 403 錯誤。如需設定自訂 CNAME 的詳細資訊，請參閱 [透過新增備用網域名稱 (CNAME) 使用自訂 URL](CNAMEs.md)。
## AWS WAF 在 CloudFront 分佈或原始伺服器設定
當 AWS WAF 位於用戶端和 CloudFront 之間時，CloudFront 無法區分原始伺服器傳回的 403 錯誤碼和封鎖請求 AWS WAF 時傳回的 403 錯誤碼。
若要尋找 403 狀態碼的來源，請檢查您的 AWS WAF Web 存取控制清單 (ACL) 規則是否有封鎖的請求。如需詳細資訊，請參閱下列主題：
+ [AWS WAF Web 存取控制清單 (Web ACLs)](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html)
+ [測試和調整您的 AWS WAF 防護](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-testing.html)
## 自訂原始伺服器傳回 403 錯誤
如果您使用的是自訂原始伺服器，且原始伺服器具有自訂防火牆組態，則可能會看到 403 錯誤。若要進行疑難排解，請直接向原始伺服器提出請求。如果您可以在沒有 CloudFront 的情況下複寫錯誤，則原始伺服器會導致 403 錯誤。
如果自訂原始伺服器造成錯誤，請檢查原始伺服器日誌以識別可能導致錯誤的因素。如需詳細資訊，請參閱下列疑難排解主題：
+ [如何對 API Gateway 的 HTTP 403 錯誤進行疑難排解？](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-troubleshoot-403-forbidden/ )
+ [如何對 Application Load Balancer 的 HTTP 403 禁止錯誤進行疑難排解？](https://repost.aws/knowledge-center/alb-http-403-error)
## Amazon S3 原始伺服器傳回 403 錯誤
您可能會收到 403 錯誤，原因如下：
+ CloudFront 無法存取 Amazon S3 儲存貯體。如果您的分佈未啟用原始存取身分 (OAI) 或原始存取控制 (OAC)，且儲存貯體為私有，則可能會發生這種情況。
+ 請求 URL 中指定的路徑不正確。
+ 請求的物件不存在。
+ 主機標頭已使用 REST API 端點轉送。如需詳細資訊，請參閱《*Amazon Simple Storage Service 使用者指南*》中的 [HTTP 託管標頭儲存貯體規格](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html#VirtualHostingSpecifyBucket)。
+ 您設定了自訂錯誤頁面。如需詳細資訊，請參閱[當您已設定自訂錯誤頁面時，CloudFront 如何處理錯誤](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages)。
## 地理限制傳回 403 錯誤
如果您啟用了地理限制功能 (有時也稱為地理封鎖) 來防止特定地理位置的使用者存取您透過 CloudFront 分佈所分佈的內容，封鎖使用者時會收到 403 錯誤。
如需詳細資訊，請參閱[限制您內容的地理分佈](georestrictions.md)。
## 已簽署 URL 或已簽署 Cookie 組態傳回 403 錯誤
如果您為分佈的行為組態啟用**限制檢視器存取**，則不使用已簽署 Cookie 或已簽署 URL 的請求會導致 403 錯誤。如需詳細資訊，請參閱下列主題：
+ [使用已簽署 URL 和已簽署 Cookie 提供私有內容](PrivateContent.md)
+ [如何對與 CloudFront 中已簽署 URL 或已簽署 Cookie 相關的問題進行疑難排解？](https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-troubleshoot-signed-url-cookies/)
## 堆疊分佈導致 403 錯誤
如果您在對原始端點的請求鏈中有兩個以上的分佈，CloudFront 會傳回 403 錯誤。我們不建議將一個分佈放在另一個分佈前面。
# HTTP 404 狀態碼 (找不到)
當用戶端嘗試存取不存在的資源時，CloudFront 會傳回 404 (找不到) 錯誤。如果您的 CloudFront 分佈收到此錯誤，常見原因如下：
+ 資源不存在。
+ URL 不正確。
+ 傳回 404 的自訂原始伺服器。
+ 傳回 404 的自訂錯誤頁面。(任何錯誤碼都可能翻譯為 404。) 如需詳細資訊，請參閱[當您已設定自訂錯誤頁面時，CloudFront 如何處理錯誤](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages)。
+ 自訂錯誤頁面意外刪除，導致 404，因為請求會尋找已刪除的自訂錯誤頁面。如需詳細資訊，請參閱[您尚未設定自訂錯誤頁面時 CloudFront 如何處理錯誤](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages)。
+ 原始伺服器路徑不正確。如果填入原始伺服器路徑，其值會附加到瀏覽器每個請求的路徑，然後再將請求轉送到原始伺服器。如需詳細資訊，請參閱[原始伺服器路徑](DownloadDistValuesOrigin.md#DownloadDistValuesOriginPath)。
# HTTP 412 狀態碼 (先決條件失敗)
當目標資源的存取遭拒時，CloudFront 會傳回 412 (先決條件失敗) 錯誤代碼。在某些情況下，伺服器設定為僅在滿足特定條件後才接受請求。如果不符合任何指定的條件，則伺服器不允許用戶端存取指定的資源。反之，伺服器會以 412 錯誤代碼回應。
CloudFront 中 412 錯誤的常見原因包括：
+ 未滿足 `If-Unmodified-Since` 或 `If-None-Match` 標頭所定義的條件時，對 `GET` 或 `HEAD` 以外的方法提出條件請求。在這種情況下，無法提出請求，通常是上傳或修改資源。
+ CloudFront [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) API 操作中一或多個請求欄位中的條件評估為 false。
# HTTP 500 狀態碼 (內部伺服器錯誤)
HTTP 500 狀態碼 (內部伺服器錯誤) 表示伺服器遇到無法滿足請求的非預期條件。以下是 Amazon CloudFront 中 500 錯誤的常見原因。
**Topics**
+ [原始伺服器傳回 500 錯誤至 CloudFront](#origin-server-500-error)
## 原始伺服器傳回 500 錯誤至 CloudFront
您的原始伺服器可能會傳回 500 錯誤至 CloudFront。如需詳細資訊，請參閱下列疑難排解主題：
+ **如果 Amazon S3 傳回 500 錯誤**，請參閱[如何對 Amazon S3 的 HTTP 500 或 503 錯誤進行疑難排解？](https://repost.aws/knowledge-center/http-5xx-errors-s3)
+ **如果 API Gateway 傳回 500 錯誤**，請參閱「[如何對 API Gateway REST API 的 5xx 錯誤進行疑難排解？](https://repost.aws/knowledge-center/api-gateway-5xx-error)」。
+ **如果 Elastic Load Balancing 傳回 500 錯誤**，請參閱《*Application Load Balancer 使用者指南*》中的 [HTTP 500：內部伺服器錯誤](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-500-issues)。
如果上述清單無法解決 500 錯誤，問題可能是 CloudFront 連接點傳回內部伺服器錯誤。您可以聯絡 [支援](https://console.aws.amazon.com/support/home#/) 尋求協助。
# HTTP 502 狀態碼 (無效的閘道)
HTTP 502 狀態碼 (無效的閘道) 表示 CloudFront 無法為請求的物件提供服務，因為它無法連接到原始伺服器。
如果您使用的是 Lambda@Edge，問題可能出自 Lambda 驗證錯誤。如果收到 `NonS3OriginDnsError` 錯誤碼的 HTTP 502 錯誤，表示存在 DNS 組態問題，導致 CloudFront 無法連線到原始伺服器。
**Topics**
+ [CloudFront 與自訂原始伺服器間的 SSL/TLS 溝通失敗](#ssl-negotitation-failure)
+ [原始伺服器無法回應受支援的加密/通訊協定](#origin-not-responding-with-supported-ciphers-protocols)
+ [原始伺服器的 SSL/TLS 憑證已過期、無效、已自我簽署，或憑證鏈順序錯誤](#ssl-certificate-expired)
+ [在原始伺服器設定中原始伺服器無法回應指定的連接埠](#origin-not-responding-on-specified-ports)
+ [Lambda 驗證錯誤](#http-502-lambda-validation-error)
+ [CloudFront 函數驗證錯誤](#http-502-cloudfront-function-validation-error)
+ [DNS 錯誤 (`NonS3OriginDnsError`)](#http-502-dns-error)
+ [Application Load Balancer 原始伺服器 502 錯誤](#cloudfront-alb-502-error)
+ [API Gateway 原始伺服器 502 錯誤](#cloudfront-api-gateway-502-error)
## CloudFront 與自訂原始伺服器間的 SSL/TLS 溝通失敗
如果您使用的自訂原始伺服器需要在 CloudFront 和原始伺服器之間使用 HTTPS，不相符的網域名稱可能會導致錯誤。原始伺服器的 SSL/TLS 憑證*必須包含*符合您為 CloudFront 分佈指定的**原始網域**或原始請求 `Host` 標頭的網域名稱。
如果網域名稱不符合，則 SSL/TLS 的交握便失敗，且 CloudFront 會傳回 HTTP 狀態碼 502 (無效的閘道) 給檢視器，並將 `X-Cache` 標頭設定成 `Error from cloudfront`。
若要判斷憑證中的網域名稱是否與分佈或 `Host` 標頭中的 **原始伺服器網域**相符，您可以使用線上 SSL 檢查或 OpenSSL。如果網域名稱不相符，您有兩個選項：
+ 取得包括適用的網域名稱的新 SSL/TLS 憑證。
如果您使用 AWS Certificate Manager (ACM)，請參閱*AWS Certificate Manager *[《 使用者指南》中的請求公有憑證](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html)以請求新的憑證。
+ 變更分佈組態，因此 CloudFront 不再嘗試使用 SSL 與您的原始伺服器連線。
### 線上 SSL 檢查
若要尋找 SSL 測試工具，請搜尋網際網路「線上 ssl 檢查。」 通常需要指定網域名稱，且此工具會傳回有關 SSL/TLS 憑證的各種資訊。確認憑證在 **Common Name (通用名稱)** 或 **Subject Alternative Names (主體別名)** 欄位中包含您的網域名稱。
### OpenSSL
若要協助故障診斷來自 CloudFront 的 HTTP 502 錯誤，您可以使用 OpenSSL 嘗試與原始伺服器建立 SSL/TLS 連線。如果 OpenSSL 無法建立連線，可能表示原始伺服器的 SSL/TLS 組態發生問題。如果 OpenSSL 能夠建立連線，它會傳回原始伺服器憑證的相關資訊，包括憑證的通用名稱 (`Subject CN` 欄位) 和主體別名 (`Subject Alternative Name` 欄位)。
使用下列 OpenSSL 命令來測試與原始伺服器的連線 (將*原始網域*取代為原始伺服器的網域名稱，例如 example.com)：
`openssl s_client -connect origin domain name:443`
如果下列為真：
+ 原始伺服器支援有多個 SSL/TLS 憑證的多個網域名稱
+ 您的分佈設定為將 `Host` 標頭轉送至原始伺服器
然後將 `-servername` 選項新增至 OpenSSL 命令，如下列範例所示 (將 *CNAME* 取代為您的分佈中設定的 CNAME)：
`openssl s_client -connect origin domain name:443 -servername CNAME`
## 原始伺服器無法回應受支援的加密/通訊協定
CloudFront 使用密碼加密和通訊協定連線至原始伺服器。如需 CloudFront 支援的密碼加密和通訊協定清單，請參閱 [CloudFront 和原始伺服器之間支援的通訊協定和密碼](secure-connections-supported-ciphers-cloudfront-to-origin.md)。如果原始伺服器在 SSL/TLS 交換中不回應這些密碼加密或通訊協定的其中之ㄧ，則 CloudFront 連線失敗。您可以使用如 [SSL Labs](https://www.ssllabs.com/ssltest) (SSL 實驗室) 等線上工具來驗證原始伺服器是否支援密碼加密和通訊協定。在 **Hostname (主機名稱)** 欄位中輸入原始伺服器的網域名稱，然後選擇 **Submit (提交)**。從測試來檢閱 **Common names (通用名稱)** 和 **Alternative names (替代名稱)** 欄位，查看它們是否符合原始伺服器的網域名稱。測試完成後，在測試結果中找到 **Protocols (通訊協定)** 與 **Cipher Suites (密碼套件)** 區段，查看原始伺服器支援哪些密碼加密或通訊協定。將其與 [CloudFront 和原始伺服器之間支援的通訊協定和密碼](secure-connections-supported-ciphers-cloudfront-to-origin.md) 的清單進行比較。
## 原始伺服器的 SSL/TLS 憑證已過期、無效、已自我簽署，或憑證鏈順序錯誤
如果原始伺服器傳回以下內容時，則 CloudFront 失去 TCP 連線，傳回 HTTP 狀態碼 502 (無效的閘道)，且將 `X-Cache` 標頭設定為 `Error from cloudfront`：
+ 過期的憑證
+ 無效的憑證
+ 已自我簽署的憑證
+ 憑證鏈順序錯誤
**注意**
若完整的憑證鏈結 (包含中繼憑證) 不存在，CloudFront 便會卸除 TCP 連線。
如需有關在自訂原始伺服器上安裝 SSL/TLS 憑證的詳細資訊，請參閱 [要求 CloudFront 與自訂原始伺服器之間的通訊使用 HTTPS](using-https-cloudfront-to-custom-origin.md)。
## 在原始伺服器設定中原始伺服器無法回應指定的連接埠
當您在 CloudFront 分佈上建立原始伺服器時，可以設定 CloudFront 用於連線至原始伺服器以傳送 HTTP 和 HTTPS 流量的連接埠。根據預設，這些都是 TCP 80/443。您可以選擇修改這些連接埠。如果原始伺服器為了任何原因拒絕這些連接埠上的流量，或者如果後端伺服器沒有回應連接埠，則 CloudFront 連線失敗。
若要故障診斷這些問題，請檢查基礎設施中執行的任何防火牆和驗證它們不會封鎖受支援的 IP 範圍。如需詳細資訊，請參閱《*Amazon VPC 使用者指南*》中的 [AWS IP 位址範圍](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html)。此外，驗證 Web 伺服器是否可在原始伺服器上執行。
## Lambda 驗證錯誤
如果您使用 Lambda@Edge，HTTP 502 狀態碼可能表示您的 Lambda 函數回應的格式不正確或包含無效的內容。如需針對 Lambda@Edge 錯誤進行故障診斷的詳細資訊，請參閱[測試和偵錯 Lambda@Edge 函數](lambda-edge-testing-debugging.md)。
## CloudFront 函數驗證錯誤
如果您使用的是 CloudFront 函數，HTTP 502 狀態碼可以表示 CloudFront 函數正在嘗試新增、刪除或變更唯讀標頭。此錯誤不會在測試期間顯示，但會在您部署函數並執行請求後顯示。若要解決此錯誤，請檢查並更新您的 CloudFront 函數。如需詳細資訊，請參閱[更新函數](update-function.md)。
## DNS 錯誤 (`NonS3OriginDnsError`)
具有 `NonS3OriginDnsError` 錯誤碼的 HTTP 502 錯誤表示存在 DNS 組態問題，導致 CloudFront 無法連線到原始伺服器。如果您從 CloudFront 收到此錯誤訊息，請確定原始伺服器的 DNS 組態正確且正常運作。
當 CloudFront 收到逾期或不在快取中的物件請求，會向原始伺服器發出請求以取得物件。若要成功向原始伺服器發出請求，則 CloudFront 在原始伺服器網域上執行 DNS 解決方案。您網域的 DNS 服務遇到問題時，CloudFront 無法解決網域名稱以取得 IP 位址，導致 502 錯誤 (`NonS3OriginDnsError`)。若要修正此問題，請聯絡您的 DNS 供應商，或者如果您使用 Amazon Route 53，請參閱[為什麼我無法存取使用 Route 53 DNS 服務的網站？](https://aws.amazon.com/premiumsupport/knowledge-center/route-53-dns-website-unreachable/)
若要進一步疑難排解此問題，請確保原始伺服器根網域的 [authoritative name servers](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-authoritative-name-server) (授權名稱伺服器) 或 Zone Apex (例如 `example.com`) 正確運作。您可以使用以下命令來尋找適用於 apex 原始伺服器的名稱，使用 [dig](https://en.wikipedia.org/wiki/Dig_(command)) 或 [nslookup](https://en.wikipedia.org/wiki/Nslookup) 等工具：
```
dig OriginAPEXDomainName NS +short
```
```
nslookup -query=NS OriginAPEXDomainName
```
當您有名稱伺服器的名稱時，請使用下列命令針對他們的原始伺服器的網域名稱做查詢，以確保每個回應都有一個答案：
```
dig OriginDomainName @NameServer
```
```
nslookup OriginDomainName NameServer
```
**重要**
請務必使用連線至公用網際網路的電腦執行此 DNS 疑難排解。CloudFront 使用網際網路上的公有 DNS 來解析原始網域名稱，因此在類似環境下進行疑難排解非常重要。
如果您的原始網域是一個子網域，其 DNS 授權委派給與根網域不同的名稱伺服器，請確定該子網域的名稱伺服器 (`NS`) 和授權開始 (`SOA`) 記錄已正確設定。您可以使用類似上述範例的命令來檢查這些記錄。
如需 DNS 的詳細資訊，請參閱 Amazon Route 53 說明文件中的[網域名稱系統 (DNS) 概念](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-domain-name-system-dns)。
## Application Load Balancer 原始伺服器 502 錯誤
如果您使用 Application Load Balancer 做為原始伺服器並收到 502 錯誤，請參閱「[如何對 Application Load Balancer HTTP 502 錯誤進行疑難排解？](https://repost.aws/knowledge-center/elb-alb-troubleshoot-502-errors)」。
## API Gateway 原始伺服器 502 錯誤
如果您使用 API Gateway 並收到 502 錯誤，請參閱「[如何透過 Lambda 代理整合解決 API Gateway REST API 的 HTTP 502 錯誤？](https://repost.aws/knowledge-center/malformed-502-api-gateway)」。
# HTTP 503 狀態碼 (服務無法使用)
HTTP 503 狀態碼 (服務無法使用) 通常表示原始伺服器上的效能問題。在極少數情況下，這表示 CloudFront 因為節點上的資源限制，暫時無法滿足請求。
如果您使用的是 Lambda@Edge 或 CloudFront Functions，問題可能是執行錯誤或 Lambda@Edge 超過限制錯誤。
**Topics**
+ [原始伺服器沒有足夠的容量來支援請求率](#http-503-service-unavailable-not-enough-origin-capacity)
+ [CloudFront 由於節點上的資源限制導致錯誤](#http-503-service-unavailable-limited-resources-at-edge-location)
+ [Lambda@Edge 或 CloudFront Function 執行錯誤](#http-503-lambda-execution-error)
+ [超過 Lambda@Edge 限制](#http-503-lambda-limit-exceeded-error)
## 原始伺服器沒有足夠的容量來支援請求率
當原始伺服器無法使用或無法提供傳入請求時，它會傳回 HTTP 503 狀態碼 (服務無法使用)。然後 CloudFront 將此錯誤傳回給使用者。若要解決這個問題，請嘗試下列解決方案：
+ **如果您使用 Amazon S3 做為原始伺服器**：
+ 您可以傳送每個分割的 Amazon S3 字首每秒 3,500 個 PUT/COPY/POST/DELETE 和 5,500 個 GET/HEAD 請求。當 Amazon S3 傳回 503 慢速下降回應時，這通常表示針對特定 Amazon S3 字首的請求率過高。
由於請求率適用於 S3 儲存貯體中的每個字首，因此物件應分散到多個字首。隨著字首上的請求率逐漸增加，Amazon S3 會向上擴展以分別處理每個字首的請求。因此，儲存貯體能處理的整體請求率為字首數的倍數。
+ 如需詳細資訊，請參閱*《Amazon Simple Storage Service 使用者指南》*中的[最佳化 Amazon S3 效能](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html)。
+ **如果您使用 Elastic Load Balancing 做為原始伺服器**：
+ 確定您的後端執行個體可以回應運作狀態檢查。
+ 確定您的負載平衡器和後端執行個體可以處理負載。
如需詳細資訊，請參閱：
+ [如何對 Classic Load Balancer 的 503 錯誤進行疑難排解？](https://repost.aws/knowledge-center/503-error-classic)
+ [如何對 Application Load Balancer 的 503 (服務無法使用) 錯誤進行疑難排解？](https://repost.aws/knowledge-center/alb-troubleshoot-503-errors)
+ **如果您使用自訂原始伺服器**：
+ 檢查應用程式日誌，以確保原始伺服器有足夠的資源，例如記憶體、CPU 和磁碟大小。
+ 如果使用 Amazon EC2 做為後端，請確保執行個體類型都有適當的資源，以符合傳入的請求。如需詳細資訊，請參閱《Amazon EC2 使用者指南》中的[執行個體類型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)。
+ **如果您使用 API Gateway**：
+ 此錯誤與當 API Gateway API 無法接收回應時的後端整合有關。後端伺服器可能：
+ 超載超過容量，無法處理新的用戶端請求。
+ 臨時維護中。
+ 若要解決此錯誤，請查看您的 API Gateway 應用程式日誌，以判斷後端容量、整合或其他問題。
## CloudFront 由於節點上的資源限制導致錯誤
在極少數的情況下，您會收到此錯誤，CloudFront 無法將請求路由到下一個最佳的可用節點，也因此無法滿足請求。在 CloudFront 分佈中執行負載測試時，常見此錯誤。為協助防止此種情況，請遵循 [負載測試 CloudFront](load-testing.md) 準則，以避免 503 (容量超過) 錯誤。
如果您的生產環境中發生這種情況，請聯絡 [支援](https://console.aws.amazon.com/support/home#/)。
## Lambda@Edge 或 CloudFront Function 執行錯誤
如果您使用 Lambda@Edge 或 CloudFront Functions，HTTP 503 狀態碼可能表示您的函數傳回執行錯誤。
如需如何識別和解決 Lambda@Edge 錯誤的詳細資訊，請參閱 [測試和偵錯 Lambda@Edge 函數](lambda-edge-testing-debugging.md)。
如需測試 CloudFront Functions 的詳細資訊，請參閱 [測試函數](test-function.md)。
## 超過 Lambda@Edge 限制
如果您使用 Lambda@Edge，HTTP 503 狀態碼可能表示 Lambda 傳回了錯誤。此錯誤可能由以下其中一項原因造成：
+ 函數執行次數超過 Lambda 設定以調節 AWS 區域 （並行執行或調用頻率） 執行的其中一個配額。
+ 此函數已超過 Lambda 函數逾時配額。
如需 Lambda@Edge 配額的詳細資訊，請參閱 [Lambda@Edge 的配額](cloudfront-limits.md#limits-lambda-at-edge)。如需如何識別和解決 Lambda@Edge 錯誤的詳細資訊，請參閱 [測試和偵錯 Lambda@Edge 函數](lambda-edge-testing-debugging.md)。您也可以參閱《*AWS Lambda 開發人員指南*》中的 [Lambda 服務配額](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)。
# HTTP 504 狀態碼 (閘道逾時)
HTTP 504 狀態碼 (閘道逾時) 代表當 CloudFront 將請求轉送回到原始伺服器時 (因為請求的物件未在邊緣快取中) 發生了下列其中一個事件：
+ 原始伺服器將 HTTP 504 狀態碼傳回 CloudFront。
+ 原始伺服器未在請求逾期之前回應。
當流量受到防火牆或安全群組封鎖而無法傳入原始伺服器，或是無法從網際網路存取該原始伺服器，則 CloudFront 將傳回 HTTP 504 狀態碼。請先查看這些問題。如果可以正常存取，請探索應用程式延遲和伺服器逾時，以協助您找出問題並進行修正。
**Topics**
+ [設定原始伺服器的防火牆來允許 CloudFront 流量](#http-504-gateway-timeout-configure-firewall)
+ [設定原始伺服器的安全群組來允許 CloudFront 流量](#http-504-gateway-timeout-configure-security-groups)
+ [設定您的自訂原始伺服器可從網際網路存取](#http-504-gateway-timeout-make-origin-accessible)
+ [尋找和修正原始伺服器上應用程式的延遲回應](#http-504-gateway-timeout-slow-application)
## 設定原始伺服器的防火牆來允許 CloudFront 流量
如果原始伺服器防火牆封鎖 CloudFront 流量，則 CloudFront 會傳回 HTTP 504 狀態碼，所以最好先確認問題不在於此，再檢查其他可能的問題。
用於判斷防火牆是否有問題的方法，將依原始伺服器使用的系統類型而定：
+ 如果是在 Linux 伺服器使用 IPTable 防火牆，則您可以搜尋工具和資訊來協助您處理 IPTable。
+ 如果您在 Windows 伺服器上使用 Windows 防火牆，請參閱 Microsoft 文件中的[新增或編輯防火牆規則](https://technet.microsoft.com/en-us/library/cc753558(v=ws.11).aspx) (英文)。
當您在評估原始伺服器的防火牆組態時，請查看是否有任何因已發布 IP 位址範圍而導致 CloudFront 節點流量遭到封鎖的防火牆或安全規則。如需詳細資訊，請參閱[CloudFront 邊緣伺服器的位置和 IP 位址範圍](LocationsOfEdgeServers.md)。
如果允許 CloudFront IP 位址範圍連線至您的原始伺服器，請務必更新伺服器的安全性規則以納入變更。您可以訂閱 Amazon SNS 主題，即可在 IP 位址範圍檔案更新時收到通知。在收到通知後，您可以使用程式碼來擷取檔案及進行剖析，並為您的本機環境進行調整。如需詳細資訊，請參閱新聞部落格上的 AWS [透過 Amazon SNS 訂閱 AWS 公有 IP 地址變更](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/)。
## 設定原始伺服器的安全群組來允許 CloudFront 流量
如果原始伺服器使用 Elastic Load Balancing，請檢閱 [ELB 安全群組](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html)，確保安全群組允許從 CloudFront 傳入流量。
您也可以使用 AWS Lambda 自動更新您的安全群組，以允許來自 CloudFront 的傳入流量。
## 設定您的自訂原始伺服器可從網際網路存取
如果 CloudFront 無法存取自訂原始伺服器是因為此伺服器無法從網際網路公開存取，CloudFront 將傳回 HTTP 504 錯誤。
CloudFront 節點是經由網際網路連接到原始伺服器。如果您的自訂原始伺服器位於私有網路，則 CloudFront 無法與其連線。基於上述原因，您不能使用包括[內部 Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html) 等私有伺服器做為搭配 CloudFront 的原始伺服器。
若要檢查網際網路流量是否可以連接到您的原始伺服器，請執行以下命令 (其中的 *OriginDomainName* 是指伺服器的網域名稱)：
檢查 HTTPS 流量時：
+ nc -zv *OriginDomainName* 443
+ telnet *OriginDomainName* 443
檢查 HTTP 流量時：
+ nc -zv *OriginDomainName* 80
+ telnet *OriginDomainName* 80
## 尋找和修正原始伺服器上應用程式的延遲回應
導致伺服器逾時發生的原因通常是等候應用程式回應的時間過長，或是設定的逾時值過短。
直接為分佈設定較高 CloudFront 逾時值，就能快速修正，協助避免 HTTP 504 錯誤的發生。但是，我們建議您先排除任何與應用程式和原始伺服器有關的效能和延遲問題。接著您可以設定合理的逾時值，協助避免 HTTP 504 錯誤的發生，並且正確回應使用者。
以下是找出效能問題並加以更正之步驟的概觀：
1. 測量 Web 應用程式的一般負載和高負載延遲 (回應能力)。
1. 視需要新增額外的資源，例如 CPU 記憶體。採取其他步驟來解決問題，例如調校資料庫查詢以配合高負載情況。
1. 視需要調整 CloudFront 分佈的逾時值。
以下是每個步驟的詳細資訊。
### 測量一般負載和高負載延遲
若要判斷一台或多台後端 Web 應用程式伺服器是否發生高度延遲，請在每台伺服器上執行下列 Linux curl 命令：
```
curl -w "DNS Lookup Time: %{time_namelookup} \nConnect time: %{time_connect} \nTLS Setup: %{time_appconnect} \nRedirect Time: %{time_redirect} \nTime to first byte: %{time_starttransfer} \nTotal time: %{time_total} \n" -o /dev/null https://www.example.com/yourobject
```
**注意**
如果伺服器執行 Windows，您可以搜尋和下載適用於 Windows 的 Curl，執行類似的命令。
在測量和評估伺服器中執行應用程式的延遲情況時，請注意以下資訊：
+ 延遲值會因應每個應用程式而有不同。不過，相對於幾秒鐘或更久時間，幾毫秒的第一個位元組的時間才算正常。
+ 如果在一般負載時測出的應用程式延遲時間正常，這時應注意檢視器在高負載情況下仍然可能遇到逾時問題。當出現高需求量時，伺服器可能會延遲回應或毫無回應。為了協助防止高負載延遲問題，請檢查您的伺服器的資源，例如 CPU、記憶體和磁碟讀取和寫入，確保您的伺服器有足夠容量可因應高負載進行擴展。
您可以執行以下 Linux 命令，檢查 Apache 程序所使用的記憶體：
`watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"`
+ 伺服器的高 CPU 使用率可能大幅降低應用程式的效能。如果後端伺服器使用 Amazon EC2 執行個體，請檢閱伺服器的 CloudWatch 指標以檢查 CPU 使用率。如需詳細資訊，請參閱 [Amazon CloudWatch 使用者指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)。若是使用您自己的伺服器，請參閱伺服器說明文件，以取得如何檢查 CPU 使用率的指示。
+ 請檢查高負載時的其他潛在問題，例如，若有大量請求時，資料庫查詢的執行速度就會變慢。
### 新增資源，並調校伺服器和資料庫
在評估過應用程式和伺服器的回應能力後，確保您有足夠的資源可供一般流量和高負載情況使用：
+ 如果您有自己的伺服器，請根據您的評估，確定伺服器具備足夠的 CPU、記憶體和磁碟空間來處理檢視器的請求。
+ 如果使用 Amazon EC2 執行個體做為後端伺服器，請確保該執行個體類型具備執行傳入請求的適當資源。如需詳細資訊，請參閱《Amazon EC2 使用者指南》中的[執行個體類型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)。
此外，請考慮以下調校步驟，以避免發生逾時：
+ 如果 Curl 命令傳回的 Time to First Byte 值看似很高，請採取適當步驟以提升應用程式的效能。提升應用程式回應能力將有助於減少逾時錯誤。
+ 調校資料庫查詢以確保其可處理大量請求，且不會降低效能。
+ 在您的後端伺服器上設定 [keep-alive (persistent)](https://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01) (保持活動 (持續)) 連線。當伺服器必須為後續請求或使用者重新建立連線時，此選項可避免此時發生延遲。
+ **如果您使用 Elastic Load Balancing 做為原始伺服器**，下列是造成 504 錯誤的可能原因：
+ 負載平衡器無法在連線逾時過期 (10 秒) 之前建立對目標的連線。
+ 負載平衡器建立了對目標的連線，但目標未在閒置逾時期間經過之前回應。
+ 子網路的網路存取控制清單 (ACL) 不允許從目標到暫時性連接埠 (1024-65535) 上負載平衡器節點的流量。
+ 目標傳回的內容長度標頭大於實體主體。負載平衡器等候遺失的位元組時逾時。
+ 目標是 Lambda 函數，且 Lambda 未在連線逾時期間經過之前回應。
如需減少延遲的詳細資訊，請參閱[如何對 ELB Classic Load Balancer 上的高延遲進行疑難排解？](https://repost.aws/knowledge-center/elb-latency-troubleshooting)
+ **如果您使用 MediaTailor 做為原始伺服器**，504 錯誤的可能原因如下：
+ 如果相對 URL 處理不當，MediaTailor 可能會收到來自播放器的格式不正確的 URL。
+ 如果 MediaPackage 是 MediaTailor 的資訊清單原始伺服器，MediaPackage 404 資訊清單錯誤可能會導致 MediaTailor 傳回 504 錯誤。
+ 對 MediaTailor 原始伺服器的請求需要超過 2 秒才能完成。
+ **如果您使用 Amazon API Gateway 做為原始伺服器**，下列是 504 錯誤的可能原因：
+ 整合請求所需的時間超過您的 API Gateway REST API 最大整合逾時參數。如需詳細資訊，請參閱[如何對 API Gateway 的 API HTTP 504 逾時錯誤進行疑難排解？](https://repost.aws/knowledge-center/api-gateway-504-errors)
### 視需要調整 CloudFront 逾時值
如果已評估並解決應用程式效能緩慢問題、原始伺服器容量和其他問題，但檢視器仍然遇到 HTTP 504 錯誤，這時您應該考慮變更在分佈中的原始伺服器回應逾時指定時間。如需詳細資訊，請參閱[回應逾時](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout)。