Server Load Balancer:CLB リスナーに関する FAQ

CLB はポート フォワーディングをサポートしていますか？

はい、CLB はポート フォワーディングをサポートしています。

詳細については、「HTTP から HTTPS へのリクエストをリダイレクトする」をご参照ください。

レイヤー 4 CLB リスナーはポート範囲でリッスンできますか？

いいえ、できません。ポート範囲でリッスンする TCP または UDP リスナーを使用する場合は、レイヤー 4 リスナーのマルチポート リッスンと転送をサポートする Network Load Balancer（NLB）インスタンスを作成できます。詳細な手順については、「NLB のマルチポート リッスンと転送を有効にする」をご参照ください。

CLB のリスナー ポートを構成する前に知っておくべきことは何ですか？

特定のキャリアは、ポート 25、135、139、444、445、5800、および 5900 を高リスク ポートとしてマークし、特定のリージョンでこれらのポートを介したトラフィックをブロックします。セキュリティグループルールによってポートが開かれている場合でも、CLB インスタンスは制限されたリージョンではこれらのポートを介してアクセスできません。これらのポートは使用しないことをお勧めします。

• Windows Server オペレーティング システム上のアプリケーションで使用されるポートについては、Windows ドキュメントのWindows のサービス概要とネットワーク ポートの要件を参照してください。

• 一般的なポートの詳細については、「一般的なポート」をご参照ください。

リクエストが CLB に送信される前にリクエストに TCP Option Address（TOA）ヘッダーがすでに含まれている場合、CLB はヘッダー内のクライアント IP アドレスを保持できますか？

いいえ、CLB は TOA ヘッダー内のクライアント IP アドレスを保持できません。デフォルトでは、TOA モジュールがインストールされている場合、CLB はクライアント IP アドレスを保持するために TOA ヘッダーを自動的に追加します。CLB が TOA ヘッダーをすでに含むリクエストを受信した場合、CLB はヘッダー内のクライアント IP アドレスを保持できません。

WebSocket または WebSocket Secure プロトコルを使用するバックエンド サービスには、どのリスナーを選択する必要がありますか？

• WebSocket プロトコルを使用するバックエンド サービスの場合は、TCP または HTTP リスナーを使用します。

• WebSocket Secure プロトコルを使用するバックエンド サービスの場合は、TCP または HTTPS リスナーを使用します。

CLB リスナー構成の変更が有効になるまでどのくらいかかりますか、またどのような影響がありますか？

変更は送信後すぐに有効になります。後続の新しいリクエストにのみ影響します。既存の接続は影響を受けません。

CLB の WAF 保護を有効にするにはどうすればよいですか？

パブリック ネットワーク インターフェース コントローラー（NIC）を無効にすると、CLB サービスは影響を受けますか？

バックエンド Elastic Compute Service（ECS）インスタンスにパブリック IP アドレスが割り当てられている場合、パブリック NIC を無効にすると、ECS インスタンスが提供するサービスは中断されます。

デフォルトでは、ECS インスタンスにパブリック IP アドレスが割り当てられている場合、通信にこの IP アドレスが使用されます。この場合、ネットワーク トラフィックは ECS インスタンスのパブリック NIC を介して転送されます。パブリック NIC を無効にすると、ECS インスタンスはインターネットに応答を送信できません。 ECS インスタンスのパブリック NIC を無効にしないことをお勧めします。無効にする必要がある場合は、サービスの中断を避けるために、デフォルト ルートの宛先をプライベート IP アドレスに変更します。さらに、サービスがインターネットへのアクセスを必要とするかどうか（インターネット経由で ApsaraDB RDS インスタンスにアクセスするなど）を確認します。

シナリオによっては、接続が最大帯域幅に達しないのはなぜですか？

• 説明: インターネット従量制が帯域幅課金であるインターネットに接続されている CLB インスタンスを購入し、クライアントでストレステストを実行するか、クライアントを使用して大きなパケットを転送すると、接続が最大帯域幅に達しない場合があります。

