Application Load Balancer のトラブルシューティング

以下の情報は、Application Load Balancer の問題のトラブルシューティングに役立ちます。

リソースマップを使用したヘルスチェックの問題のトラブルシューティング

Application Load Balancer ターゲットがヘルスチェックに失敗している場合は、Elastic Load Balancing リソースマップを使用して異常なターゲットを検索し、失敗理由コードに基づいてアクションを実行できます。

リソースマップへのアクセス

1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

2. ナビゲーションペインで、[ロードバランサー] を選択します。

3. ロードバランサーを選択します。

4. [リソースマップ] タブを選択すると、視覚化されたリソースが表示されます。

リソースマップのナビゲーション

• リソースタイルにカーソルを合わせるか選択して、そのタイルと他のリソースとの関係を強調表示します。

• リソースタイルを選択すると、そのリソースに関する追加の詳細が表示されます。

• タイル内のリソース名を選択して、そのリソースの詳細ページにアクセスします。

リソースマップの使用

リソースマップには、概要 と異常なターゲットマップ の 2 つのビューがあります。概要はデフォルトで選択され、ロードバランサーのすべてのリソースが表示されます。異常なターゲットマップビューを選択すると、Application Load Balancer に関連付けられている各ターゲットグループの異常なターゲットのみが表示されます。

注記

リソースマップ内でヘルスチェックの概要とエラーメッセージを表示するには、リソースの詳細を表示を有効にする必要があります。有効になっていない場合は、各リソースを選択して詳細を表示する必要があります。

ターゲットグループ列には、各ターゲットグループの正常および異常のあるターゲットの概要が表示されます。これにより、すべてのターゲットがヘルスチェックに合格していないか、特定のターゲットのみが不合格かを判断することができます。ターゲットグループ内のすべてのターゲットがヘルスチェックに失敗している場合は、ターゲットグループの設定を確認します。ターゲットグループ名を選択して、新しいタブで詳細ページを開きます。

Targets 列には、各ターゲットの TargetID と現在のヘルスチェックのステータスが表示されます。ターゲットに異常がある場合、ヘルスチェックの失敗理由コードが表示されます。1 つのターゲットがヘルスチェックに失敗した場合は、ターゲットに十分なリソースがあることを確認し、ターゲットで実行されているアプリケーションが使用可能であることを確認します。ターゲット名を選択して、新しいタブで詳細ページを開きます。

エクスポートを選択すると、Application Load Balancer のリソースマップの現在のビューを PDF としてエクスポートするオプションが表示されます。

異常なターゲットステータスのトラブルシューティング

• 異常: HTTP レスポンスの不一致

  • ターゲットで実行されているアプリケーションが、Application Load Balancer のヘルスチェックリクエストに正しい HTTP レスポンスを送信していることを確認します。

  • または、Application Load Balancer のヘルスチェックリクエストを更新して、ターゲットで実行されているアプリケーションからのレスポンスと一致させることもできます。

• 異常: リクエストがタイムアウトしました

  • ターゲットに関連付けられているセキュリティグループとネットワークアクセスコントロールリスト (ACL) と Application Load Balancer が接続をブロックしていないことを確認します。

  • ターゲットに、Application Load Balancer からの接続を受け入れるのに十分なリソースがあることを確認します。

  • ターゲットで実行されているアプリケーションのステータスを確認します。

  • Application Load Balancer のヘルスチェックレスポンスは、各ターゲットのアプリケーションログで表示できます。詳細については、「ヘルスチェックの理由コード」を参照してください。

• 異常： FailedHealthChecks

  • ターゲットで実行されているアプリケーションのステータスを確認します。

  • ターゲットがヘルスチェックポートでトラフィックをリッスンしていることを確認します。

    HTTPS リスナーを使用する場合

    フロントエンド接続に使用するセキュリティポリシーを選択します。バックエンド接続に使用されるセキュリティポリシーは、使用中のフロントエンドセキュリティポリシーに基づいて自動的に選択されます。

    • HTTPS リスナーがフロントエンド接続に TLS 1.3 セキュリティポリシーを使用している場合は、バックエンド接続にELBSecurityPolicy-TLS13-1-0-2021-06セキュリティポリシーが使用されます。

    • HTTPS リスナーがフロントエンド接続に TLS 1.3 セキュリティポリシーを使用していない場合、ELBSecurityPolicy-2016-08セキュリティポリシーがバックエンド接続に使用されます。

    詳細については、「セキュリティポリシー」を参照してください。

  • ターゲットがサーバー証明書とキーをセキュリティポリシーで指定された正しい形式で提供していることを確認します。

  • TLS 接続の場合、ターゲットが 1 つ以上の一致する暗号と、Application Load Balancer によって提供されるプロトコルをサポートしていることを確認します。

