Application Load Balancer のリスナー - Elastic Load Balancing
リスナーの設定リスナールールルールアクションタイプルールの条件のタイプX-Forwarded ヘッダー

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Application Load Balancer のリスナー

リスナーとは、設定したプロトコルとポートを使用して接続リクエストをチェックするプロセスです。Application Load Balancer の使用を開始する前に、最低 1 つのリスナーを追加する必要があります。ロードバランサーにリスナーがない場合、クライアントからのトラフィックを受信できません。リスナーに定義するルールによって、ロードバランサーがEC2インスタンスなど、登録するターゲットにリクエストをルーティングする方法が決まります。

内容

リスナーの設定

リスナーは次のポートとプロトコルをサポートします。

  • プロトコル: HTTP、 HTTPS

  • ポート: 1 ～ 65535

HTTPS リスナーを使用して暗号化と復号の作業をロードバランサーにオフロードし、アプリケーションがビジネスロジックに集中できるようにします。リスナープロトコルが の場合HTTPS、リスナーに少なくとも 1 つのSSLサーバー証明書をデプロイする必要があります。詳細については、「Application Load Balancer のHTTPSリスナーを作成する」を参照してください。

ターゲットがロードバランサーの代わりにHTTPSトラフィックを復号化する必要があることを確認する場合は、ポート 443 でTCPリスナーを使用して Network Load Balancer を作成できます。TCP リスナーを使用すると、ロードバランサーは暗号化されたトラフィックを復号化せずにターゲットに渡します。Network Load Balancer の詳細については、「https://docs.aws.amazon.com/elasticloadbalancing/latest/network/ のユーザーガイド」を参照してください。

Application Load Balancer は、 のネイティブサポートを提供します WebSockets。接続アップグレードを使用して、既存の HTTP/1.1 接続を WebSocket （ws または wss) HTTP接続にアップグレードできます。アップグレードすると、リクエストに使用されるTCP接続 (ロードバランサーとターゲット) は、ロードバランサーを介したクライアントとターゲット間の永続的な WebSocket 接続になります。HTTP とHTTPSリスナー WebSockets の両方で を使用できます。リスナーに選択したオプションは、 WebSocket 接続とHTTPトラフィックに適用されます。詳細については、「Amazon CloudFront デベロッパーガイド」の WebSocket 「プロトコルの仕組み」を参照してください。

Application Load Balancer は、HTTPSリスナーによる HTTP/2 のネイティブサポートを提供します。1 つの HTTP/2 接続を使用して、最大 128 件のリクエストを並列に送信できます。プロトコルバージョンを使用して、HTTP/2 を使用してターゲットにリクエストを送信できます。詳細については、「プロトコルバージョン」を参照してください。HTTP/2 はフロントエンド接続をより効率的に使用するため、クライアントとロードバランサー間の接続が少なくなることがあります。HTTP/2 のサーバープッシュ機能は使用できません。

詳細については、Elastic Load Balancing ユーザーガイドのルーティングのリクエストを参照してください。

リスナールール

リスナーには、必ずデフォルトアクションがあります。これはデフォルトルールとも言います。デフォルトルールは削除できず、必ず最後に実行されます。新しいルールの作成は可能で、優先度、1 つ以上のアクション、および 1 つ以上の条件を構成できます。ルールの追加や編集はいつでも行うことができます。詳細については、「ルールの編集」を参照してください。

デフォルトのルール

リスナーを作成するときは、デフォルトのルールのアクションを定義します。デフォルトのルールに条件を定義することはできません。リスナーのルールに設定された条件のいずれも満たされない場合は、デフォルトのルールのアクションが実行されます。

デフォルトのルールの例を、コンソールに表示されるとおりに次に示します。

リスナーのデフォルトのルール。

ルールの優先順位

各ルールには優先順位があります。ルールは優先順位の低~高順によって評価されます。デフォルトのルールが最後に評価されます。デフォルト以外のルールは、優先順位をいつでも変更できます。デフォルトルールの優先順位は変更できません。詳細については、「ルールの優先度の更新」を参照してください。

ルールのアクション

ルールのアクションごとに、タイプ、優先度、およびアクションを実行するために必要な情報があります。詳細については、「ルールアクションタイプ」を参照してください。

ルールの条件

ルールのアクションごとにタイプと設定情報があります。ルールの条件が満たされると、アクションが実行されます。詳細については、「ルールの条件のタイプ」を参照してください。

