Application Load Balancer の HTTP 502 エラーのトラブルシューティング方法を教えてください。

最終更新日: 2022 年 5 月 17 日

HTTP 502:「不正なゲートウェイ」エラーにはいくつかの原因が考えられます。この原因はターゲットまたは Application Load Balancer のいずれかです。Amazon CloudWatch メトリクスとアクセスログを使用して、エラーの原因を特定できます。

Application Load Balancer からのエラーのトラブルシューティングを開始する前に、アクセスログを有効にしてください。アクセスログの各フィールドの意味を理解するには、「アクセスログのエントリ」を参照してください。

ターゲットが AWS Lambda 関数の場合は、「解決方法」セクションの「ターゲットが Lambda 関数の場合の HTTP 502 エラーのトラブルシューティング」を参照してください。

CloudWatch メトリクスを使用する

データポイントが HTTPCode_ELB_502_Count メトリクスの下に表示される場合、ロードバランサーが HTTP 502 エラーの原因です。それらが HTTP_Target_5XX_Count メトリクスの下に表示される場合、ターゲットが原因です。

アクセスログを使用する

elb_status_code が「502」で、target_status_code が「-」の場合、ロードバランサーが HTTP 502 エラーの原因です。elb_status_code が「502」で、target_status_code が「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 との接続を切断したが、ロードバランサーはターゲットに対する未処理のリクエストがあった

ロードバランサーはリクエストを受け取り、ターゲットに転送します。ターゲットはリクエストを受信して処理を開始しますが、ロードバランサーへの接続を早期に切断してしまいます。これは通常、ターゲットの KeepAliveTimeout の期間がロードバランサーのアイドルタイムアウト値よりも短い場合に発生します。KeepAliveTimeout の期間がアイドルタイムアウト値より大きいことを確認してください。

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 プロトコルを使用しているかどうかを確認します。そうでなければ、SSL ハンドシェイクのタイムアウトが原因ではありません。ターゲットグループが HTTPS プロトコルを使用している場合、以下を試してください。

• アクセスログの request_processing_time、target_processing_time、およびresponse_processing_time フィールドがすべて値「-1」に設定されているかどうかを確認します。
• TargetTLSNegotiationErrorCount メトリクスのデータポイントがあるかどうかを確認します。
• 問題の時間枠についてターゲットに対してパケットキャプチャを実行し、SSL ハンドシェイクに関連していることを確認します。その場合は、「パケットキャプチャを実行する」セクションの手順を完了します。
• 暗号またはプロトコルが一致していないか確認します。

登録解除されたターゲットによって処理されたリクエストについて、登録解除の遅延期間が経過した

CloudTrail イベントで、問題の期間中に DeregisterTargets アクションを含む API コールを確認します。問題の期間中に DeregisterTargets を使用した API コールが発生した場合、このエラーは早期に登録解除されたターゲットが原因です。この問題を解決するには、登録解除の遅延時間を長くして、長時間のオペレーションが失敗することなく完了できるようにします。

注: Lambda 関数へのリクエストが失敗した場合、ロードバランサーはアクセスログの error_reason フィールドに Lambda 固有のエラー理由コードを保存します。

ターゲットは 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 の ウェブサイトから) ダウンロードして使用します。