Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

Network Load Balancer をトラブルシューティングする

フォーカスモード
Network Load Balancer をトラブルシューティングする - Elastic Load Balancing

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

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

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

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

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

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

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

インスタンスに関連付けられたセキュリティグループでは、ヘルスチェックポートとヘルスチェックプロトコルを使用してロードバランサーからのトラフィックを許可する必要があります。詳細については、「ターゲットセキュリティグループ」を参照してください。

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

インスタンスのサブネットとロードバランサーのサブネットACLに関連付けられたネットワークは、ロードバランサーからのトラフィックとヘルスチェックを許可する必要があります。詳細については、「ネットワーク ACLs」を参照してください。

リクエストがターゲットにルーティングされない

以下を確認します。

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

インスタンスに関連付けられているセキュリティグループでは、リスナーポートからクライアント IP アドレス (ターゲットがインスタンス ID で指定されている場合) またはロードバランサーノード (ターゲットが IP アドレスで指定されている場合) へのトラフィックが許可されている必要があります。詳細については、「ターゲットセキュリティグループ」を参照してください。

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

のサブネットACLsに関連付けられたネットワークは、ロードバランサーとターゲットがリスナーポートで双方向に通信できるようにVPCする必要があります。詳細については、「ネットワーク ACLs」を参照してください。

有効になっていないアベイラビリティーゾーンにターゲットがある

ターゲットをアベイラビリティーゾーンに登録したが、アベイラビリティーゾーンを有効にしていない場合、登録したターゲットはロードバランサーからのトラフィックを受信しません。

インスタンスがピア接続されている VPC

ロードバランサー とVPCピアリング接続されている にインスタンスがある場合はVPC、インスタンス ID ではなく IP アドレスでロードバランサーに登録する必要があります。

ターゲットが受け取るヘルスチェックリクエストが想定よりも多い

Network Load Balancer のヘルスチェックは分散され、コンセンサスメカニズムを使用してターゲットのヘルスを判断します。そのため、ターゲットは HealthCheckIntervalSeconds 設定で設定されているヘルスチェック数よりも多くのヘルスチェックを受けます。

ターゲットが受け取るヘルスチェックリクエストが想定よりも少ない

net.ipv4.tcp_tw_recycle が有効化されているかどうかを確認します。この設定は、ロードバランサーに関する問題が発生することが判っています。net.ipv4.tcp_tw_reuse 設定の方が安全であると見なされています。

異常なターゲットがロードバランサーからリクエストを受信する

この状態は、登録されているすべてのターゲットに異常がある場合に発生します。少なくとも 1 つの正常なターゲットが登録されている場合、Network Load Balancer は、この正常な登録済みターゲットに対してのみリクエストをルーティングします。

登録されているのが異常なターゲットのみの場合、Network Load Balancer は、登録されたすべてのターゲットに対しリクエストをルーティングします。これは、fail-open モードと呼ばれます。Network Load Balancer は、すべてのターゲットが異常DNSで、それぞれのアベイラビリティーゾーンにリクエストを送信する正常なターゲットがない場合に、 からすべての IP アドレスを削除する代わりにこれを行います。

ホストヘッダーの不一致によるターゲットの失敗HTTPまたはHTTPSヘルスチェック

ヘルスチェックリクエストのHTTPホストヘッダーには、ターゲットの IP アドレスとヘルスチェックポートではなく、ロードバランサーノードの IP アドレスとリスナーポートが含まれます。受信リクエストをホストヘッダーでマッピングする場合は、ヘルスチェックが任意のHTTPホストヘッダーと一致することを確認する必要があります。もう 1 つのオプションは、別のポートに別のHTTPサービスを追加し、代わりにそのポートをヘルスチェックに使用するようにターゲットグループを設定することです。または、TCPヘルスチェックの使用を検討してください。

セキュリティグループをロードバランサーに関連付けできない