• 原因:

  CLB は、バックエンド サーバーのグループにリクエストを均等に分散することにより、負荷分散サービスを提供します。指定した最大帯域幅は、各バックエンド サーバーに均等に割り当てられます。

  接続を介してダウンロードできるデータの上限は、次の式を使用して計算されます。指定した CLB インスタンスの最大帯域幅 /（N-1）。 N は CLB クラスタ内のノード数を示し、レイヤー 4 CLB の場合は N は 4 です。レイヤー 7 CLB の場合は N は 8 です。CLB インスタンスの購入時に 10 Mbit/s の帯域幅を指定し、レイヤー 4 転送に使用するとします。複数のクライアントが CLB にアクセスしようとすると、CLB インスタンスの合計帯域幅は 10 Mbit/s に達する可能性がありますが、各クライアントが CLB からダウンロードできるデータの上限は 10/(4-1)=3.33 Mbit/s です。

• 各バックエンド サーバーの最大帯域幅は、次の式を使用して計算されます。単一接続でのダウンロードのピーク帯域幅 = CLB インスタンスの合計帯域幅 /（N-1）。 N はサーバーグループの数を表し、4 です。たとえば、CLB コンソールで最大帯域幅を 10 Mbit/s に設定した場合、複数のクライアントの接続が同時に使用されている場合、合計帯域幅は 10 Mbit/s に達する可能性があります。各クライアントの最大帯域幅は、次の式に基づいて計算されます。10/(4-1) = 3.33 Mbit/s。

• 推奨ソリューション:

  • CLB インスタンスのインターネット従量制をトラフィック課金に変更します。

  • Network Load Balancer（NLB）または Application Load Balancer（ALB）インスタンス、Elastic IP Address（EIP）、および EIP 帯域幅プランを使用します。このソリューションは、ALB または NLB インスタンスのスケーラビリティを高め、接続が最大帯域幅に達するようにします。

モニタリング データで CLB インスタンスの最大帯域幅に達していないことが示されている場合でも、パケット損失が発生するのはなぜですか？

考えられる原因:

• モニタリング データはリアルタイムではなく、1 分間のモニタリング メトリック値の平均です。着信トラフィックが 1 分間の特定の秒以内に CLB の最大帯域幅を超えても、1 分間の平均帯域幅値が最大帯域幅よりも小さい場合、モニタリング パネルに表示される帯域幅の使用量は最大帯域幅よりも少なくなります。

• CLB は、バックエンド サーバーのグループにリクエストを均等に分散することにより、負荷分散サービスを提供します。指定した最大帯域幅は、各バックエンド サーバーに均等に割り当てられます。クライアントがダウンロードをリクエストしたデータ量が単一のバックエンド サーバーの上限を超えると、パケット損失が発生します。バックエンド サーバーの上限を決定するために使用される特定の式については、「シナリオによっては、接続が最大帯域幅に達しないのはなぜですか？」をご参照ください。

シナリオによっては、CLB が最大 QPS に達しないのはなぜですか？

• 説明: 少数の持続的接続が使用されるシナリオでは、サーバーグループ内のすべてのバックエンド サーバーに少なくとも 1 つの持続的接続が割り当てられるわけではありません。その結果、CLB インスタンスは最大 QPS に達することができません。

• 原因:

  CLB は、バックエンド サーバーのグループにリクエストを均等に分散することにより、負荷分散サービスを提供します。構成する最大 QPS は、各バックエンド サーバーに均等に割り当てられます。

  各バックエンド サーバーの最大 QPS は、次の式を使用して計算されます。各バックエンド サーバーの最大 QPS = 合計 QPS /（N-1）。 N はサーバーグループ内のバックエンド サーバーの数です。たとえば、CLB コンソールで Small I（slb.s1.small）仕様の CLB インスタンスを購入した場合、最大 QPS は 1,000 です。複数のクライアントが同時に使用されている場合、合計 QPS は 1,000 に達する可能性があります。バックエンド サーバーの数が 8 の場合、各バックエンド サーバーの最大 QPS は次の式に基づいて計算されます。1000/(8-1) = 142。

  説明

  2025 年 6 月 1 日午前 0 時 0 分 0 秒（UTC + 08:00）以降、仕様別課金 CLB インスタンスは購入できなくなります。詳細については、「仕様別課金 CLB インスタンスの販売終了」をご参照ください。

• 推奨ソリューション:

  • ストレステストには、単一クライアントで短命の接続を使用します。

  • ビジネス要件に基づいて接続の再利用を減らします。

  • CLB インスタンスの仕様をアップグレードします。詳細については、「従量課金（pay-by-specification）インスタンスをアップグレードまたはスペックダウンする」をご参照ください。

  • より高いスケーラビリティをサポートする ALB インスタンスを使用します。

