すべてのプロダクト
Search
ドキュメントセンター

Server Load Balancer:NLB のヘルスチェック失敗のトラブルシューティング

最終更新日:Apr 21, 2026

Network Load Balancer (NLB) のヘルスチェックは、バックエンドサーバーが正常に実行されていることを確認するために使用されます。 ヘルスチェックが失敗した場合、通常はバックエンドサーバーに問題があることを示します。 ただし、ヘルスチェック設定やバックエンドサーバーの設定が正しくない場合も、失敗の原因となることがあります。 このトピックでは、これらの失敗をトラブルシューティングする方法について説明します。

症状

NLB インスタンスのリスナーの ヘルスチェックステータス異常 と表示されます。

原因

初めてヘルスチェックを設定した後に失敗する場合、まずヘルスチェック設定を確認してください。 失敗は、次のいずれかの理由が原因である可能性があります。

  • ヘルスチェックパラメーターが正しくない

  • リスナーポートの問題

ヘルスチェックが正常に実行された後に失敗する場合、まずバックエンドサーバーを確認してください。 失敗は、次のいずれかの理由が原因である可能性があります。

  • セキュリティソフトウェアの問題

  • ルート設定が正しくない

  • バックエンドサーバーの高負荷

ソリューション

初回設定後にヘルスチェックが失敗する場合

原因 1:ヘルスチェックパラメーターが正しくない

  1. NLB コンソールにログインします。

  2. トップナビゲーションバーで、NLB インスタンスがデプロイされているリージョンを選択します。

  3. 左側のナビゲーションウィンドウで、NLB > [サーバーグループ] を選択します。

  4. サーバーグループ ページで、お使いの NLB インスタンスのサーバーグループを見つけ、ヘルスチェック設定の変更 をクリックします。

  5. ヘルスチェック設定の変更 ダイアログボックスで、ヘルスチェックパラメーターが正しいことを確認します。デフォルトのヘルスチェックパラメーターを使用することを推奨します。

原因 2:リスナーポートの問題

ヘルスチェックポートの確認

  1. NLB コンソールにログインします。

  2. トップナビゲーションバーで、NLB インスタンスがデプロイされているリージョンを選択します。

  3. 左側のナビゲーションウィンドウで、NLB > [サーバーグループ] を選択します。

  4. サーバーグループ ページで、ご利用の NLB インスタンスのサーバーグループを見つけ、サーバーグループ ID をクリックします。

  5. サーバーグループの詳細ページで、バックエンドサーバー タブをクリックして、バックエンドサーバーのポートを表示および記録します。

  6. サーバーグループの詳細ページで詳細 タブをクリックし、ヘルスチェック セクションでヘルスチェック設定の変更 をクリックします。ヘルスチェック設定の変更 ダイアログボックスで、ヘルスチェックパラメーターを表示して記録します。

TCP リスナー

  1. バックエンドサーバーにログインし、次のコマンドを実行してヘルスチェックポートへの接続をテストします。

    バックエンドサーバーへのログイン方法の詳細については、「ECS インスタンスへのリモート接続ガイド」をご参照ください。

    telnet [$IP] [$Port]
    説明
    • [$IP] はバックエンドサーバーのプライベート IP アドレスです。

    • [$Port] はサーバーグループのヘルスチェック用のプローブポートです。 特定のプローブポートが設定されていない場合、これはデフォルトでバックエンドサーバーのポートになります。

  2. コマンドの出力を確認します。

    次の図に示すように、「telnet: connect to address [$IP]: Connection refused」のような応答は、接続が拒否され、ヘルスチェックポートが応答していないことを示します。image

    次の図に示すように、「Connected to [$IP]」のような応答は、バックエンドサーバーのヘルスチェックポートが正常にリッスンしていることを示します。image

UDP リスナー

  1. バックエンドサーバーにログインし、次のコマンドを実行してヘルスチェックポートの状態を確認します。

    バックエンドサーバーへのログイン方法の詳細については、「ECS インスタンスへのリモート接続ガイド」をご参照ください。

    netstat -anu | grep [$IP]:[$Port]
    説明
    • [$IP] はバックエンドサーバーのプライベート IP アドレスです。

    • [$Port] はサーバーグループのヘルスチェック用のプローブポートです。 特定のプローブポートが設定されていない場合、これはデフォルトでバックエンドサーバーのポートになります。

  2. コマンドの出力を確認します。

    次の図に示すように、[$IP]:[$Port] のエントリが返されない場合、バックエンドサーバーのヘルスチェックポートは応答していません。

    image

    次の図に示すように、[$IP]:[$Port] のエントリが返される場合、バックエンドサーバーのヘルスチェックポートは正常にリッスンしています。image