Network Load Balancer がセキュリティグループなしで作成された場合、作成後にセキュリティグループをサポートすることはできません。セキュリティグループは、作成中にロードバランサに関連付けるか、または最初にセキュリティグループを使用して作成した既存のロードバランサーに関連付けることができます。

すべてのセキュリティグループを削除できない

セキュリティグループを使用して Network Load Balancer が作成された場合は、常に 1 つ以上のセキュリティグループが関連付けられている必要があります。ロードバランサーからすべてのセキュリティグループを同時に削除することはできません。

TCP_ELB_Reset_Count メトリクスの増加

クライアントが Network Load Balancer を介して行うTCPリクエストごとに、その接続の状態が追跡されます。アイドルタイムアウトよりも長い時間、クライアントからもターゲットからもその接続経由でデータが送信されない場合、接続は閉じられます。アイドルタイムアウト期間が経過した後にクライアントまたはターゲットがデータを送信すると、接続が無効になったことを示すTCPRSTパケットを受け取ります。さらに、ターゲットが異常になった場合、ロードバランサーは、異常なターゲットがロードバランサーをフェイルオープンにトリガーしない限り、ターゲットに関連付けられたクライアント接続で受信したパケットTCPRSTの を送信します。

TCP_ELB_Reset_Count メトリクスの増加直前または増加直後にUnhealthyHostCountメトリクスにスパイクが表示された場合は、ターゲットが失敗し始めていたが異常とマークされなかったためにTCPRSTパケットが送信された可能性があります。ターゲットが異常とマークTCP_ELB_Reset_Countされずに が永続的に増加する場合は、期限切れのVPCフローでデータを送信するクライアントのフローログを確認できます。

ターゲットからそのロードバランサーへのリクエストが接続タイムアウトになる

クライアント IP 保存がターゲットグループで有効になっているかどうかを確認します。 NATループバックはヘアピニングとも呼ばれ、クライアント IP 保存が有効になっている場合はサポートされません。インスタンスが、登録されているロードバランサーのクライアントである場合で、クライアント IP 保護が有効になっている場合、リクエストが別のインスタンスにルーティングされる場合のみ接続が成功します。送信元と同じインスタンスにリクエストがルーティングされている場合、送信元と宛先の IP アドレスが同じであるため、接続がタイムアウトします。

インスタンスが、それが登録されているロードバランサーにリクエストを送信する必要がある場合は、次のいずれかを実行します。

  • クライアント IP の無効化

  • 通信する必要があるコンテナが異なるコンテナインスタンスにあることを確認します。

Network Load Balancer にターゲットを移動する際にパフォーマンスが低下する

Classic Load Balancer と Application Load Balancer はどちらも接続の多重化を使用しますが、Network Load Balancer では使用しません。したがって、ターゲットは Network Load Balancer の背後でより多くのTCP接続を受信できます。必ず、ターゲットが受信する可能性のある接続リクエストのボリュームを処理できるようにしてください。

Network Load Balancer がVPCエンドポイントサービスに関連付けられている場合、一意の各ターゲット (IP アドレスとポート) に対して 55,000 の同時接続または 1 分あたり約 55,000 の接続をサポートします。これらの接続数を超えた場合、ポート割り当てエラーが発生する可能性が高くなります。ポート割り当てエラーは、PortAllocationErrorCount メトリクスを使用して追跡できます。ポート割り当てエラーを修正するには、ターゲットグループにさらに多くのターゲットを追加します。詳細については、「CloudWatch Network Load Balancer の メトリクス」を参照してください。

断続的なTCP接続確立の失敗またはTCP接続確立の遅延

