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

Server Load Balancer:HTTP リスナーの追加

最終更新日:Nov 09, 2025

HTTP を使用し、内部ネットワーク通信、テストおよび開発環境、機密性の低いデータの送信などのシナリオで暗号化通信を必要としないアプリケーションを開発する場合、Classic Load Balancer (CLB) インスタンスに HTTP リスナーを追加して、HTTP 経由でリクエストを転送できます。

前提条件

Classic Load Balancer (CLB) インスタンスを作成済みであること。 詳細については、「CLB インスタンスの作成と管理」をご参照ください。

手順

手順 1: リスナーを設定する

  1. Classic Load Balancer (CLB) コンソールにログインします。

  2. インスタンスがデプロイされているリージョンを選択します。

  3. 次のいずれかの方法でリスナー設定ウィザードを開きます。

    • [インスタンス管理] ページで、対象のインスタンスを見つけ、[アクション] 列の [リスナー設定ウィザード] をクリックします。

    • [インスタンス管理] ページで、対象のインスタンス ID をクリックします。[リスナー] タブで、[リスナーの追加] をクリックします。

  4. [プロトコルとリスナー] ウィザードで、次のパラメーターを設定し、[次へ] をクリックします。

    リスナー設定

    説明

    リスナープロトコルの選択

    リスナープロトコルを選択します。

    このトピックでは HTTP を選択します。

    バックエンドプロトコル

    HTTP プロトコルを選択した場合、[バックエンドプロトコル]HTTP になります。

    リスナーポート

    リクエストを受信し、バックエンドサーバーに転送するために使用されるリスナーポート。ポート番号は 1~65535 の範囲で指定する必要があります。

    HTTP プロトコルは、デフォルトでポート 80 を使用します。

    タグ

    [タグキー][タグ値] を選択または入力します。

    詳細設定

    [変更] をクリックして詳細設定を展開します。

    スケジューリングアルゴリズム

    次のスケジューリングアルゴリズムのいずれかを選択できます。デフォルトでは、ラウンドロビン (RR) が選択されています。

    • 加重ラウンドロビン (WRR): 重みが大きいバックエンドサーバーほど、より多くのリクエストを受信します。

    • ラウンドロビン (RR): リクエストはバックエンドサーバーに順番に分散されます。

    スケジューリングアルゴリズムとそのシナリオの詳細については、「Server Load Balancer のスケジューリングアルゴリズムの概要」をご参照ください。

    リスナー転送

    HTTP リスナーから HTTPS リスナーにトラフィックを転送するかどうかを選択します。この機能を有効にする場合は、宛先の HTTPS リスナーを選択する必要があります。

    説明
    • 既存の HTTP リスナーに対してリスナー転送を有効にすることはできません。HTTP リスナーを作成し、リスナー転送を有効にする必要があります。

    • リスナー転送を有効にする場合は、HTTPS リスナーを作成済みであることを確認してください。詳細については、「CLB を使用して HTTP リクエストを HTTPS にリダイレクトする」チュートリアルをご参照ください。

    セッション維持を有効にする

    セッション維持はデフォルトで無効になっています。

    セッション維持を有効にすると、CLB は同じクライアントからのリクエストを同じバックエンドサーバーに分散します。HTTP のセッション維持は Cookie に基づいています。

    Cookie 処理方法:

    • Cookie の挿入: Cookie の有効期限を指定するだけで済みます。

      クライアントが最初のリクエストを送信すると、SLB は HTTP または HTTPS 応答に Cookie (SERVERID) を挿入します。次回クライアントがこの Cookie を付けてリクエストを送信すると、SLB サービスは以前に記録されたバックエンドサーバーにリクエストを転送します。

      セッションタイムアウト: [Cookie の挿入] を選択した場合は、セッションのタイムアウト期間を入力します。

    • Cookie の書き換え: HTTPS または HTTP 応答に挿入する Cookie を指定できます。バックエンドサーバーで Cookie の有効期限とライフタイムを維持する必要があります。

      SLB サービスがカスタム Cookie を検出すると、元の Cookie を書き換えます。次回クライアントが新しい Cookie を付けてリクエストを送信すると、SLB サービスは以前に記録されたバックエンドサーバーにリクエストを転送します。

      Cookie 名: [Cookie の書き換え] を選択した場合は、Cookie 名を入力します。

    アクセス制御を有効にする

    アクセス制御はデフォルトで無効になっています。

    アクセス制御を有効にした後、アクセス制御方法を選択し、アクセス制御ポリシーグループをリスナーのホワイトリストまたはブラックリストとして設定します。

    • ホワイトリスト: 指定された IP アドレスの SLB インスタンスへのアクセスを許可します。ネットワーク ACL で指定された IP アドレスまたは CIDR ブロックからのリクエストのみが転送されます。ホワイトリストは、特定の IP アドレスからのアクセスのみを許可する場合のシナリオに適用されます。ホワイトリストが適切に設定されていない場合、サービスに悪影響が及ぶ可能性があります。ホワイトリストを設定すると、ホワイトリストに追加された IP アドレスからのリクエストのみがリスナーによって転送されます。

      ホワイトリストが設定されていても、IP アドレスがホワイトリストに追加されていない場合、リスナーはすべてのリクエストを転送します。

    • ブラックリスト: 指定された IP アドレスの SLB インスタンスへのアクセスを禁止します。ネットワーク ACL で指定された IP アドレスまたは CIDR ブロックからのリクエストは拒否されます。ブラックリストは、特定の IP アドレスからのアクセスを拒否する場合のシナリオに適用されます。

      ブラックリストが設定されていても、IP アドレスがブラックリストに追加されていない場合、リスナーはすべてのリクエストを転送します。

    • ホワイトリスト: ネットワーク ACL で指定された IP アドレスまたは CIDR ブロックからのリクエストのみが転送されます。ホワイトリストは、特定の IP アドレスからのアクセスのみを許可する場合のシナリオに適用されます。ホワイトリストが適切に設定されていない場合、サービスに悪影響が及ぶ可能性があります。ホワイトリストを設定すると、ホワイトリストに追加された IP アドレスからのリクエストのみがリスナーによって転送されます。

      ホワイトリストが設定されていても、IP アドレスがホワイトリストに追加されていない場合、リスナーはすべてのリクエストを転送します。

    • ブラックリスト: ネットワーク ACL で指定された IP アドレスまたは CIDR ブロックからのリクエストは拒否されます。ブラックリストは、特定の IP アドレスからのアクセスを拒否する場合のシナリオに適用されます。

      ブラックリストが設定されていても、IP アドレスがブラックリストに追加されていない場合、リスナーはすべてのリクエストを転送します。

    説明

    IPv6 インスタンスは IPv6 アクセス制御ポリシーグループにのみバインドできます。IPv4 インスタンスは IPv4 アクセス制御ポリシーグループにのみバインドできます。詳細については、「アクセス制御ポリシーグループの作成」をご参照ください。

    リスナーの帯域幅調整を有効にする

    帯域幅課金 SLB インスタンスの場合、各リスナーに最大帯域幅を設定して、リスナーによって転送されるトラフィックを制限できます。インスタンスのすべてのリスナーの最大帯域幅値の合計は、インスタンスの帯域幅を超えることはできません。

    この機能はデフォルトで無効になっています。すべてのリスナーはインスタンスの合計帯域幅を共有します。リスナーが合計帯域幅を共有する方法の詳細については、「CLB インスタンスのリスナーはインスタンスの帯域幅を共有する」をご参照ください。

    重要
    • インターネット向け CLB インスタンスの合計インターネット帯域幅が 5 Mbit/s で、2 つのリスナーが設定されている場合に、リスナー A に 5 Mbit/s の帯域幅を割り当て、リスナー B に帯域幅を割り当てないと、リスナー B のポートにアクセスできなくなります。帯域幅を割り当てる際は注意してください。

    • イントラネット向け CLB インスタンスに 3 つのリスナーが設定されており、リスナー A と B に合計 5,120 Mbit/s の帯域幅が割り当てられている場合、リスナー C のポートにアクセスできなくなります。帯域幅を割り当てる際は注意してください。

    • デフォルトでは、トラフィック課金インスタンスの最大帯域幅は制限されません。

    接続タイムアウト

    CLB インスタンスとクライアント間の TCP 接続がデータ転送なしで開いたままにできる最大期間。有効な値: 1~60。デフォルト値: 15。単位: 秒。

    タイムアウト期間内にリクエストが受信されない場合、SLB は現在の接続を一時的に切断します。次のリクエストが到着すると、新しい接続が確立されます。

    説明

    接続タイムアウトを設定すると、その設定はリスナー全体に適用されます。特定のバックエンドサーバーの接続タイムアウトを設定するには、そのバックエンドサーバー用に別のリスナーを設定し、新しいリスナーで接続タイムアウトを設定する必要があります。

    リクエストタイムアウト

    バックエンドサーバーがタイムアウト期間内に応答しない場合、SLB は待機を停止し、クライアントに HTTP 504 エラーコードを返します。

    有効な値: 1~180。デフォルト値: 60。単位: 秒。

    Gzip データ圧縮

    この機能を有効にすると、特定の種類のファイルが圧縮されます。この機能を無効にすると、ファイルは圧縮されません。Gzip データ圧縮はデフォルトで有効になっています。

    Gzip は次のファイルタイプをサポートしています: text/xmltext/plaintext/cssapplication/javascriptapplication/x-javascriptapplication/rss+xmlapplication/atom+xml、および application/xml

    追加の HTTP ヘッダーフィールド

    追加するカスタム HTTP ヘッダーフィールドを選択します:

    • クライアントの送信元 IP アドレスを取得するために X-Forwarded-For ヘッダーを追加します。

      説明

      デフォルトでは、CLB のレイヤー 7 リスナーは X-Forwarded-For ヘッダーを使用してクライアントの送信元 IP アドレスを取得します。この機能は無効にできません。このフィールドを使用して複数の IP アドレスが取得された場合、最初の IP アドレスがクライアントの送信元 IP アドレスになります。詳細については、「CLB のレイヤー 7 リスナーを介してクライアントの送信元 IP アドレスを取得する」をご参照ください。

    • SLB インスタンスの ID を取得するために SLB-ID ヘッダーを追加します。

    • SLB インスタンスの IP アドレスを取得するために SLB-IP ヘッダーを追加します。

    • SLB のリスナープロトコルを取得するために X-Forwarded-Proto ヘッダーを追加します。

    送信元 IP アドレスの取得

    訪問者の送信元 IP アドレスを取得します。この機能はデフォルトで有効になっています。

    作成後にリスナーを自動的に有効にする

    リスナーの設定後に SLB リスナーを有効にするかどうかを指定します。この機能はデフォルトで有効になっています。

