如何疑難排解 Application Load Balancer HTTP 502 錯誤？

簡短描述

HTTP 502 的可能原因有幾種：閘道錯誤，來源可能來自目標或 Application Load Balancer。若要識別錯誤的來源，請使用 Amazon CloudWatch 指標和存取日誌。

從 Application Load Balancer 疑難排解錯誤之前，請確定您已開啟存取日誌功能。若要瞭解每個欄位在存取日誌中的意義，請參閱存取日誌項目。

如果目標是 AWS Lambda 函數，請參閱解決方法一節中的目標為 Lambda 函數時，疑難排解 HTTP 502 錯誤。

解決方法

尋找 HTTP 502 錯誤的來源

使用 CloudWatch 指標

如果資料點出現在 HTTPCode_ELB_502_Count 指標之下，則您的負載平衡器就是 HTTP 502 錯誤的來源。如果它們出現在 HTTPCode_Target_5XX_Count 指標之下，則您的目標就是來源。

使用存取日誌

如果 elb_status_code 為「502」，且 target_status_code 為「-」，則您的負載平衡器就是 HTTP 502 錯誤的來源。如果 elb_status_code 為「502」，且 target_status_code 為「502」，則您的目標就是錯誤的來源。

疑難排解 HTTP 502 錯誤

**注意：**透過 elb_status_code = "502" 和 target_status_code 篩選存取日誌，以幫助您確定原因。然後，針對您的使用案例完成相關步驟。

負載平衡器在嘗試建立連線時收到來自目標的 TCP RST

如果您在建立連線時收到來自目標的 TCP RST，則負載平衡器無法與目標建立 TCP 3 向交握。因此，負載平衡器無法將使用者要求轉送至目標。

• 檢查 TargetConnectionErrorCount 指標是否有資料點。此指標代表在負載平衡器與目標之間未成功建立的連線數目。
• 檢查存取日誌中的 request_processing_time、target_processing_time 和 response_processing_time 欄位是否都設定為值 \ -1。此值表示負載平衡器無法將要求分派至目標，因為它需要成功的連線。

以下是存取日誌項目的範例：

http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 -1 -1 -1 502 - 86 155 "GET http://example.com:80/ HTTP/1.1"
"curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067" Root=1-58337262-36d228ad5d99923122bbe354"

**注意：**在此存取日誌項目中，request_processing_time、target_processing_time 和 response_processing_time 都設定為 -1。

當負載平衡器嘗試建立連線時，從目標收到非預期的回應，例如「ICMP 目的地無法連線 (主機無法連線)」

• 檢查存取日誌中的 request_processing_time、target_processing_time 和 response_processing_time 欄位是否全部設定為值 \ -1。
• 檢查流量是否允許從負載平衡器子網路傳送到目標連接埠上的目標。

目標關閉了與 TCP RST 或 TCP FIN 的連線，而負載平衡器對目標有未處理的請求

負載平衡器會接收要求並將其轉送至目標。目標接收請求並開始處理它，但過早關閉與負載平衡器的連線。這通常發生在目標的 keep-alive timeout 持續時間短於負載平衡器的idle timeout value持續時間時。請確定 keep-alive timeout 持續時間大於idle timeout value。

檢查 request_processing_time、target_processing_time 和 response_processing_time 欄位的值。

請參閱下列範例存取日誌項目：

http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 0.001 4.205 -1 502 - 94 326 "GET http://example.com:80 HTTP/1.1" "curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067 "Root=1-58337262-36d228ad5d99923122bbe354"

注意：在此存取日誌項目中，request_processing_time 為 ** 0.001，target_processing_time 為 4.205，而response_processing_time** 為 \ -1。

目標回應格式錯誤或包含無效的 HTTP 標頭

在問題的時間範圍內對目標執行封包擷取，以瞭解目標回應。

連線至目標時，負載平衡器遇到 SSL 交握錯誤或 SSL 交握逾時 (10 秒)

從負載平衡器到目標 HTTPS 接聽程式的 TCP 連線成功，但後續的 SSL 交握逾時。因此，負載平衡器無法將要求轉送至目標。

檢查目標群組是否使用 HTTPS 通訊協定。如果不使用 HTTPS 通訊協定，則 SSL 交握逾時不是造成問題的原因。如果目標群組使用 HTTPS 通訊協定，請檢查以下幾點：

• 檢查存取日誌中的 request_processing_time、target_processing_time 和 response_processing_time 欄位是否全部設定為值 \ -1。
• 檢查 TargetTLSNegotiationErrorCount 指標是否有資料點。
• 在問題的時間範圍對目標執行封包擷取，以驗證它是否與 SSL 交握相關。如果是，請完成執行封包擷取一節中的步驟。
• 檢查密碼或通訊協定是否不相符。

取消註冊的目標所處理的要求經過的取消註冊延遲期間

在 CloudTrail 事件中，請在問題發生的時間範圍內使用取消註冊目標動作檢查 API 呼叫。如果在問題的時間範圍內發生了使用 取消註冊目標的 API 呼叫，則錯誤是因為太早取消註冊目標所引起。若要解決此問題，請增加取消註冊延遲期間，以便冗長的作業可以順利完成。

疑難排解目標為 Lambda 函數時的 HTTP 502 錯誤

**注意：**對於失敗的 Lambda 函數要求，負載平衡器會將 Lambda 特定的錯誤原因代碼儲存在存取日誌的 error_reason 欄位中。

目標是 Lambda 函數，且回應主體超過 1 MB

• 檢查 LambdaUserError 指標是否有資料點。
• 檢查負載平衡器存取日誌檔中的 error_reason 欄位是否設定為 LambdaResponseTooLarge。

目標是一個 Lambda 函數，在達到其設定的逾時之前沒有回應

• 檢查 Lambda 函數逾時設定。
• 檢查 LambdaUserError 指標是否有資料點。
• 檢查負載平衡器存取日誌檔中的 error_reason 欄位是否設定為 LambdaUnhandled。

目標是傳回錯誤的 Lambda 函數，或該函數已由 Lambda 服務限制

請聯絡 AWS Support 以取得有關服務限流的指引。

執行封包擷取

對於 Linux，請使用以下命令：

sudo tcpdump -i any -w filename.pcap

對於Microsoft Windows，請下載並使用 Wireshark 應用程式 (從 Wireshark 網站)。

如需詳細資訊，請參閱如何透過網際網路閘道疑難排解 VPC 中 EC2 Linux 或 Windows 執行個體和內部部署主機之間的網路效能問題？請參閱使用 tcpdump 測試封包擷取範例和進行封包擷取一節。