シナリオによっては、新しい接続数が上限に達しないのはなぜですか？

• 問題: 仕様別課金従量制を使用する CLB インスタンスを購入した後、クライアント側のストレステストや単一ソース アクセスなど、一部のシナリオでは新しい接続が最大帯域幅に達しません。

  説明

  2025 年 6 月 1 日午前 0 時 0 分 0 秒（UTC + 08:00）以降、仕様別課金 CLB インスタンスは購入できなくなります。詳細については、「仕様別課金 CLB インスタンスの販売終了」をご参照ください。

• 原因:

  負荷分散システムは、クラスタデプロイメントを使用して高可用性とスケーラビリティを確保します。外部ネットワークからの接続は、クラスタ内の複数のシステム サーバーに分散されます。その結果、1 秒あたりの接続のクォータはサーバー間で均等に分散されます。

  1 秒あたりの最大接続数 = CLB インスタンスの 1 秒あたりの合計接続数 /（N-1）。 N はサーバーの数を表します。

  たとえば、Small I（slb.s1.small）インスタンスを購入した場合、CLB インスタンスでサポートされる 1 秒あたりの最大接続数は 3,000 です。複数のクライアントが CLB インスタンスにアクセスすると、CLB インスタンスの 1 秒あたりの合計接続数は 3,000 に達する可能性があります。 3,000/(4-1) = 1,000。したがって、各サーバーは 1 秒あたり最大 1,000 接続をサポートします。

• 推奨ソリューション:

  • CLB インスタンスの従量制を変更する: CLB インスタンスの従量制を仕様別課金から従量課金に変更します。従量課金では仕様を指定する必要がなく、より高いパフォーマンスがサポートされます。

  • NLB を使用する: NLB は、高い同時実行性または 1 秒あたり多数の新しい接続を必要とするシナリオに最適です。 NLB は、CLB よりも高いパフォーマンスとスケーラビリティをサポートします。 CLB はサーバーによって制限されており、CLB は 1 秒あたり限られた数の接続のみをサポートします。ただし、NLB は多数の同時接続に耐えることができます。

各タイプのリスナーの接続タイムアウト期間はどのくらいですか？

• TCP リスナー: 10 ～ 900 秒。

• HTTP リスナー:

  • アイドル接続タイムアウト期間: 1 ～ 60 秒。

  • 接続リクエスト タイムアウト期間: 1 ～ 180 秒。

• HTTPS リスナー:

  • アイドル接続タイムアウト期間: 1 ～ 60 秒。

  • 接続リクエスト タイムアウト期間: 1 ～ 180 秒。

CLB のサービス アドレスへの接続がタイムアウトするのはなぜですか？

考えられる原因:

• セキュリティ上の理由から、CLB のサービス IP アドレスがブロックされています。

  トラフィック ブラックホール化、トラフィック スクラブ、または WAF により、CLB の IP アドレスがブロックされている可能性があります。 WAF は、接続が確立された後にクライアントとバックエンド サーバーにリセット（RST）パケットを送信することで保護を提供します。

• クライアント ポートの枯渇

  クライアント ポートの枯渇は、特にストレステストで接続エラーを引き起こす可能性があります。デフォルトでは、CLB は TCP 接続のタイムスタンプを削除します。その結果、tw_reuse 設定は有効にならず、time_wait 状態の接続は再利用できません。これらの累積された接続はすべてのポートを使い果たします。

  解決策: クライアントが短命の接続ではなく持続的接続を確立するように設定します。 so_linger ソケット オプションを FIN パケットではなく RST パケットを送信することで接続を閉じるように設定します。

• バックエンド サーバーの accept キューがいっぱいです。

  バックエンド サーバーの accept キューがいっぱいの場合、バックエンド サーバーは syn_ack パケットを返すことができなくなります。その結果、クライアントからのリクエストがタイムアウトします。

  解決策: net.core.somaxconn を 128 に設定します。ビジネス要件に基づいて適切な値を指定し、sysctl -w net.core.somaxconn=<Desired value> を実行してパラメータの値を変更し、バックエンド サーバーでアプリケーションを再起動します。

• レイヤー 4 CLB はバックエンド サーバーからアクセスされます。

  バックエンド サーバーからレイヤー 4 CLB にアクセスすると、接続は失敗します。たとえば、バックエンド サーバーに到達したリクエストは、別のバックエンド サーバーのアプリケーションにリダイレクトされます。