手順 2: バックエンドサーバーを追加する

フロントエンドのリクエストを処理するためにバックエンドサーバーを追加します。インスタンスに設定されているデフォルトサーバーグループを使用するか、リスナーに vServer グループを設定できます。詳細については、「CLB サーバーグループ」をご参照ください。このトピックでは、デフォルトサーバーグループを例として使用します。

重要

HTTP リスナーはプライマリ/セカンダリサーバーグループをサポートしていません。

  1. [バックエンドサーバー] ウィザードで、[デフォルトサーバーグループ] を選択し、[追加を続行] をクリックします。

  2. [サーバーの選択] ウィザードで、目的のバックエンドサーバーを選択し、[次へ] をクリックします。

  3. [ポートと重みの設定] ウィザードで、重みを設定し、[追加] をクリックします。

    説明
    • デフォルトの重みは 100 です。重みが大きいバックエンドサーバーほど、より多くのアクセスリクエストを受信します。

    • 重みが 0 のサーバーは新しいリクエストを受け付けません。

  4. リクエストを受信するバックエンドサーバー (ECS インスタンス) のポートを設定し、[次へ] をクリックします。ポートは 1~65535 の範囲の数値である必要があります。

    説明

    SLB インスタンスのバックエンドサーバーは同じポートを使用できます。

