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

解決策

HTTP 502 エラーの原因を特定する

HTTP 502: Bad gateway エラーは、いくつかの要因で発生する場合があります。ターゲットまたはロードバランサーがエラーの原因である可能性があります。エラーの原因を特定するには、CloudWatch メトリクスまたはアクセスログを使用します。

CloudWatch メトリクスを使用する

HTTPCode_ELB_502_Count メトリクスにデータポイントがある場合は、ロードバランサーがエラーの原因です。HTTPCode_Target_5XX_Count メトリクスにデータポイントがある場合は、ターゲットがエラーの原因です。

アクセスログを使用する

elb_status_code が 502 であり、target_status_code が - (ハイフン) の場合は、ロードバランサーがエラーの原因です。elb_status_code が 502 であり、target_status_code が 502 の場合は、ターゲットがエラーの原因です。

HTTP 502 エラーのトラブルシューティング

原因を判断するには、アクセスログを elb_status_code = "502" および target_status_code で絞り込みます。次に、発生している問題に対して解決策を実施します。

ロードバランサーが接続を確立しようとする際、ターゲットがロードバランサーに RCP RSTを返す

接続を確立する際、ターゲットが TCP RST メッセージを返す場合があります。このメッセージは、ロードバランサーがターゲットとの TCP 3 ウェイハンドシェイクを確立できない場合に表示されます。その結果、ロードバランサーはユーザーリクエストをターゲットに転送できません。

TargetConnectionErrorCount メトリクスで、ターゲットがロードバランサーからの接続を拒否しており、TCP RST が発生しているデータポイントの有無を確認します。

アクセスログの request_processing_time、target_processing_time、response_processing_time フィールドの値を -1 に設定します。値を -1 に設定した場合、ロードバランサーへの接続が必要になるため、そのロードバランサーはターゲットにリクエストを送信できません。

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"

ロードバランサーが接続を試みた際、ターゲットから ICMP Destination unreachable (Host unreachable) などの予期しない応答がロードバランサーに返された

アクセスログの request_processing_time、target_processing_time、response_processing_time フィールドの値を -1 に設定します。次に、ロードバランサーのサブネットがターゲットへのトラフィックをターゲットのポートで許可していることを確認します。

ロードバランサーに、ターゲットへの未送信リクエストがあるときにターゲットが接続を閉じ、TCP RST または TCP FIN メッセージが発生した

ロードバランサーはリクエストを受信した後、ターゲットに転送します。ターゲットはリクエストを受信して処理を開始しますが、ロードバランサーへの接続をすぐ閉じました。この現象は、ターゲットで設定した keep-alive タイムアウト期間が、ロードバランサーのアイドルタイムアウト値よりも短い場合に発生します。keep-alive タイムアウト期間は、アイドルタイムアウト値よりも長くする必要があります。

ターゲットの応答が不正な形式であるか、無効な HTTP ヘッダーが含まれている

ターゲットの応答をトラブルシューティングするには、問題が起こる期間において、ターゲットでパケットキャプチャを実行します。

Linux でパケットキャプチャを実行するには、次のコマンドを実行します。

sudo tcpdump -i any -w filename.pcap

重要: ターゲットインスタンスに大量のトラフィックがある場合、tcpdump コレクションが生成するパケットキャプチャ (PCAP) ファイルにより、ディスク容量が影響を受ける可能性があります。大量のトラフィックは、ターゲットインスタンスのサービスにも影響する可能性があります。

Windows の場合は、Wireshark のウェブサイトから Wireshark アプリケーションをダウンロードして使用します。

tcpdump を使用してパケットキャプチャのサンプルをテストする方法については、「Amazon Elastic Compute Cloud (Amazon EC2) 内の Linux または Windows Amazon Elastic Compute Cloud (Amazon EC2) インスタンスと、オンプレミスのホストとの間の、インターネットゲートウェイ経由でのネットワークパフォーマンスに関する問題のトラブルシューティング方法を教えてください」を参照してください。

ロードバランサーがターゲットに接続する際に SSL ハンドシェイクエラーが発生する

ロードバランサーからターゲットの HTTPS リスナーへの TCP 接続は成功しますが、その後の SSL ハンドシェイクでエラーが発生します。その結果、ロードバランサーはリクエストをターゲットに転送できません。

ターゲットグループが HTTPS プロトコルを使用している場合は、問題が起こる期間において、ターゲットでパケットキャプチャを実行します。

サーバーは、ロードバランサーがバックエンド接続に使用するセキュリティポリシーがサポートする TLS 暗号スイートを使用する必要があります。

登録解除されたターゲットが管理するリクエストに対する、登録解除遅延期間が経過した

AWS CloudTrail イベントで、問題が発生する期間において、DeregisterTargets API アクションを確認します。ターゲットの登録解除が早すぎた場合、HTTP 502 エラーが発生します。この問題を解決するには、時間のかかる操作を完了できるように、登録解除遅延期間を長くします。

ターゲットが Lambda 関数である場合の HTTP 502 エラーのトラブルシューティング

AWS Lambda 関数へのリクエストが失敗した場合は、ロードバランサーのアクセスログで error_reason フィールド内の Lambda のエラー理由コードを確認します。

ターゲットは Lambda 関数であり、応答本文が 1 MB を超えている

問題を確認するには、LambdaUserError メトリクスのデータポイントがあるかどうかを確認します。または、ロードバランサーのアクセスログで error_reason フィールドが LambdaResponseTooLarge に設定されているかどうかを確認します。

問題をトラブルシューティングするには、Lambda コードを更新し、エラー処理ロジックを追加します。

ターゲットは、設定したタイムアウトまで応答しなかった Lambda 関数である

問題を確認するには、LambdaUserError メトリクスのデータポイントがあるかどうかを確認します。または、ロードバランサーのアクセスログで error_reason フィールドが LambdaUnhandled に設定されているかどうかを確認します。

ターゲットは Lambda 関数であり、エラーを返した。または Lambda により関数がスロットリングされた

Lambda により関数がスロットリングされたかどうかを確認するには、データポイントで Throttles メトリクスの有無を確認します。Lambda により関数がスロットリングされている場合は、AWS Service Quotas を使用して Lambda 同時実行のクォータ増加をリクエストしてください。

詳細については、「Lambda 呼び出しのスロットリング制限について」を参照してください。