ルールアクションタイプ

リスナールールでサポートされているアクションタイプを以下に示します。

authenticate-cognito

〔HTTPSリスナー] Amazon Cognito を使用してユーザーを認証します。詳細については、「Application Load Balancer を使用してユーザーを認証する」を参照してください。

authenticate-oidc

〔HTTPSリスナー] OpenID Connect (OIDC) に準拠した ID プロバイダーを使用してユーザーを認証します。

fixed-response

カスタムHTTPレスポンスを返します。詳細については、「固定レスポンスアクション」を参照してください。

forward

指定されたターゲットグループにリクエストを転送します。詳細については、「転送アクション」を参照してください。

redirect

リクエストを別の にリダイレクトURLします。詳細については、「リダイレクトアクション」を参照してください。

最も優先度の低いアクションが最初に実行されます。各ルールには次のアクションのうち、厳密に 1 つを含む必要があります。forward、redirect、fixed-response。またはそれは最後に実行されるアクションである必要があります。

プロトコルバージョンが gRPC または HTTP/2 の場合、サポートされているアクションはforwardアクションのみです。

固定レスポンスアクション

fixed-response アクションを使用してクライアントリクエストを削除し、カスタムHTTPレスポンスを返すことができます。このアクションを使用して、2XX、4XX、または 5XX のレスポンスコードとオプションのメッセージを返すことができます。

fixed-response アクションを実行すると、リダイレクトターゲットURLの アクションと がアクセスログに記録されます。詳細については、「アクセスログのエントリ」を参照してください。fixed-response アクションが正常に実行された数は、HTTP_Fixed_Response_Count メトリクスでレポートされます。詳細については、「Application Load Balancer のメトリック」を参照してください。

例 の固定レスポンスアクションの例 AWS CLI

ルールの作成時、または変更時にアクションを指定できます。詳細については、create-rule および modify-rule コマンドを参照してください。次のアクションは指定されたステータスコードとメッセージの本文を含む固定レスポンスを送信します。

[
  {
      "Type": "fixed-response",
      "FixedResponseConfig": {
          "StatusCode": "200",
          "ContentType": "text/plain",
          "MessageBody": "Hello world"
      }
  }
]

転送アクション

forward アクションを使用して、1 つ以上のターゲットグループにリクエストをルーティングできます。forward アクションに複数のターゲットグループを指定する場合は、ターゲットグループごとに重みを指定する必要があります。各ターゲットグループの重みは、0～999 の値です。加重ターゲットグループを持つリスナールールと一致するリクエストは、それらの重みに基づいてこれらのターゲットグループに分散されます。たとえば、ターゲットグループを 2 つ指定し、それぞれ重みが 10 の場合、各ターゲットグループはリクエストの半分を受け取ります。2 つのターゲットグループ (1 つは重みが 10 で、もう 1 つは重みが 20) を指定すると、重みが 20 のターゲットグループは他のターゲットグループの 2 倍の数のリクエストを受信します。

デフォルトでは、加重ターゲットグループ間でトラフィックを分散するようにルールを設定しても、スティッキーセッションが優先されるとは限りません。スティッキーセッションが確実に優先されるようにするには、ルールのターゲットグループの維持を有効にします。ロードバランサーが最初にリクエストを加重ターゲットグループにルーティングすると、選択したターゲットグループに関する情報をエンコード AWSALBTG し、Cookie を暗号化し、クライアントへのレスポンスに Cookie を含む という名前の Cookie が生成されます。クライアントは、受信した Cookie を、ロードバランサーへの後続のリクエストに含める必要があります。ロードバランサーが、ターゲットグループの維持が有効になっているルールに一致するリクエストを受信して Cookie が含まれている場合、リクエストは Cookie で指定されたターゲットグループにルーティングされます。

Application Load Balancer は、URLエンコードされた Cookie 値をサポートしていません。

CORS (クロスオリジンリソース共有) リクエストでは、一部のブラウザでスティッキーSameSite=None; Secureを有効にする必要があります。この場合、Elastic Load Balancing は 2 番目の Cookie を生成します。これには AWSALBTGCORS、元のスティッキーネス Cookie とこのSameSite属性と同じ情報が含まれます。クライアントは両方の Cookie を受け取ります。

例 1 つのターゲットグループを使用した転送アクションの例

