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

Server Load Balancer:HTTP ヘッダー

最終更新日:Jun 09, 2026

このトピックでは、Application Load Balancer (ALB) でサポートされている追加の HTTP ヘッダーと、リスナーでそれらを設定する方法について説明します。これらのヘッダーを使用して、要件に基づいて特定の機能を実現できます。

ALB でサポートされるヘッダー

HTTP ヘッダーは、HTTP リクエストまたはレスポンスメッセージのヘッダーセクションにあるフィールドです。特定のニーズに合わせてヘッダーをカスタマイズでき、これにより Web サーバーやブラウザで追加の HTTP ヘッダーが使用されることがあります。次の表に、ALB がサポートする追加の HTTP ヘッダーとその機能を示します。

ヘッダーフィールド

説明

リスナープロトコル

X-Forwarded-For

リスナーが X-Forwarded-For ヘッダーを使用してクライアント IP アドレスを取得できるようにします。

  • X-Forwarded-For ヘッダーが有効な場合:

    ALB は、リクエストをバックエンドサーバーに転送する前に、リクエスト内の X-Forwarded-For ヘッダーを追加または削除します。

    • [追加] (デフォルト)

      デフォルトでは、ALB はクライアント IP アドレスを X-Forwarded-For ヘッダーフィールドに保存し、このヘッダーフィールドをバックエンドサーバーに送信します。元のリクエストに X-Forwarded-For ヘッダーフィールドが含まれていない場合、ALB はクライアント IP アドレスを含む X-Forwarded-For ヘッダーフィールドを作成します。それ以外の場合、ALB はクライアント IP アドレスを既存の X-Forwarded-For ヘッダーフィールドに追加し、そのヘッダーフィールドをバックエンドサーバーに送信します。X-Forwarded-For リクエストヘッダーフィールドには、コンマで区切られた複数の IP アドレスが含まれる場合があります。

    • [削除]

      ALB は、リクエストをバックエンドサーバーに転送する前に、リクエストから X-Forwarded-For ヘッダーを削除します。

  • X-Forwarded-For ヘッダーが無効な場合:

    ALB は、リクエストをバックエンドサーバーに転送する前に、リクエスト内の X-Forwarded-For ヘッダーを変更しません。

フォーマット:

X-Forwarded-For: <client-ip-address>, <proxy1>, <proxy2>, …

クリックすると、選択したアクション (追加、削除、または無効化) に基づいてバックエンドサーバーが受信する X-Forwarded-For ヘッダーの例が表示されます。

この例では、ALB に接続するクライアント IP アドレスは127.0.0.1 です。

リクエストの説明

リクエストの例

有効化 X-Forwarded-For ヘッダーフィールド

無効にする X-Forwarded-For ヘッダーフィールド

追加

削除

元のリクエストに X-Forwarded-For ヘッダーが含まれていない

GET /index.html HTTP/1.1

Host: example.com

X-Forwarded-For: 127.0.0.1

なし

なし

元のリクエストに、1 つのクライアント IP アドレスを持つ X-Forwarded-For ヘッダーが含まれている

GET /index.html HTTP/1.1

Host: example.com

X-Forwarded-For: 127.0.0.2

X-Forwarded-For: 127.0.0.2, 127.0.0.1

なし

X-Forwarded-For: 127.0.0.2

元のリクエストに、複数のクライアント IP アドレスを持つ X-Forwarded-For ヘッダーが含まれている

GET /index.html HTTP/1.1

Host: example.com

X-Forwarded-For: 127.0.0.2, 127.0.0.3

X-Forwarded-For: 127.0.0.2, 127.0.0.3, 127.0.0.1

なし

X-Forwarded-For: 127.0.0.2, 127.0.0.3

実際のクライアント IP アドレスを取得する方法については、「バックエンドサーバーでのクライアント IP の取得」をご参照ください。

SLB-ID

ALB インスタンスの ID を含む SLB-ID ヘッダーを追加します。

  • HTTP

  • HTTPS

  • QUIC

X-Forwarded-Proto

クライアントがリスナーへの接続に使用したプロトコルを含む X-Forwarded-Proto ヘッダーを追加します。アプリケーションは X-Forwarded-Proto ヘッダーに格納されているプロトコルを使用して、リクエストをターゲット URL にリダイレクトできます。

フォーマット:

X-Forwarded-Proto: <originatingProtocol>

