Application Load Balancer のトラブルシューティング - Elastic Load Balancing
登録されたターゲットが実行中でないクライアントがインターネット向けロードバランサーに接続できないロードバランサーがカスタムドメインに送信されたリクエストを受信しませんロードバランサーに送信された HTTPS リクエストは「NET::ERR_CERT_COMMON_NAME_INVALID」を返しますロードバランサーが処理時間の増加を示していますロードバランサーは、レスポンスコード 000 を送信します。ロードバランサーが HTTP エラーを生成するターゲットが HTTP エラーを生成するAWS Certificate Manager 証明書を使用できません複数行のヘッダーはサポートされていませんリソースマップを使用して異常なターゲットをトラブルシューティングする

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

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

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

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

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

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

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

ネットワークアクセスコントロールリスト (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 仕様を満たさない誤った形式のリクエストを送信した。

  • リクエストヘッダーが、リクエスト行あたり 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 または SecurityGroup のポリシーで、ターゲットから一時ポート (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 は、コロン文字「:」を付加してターゲットに渡します。

リソースマップを使用して異常なターゲットをトラブルシューティングする

Application Load Balancer のターゲットがヘルスチェックに失敗した場合は、リソースマップを使用することで、異常なターゲットを特定し、障害理由コードに基づいたアクションを取ることができます。詳細については、「Application Load Balancer リソースマップを表示する」を参照してください。

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

注記

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

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

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

[エクスポート] を選択すると、Application Load Balancer のリソースマップの現在の画面を PDF でエクスポートできます。

インスタンスがヘルスチェックに合格していないことを確認したら、エラー理由コードに基づいて、以下の点を確認します。

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

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

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

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

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

    • ターゲットに 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 セキュリティポリシーはバックエンド接続に使用されます。

      詳細については、「Security policies」を参照してください。

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

    • ターゲットが、1 つ以上の一致する暗号と、TLS ハンドシェイクを確立するために Application Load Balancer が提供するプロトコルをサポートしていることを確認します。