ルールの作成時、または変更時にアクションを指定できます。詳細については、create-rule および modify-rule コマンドを参照してください。次のアクションは指定されたターゲットグループにリクエストを転送します。

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067"
              }
          ]
      }
  }
]
例 2 つの加重ターゲットグループを使用した転送アクションの例

次のアクションは、各ターゲットグループの重みに基づいて、指定された 2 つのターゲットグループにリクエストを転送します。

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067",
                  "Weight": 10
              },
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59",
                  "Weight": 20
              }
          ]
      }
  }
]
例 維持を有効にした転送アクションの例

複数のターゲットグループを含む転送アクションがあり、1 つ以上のターゲットグループでスティッキーセッションが有効になっている場合は、ターゲットグループの維持を有効にする必要があります。

次のアクションは、ターゲットグループの維持を有効にして、指定された 2 つのターゲットグループにリクエストを転送します。維持 Cookie を含まないリクエストは、各ターゲットグループの重みに基づいてルーティングされます。

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067",
                  "Weight": 10
              },
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59",
                  "Weight": 20
              }
          ],
          "TargetGroupStickinessConfig": {
              "Enabled": true,
              "DurationSeconds": 1000
          }
      }
  }
]

リダイレクトアクション

redirect アクションを使用して、クライアントリクエストURLを別の にリダイレクトできます。必要に応じて、リダイレクトを一時 (HTTP 302) または永続的 (HTTP 301) として設定できます。

URI は、次のコンポーネントで構成されます。

protocol://hostname:port/path?query

リダイレクトのループを避けるために、次のコンポーネントを 1 つ以上変更する必要があります: protocol、hostname、port、または path。変更しないコンポーネントはすべて、元の値が保持されます。

protocol