手順 3: ヘルスチェックを設定する

CLB はヘルスチェックを実行してバックエンドサーバーの可用性を確認します。これにより、フロントエンドサービスの全体的な可用性が向上し、異常なバックエンドサーバーによるサービスの中断を防ぎます。

  1. 任意: [ヘルスチェック] ウィザードで、[編集] をクリックしてヘルスチェックの設定を変更し、[次へ] をクリックします。 詳細については、「CLB ヘルスチェックの設定と管理」をご参照ください。

  2. [設定の確認] ウィザードで、リスナーの設定を確認し、[変更] をクリックして変更を加えます。

  3. 設定を確認し、[送信] をクリックします。設定が適用されたら、[OK] をクリックします。

    リスナーが作成されると、[リスナー] タブで表示できます。

よくある質問

レイヤー 7 ロードバランサーによってリクエストが転送された後、バックエンドサーバーの応答ヘッダーの一部のパラメーターが削除されるのはなぜですか?

セッション維持を実装するために、SLB はバックエンドサーバーの応答ヘッダーにある Date、Server、X-Pad、X-Accel-Redirect などのパラメーターの値を変更します。

解決策:

  • バックエンドサーバーの応答ヘッダーにカスタムメッセージヘッダーを追加する場合、xl-server や xl-date などのプレフィックスを追加して SLB の処理をバイパスできます。

  • レイヤー 7 HTTP リスナーをレイヤー 4 TCP リスナーに変更します。

HTTP リクエストのヘッダーに Transfer-Encoding: chunked フィールドが追加されるのはなぜですか?

現象:

ドメイン名をレイヤー 7 ロードバランサーのエンドポイントにマッピングした後、ローカルホストからドメイン名にアクセスすると、HTTP リクエストのヘッダーに Transfer-Encoding: chunked フィールドが追加されます。ローカルホストから直接バックエンドサーバーにアクセスする場合、このフィールドは存在しません。

原因:

これは、レイヤー 7 のロードバランシングが Tengine リバースプロキシを使用して実装されているために発生します。Transfer-Encoding フィールドは、Web サーバーが応答メッセージの本文をどのようにフォーマットするかを示します。たとえば、Transfer-Encoding: chunked は、Web サーバーが応答メッセージの本文にチャンク転送エンコーディングを使用することを示します。

説明

レイヤー 4 のロードバランシングでは、SLB はトラフィックを転送するだけです。したがって、このフィールドは追加されません。

WebSocket プロトコルをサポートするように CLB リスナーを設定するにはどうすればよいですか?

CLB HTTP リスナーは、デフォルトで WebSocket プロトコルをサポートしています。詳細については、「WebSocket および WebSocket Secure プロトコルの概要」をご参照ください。