バックエンドサーバーでアプリケーションが実行されており、そのポートがヘルスチェックポートと一致することを確認します。 このセクションでは、Nginx サービスを例として使用します。

  1. 異常なバックエンドサーバーにログインし、次のコマンドを実行して Nginx サービスの状態を確認します。

    systemctl status nginx
  2. 以下のような応答は、サービスが実行されていないことを示します。

    image

  3. 次のコマンドを実行して Nginx サービスを開始します。

    systemctl start nginx
  4. 次に、次のコマンドを再度実行して Nginx サービスの状態を確認します。

    systemctl status nginx

    以下のような応答は、サービスが実行されていることを示します。image

  5. NLB コンソールにログインし、次の手順を実行します。

    1. 左側のナビゲーションウィンドウで、NLB > サーバーグループ を選択します。

    2. サーバーグループ ページで、対象のサーバーグループを探し、操作 列の ヘルスチェック設定の変更 をクリックします。

    3. ヘルスチェック設定の変更 ダイアログボックスで、ヘルスチェックポート [$Port] を確認します。image

    4. ヘルスチェックが正常かどうかを確認します。 正常でない場合は、次のコマンドを実行して Nginx サービスのリスナーポートを確認します。

      netstat -tanp |grep nginx
  6. 出力が次のようになっている場合、リッスンポートが [$Port] の値と一致しません。

    image

    /etc/nginx/nginx.conf ファイルを編集し、listen の値を [$Port] に変更して保存し、終了します。

    説明

    listen の値を変更できない場合は、代わりにヘルスチェックポートを変更できます。 詳細については、「NLB のリスナー」をご参照ください。

    image

  7. 次のコマンドを実行して Nginx サービスを再起動します。 しばらく待ってから、ヘルスチェックが正常であることを確認します。

    systemctl restart nginx

正常実行後にヘルスチェックが失敗する場合

原因 1:セキュリティソフトウェアの問題

NLB インスタンスは、VPC CIDR ブロックを使用してバックエンドサーバーと通信します。 iptables などのバックエンドサーバー上のセキュリティソフトウェアが、この CIDR ブロックからのトラフィックをブロックしていないことを確認してください。 このトラフィックがブロックされると、ヘルスチェックは失敗します。 このセクションでは、iptables を例として、ブロックされている IP アドレス範囲を確認します。

  1. NLB コンソールにログインし、NLB インスタンスがバックエンドサーバーとの通信に使用するローカル IP アドレスを表示します。

    image

  2. 異常なバックエンドサーバーインスタンスにログインし、次のコマンドを実行してフィルターテーブル内のすべてのルールを表示します。

    iptables -nL

    以下のような応答は、バックエンドサーバーが NLB インスタンスのローカル IP アドレスからのリクエストを拒否していることを示します。

    image

  3. 次のコマンドを実行して、ブロッキングルールを削除します。

    iptables -t filter -D INPUT -s 192.168.20.75 -j DROP  # この IP アドレスはデモ用です。
    説明

    コマンド内の IP アドレスを、ご利用の NLB インスタンスが使用するローカル IP アドレスに置き換えてください。

  4. 次のコマンドを実行して、NLB VPC CIDR ブロックからのリクエストがブロックされなくなったことを確認します。

    iptables -nL
  5. NLB リスナーのヘルスチェックステータス正常に変更されることを確認します。

原因 2:ルート設定が正しくない

バックエンドサーバー上の NLB インスタンスの VPC CIDR ブロックに対するルートが正しくないと、NLB インスタンスがヘルスチェックの応答を受信できなくなり、失敗の原因となります。 このセクションでは、Linux の route コマンドを例として、ルート設定を確認します。

  1. NLB コンソールにログインし、NLB インスタンスがバックエンドサーバーとの通信に使用するローカル IP アドレスを表示します。

    image

  2. 異常なバックエンドサーバーにログインし、次のコマンドを実行して現在のルート設定を確認します。

    route -n

    [Destination] が NLB インスタンスのローカル IP アドレス、[Genmask] が 255.255.255.255 であり、かつ [Gateway] がネットワークインターフェースのデフォルトゲートウェイでないルートエントリが存在する場合、ルート設定は正しくありません。 デフォルトゲートウェイは、[Destination] が 0.0.0.0 の場合に [Gateway] 列にリストされる IP アドレスです。

    image

  3. 次のコマンドを実行して、正しくないルートを削除します。

    ip route del blackhole 192.168.20.75 # この IP アドレスはデモ用です。
    説明

    コマンド内の IP アドレスを、ご利用の NLB インスタンスが使用するローカル IP アドレスに置き換えてください。

  4. NLB リスナーの ヘルスチェックステータス正常 に変わることを確認します。

原因 3:バックエンドサーバーの高負荷

サーバーの高負荷が失敗の原因であるかどうかを判断するには、「Linux インスタンスの高負荷問題のトラブルシューティングと解決」をご参照ください。

参考

NLB インスタンス診断機能も、ヘルスチェックの失敗のトラブルシューティングに役立ちます。