如何疑難排解 Application Load Balancer HTTP 502 錯誤?
我想要了解如何使用 Application Load Balancer 疑難排解 HTTP 502 無效的閘道錯誤,並使用 CloudWatch 指標和存取日誌識別錯誤來源。
簡短描述
HTTP 502: bad gateway 錯誤有幾個可能的原因。錯誤的來源可以來自您的目標或 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 向交握時,則會出現此訊息。因此,負載平衡器無法將使用者要求轉送至目標。
確認存取日誌中的 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 呼叫。使用在問題導致錯誤的時間範圍期間發生的 DeregisterTargets 進行 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
對於 Windows,請下載並使用 Wireshark 應用程式 (從 Wireshark 網站)。
如需使用 tcpdump 測試封包擷取樣本或取得擷取封包的說明,請參閱如何透過網際網路閘道疑難排解 Amazon Virtual Private Cloud 中 EC2 Linux 或 Windows 執行個體和內部部署主機之間的網路效能問題?
相關內容
- 已提問 2 天前lg...
- 已提問 2 年前lg...
- 已提問 1 年前lg...
- 已提問 1 年前lg...
- AWS 官方已更新 1 年前
- AWS 官方已更新 2 年前
- AWS 官方已更新 2 年前