プロトコル (HTTP または HTTPS）。HTTP 、HTTP、 HTTP HTTPSHTTPSにリダイレクトできますHTTPS。HTTPS にリダイレクトすることはできませんHTTP。

hostname

ホスト名。ホスト名は大文字と小文字を区別せず、最大 128 文字の長さで、英数字、ワイルドカード (* と ?)、およびハイフン (-) で構成されます。

port

ポート (1～65535)。

パス

絶対パス (先頭は「/」で始まる)。パスは大文字と小文字が区別され、最大 128 文字の長さで、英数字、ワイルドカード (* と ?)、& (& を使用) および次の特殊文字 _-.$/~"'@:+ で構成されます。

query

クエリパラメータ 最大長は 128 文字です。

次の予約キーワードURLを使用して、ターゲットURL内の元の のURIコンポーネントを再利用できます。

  • #{protocol} – プロトコルが保持されます。プロトコルとクエリコンポーネントで使用します。

  • #{host} – ドメインが保持されます。ホスト名、パス、クエリコンポーネントで使用します。

  • #{port} – ポートが保持されます。ポート、パス、クエリコンポーネントで使用します。

  • #{path} – パスが保持されます。パスとクエリコンポーネントで使用します。

  • #{query} – クエリパラメータが保持されます。クエリコンポーネントで使用します。

redirect アクションが実行されると、そのアクションはアクセスログに記録されます。詳細については、「アクセスログのエントリ」を参照してください。redirect アクションが正常に実行された数は、HTTP_Redirect_Count メトリクスでレポートされます。詳細については、「Application Load Balancer のメトリック」を参照してください。

例 コンソールを使用したリダイレクトアクションの例

次のルールは、HTTPSプロトコルと指定されたポート (40443) を使用する URL への永続的なリダイレクトを設定しますが、元のホスト名、パス、クエリパラメータは保持します。この画面は「https://#{host}:40443/#{path}?#{query}」に相当します。

HTTPS プロトコルと指定されたポート (40443) を使用する にリクエストをリダイレクトURLするが、元の の元のドメイン、パス、クエリパラメータを保持するルールURL。

次のルールは、元のプロトコル、ポート、ホスト名、クエリパラメータURLを保持する への永続的なリダイレクトを設定し、 #{path}キーワードを使用して変更されたパスを作成します。この画面は「#{protocol}://#{host}:#{port}/new/#{path}?#{query}」に相当します。

元のプロトコル、ポート、ホスト名、クエリパラメータURLを保持する にリクエストをリダイレクトし、 #{path}キーワードを使用して変更されたパスを作成するルール。
例 のリダイレクトアクションの例 AWS CLI

ルールの作成時、または変更時にアクションを指定できます。詳細については、create-rule および modify-rule コマンドを参照してください。次のアクションは、HTTPリクエストをHTTPS、リクエストと同じホスト名、パス、クエリ文字列を持つポート 443 のHTTPリクエストにリダイレクトします。

[
  {
      "Type": "redirect",
      "RedirectConfig": {
          "Protocol": "HTTPS",
          "Port": "443",
          "Host": "#{host}",
          "Path": "/#{path}",
          "Query": "#{query}",
          "StatusCode": "HTTP_301"
      }
  }
]

ルールの条件のタイプ

サポートされているルールの条件のタイプを以下に示します。

host-header

各リクエストのホスト名に基づいたルーティング。詳細については、「ホストの条件」を参照してください。

http-header

各リクエストのHTTPヘッダーに基づいてルーティングします。詳細については、「HTTP ヘッダー条件」を参照してください。

http-request-method

各HTTPリクエストのリクエスト方法に基づいてルーティングします。詳細については、「HTTP リクエストメソッドの条件」を参照してください。

path-pattern

リクエスト のパスパターンに基づいてルーティングしますURLs。詳細については、「パスの条件」を参照してください。

query-string

キーと値のペアまたはクエリストリングの値に基づいたルーティング。詳細については、「クエリ文字列の条件」を参照してください。

source-ip

各リクエストの送信元 IP アドレスに基づいたルーティング。詳細については、「送信元 IP アドレス条件」を参照してください。

各ルールには、オプションで次の各条件を 1 つ含めることができます。host-header、http-request-method、path-pattern、および source-ip。各ルールには、オプションで次の各条件を 1 つ以上含めることもできます。http-header および query-string。

1 つの条件につき最大 3 つの一致評価を指定できます。例えば、http-header条件ごとに、リクエスト内のHTTPヘッダーの値と比較する最大 3 つの文字列を指定できます。いずれかの文字列がHTTPヘッダーの値と一致する場合、条件は満たされます。すべての文字列が一致することを要求するには、一致評価ごとに 1 つの条件を作成します。

1 つのルールにつき最大 5 つの一致評価を指定できます。すべての文字列が一致であることを要求するには、一致評価ごとに1つの条件を作成します。

http-header、host-header、path-pattern、query-string 条件に対する一致評価にワイルドカード文字を含めることができます。1 ルールあたりのワイルドカード文字は 5 つまでです。

ルールは表示可能なASCII文字にのみ適用されます。コントロール文字 (0x00～0x1f および 0x7f) は除外されます。

デモについては、「Advanced Request Routing」を参照してください。

HTTP ヘッダー条件

HTTP ヘッダー条件を使用して、リクエストのHTTPヘッダーに基づいてリクエストをルーティングするルールを設定できます。標準またはカスタムHTTPヘッダーフィールドの名前を指定できます。ヘッダー名と一致評価では大文字と小文字は区別されません。次のワイルドカード文字は比較文字列でサポートされています。* (0 個以上の文字と一致) および ? (厳密に 1 文字と一致） ワイルドカード文字はヘッダー名ではサポートされていません。

例 のHTTPヘッダー条件の例 AWS CLI

ルールの作成時、または変更時に条件を指定できます。詳細については、create-rule および modify-rule コマンドを参照してください。以下の条件は、指定された文字列の 1 つに一致するユーザーエージェントヘッダーを使用するリクエストによって満たされます。

[
  {
      "Field": "http-header",
      "HttpHeaderConfig": {
          "HttpHeaderName": "User-Agent",
          "Values": ["*Chrome*", "*Safari*"]
      }
  }
]

HTTP リクエストメソッドの条件

HTTP リクエストメソッド条件を使用して、リクエストのHTTPリクエストメソッドに基づいてリクエストをルーティングするルールを設定できます。標準メソッドまたはカスタムHTTPメソッドを指定できます。一致評価は大文字と小文字を区別します。ワイルドカード文字はサポートされていません。したがって、メソッド名は厳密な一致である必要があります。

HEAD リクエストへのレスポンスはキャッシュされる可能性があるため、 GET および HEADリクエストは同じ方法でルーティングすることをお勧めします。

例 のHTTPメソッド条件の例 AWS CLI

ルールの作成時、または変更時に条件を指定できます。詳細については、create-rule および modify-rule コマンドを参照してください。以下の条件は、指定されたメソッドを使用するリクエストによって満たされます。

[
  {
      "Field": "http-request-method",
      "HttpRequestMethodConfig": {
          "Values": ["CUSTOM-METHOD"]
      }
  }
]

ホストの条件

ホストの条件を使用して、ホストヘッダーのホスト名に基づいてリクエストをルーティングする (ホストベースのルーティングとも呼ばれます) ルールを定義できます。これにより、1 つのロードバランサーを使用して複数のサブドメインおよび異なるトップレベルドメインをサポートできます。

ホスト名では大文字と小文字が区別されず、最大 128 文字までの次の文字を含めることができます。

  • A～Z、a～z、0～9

  • - .

  • * (0 個以上の文字と一致します)

  • ? (厳密に 1 個の文字と一致します)

少なくとも 1 つの「.」文字を含める必要があります。最後の「.」の文字の後はアルファベット文字のみ含めることができます。

ホスト名の例

  • example.com

  • test.example.com

  • *.example.com

ルール *.example.com は、test.example.com には一致しますが、example.com には一致しません。

例 のホストヘッダー条件の例 AWS CLI

ルールの作成時、または変更時に条件を指定できます。詳細については、create-rule および modify-rule コマンドを参照してください。以下の条件は、指定された文字列に一致するホストヘッダーを使用するリクエストによって満たされます。

[
  {
      "Field": "host-header",
      "HostHeaderConfig": {
          "Values": ["*.example.com"]
      }
  }
]

パスの条件

パス条件を使用して、リクエストURLの に基づいてリクエストをルーティングするルールを定義できます (パスベースのルーティング とも呼ばれます）。

パスパターンは、クエリパラメータではなくURL、 のパスにのみ適用されます。表示可能なASCII文字にのみ適用され、コントロール文字 (0x00～0x1f および 0x7f) は除外されます。

ルール評価は、URI正規化が発生した後にのみ実行されます。

パスパターンでは大文字と小文字が区別され、最大 128 文字までの次の文字を含めることができます。

  • A～Z、a～z、0～9

  • _ - . $ / ~ " ' @ : +

  • & (& を使用)

  • * (0 個以上の文字と一致します)

  • ? (厳密に 1 個の文字と一致します)

プロトコルバージョンが g の場合RPC、条件はパッケージ、サービス、またはメソッドに固有の場合があります。

HTTP パスパターンの例

  • /img/*

  • /img/*/pics

gRPC パスパターンの例

  • /package

  • /package.service

  • /package.service/method

パスパターンはリクエストのルーティングに使用されますが、変更はしません。例えば、ルールにパスパターン /img/* がある場合、ルールは /img/picture.jpg のリクエストを /img/picture.jpg のリクエストとして、指定されたターゲットグループに転送します。

例 のパスパターン条件の例 AWS CLI

ルールの作成時、または変更時に条件を指定できます。詳細については、create-rule および modify-rule コマンドを参照してください。次の条件は、指定された文字列URLを含む を持つリクエストによって満たされます。

[
  {
      "Field": "path-pattern",
      "PathPatternConfig": {
          "Values": ["/img/*"]
      }
  }
]

クエリ文字列の条件

クエリ文字列の条件を使用して、キー/値のペアまたはクエリ文字列内の値に基づいてリクエストをルーティングするルールを設定できます。一致評価では大文字と小文字は区別されません。次のワイルドカード文字はサポートされています。* (0 個以上の文字と一致) および ? (厳密に 1 文字と一致)

例 のクエリ文字列条件の例 AWS CLI

ルールの作成時、または変更時に条件を指定できます。詳細については、create-rule および modify-rule コマンドを参照してください。次の条件は、「version = v1」のキー/値ペア、または「example」に設定されたキーのいずれかを含むクエリ文字列を使用するリクエストによって満たされます。

[
  {
      "Field": "query-string",
      "QueryStringConfig": {
          "Values": [
            {
                "Key": "version", 
                "Value": "v1"
            },
            {
                "Value": "*example*"
            }
          ]
      }
  }
]

送信元 IP アドレス条件

送信元 IP アドレス条件を使用して、リクエストの送信元 IP アドレスに基づいてリクエストをルーティングするルールを設定できます。IP アドレスは CIDR 形式で指定する必要があります。IPv4 と IPv6 アドレスの両方を使用できます。ワイルドカード文字はサポートされていません。ソース IP ルール条件255.255.255.255/32CIDRに を指定することはできません。

クライアントがプロキシの背後にある場合、これはクライアントの IP アドレスではなくプロキシの IP アドレスです。

この条件は、 ヘッダー内のアドレス X-Forwarded-Forでは満たされません。ヘッダーで X-Forwarded-Forアドレスを検索するには、 http-header 条件を使用します。

例 のソース IP 条件の例 AWS CLI

ルールの作成時、または変更時に条件を指定できます。詳細については、create-rule および modify-rule コマンドを参照してください。次の条件は、指定されたCIDRブロックのいずれかにソース IP アドレスを持つリクエストによって満たされます。

[
  {
      "Field": "source-ip",
      "SourceIpConfig": {
          "Values": ["192.0.2.0/24", "198.51.100.10/32"]
      }
  }
]

HTTP ヘッダーと Application Load Balancer

HTTP リクエストとHTTPレスポンスは、ヘッダーフィールドを使用してHTTPメッセージに関する情報を送信します。HTTP ヘッダーは自動的に追加されます。ヘッダーフィールドはコロンで区切られた名前と値のペアであり、キャリッジリターン (CR) とラインフィード (LF) で区切ります。HTTP ヘッダーフィールドの標準セットは、RFC2616 Message Headers で定義されています。また、アプリケーションによって自動的に追加され、広く使用される非標準HTTPヘッダーもあります。一部の非標準HTTPヘッダーにはX-Forwardedプレフィックスがあります。Application Load Balancer では、次の X-Forwarded ヘッダーがサポートされます。

HTTP 接続の詳細については、Elastic Load Balancing ユーザーガイド」の「リクエストルーティング」を参照してください。

X-Forwarded-For

X-Forwarded-For リクエストヘッダーは、 HTTPまたは HTTPSロードバランサーを使用する際にクライアントの IP アドレスを識別するのに役立ちます。ロードバランサーはクライアント/サーバー間のトラフィックをインターセプトするので、サーバーアクセスログにはロードバランサーの IP アドレスのみが含まれます。クライアントの IP アドレスを確認するには、routing.http.xff_header_processing.mode 属性を使用します。この属性を使用すると、Application Load Balancer がHTTPリクエストをターゲットに送信する前に、リクエスト内のX-Forwarded-Forヘッダーを変更、保存、または削除できます。この属性に指定できる値は、append、preserve、および remove です。この属性のデフォルト値は append です。

重要

X-Forwarded-For ヘッダーは、セキュリティリスクの可能性があるため、慎重に使用する必要があります。エントリは、ネットワーク内で適切に保護されているシステムによって追加された場合にのみ、信頼できると見なすことができます。

Append

デフォルトでは、Application Load Balancer は、クライアントの IP アドレスを X-Forwarded-For リクエストヘッダーに格納し、このヘッダーをサーバーに渡します。X-Forwarded-For リクエストヘッダーがオリジナルリクエストに含まれていない場合、ロードバランサーはリクエスト値としてクライアント IP アドレスを持つリクエストヘッダーを作成します。それ以外の場合、ロードバランサーはクライアント IP アドレスを既存のヘッダーに追加し、ヘッダーをサーバーに渡します。X-Forwarded-For リクエストヘッダーには、カンマで区切られた複数の IP アドレスを含めることができます。

X-Forwarded-For リクエストヘッダーは以下のような形式です。

X-Forwarded-For: client-ip-address

以下に、IP アドレスが 203.0.113.7 であるクライアントの X-Forwarded-For リクエストヘッダーの例を示します。

X-Forwarded-For: 203.0.113.7

アドレスが のクライアントのX-Forwarded-Forリクエストヘッダーの例を次に示しますIPv62001:DB8::21f:5bff:febf:ce22:8a2e。

X-Forwarded-For: 2001:DB8::21f:5bff:febf:ce22:8a2e

ロードバランサーでクライアントポート保持属性 (routing.http.xff_client_port.enabled) が有効になっている場合、X-Forwarded-For リクエストヘッダーには、client-ip-address の後にコロンで区切って client-port-number が含まれます。ヘッダーは、次のような形式になります。

IPv4 -- X-Forwarded-For: client-ip-address:client-port-number
IPv6 -- X-Forwarded-For: [client-ip-address]:client-port-number

の場合IPv6、ロードバランサーが既存のヘッダーclient-ip-addressに を追加すると、アドレスが角括弧で囲まれることに注意してください。

以下に、IPv4アドレスが 12.34.56.78でポート番号が のクライアントのX-Forwarded-Forリクエストヘッダーの例を示します8080。

X-Forwarded-For: 12.34.56.78:8080

以下に、IPv6アドレスが 2001:db8:85a3:8d3:1319:8a2e:370:7348でポート番号が のクライアントのX-Forwarded-Forリクエストヘッダーの例を示します8080。

X-Forwarded-For: [2001:db8:85a3:8d3:1319:8a2e:370:7348]:8080

Preserve

属性の preserve モードでは、HTTPリクエストのX-Forwarded-Forヘッダーがターゲットに送信される前に変更されないようにします。

Remove

属性の remove モードは、ターゲットに送信される前に、HTTPリクエストのX-Forwarded-Forヘッダーを削除します。

注記

クライアントポート保持の属性を有効にし (routing.http.xff_client_port.enabled)、かつ routing.http.xff_header_processing.mode 属性 に preserve または remove を選択した場合、Application Load Balancer はクライアントポート保持属性を上書きします。選択したモードに応じて、X-Forwarded-For ヘッダーを変更せずにおくか削除するかして、ターゲットに送信します。

次の表では、append、preserve、remove モードのいずれかを選択した際にターゲットが受信する X-Forwarded-For ヘッダーの例を示します。この例では、ラストホップの IP アドレスは 127.0.0.1 です。

リクエストの説明

リクエストの例

 XFF append モード XFF preserve モード XFF remove モード
リクエストはXFFヘッダーなしで送信されます GET /index.html HTTP/1.1 Host: example.com X-Forwarded-For: 127.0.0.1 [なし] [なし]
リクエストは、XFFヘッダーとクライアント IP アドレスとともに送信されます。 GET /index.html HTTP/1.1 Host: example.com X-Forwarded-For: 127.0.0.4 X-Forwarded-For: 127.0.0.4, 127.0.0.1 X-Forwarded-For: 127.0.0.4 [なし]
リクエストは、複数のクライアント IP アドレスを持つXFFヘッダーとともに送信されます。 GET /index.html HTTP/1.1 Host: example.com X-Forwarded-For: 127.0.0.4, 127.0.0.8 X-Forwarded-For: 127.0.0.4, 127.0.0.8, 127.0.0.1 X-Forwarded-For: 127.0.0.4, 127.0.0.8 [なし]
を変更、保存、または削除するには X-Forwarded-For コンソールを使用した ヘッダー

  1. で Amazon EC2コンソールを開きますhttps://console.aws.amazon.com/ec2/。

  2. ナビゲーションペインで、[ロードバランサー] を選択します。

  3. ロードバランサーを選択します。

  4. [属性] タブで、[編集] を選択します。

  5. トラフィック設定セクションのパケット処理 で、X-Forwarded-For ヘッダーに「追加 (デフォルト）」、「保存」、または「削除」を選択します。

  6. [Save changes] (変更の保存) をクリックします。

を変更、保存、または削除するには X-Forwarded-For を使用した ヘッダー AWS CLI

routing.http.xff_header_processing.mode 属性で modify-load-balancer-attributes コマンドを使用します。

X-Forwarded-Proto

X-Forwarded-Proto リクエストヘッダーは、クライアントがロードバランサーへの接続に使用したプロトコル (HTTP または HTTPS) を特定するのに役立ちます。サーバーアクセスログには、サーバーとロードバランサーの間で使用されたプロトコルのみが含まれ、クライアントとロードバランサーの間で使用されたプロトコルに関する情報は含まれません。クライアントとロードバランサーの間で使用されたプロトコルを判別するには、X-Forwarded-Proto リクエストヘッダーを使用します。Elastic Load Balancing は、クライアントとロードバランサーの間で使用されたプロトコルを X-Forwarded-Proto リクエストヘッダーに格納し、このヘッダーをサーバーに渡します。

アプリケーションまたはウェブサイトは、X-Forwarded-Protoリクエストヘッダーに保存されているプロトコルを使用して、適切な にリダイレクトされるレスポンスをレンダリングできますURL。

X-Forwarded-Proto リクエストヘッダーは以下のような形式です。

X-Forwarded-Proto: originatingProtocol

次の例には、X-Forwarded-Protoクライアントからリクエストとして発信されたリクエストのHTTPSリクエストヘッダーが含まれています。

X-Forwarded-Proto: https

X-Forwarded-Port

X-Forwarded-Port リクエストヘッダーは、ロードバランサーへの接続にクライアントが使用した送信先ポートを識別するために役立ちます。