登録されたターゲットが実行中でない

ターゲットが InService 状態になるまでに予想以上に時間がかかっている場合、ヘルスチェックに合格していない可能性があります。ターゲットは、ヘルスチェックに合格するまで実行されません。詳細については、「ターゲットグループのヘルスチェック」を参照してください。

インスタンスがヘルスチェックに合格していないことを確認したら、以下の点を確認します。

セキュリティグループでトラフィックが許可されていない

インスタンスに関連付けられたセキュリティグループでは、ヘルスチェックポートとヘルスチェックプロトコルを使用してロードバランサーからのトラフィックを許可する必要があります。インスタンスセキュリティグループにルールを追加して、ロードバランサーセキュリティグループからのすべてのトラフィックを許可できます。また、ロードバランサーのセキュリティグループは、インスタンスへのトラフィックを許可する必要があります。

ネットワークアクセスコントロールリスト (ACL) ではトラフィックが許可されない

インスタンスのサブネットに関連付けられたネットワーク ACL では、ヘルスチェックポートでインバウンドトラフィックを許可し、一時ポート (1024-65535) でアウトバウンドトラフィックを許可する必要があります。ロードバランサーノードのサブネットに関連付けられたネットワーク ACL では、一時ポートでインバウンドトラフィックを許可し、ヘルスチェックおよび一時ポートでアウトバウンドトラフィックを許可する必要があります。

ping パスが存在しない

ヘルスチェックのターゲットページを作成し、そのパスを ping パスとして指定します。

接続がタイムアウトする

最初に、ターゲットのプライベート IP アドレスとヘルスチェックプロトコルを使用して、ネットワーク内から直接ターゲットに接続できることを確認します。接続できない場合は、インスタンスの使用率が高すぎないかどうかを確認し、ビジー状態で応答できない場合はさらにターゲットをターゲットグループに追加します。接続できる場合、ヘルスチェックのタイムアウト時間の前に、ターゲットページが応答していない可能性があります。ヘルスチェック用のよりシンプルなターゲットページを選択するか、ヘルスチェックの設定を調整します。

ターゲットが正常なレスポンスコードを返さなかった

デフォルトの成功コードは 200 ですが、ヘルスチェックを設定するときにオプションで成功コードを追加して指定できます。ロードバランサーで予期される成功コードを確認し、成功時にアプリケーションがそれらのコードを返すよう設定されていることを確認します。

ターゲットレスポンスコードの形式が正しくないか、ターゲットへの接続中にエラーが発生しました

アプリケーションがロードバランサーの正常性チェックリクエストに応答することを確認します。一部のアプリケーションでは、正常性チェックに応答するために追加の設定が必要です。例えば、ロードバランサーから送信された HTTP ホストヘッダーに応答するための仮想ホスト設定などです。ホストヘッダー値には、ターゲットのプライベート IP アドレスが含まれ、デフォルトのポートを使用しない場合はヘルスチェックポートが続きます。ターゲットがデフォルトのヘルスチェックポートを使用する場合、ホストヘッダー値にはターゲットのプライベート IP アドレスのみが含まれます。例えば、ターゲットのプライベート IP アドレスが で10.0.0.10、ヘルスチェックポートが の場合8080、ロードバランサーによってヘルスチェックで送信される HTTP ホストヘッダーは ですHost: 10.0.0.10:8080。ターゲットのプライベート IP アドレスが で10.0.0.10、ヘルスチェックポートが 80の場合、ロードバランサーによってヘルスチェックで送信される HTTP ホストヘッダーは ですHost: 10.0.0.10。アプリケーションの正常性チェックを正常に実行するには、そのホストに応答する仮想ホスト設定、またはデフォルト設定が必要になる場合があります。正常性チェックリクエストは、次の属性を有しています。すなわち、User-Agent が ELB-HealthChecker/2.0 に設定され、メッセージヘッダーフィールドの行終端記号はシーケンス CRLF、ヘッダーは最初の空の行で終了し、その後に CRLF が続きます。

クライアントがインターネット向けロードバランサーに接続できない