クライアント IP アドレスの保存が有効になっている場合、クライアントは同じ送信元一時ポートを使用して異なる送信先 IP アドレスに接続できます。これらの送信先 IP アドレスは、クロスゾーン負荷分散が有効になっている場合は同じロードバランサー (異なるアベイラビリティーゾーン内) から、または同じターゲット IP アドレスと登録されたポートを使用する異なる Network Load Balancer から取得できます。この場合、これらの接続が同じターゲット IP アドレスとポートにルーティングされると、ターゲットは同じクライアント IP アドレスとポートから送信されるため、重複した接続が表示されます。これにより、これらの接続の 1 つを確立するときに接続エラーや遅延が発生します。これは、クライアントの前にあるNATデバイスと、複数の Network Load Balancer の IP アドレスに同時に接続するときに同じ送信元 IP アドレスと送信元ポートが割り当てられている場合に頻繁に発生します。

このタイプの接続エラーを減らすには、クライアントまたはNATデバイスによって割り当てられたソースエフェメラルポートの数を増やすか、ロードバランサーのターゲットの数を増やします。これらの接続障害後に再接続するときに使用するソースポートをクライアントが変更することをお勧めします。このような接続エラーを防ぐために、単一の Network Load Balancer を使用している場合は、クロスゾーン負荷分散を無効にすることを検討できます。複数の Network Load Balancer を使用している場合は、複数のターゲットグループに登録されている同じターゲット IP アドレスとポートを使用しないことを検討できます。または、クライアント IP 保存を無効にすることを検討することもできます。クライアント IP が必要な場合は、Proxy Protocol v2 を使用して取得できます。Proxy Protocol v2 の詳細については、「」を参照してくださいProxy Protocol

ロードバランサーのプロビジョニング時に発生する可能性のあるエラー

Network Load Balancer がプロビジョニング中に失敗する理由の 1 つは、既に割り当てられている、または他の場所で割り当てられている IP アドレス (インスタンスのセカンダリ IP アドレスとして割り当てられるなど) を使用する場合ですEC2。この IP アドレスにより、ロードバランサーの設定が妨げられ、状態は failed になります。この問題は、関連付けられた IP アドレスの割り当てを解除し、作成プロセスを再試行することで解決できます。

DNS 名前解決に含まれる IP アドレスが有効なアベイラビリティーゾーンよりも少ない

アベイラビリティーゾーンに少なくとも 1 つの正常なホストがある場合、Network Load Balancer は有効なアベイラビリティーゾーンごとに IP アドレスを 1 つ提供するのが理想です。特定のアベイラビリティーゾーンに正常なホストがなく、クロスゾーン負荷分散が無効になっている場合、その AZ に対応する Network Load Balancer の IP アドレスは から削除されますDNS。

例えば、Network Load Balancer が有効なアベイラビリティーゾーンを 3 つ持っており、すべてのアベイラビリティーゾーンには、正常なターゲットインスタンスが少なくとも 1 つ登録されているとします。

  • アベイラビリティーゾーン A に登録されたターゲットインスタンス (複数可) が異常になると、Network Load Balancer のアベイラビリティーゾーン A の対応する IP アドレスが から削除されますDNS。

  • 有効なアベイラビリティーゾーンのいずれか 2 つに正常な登録済みターゲットインスタンスがない場合 (複数可)、Network Load Balancer のそれぞれの 2 つの IP アドレスが から削除されますDNS。

  • 有効なすべてのアベイラビリティーゾーンに正常な登録済みターゲットインスタンス (複数可) がない場合、フェイルオープンモードが有効になり、結果AZsで有効になっている 3 つの のすべての IP アドレスDNSが提供されます。

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

Network Load Balancer ターゲットがヘルスチェックに合格しなかった場合は、リソースマップを使用して異常なターゲットを見つけ、エラー理由コードに基づいてアクションを実行できます。詳細については、「Network Load Balancer リソースマップを表示する」を参照してください。

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

注記

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

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

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

Export を選択すると、Network Load Balancer のリソースマップの現在のビューを としてエクスポートできますPDF。

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

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

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

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

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

  • 異常: FailedHealthChecks

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

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

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

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

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

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

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

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

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.