• RST パケットが正しく応答されていません。

  CLB で TCP 接続が確立されてから 900 秒以内にデータが送信されない場合、CLB は RST パケットをクライアントとバックエンド サーバーに送信して接続を閉じます。バックエンド サーバーのアプリケーションが RST パケットに正しく応答しない場合、アプリケーションは接続が閉じられた後にデータ パケットを送信する可能性があります。その結果、CLB 接続タイムアウトが発生します。

  説明

  デフォルトのタイムアウト期間は 900 秒です。ビジネス要件に基づいてこの値を変更できます。

HTTP および HTTPS リスナーに指定されているタイムアウト値は何ですか？

• HTTP 持続的接続では最大 100 リクエストを連続して送信できます。制限に達すると、接続は閉じられます。

• HTTP 持続的接続を介した 2 つの HTTP または HTTPS リクエスト間のタイムアウト期間は、1 ～ 60 秒の値に設定できます。実際のタイムアウト期間には、1 ～ 2 秒の時間誤差がある場合があります。タイムアウト期間が指定された値に達すると、TCP 接続は閉じられます。顧客が HTTP 持続的接続を使用する場合、クライアントが 13 秒以下ごとにハートビート リクエストを送信するように構成します。

• CLB とバックエンド Elastic Compute Service（ECS）インスタンス間の TCP 3 ウェイハンドシェイクのタイムアウト期間は 5 秒です。ハンドシェイクがタイムアウトした後、CLB は次の ECS インスタンスを選択します。アクセスログのアップストリーム応答時間を確認することで、タイムアウト レコードを見つけることができます。

• CLB が ECS インスタンスからの応答を待機する時間は、1 ～ 180 秒の範囲の値に設定できます。待機時間が指定されたタイムアウト期間に達すると、HTTP 504 または 408 ステータスコードがクライアントに送信されます。アクセスログのアップストリーム応答時間を確認することで、タイムアウト レコードを見つけることができます。

• 300 秒後、HTTPS セッションの再利用はタイムアウトします。その後、クライアントは完全な SSL ハンドシェイクプロセスを再度実行する必要があります。

クライアントが応答を受信する前に CLB との接続を閉じると、CLB はバックエンド サーバー側の接続を閉じますか？

いいえ、この場合、CLB はバックエンド サーバー側の接続を閉じません。

CLB インスタンスの持続的接続を有効にできますか？

いいえ、CLB は持続的接続をサポートしていません。

持続的接続を実装するには、Application Load Balancer（ALB）インスタンスを使用し、バックエンド サーバーに Keep-Alive をデプロイして有効にする必要があります。詳細な手順については、「サーバーグループを作成および管理する」をご参照ください。

シナリオによっては、セッション維持が失敗するのはなぜですか？

考えられる原因と対応する解決策は次のとおりです。

• 原因: セッション維持機能が有効になっていません。

  解決策: 使用中のリスナーでセッション維持が有効になっているかどうかを確認します。

• 原因: HTTP または HTTPS リスナーが使用されています。 HTTP および HTTPS リスナーは、4xx ステータスコードを含む応答に Cookie を挿入することでセッションを維持することはできません。

  解決策 1: HTTP および HTTPS リスナーの代わりに TCP リスナーを使用します。 TCP リスナーは、クライアント IP アドレスに基づいてセッションを維持します。

  解決策 2: バックエンド ECS インスタンスがセッションを維持するように構成します。 ECS インスタンスは、セッションが維持されるように Cookie を挿入および検証できます。

• 原因: HTTP または HTTPS リスナーが使用されています。 HTTP 302 リダイレクトは、セッションを維持するための SERVERID 文字列を変更します。 CLB が HTTP ステータスコード 302 を含む応答に Cookie を挿入すると、SERVERID 文字列が変更されます。その結果、セッションを維持できません。

  原因を確認するには、ブラウザまたはパケットキャプチャ ソフトウェアを使用して CLB へのリクエストと CLB からの応答をキャプチャし、パケットに 302 ステータスコードが含まれているかどうか、および Cookie 内の SERVERID 文字列が変更されているかどうかを確認します。

  解決策 1: HTTP および HTTPS リスナーの代わりに TCP リスナーを使用します。 TCP リスナーは、クライアント IP アドレスに基づいてセッションを維持します。

  解決策 2: バックエンド ECS インスタンスがセッションを維持するように構成します。 ECS インスタンスは、セッションが維持されるように Cookie を挿入および検証できます。

