本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
HTTP 504 狀態碼 （閘道逾時）
504 狀態碼 HTTP （閘道逾時） 表示在將請求 CloudFront 轉送至原始伺服器 （因為請求的物件不在邊緣快取中） 時，發生下列其中一種情況：
-
原始伺服器傳回 HTTP 504 狀態碼給 CloudFront。
-
原始伺服器未在請求逾期之前回應。
CloudFront 如果防火牆或安全群組封鎖流量至原始伺服器，或無法從網際網路存取原始伺服器， 將傳回 HTTP504 狀態碼。請先查看這些問題。如果可以正常存取，請探索應用程式延遲和伺服器逾時，以協助您找出問題並進行修正。
主題
將原始伺服器上的防火牆設定為允許 CloudFront 流量
如果原始伺服器上的防火牆封鎖 CloudFront 流量， CloudFront 會傳回 HTTP 504 狀態碼，因此檢查其他問題之前，最好先確認 不是問題。
用於判斷防火牆是否有問題的方法，將依原始伺服器使用的系統類型而定：
-
如果您在 Linux 伺服器上使用IPTable防火牆，您可以搜尋工具和資訊，以協助您使用 IPTables。
-
如果您在 Windows 伺服器上使用 Windows 防火牆，請參閱 Microsoft 文件中的新增或編輯防火牆規則
(英文)。
當您評估原始伺服器的防火牆組態時，請根據發佈的 IP 地址範圍，尋找封鎖來自 CloudFront 邊緣位置流量的任何防火牆或安全規則。如需詳細資訊，請參閱 CloudFront 邊緣伺服器的位置和 IP 位址範圍。
如果允許 CloudFront IP 地址範圍連線至原始伺服器，請務必更新伺服器的安全規則，以合併變更。您可以訂閱 Amazon SNS主題，並在更新 IP 地址範圍檔案時收到通知。在收到通知後，您可以使用程式碼來擷取檔案及進行剖析，並為您的本機環境進行調整。如需詳細資訊，請參閱新聞部落格上的 AWS 透過 Amazon 訂閱 AWS 公有 IP 地址變更SNS
設定原始伺服器的安全群組以允許 CloudFront 流量
如果您的原始伺服器使用 Elastic Load Balancing ，請檢閱ELB安全群組，並確保安全群組允許來自 的傳入流量 CloudFront。
您也可以使用 AWS Lambda 自動更新安全群組，以允許來自 的傳入流量 CloudFront。
設定您的自訂原始伺服器可從網際網路存取
如果 CloudFront 無法存取您的自訂原始伺服器，因為其無法在網際網路上公開使用， 會 CloudFront 傳回 504 HTTP 錯誤。
CloudFront 邊緣位置會透過網際網路連線至原始伺服器。如果您的自訂原始伺服器位於私有網路上， CloudFront 將無法連線。因此，您無法將私有伺服器，包括內部 Classic Load Balancer ，用作具有 的原始伺服器 CloudFront。
若要檢查網際網路流量是否可以連線至原始伺服器，請執行下列命令 （其中 OriginDomainName 是伺服器的網域名稱）：
對於HTTPS流量：
-
nc -zv
OriginDomainName443 -
telnet
OriginDomainName443
對於HTTP流量：
-
nc -zv
OriginDomainName80 -
telnet
OriginDomainName80
尋找和修正原始伺服器上應用程式的延遲回應
導致伺服器逾時發生的原因通常是等候應用程式回應的時間過長，或是設定的逾時值過短。
協助避免 HTTP 504 錯誤的快速修正是只需為您的分佈設定更高的 CloudFront逾時值。但是，我們建議您先排除任何與應用程式和原始伺服器有關的效能和延遲問題。然後，您可以設定合理的逾時值，以協助防止 HTTP 504 個錯誤，並為使用者提供良好的回應能力。
以下是找出效能問題並加以更正之步驟的概觀：
-
測量 Web 應用程式的一般負載和高負載延遲 (回應能力)。
-
視需要新增其他資源，例如 CPU或 記憶體。採取其他步驟來解決問題，例如調校資料庫查詢以配合高負載情況。
-
如有需要，請調整 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 使用者指南 。或者，如果您使用自己的伺服器，請參閱伺服器說明文件，以取得如何檢查CPU使用率的指示。
-
請檢查高負載時的其他潛在問題，例如，若有大量請求時，資料庫查詢的執行速度就會變慢。
新增資源，並調校伺服器和資料庫
在評估過應用程式和伺服器的回應能力後，確保您有足夠的資源可供一般流量和高負載情況使用：
-
如果您有自己的伺服器，請確定它有足夠的 CPU、記憶體和磁碟空間來處理檢視器請求，視您的評估而定。
-
如果您使用 Amazon EC2執行個體做為後端伺服器，請確定執行個體類型具有適當的資源來滿足傳入的請求。如需詳細資訊，請參閱 Amazon EC2使用者指南 中的執行個體類型。
此外，請考慮以下調校步驟，以避免發生逾時：
-
如果 Curl 命令傳回的 Time to First Byte 值看似很高，請採取適當步驟以提升應用程式的效能。提升應用程式回應能力將有助於減少逾時錯誤。
-
調校資料庫查詢以確保其可處理大量請求，且不會降低效能。
-
在您的後端伺服器上設定 keep-alive (persistent)
(保持活動 (持續)) 連線。當伺服器必須為後續請求或使用者重新建立連線時，此選項可避免此時發生延遲。 -
如果您使用 Elastic Load Balancing 作為原始伺服器 ，則下列是 504 錯誤的潛在原因：
負載平衡器無法在連線逾時到期 （10 秒） 之前建立與目標的連線。
負載平衡器會建立與目標的連線，但目標在閒置逾時期間結束前不會回應。
子網路的網路存取控制清單 （ACL） 不允許從目標到暫時連接埠 (1024-65535） 上負載平衡器節點的流量。
目標傳回的內容長度標頭大於實體主體。負載平衡器會逾時等待缺少的位元組。
目標為 Lambda 函數，Lambda 在連線逾時到期之前不會回應。
如需減少延遲的詳細資訊，請參閱如何在 ELB Classic Load Balancer 上對高延遲進行疑難排解？
-
如果您使用 MediaTailor 作為原始伺服器 ，則下列是 504 錯誤的可能原因：
如果親戚處理URLs不當， MediaTailor 可能會URLs收到來自玩家的格式錯誤。
如果 MediaPackage 是 MediaTailor， MediaPackage 404 個資訊清單錯誤的資訊清單原始伺服器，可能會導致 MediaTailor 傳回 504 個錯誤。
對 MediaTailor 原始伺服器提出的請求需要超過 2 秒才能完成。
-
如果您使用 Amazon API Gateway 作為原始伺服器 ，則下列是 504 錯誤的可能原因：
整合請求所需的時間超過API閘道RESTAPI最大整合逾時參數。如需詳細資訊，請參閱如何使用 API Gateway 疑難排解 API HTTP 504 逾時錯誤？
如有需要，請調整 CloudFront 逾時值
如果您已評估並解決緩慢的應用程式效能、原始伺服器容量和其他問題，但檢視者仍然遇到 HTTP 504 個錯誤，則應考慮變更原始伺服器回應逾時分佈中指定的時間。如需詳細資訊，請參閱回應逾時 (僅限自訂原始伺服器)。