ロードバランサーがリクエストに応答しない場合は、以下の点を確認します。

インターネット向けロードバランサーがプライベートサブネットにアタッチされている

ロードバランサーのパブリックサブネットを指定する必要があります。パブリックサブネットには Virtual Private Cloud (VPC) のインターネットゲートウェイへのルートがあります。

セキュリティグループまたはネットワーク ACL でトラフィックが許可されていない

ロードバランサーのセキュリティグループ、およびロードバランサーサブネットのネットワーク ACL で、クライアントからのインバウンドトラフィックとクライアントへのアウトバウンドトラフィックをリスナーポートで許可する必要があります。

ロードバランサーがカスタムドメインに送信されたリクエストを受信しません

ロードバランサーがカスタムドメインに送信されたリクエストを受信しない場合は、以下の点を確認します。

カスタムドメイン名がロードバランサーの IP アドレスを解決しません

• コマンドラインインターフェイスを使用して、カスタムドメイン名がどの IP アドレスを解決するのかを確認します。

  • Linux、macOS、または Unix — ターミナルで dig コマンドを使用できます。例 dig example.com

  • Windows — コマンドプロンプトで nslookup コマンドを使用できます。例 nslookup example.com

• コマンドラインインターフェイスを使用して、ロードバランサーの DNS 名がどの IP アドレスを解決するのかを確認します。

• 2 つの出力の結果を比較します。IP アドレスは一致する必要があります。

Route 53 を使用してカスタムドメインをホストしている場合は、Amazon Route 53 開発者ガイドの 「ドメインがインターネットで利用できない」を参照してください。

ロードバランサーに送信された HTTPS リクエストは「NET::ERR_CERT_COMMON_NAME_INVALID」を返します

ロードバランサーから HTTPS リクエストが NET::ERR_CERT_COMMON_NAME_INVALID を受信している場合は、次の原因が考えられます。

• HTTPS リクエストで使用されているドメイン名が、リスナーに関連付けられた ACM 証明書で指定されている代替名と一致しません。

• ロードバランサーのデフォルトの DNS 名が使用されています。*.amazonaws.com ドメインに対してパブリック証明書をリクエストできないため、デフォルトの DNS 名を使用して HTTPS リクエストを実行できません。

ロードバランサーが処理時間の増加を示しています

ロードバランサーは、設定に基づいて処理時間を異なる方法でカウントします。

• AWS WAF が Application Load Balancer に関連付けられ、クライアントが HTTP POST リクエストを送信すると、POST リクエストのデータを送信する時間はロードバランサーのアクセスログの request_processing_timeフィールドに反映されます。この動作は HTTP POST リクエストで想定されるものです。

• AWS WAF が Application Load Balancer に関連付けられておらず、クライアントが HTTP POST リクエストを送信した場合、POST リクエストのデータを送信する時間はロードバランサーのアクセスログの target_processing_timeフィールドに反映されます。この動作は HTTP POST リクエストで想定されるものです。

ロードバランサーは、レスポンスコード 000 を送信します。

HTTP/2 接続では、いずれかのヘッダーの圧縮された長さが 8 K バイトを超える場合、または 1 つの接続を介して処理されるリクエスト数が 10,000 を超える場合、ロードバランサーは GOAWAY フレームを送信し、TCP FIN を使用して接続を閉じます。

ロードバランサーが HTTP エラーを生成する

次の HTTP エラーは、ロードバランサーで生成されます。ロードバランサーはクライアントに HTTP コードを送信し、アクセスログにリクエストを保存して、HTTPCode_ELB_4XX_Count または HTTPCode_ELB_5XX_Count メトリクスを増やします。

エラー

• HTTP 400: Bad request
• HTTP 401: Unauthorized
• HTTP 403: Forbidden
• HTTP 405: Method not allowed
• HTTP 408: Request timeout
• HTTP 413: Payload too large
• HTTP 414: URI too long
• HTTP 460
• HTTP 463
• HTTP 464
• HTTP 500: Internal server error
• HTTP 501: Not implemented
• HTTP 502: Bad gateway
• HTTP 503: Service Unavailable
• HTTP 504: Gateway Timeout
• HTTP 505: バージョンはサポートされていません
• HTTP 507: ストレージ不足
• HTTP 561: Unauthorized

HTTP 400: Bad request

考えられる原因:

• クライアントが HTTP 仕様を満たさない誤った形式のリクエストを送信した。