• 原因: タイムアウト期間が小さい値に設定されています。

  解決策: タイムアウト期間を大きい値に設定します。

Cookie を表示するにはどうすればよいですか？

ブラウザを開き、F12 キーを押して、SERVERID またはユーザー定義の Cookie が応答に挿入されているかどうかを確認します。 curl www.example.com -c /tmp/cookie123 コマンドを実行して Cookie を保存し、curl www.example.com -b /tmp/cookie123 コマンドを実行して Cookie を表示することもできます。

Linux curl コマンドを使用してセッション維持をテストするにはどうすればよいですか？

1. テスト ページを作成します。

   バックエンド サーバーのプライベート IP アドレスを表示できる各バックエンド ECS インスタンスにテスト ページを作成します。次の図は、テスト ページの例を示しています。プライベート IP アドレスは、リクエストの配信先となるバックエンド サーバーを示します。プライベート IP アドレスは、CLB がセッションを維持できるかどうかをテストするために使用されます。

   

2. Linux で curl コマンドを実行します。

   この例では、Linux を実行する CLB インスタンスの IP アドレスは 10.170.XX.XX で、テスト ページの URL は http://10.170.XX.XX/check.jsp です。

   1. Linux を実行しているサーバーにログオンします。

   2. 次のコマンドを実行して、バックエンド サーバーによって挿入された Cookie をクエリします。

      curl -c test.cookie http://10.170.XX.XX/check.jsp

      説明

      デフォルトでは、CLB は Cookie を挿入することでセッションを維持します。ただし、curl は Cookie を送信または保存しません。したがって、テストを実行する前に Cookie を保存する必要があります。そうしないと、curl テスト結果にセッション維持が無効であると表示される場合があります。

   3. Cookie を保存した後、次のコマンドを実行します。

      for ((a=1;a<=30;a++));
          do curl  -b test.cookie http://10.170.XX.XX/check.jsp  | grep '10.170.XX.XX';
          sleep 1;
      done

      説明

      a<=30 は、実行されるテストの数を示します。ビジネス要件に基づいてこの値を設定できます。grep '10.170.XX.XX' の IP アドレスを ECS インスタンスのプライベート IP アドレスに設定します。

   4. 上記のテストで返された IP アドレスを確認します。同じ IP アドレスが返された場合は、CLB がセッションを維持できることを示します。

HTTPS リスナー経由で Web サイトを開くと、スタイルシートが読み込まれないのはなぜですか？

問題:

HTTP リスナーと HTTPS リスナーが作成され、同じバックエンド サーバーを使用しています。指定されたポート番号で HTTP リスナー経由で Web サイトにアクセスすると、Web サイトが表示されます。ただし、HTTPS リスナー経由で Web サイトにアクセスすると、Web サイトのレイアウトが歪んでいます。

原因:

デフォルトでは、CLB は JavaScript ファイルの読み込みと転送をブロックしません。この問題は、次の理由で発生する可能性があります。

• 証明書が Web ブラウザのセキュリティ レベルと互換性がありません。

• 証明書は不適格なサードパーティ証明書です。この場合は、証明書の発行者に連絡して、証明書の資格を確認してください。

解決策:

1. Web サイトを開くときは、ブラウザの指示に従ってスクリプトを読み込みます。

2. 必要な証明書をブラウザに追加します。

バックエンド サーバーにアクセスするときに、HTTP および HTTPS リスナーはどのバージョンの HTTP を使用しますか？

• リクエストで HTTP/1.1 または HTTP/2 が使用されている場合、レイヤー 7 リスナーは HTTP/1.1 を使用してリクエストをバックエンド サーバーに配信します。

• リクエストで HTTP/1.1 および HTTP/2 以外のプロトコルが使用されている場合、レイヤー 7 リスナーは HTTP/1.0 を使用してリクエストをバックエンド サーバーに配信します。

バックエンド サーバーは、クライアントが HTTP または HTTPS リスナーへのアクセスに使用するプロトコルバージョンを取得できますか？

はい、できます。

HTTP リスナーから HTTPS リスナーへのトラフィック リダイレクトを有効にする場合、バックエンド サーバーに証明書をデプロイする必要がありますか？

いいえ、必要ありません。 CLB に証明書をデプロイし、HTTPS リスナーの証明書を設定するだけで済みます。 詳細については、「SSL 証明書を設定する」をご参照ください。