典型的なユースケース:ALB インスタンスが HTTPS リスナーを使用し、リスナーとそのバックエンドサーバーグループ間の通信が HTTP を使用する場合。このシナリオでは、バックエンドサーバーは HTTP プロトコルでリクエストを受信します。バックエンドサーバーに HTTP を HTTPS に自動的にリダイレクトするルールが設定されている場合、クライアントが HTTP を使用していると誤って判断し、リダイレクトループが発生する可能性があります。 X-Forwarded-Proto ヘッダーを有効にすると、バックエンドサーバーはクライアントの元のリクエストプロトコルを取得でき、この誤ったリダイレクトを防ぐことができます。バックエンドサーバーがクライアントの元のリクエストポートを取得できるように、 X-Forwarded-Port ヘッダーも有効にすることを推奨します。

  • HTTP

  • HTTPS

  • QUIC

X-Forwarded-Port

リクエストを受信したリスナーポートを含む X-Forwarded-Port ヘッダーを追加します。

フォーマット:

X-Forwarded-Port: <port>
  • HTTP

  • HTTPS

  • QUIC

X-Forwarded-Host

クライアントからリクエストされた元のホストを含む X-Forwarded-Host ヘッダーを追加します。

フォーマット:

X-Forwarded-Host: <host>
  • HTTP

  • HTTPS

  • QUIC

X-Forwarded-Client-srcport

クライアントの送信元ポートを含む X-Forwarded-Client-srcport ヘッダーを追加します。

フォーマット:

X-Forwarded-Client-srcport: <port>

X-Forwarded-Clientcert-subjectdn

X-Forwarded-Clientcert-subjectdn ヘッダーフィールドを有効にすると、ALB インスタンスへのアクセスに使用されるクライアント証明書の所有者情報を取得できます。

このヘッダーを有効にした後、カスタム HTTP ヘッダー名を入力する必要があります。

HTTPS

X-Forwarded-Clientcert-issuerdn

X-Forwarded-Clientcert-issuerdn ヘッダーフィールドを有効にすると、ALB インスタンスへのアクセスに使用されるクライアント証明書の発行者情報を取得できます。

このヘッダーを有効にした後、カスタム HTTP ヘッダー名を入力する必要があります。

HTTPS

X-Forwarded-Clientcert-fingerprint

X-Forwarded-Clientcert-fingerprint ヘッダーフィールドを有効にすると、ALB インスタンスへのアクセスに使用されるクライアント証明書のフィンガープリント値を取得できます。

このヘッダーを有効にした後、カスタム HTTP ヘッダー名を入力する必要があります。

HTTPS

X-Forwarded-Clientcert-clientverify

X-Forwarded-Clientcert-clientverify ヘッダーフィールドを有効にすると、ALB インスタンスへのアクセスに使用されるクライアント証明書の検証結果を取得できます。

このヘッダーを有効にした後、カスタム HTTP ヘッダー名を入力する必要があります。

HTTPS

上記の追加 HTTP ヘッダーは、リスナーレベルのスイッチを使用して設定します。有効にすると、ALB は対応するヘッダーをバックエンドサーバーに転送されるリクエストに自動的に追加します。元のリクエストプロトコルやポートの指定など、ヘッダー値をカスタマイズする必要がある場合は、転送ルールのヘッダー挿入アクションを使用して手動で設定できます。リスナーレベルのスイッチはほとんどのパススルーシナリオに適していますが、転送ルールはヘッダー値のきめ細かい制御が必要なシナリオに最適です。これらの設定は、それぞれリスナー設定と転送ルールエディターの [詳細設定] セクションにあります。

