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

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

最終更新日:Feb 04, 2026

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

前提条件

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

操作手順

ステップ 1:リスナーの設定

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

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

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

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

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

  4. [プロトコルとリスナー] ステップで、必須パラメーターを設定し、[次へ] をクリックします。

    リスナーの設定

    説明

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

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

    この Topic では、[HTTP] が選択されています。

    メキシコリージョンの CLB インスタンスは HTTP リスナーをサポートしていません。Application Load Balancer (ALB) を使用するか、別のリージョンで CLB インスタンスを作成してください。

    バックエンドプロトコル

    リスナープロトコルが [HTTP] の場合、[バックエンドプロトコル][HTTP] になります。

    リスニングポート

    リクエストを受信し、バックエンドサーバーに転送するリスナーポートです。ポートの有効値は 1~65535 です。

    HTTP のデフォルトポートは 80 です。

    タグ

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

    詳細設定

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

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

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

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

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

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

    リスナーリダイレクト

    有効にすると、CLB は HTTP リスナーが受信したリクエストに対して 302 ステータスコードを返し、指定された HTTPS リスナーにリダイレクトします。完全なプロセスについては、「CLB を使用して HTTP リクエストを HTTPS にリダイレクトする」をご参照ください。

    リスナーリダイレクトを有効にする前に、宛先の HTTPS リスナーが作成され、証明書が設定されていることを確認してください。
    既存の HTTP リスナーでリスナーリダイレクトを有効にすることはできません。リスナーを削除して、新しく作成する必要があります。

    セッション維持の有効化

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

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

    Cookie 処理方法

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

      クライアントが最初のリクエストを送信すると、SLB はレスポンスに Cookie (具体的には ServerId) を挿入します。次回クライアントがこの Cookie を含むリクエストを送信すると、SLB はそのリクエストを以前に記録されたバックエンドサーバーに転送します。

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

    • Cookie の書き換え:必要に応じて、HTTP または HTTPS レスポンスに挿入する 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 インスタンスの場合、各リスナーに最大帯域幅を設定してトラフィックを制限できます。すべてのリスナーの最大帯域幅の合計は、インスタンスの帯域幅を超えることはできません。

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

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

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

    • トラフィック課金の CLB インスタンスを使用する場合、リスナーの帯域幅はデフォルトで無制限です。

    接続タイムアウト

    SLB インスタンスとクライアント間の TCP 接続がアイドル状態でいられる最大時間です。値は 1~60 秒の間でなければなりません。デフォルト値は 15 秒です。

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

    説明

    リクエストタイムアウト

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

    値は 1~180 秒の間でなければなりません。デフォルト値は 60 秒です。より長いリクエストタイムアウトが必要な場合は、最大 3600 秒のタイムアウトをサポートする ALB を使用してください。

    Gzip データ圧縮

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

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

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

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

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

      説明

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

    • SLB-ID ヘッダーを追加して、SLB インスタンスの ID を取得します。

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

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

    送信元 IP アドレスの取得

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

    作成後にリスナーを自動的に開始

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

ステップ 2:バックエンドサーバーの追加

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

重要

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

    ステップ 3:ヘルスチェックの設定

      よくある質問

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

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

      ソリューション:

      • バックエンドサーバーのレスポンスヘッダーにカスタムメッセージヘッダーを追加する場合、`xl-server` や `xl-date` などのプレフィックスを追加して、ヘッダーが SLB によって処理されるのを防ぐことができます。

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

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

      現象:

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

      原因:

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

      説明

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

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

      SLB HTTP リスナーは、デフォルトで WebSocket プロトコルをサポートしています。詳細については、「SLB を使用して WebSocket でリアルタイムにメッセージをプッシュする」をご参照ください。