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

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

最終更新日:Apr 21, 2026

Classic Load Balancer (CLB) インスタンスに HTTP リスナーを追加して、暗号化通信を必要としないアプリケーションの HTTP リクエストを転送します。一般的なユースケースには、内部ネットワーク、テスト環境および開発環境、機密性の低いデータの転送などがあります。

前提条件

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

操作手順

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

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

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

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

    • インスタンス ページで、ターゲットインスタンスを見つけ、リスナーの設定 列の 操作 をクリックします。

    • インスタンス ページで、ターゲットインスタンスの ID をクリックします。次に、リスナー タブで、リスナーの追加 をクリックします。

  4. プロトコルとリスナー ウィザードで、次の設定を行い、次へ をクリックします。

    パラメーター

    説明

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

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

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

    メキシコリージョンの CLB インスタンスは HTTP リスナーをサポートしていません。Application Load Balancer または別のリージョンの CLB インスタンスを使用することを推奨します。

    バックエンドプロトコル

    リスナープロトコルとして [HTTP] を選択した場合、バックエンドプロトコル は自動的に [HTTP] に設定されます。

    リスニングポート

    リスナーがリクエストを受信し、バックエンドサーバーに転送するために使用するポートです。有効な値:1~65535。

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

    タグ

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

    高度な設定

    編集 をクリックして詳細設定を展開します。

    転送ルール

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

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

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

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

    リダイレクション

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

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

    セッション維持の有効化

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

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

    クッキーの処理モード

    • クッキーの追加:Cookie のタイムアウト期間を指定するだけで済みます。

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

      セッション維持タイムアウトクッキーの追加 を選択した場合は、セッション維持のタイムアウト期間を入力します。

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

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

      クッキー名: クッキーの上書き を選択した場合は、クッキーの名前を入力します。

    アクセス制御の有効化

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

    アクセス制御を有効にした後、アクセス制御メソッドと、リスナーのホワイトリストまたはブラックリストとして使用するアクセス制御リスト (ACL) を選択します。

    • ホワイトリスト:特定の IP アドレスの SLB へのアクセスを許可する。選択した ACL で指定された IP アドレスまたは CIDR ブロックからのリクエストのみが転送されます。ホワイトリストは、特定の IP アドレスからのアクセスのみを許可したいシナリオに適しています。ホワイトリストを設定すると、特定のビジネスリスクが生じます。ホワイトリストが設定されると、リスト内の IP アドレスのみが CLB リスナーにアクセスできます。

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

    • ブラックリスト:特定の IP アドレスの SLB へのアクセスを禁止する。選択した ACL で指定された IP アドレスまたは CIDR ブロックからのリクエストは転送されません。ブラックリストは、特定の IP アドレスからのアクセスのみをブロックしたいシナリオに適しています。

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

    説明

    IPv6 インスタンスは IPv6 ACL にのみ関連付けることができ、IPv4 インスタンスは IPv4 ACL にのみ関連付けることができます。詳細については、「ACL の作成」をご参照ください。

    ピーク帯域幅の上限を有効化

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

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

    重要

    接続アイドルのタイムアウト時間

    アイドル接続のタイムアウト期間です。値は 1~60 秒の範囲で設定できます。デフォルト値は 15 秒です。

    指定されたタイムアウト期間内に接続上でデータが転送されない場合、CLB は接続を閉じます。次のリクエストが到着すると、新しい接続が確立されます。

    説明

    接続要求のタイムアウト時間

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

    値は 1~180 秒の範囲で設定できます。デフォルト値は 60 秒です。より長いリクエストタイムアウトが必要な場合は、最大 3,600 秒のタイムアウトをサポートする Application Load Balancer の使用を推奨します。

    Gzip 圧縮の有効化

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

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

    追加のHTTPヘッダー

    追加したいカスタム HTTP ヘッダーを選択します:

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

      説明

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

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

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

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

    クライアント IP の取得

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

    作成後に自動的に有効化する

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

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

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

重要

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

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

      よくある質問

      レイヤー 7 リスナーによって削除されるレスポンスヘッダー

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

      ソリューション:

      • バックエンドサーバーのレスポンスにカスタムヘッダーを追加する際は、CLB インスタンスによる処理を避けるために、xl-server や xl-date などのプレフィックスを使用します。

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

      レスポンス内の Transfer-Encoding: chunked ヘッダー

      現象:

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

      原因:

      これは、レイヤー 7 負荷分散が Tengine リバースプロキシに基づいて実装されているためです。Transfer-Encoding ヘッダーは、Web サーバーがレスポンスボディをどのようにエンコーディングするかを示します。例えば、「Transfer-Encoding: chunked」は、Web サーバーがレスポンスボディにチャンク転送エンコーディングを使用していることを意味します。

      説明

      レイヤー 4 負荷分散サービスでは、CLB インスタンスはトラフィックを転送するだけで、このヘッダーを追加しません。

      CLB リスナーにおける WebSocket のサポート

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