• リクエストヘッダーが、リクエスト行あたり 16 K、1 つのヘッダーあたり 16 K、またはリクエストヘッダー全体に対して 64 K を超えている。

• クライアントが、リクエスト本文全体を送信する前に接続を閉じた。

HTTP 401: Unauthorized

ユーザーを認証するようリスナールールを設定しましたが、以下のいずれかが該当しません。

• OnUnauthenticatedRequest が認証されていないユーザーを拒否するように設定されているか、IdP によってアクセスが拒否されました。

• IdP によって返されるクレームのサイズが、ロードバランサーによってサポートされる最大サイズを超えています。

• クライアントがホストヘッダーなしで HTTP/1.0 リクエストを送信し、ロードバランサーはリダイレクト URL を生成できませんでした。

• リクエストされたスコープで ID トークンが返さません。

• クライアントのログインがタイムアウトする前にログインプロセスが完了しません。詳細については、「クライアントログインタイムアウト」を参照してください。

HTTP 403: Forbidden

Application Load Balancer へのリクエストをモニタリングするように AWS WAF ウェブアクセスコントロールリスト (ウェブ ACL) を設定し、リクエストがブロックされました。

HTTP 405: Method not allowed

クライアントが、Application Load Balancer でサポートされていない TRACE メソッドを使用しました。

HTTP 408: Request timeout

アイドルタイムアウト期間の期限が切れる前に、クライアントからデータが送信されませんでした。TCP キープアライブを送信しても、このタイムアウトを防ぐことはできません。各アイドルタイムアウト期間が経過する前に、1 バイト以上のデータを送信します。必要に応じて、アイドルタイムアウト期間を長くします。

HTTP 413: Payload too large

考えられる原因:

• ターゲットは Lambda 関数で、リクエストボディが 1 MB を超えています。

• リクエストヘッダーが、リクエスト行あたり 16 K、1 つのヘッダーあたり 16 K、またはリクエストヘッダー全体に対して 64 K を超えている。

HTTP 414: URI too long

リクエストの URL またはクエリ文字列パラメータが大きすぎます。

HTTP 460

ロードバランサーはクライアントからリクエストを受信したが、クライアントはアイドルタイムアウトが経過する前に、ロードバランサーとの接続を閉じました。

クライアントのタイムアウト期間がロードバランサーのアイドルタイムアウト期間より長いかどうか確認してください。クライアントのタイムアウト期間が経過する前に、ターゲットがクライアントにレスポンスを返すことを確認するか、クライアントがサポートする場合は、クライアントのタイムアウト期間を増やしてロードバランサーのアイドルタイムアウトに合わせます。

HTTP 463

多すぎる IP アドレスを含む X-Forwarded-For リクエストヘッダーがロードバランサーに送信されました。IP アドレスの上限は 30 です。

HTTP 464

ロードバランサーは、ターゲットグループプロトコルのバージョン構成と互換性のない着信リクエストプロトコルを受信しました。

考えられる原因:

• リクエストプロトコルは HTTP/1.1 であるが、ターゲットグループのプロトコルバージョンが gRPC または HTTP/2 である。

• リクエストプロトコルは gRPC であるが、ターゲットグループのプロトコルバージョンが HTTP/1.1 である。

• リクエストプロトコルは HTTP/2 であり、リクエストは POST ではないが、ターゲットグループのプロトコルバージョンが gRPC である。

HTTP 500: Internal server error

考えられる原因:

• AWS WAF ウェブアクセスコントロールリスト (ウェブ ACL) を設定しましたが、ウェブ ACL ルールの実行中にエラーが発生しました。

• ロードバランサーは、IdP トークンのエンドポイントまたは IdP ユーザー情報エンドポイントと通信できません。

  • IdP の DNS がパブリックに解決可能であることを確認します。

  • ロードバランサーのセキュリティグループおよび VPC のネットワーク ACL がこれらのエンドポイントに対するアウトバウンドアクセスを許可していることを検証します。

  • VPC がインターネット接続されていることを確認します。内部向けロードバランサーがある場合は、NAT ゲートウェイを使用してインターネットアクセスを有効にします。

• IdP から受信したユーザークレームが 11 KB を超えています。

HTTP 501: Not implemented

サポートされていない値を含む Transfer-Encoding ヘッダーがロードバランサーに送信されました。Transfer-Encoding でサポートされている値は、chunked と identity です。代わりに、Content-Encoding ヘッダーを使用することができます。