説明
  • バックエンドサーバーが HTTP 仕様に従い、HTTP ヘッダーキーを大文字と小文字を区別しないものとして扱うことを推奨します。

    • ALB がバックエンドサーバーに転送する X-Forwarded-For ヘッダーは、常に大文字で始まります。

    • その他の追加 HTTP ヘッダーについては、クライアントリクエストにこれらのヘッダーのいずれかがすでに含まれている場合、ALB は転送時に元の大文字小文字の区別を保持します。それ以外の場合、ALB は上記の表に示されている大文字小文字の区別を使用してヘッダーを追加します。

  • X-Forwarded-Clientcert-subjectdnX-Forwarded-Clientcert-issuerdnX-Forwarded-Clientcert-fingerprint、またはX-Forwarded-Clientcert-clientverify を有効にする場合、カスタム HTTP ヘッダー名を次の予約済みフィールドのいずれかに設定することはできません: slb-id, slb-ip, x-forwarded-for, x-forwarded-proto, x-forwarded-eip, x-forwarded-port, x-forwarded-client-srcport, x-forwarded-host, connection, upgrade, content-length, transfer-encoding, keep-alive, te, host, cookie, remoteip, or authority

  • クライアント証明書に関連する追加 HTTP ヘッダーの説明

    次の追加 HTTP ヘッダーは、HTTPS リスナーで相互認証が有効になっている場合にのみ有効になります。

    X-Forwarded-Clientcert-subjectdn

    • 目的:クライアント証明書からのサブジェクト識別名 (DN) を含みます。

    • 内容:証明書所有者の識別情報。

    • フォーマット例: X-Forwarded-Clientcert-Subjectdn: CN=client.example.com,O=Example Corp,C=US

    • 含まれるもの:

      • CN (コモンネーム)

      • O (組織)

      • OU (組織単位)

      • C (国)

      • ST (都道府県)

      • L (市区町村)

    X-Forwarded-Clientcert-issuerdn

    • 目的:クライアント証明書からの発行者識別名 (DN) を含みます。

    • 内容:証明書を発行した認証局 (CA) に関する情報。

    • フォーマット例: X-Forwarded-Clientcert-Issuerdn: CN=Example CA,O=Example Corp,C=US

    • ユースケース:証明書が信頼された CA によって発行されたかどうかを検証します。

    X-Forwarded-Clientcert-fingerprint

    • 目的:クライアント証明書のデジタルフィンガープリントを含みます。

    • 内容:証明書のフィンガープリント。これは、SHA-1 や SHA-256 などのハッシュアルゴリズムを使用して、証明書全体のコンテンツから計算された固定長のハッシュ値です。証明書の一意の識別子として機能します。

    • フォーマット例: X-Forwarded-Clientcert-Fingerprint: SHA256=1234567890abcdef...

    • ユースケース:検証と監査のために証明書を一意に識別します。

    X-Forwarded-Clientcert-clientverify

    • 目的:クライアント証明書の検証結果を含みます。

    • 内容:証明書の検証ステータス。

    • 指定可能な値:

      • SUCCESS:証明書は検証済みです。

      • FAILED:証明書の検証に失敗しました。

      • NONE:クライアント証明書が提示されませんでした。

      • EXPIRED:証明書の有効期限が切れています。

      • REVOKED:証明書は失効しています。

コンソールでのヘッダーの追加

リスナー作成時のヘッダー追加

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

  2. 上部メニューで、ALB インスタンスがデプロイされているリージョンを選択します。

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

    • インスタンス ページで、管理するインスタンスを見つけ、操作 列の リスナーの作成 をクリックします。

    • インスタンス ページで、対象インスタンスの ID をクリックします。リスナー タブで、リスナーの作成 をクリックします。

  4. リスナーの設定 ウィザードで、次のパラメーターを設定し、次へ をクリックします。

    パラメーター

    説明

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

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

    [詳細設定]

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

    [追加のHTTPヘッダー]

    ビジネス要件に基づいて有効にする追加の HTTP ヘッダーを選択します。

    説明

    このセクションでは、ヘッダーに関連するパラメーターのみを説明します。その他のパラメーターの詳細については、次のトピックをご参照ください。

  5. 画面の指示に従って、リスナーの作成を完了します。

既存リスナーへのヘッダー追加

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

  2. 上部メニューで、ALB インスタンスがデプロイされているリージョンを選択します。

  3. インスタンス ページで、対象インスタンスの ID をクリックします。

  4. リスナー タブで、対象のリスナーを見つけ、操作 列の 更多>リスナーの変更 を選択します。

  5. リスナーの変更 ダイアログボックスで、詳細設定 の右側にある 変更 をクリックします。

  6. 追加のHTTPヘッダー セクションで、必要に応じてヘッダーを有効または無効にし、保存 をクリックします。

API を使用したヘッダーの追加

リスナーを作成するときに追加のヘッダーを設定したり、既存のリスナーのヘッダー設定を変更したりできます。

  • リスナーの作成:CreateListener API を呼び出し、XForwardedForConfig パラメーターで関連設定を構成します。

  • 既存のリスナーの変更:UpdateListenerAttribute API を呼び出して、XForwardedForConfig パラメーター内の設定を更新します。

関連ドキュメント

コンソール

  • ALB インスタンスを介して HTTP リクエストを転送するには、「HTTP リスナーの追加」をご参照ください。

  • ALB インスタンスを介して HTTPS リクエストを転送するには、「HTTPS リスナーの追加」をご参照ください。

  • ALB インスタンスを介して QUIC リクエストを転送するには、「QUIC リスナーの追加」をご参照ください。

API

  • CreateListener:HTTP、HTTPS、または QUIC リスナーを作成します。XForwardedForConfig パラメーターで HTTP ヘッダー関連の設定を構成することで、HTTP ヘッダーを追加できます。

  • UpdateListenerAttribute:リスナーの設定を更新します。XForwardedForConfig パラメーターを更新して、ヘッダー設定を変更できます。