HTTP 502: Bad gateway

考えられる原因:

• 接続の確立を試みているときに、ロードバランサーがターゲットから TCP RST を受信した。

• 接続の確立を試みているときに、ロードバランサーがターゲットから予期しないレスポンスを受信した (例: 「ICMP Destination unreachable (Host unreachable) (ICMP 送信先に到達できません (ホストに到達できません))」など)。ターゲットポートでロードバランサーサブネットからターゲットへのトラフィックが許可されているかどうかを確認します。

• ロードバランサーにターゲットへの未処理のリクエストがあるときに、ターゲットが TCP RST または TCP FIN との接続を閉じた。ターゲットのキープアライブ期間がロードバランサーのアイドルタイムアウト値よりも短いことを確認します。

• ターゲットのレスポンス形式が正しくないか、有効でない HTTP ヘッダーが含まれている。

• ターゲットレスポンスヘッダーは、レスポンスヘッダー全体で32 K を超えました。

• 登録解除されたターゲットによって処理されていたリクエストで登録解除の遅延期間が経過しました。時間のかかるオペレーションが完了できるように、遅延期間を増やします。

• ターゲットは Lambda 関数で、レスポンスボディが 1 MB を超えています。

• ターゲットは、設定されたタイムアウトに達する前に応答しなかった Lambda 関数です。

• ターゲットとなるのは、エラーを返した Lambda 関数、または Lambda サービスがスロットリングした関数です。

• ロードバランサーがターゲットに接続するときに SSL ハンドシェイクエラーが発生しました。

詳細については、 AWS サポートナレッジセンターの「Application Load Balancer HTTP 502 エラーのトラブルシューティング方法」を参照してください。

HTTP 503: Service Unavailable

ロードバランサーのターゲットグループに登録済みターゲットがありません。

HTTP 504: Gateway Timeout

考えられる原因:

• ロードバランサーは、接続タイムアウトが期限切れになる (10 秒) 前にターゲットへの接続の確立に失敗した。

• ロードバランサーはターゲットへの接続を確立したが、アイドルタイムアウト期間が経過する前にターゲットが応答しなかった。

• サブネットのネットワーク ACL で、ターゲットから一時ポート (1024-65535) のロードバランサーノードへのトラフィックが許可されなかった。

• ターゲットがエンティティ本文より大きな Content-Length ヘッダーを返した。ロードバランサーが欠落しているバイトを待機してタイムアウトした。

• ターゲットは Lambda 関数であり、接続タイムアウトが期限切れになる前に Lambda サービスが応答しませんでした。

• ロードバランサーがターゲットに接続するときに SSL ハンドシェイクタイムアウト (10 秒) が発生しました。

HTTP 505: バージョンはサポートされていません

ロードバランサーが予期しない HTTP バージョンリクエストを受信しました。例えば、ロードバランサーが HTTP/1 接続を確立したが、HTTP/2 リクエストを受信したとします。

HTTP 507: ストレージ不足

リダイレクト URL が長すぎます。

HTTP 561: Unauthorized

リスナールールがユーザーを認証するように設定されていますが、IdP がユーザーの認証時にエラーコードを返しました。関連するエラー理由コードについてはアクセスログを確認してください。

ターゲットが HTTP エラーを生成する

ロードバランサーはターゲットからの有効な HTTP レスポンスを、HTTP エラーを含めてクライアントに転送します。ターゲットによって生成された HTTP エラーは、HTTPCode_Target_4XX_Count および HTTPCode_Target_5XX_Count メトリクスに記録されます。

AWS Certificate Manager 証明書は使用できません

Application Load Balancer で HTTPS リスナーを使用することを決定する場合、 AWS Certificate Manager は証明書を発行する前にドメインの所有権を検証する必要があります。設定中にこのステップを実行しなかった場合、証明書は Pending Validation 状態のままとなり、検証されるまで使用できません。

• E メール検証を使用する場合は、「AWS Certificate Manager ユーザーガイド」の「E メール検証」を参照してください。

• DNS での検証を使用する場合は、「AWS Certificate Manager ユーザーガイド」の「DNS での検証」を参照してください。

複数行のヘッダーはサポートされていません

Application Load Balancer は、message/http メディアタイプヘッダーを含め、複数行のヘッダーをサポートしていません。複数行のヘッダーが提供されると、Application Load Balancer は、コロン文字「:」を付加してターゲットに渡します。