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

Server Load Balancer:レイヤー 7 リスナーがクライアント IP アドレスを保持し、バックエンドサーバーに渡すことを有効にする

最終更新日:Mar 27, 2025

このトピックでは、X-Forwarded-For リクエストヘッダーを使用して、Classic Load Balancer(CLB)のレイヤー 7 リスナーがクライアント IP アドレスを保持できるようにする方法について説明します。

X-Forwarded-For のしくみ

HTTP および HTTPS リスナーは、X-Forwarded-For ヘッダーをサポートしています。バックエンドサーバーが X-Forwarded-For ヘッダーからクライアント IP アドレスを取得するように構成できます。

X-Forwarded-For の形式:

X-Forwarded-For: <Client IP address, IP address of Proxy Server 1, IP address of Proxy Server 2, ...>

したがって、X-Forwarded-For ヘッダーに含まれる一番左側の IP アドレスがクライアント IP アドレスです。

説明

CLB の HTTPS リスナーは、CLB 上の リクエストを暗号化します。ただし、CLB は HTTP を介してバックエンドサーバーと通信します。したがって、HTTPS リスナーを使用している場合でも、バックエンドサーバーは HTTP を使用します。

手順

前提条件

  • CLB インスタンスが作成されています。CLB インスタンス用にレイヤー 7 リスナーが作成されています。この例では、ポート 80 を使用する HTTP リスナーを使用します。詳細については、「CLB インスタンスの作成と管理」および「HTTP リスナーの追加」をご参照ください。

  • CLB インスタンス用にサーバーグループが作成されています。バックエンドサーバーがサーバーグループに追加されています。この例では、Elastic Compute Service(ECS)インスタンスを含み、HTTP とポート 80 を使用する vServer グループを使用します。詳細については、「vServer グループの作成と管理」をご参照ください。

ステップ 1: X-Forwarded-For に基づくクライアント IP の保持がリスナーで有効になっているかどうかを確認する

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

  2. 上部のナビゲーションバーで、CLB インスタンスがデプロイされているリージョンを選択します。

  3. [インスタンス] ページで、管理する CLB インスタンスの ID をクリックします。

  4. インスタンスの詳細ページで、[リスナー] タブをクリックし、管理するレイヤー 7 リスナーの ID をクリックします。

  5. リスナーの詳細ページで、[カスタム HTTP ヘッダー][x-forwarded-for: クライアント IP の取得] オプションが含まれているかどうかを確認します。

    説明

    デフォルトでは、CLB のレイヤー 7 リスナーは、X-Forwarded-For ヘッダーを使用してクライアント IP アドレスを保持します。このヘッダーは無効にすることができません。

ステップ 2: バックエンドサーバーを構成する

以下の手順は、バックエンドサーバーを構成する方法を示しています。使用するバックエンドサーバーのタイプに基づいて手順を選択してください。

NGINX サーバーを構成する

この例では、CentOS 7.9 オペレーティングシステムと NGINX 1.20.1 を使用します。使用する環境に基づいて構成を調整してください。

  1. NGINX サーバーで nginx -V | grep http_realip_module コマンドを実行して、http_realip_module モジュールが NGINX サーバーにインストールされているかどうかを確認します。NGINX サーバーは、http_realip_module モジュールを使用して X-Forwarded-For の値を解析します。

    出力に --with-http_realip_module が含まれている場合、http_realip_module が NGINX サーバーにインストールされていることを示しており、次のステップに進むことができます。

    http_realip_module がインストールされていることを示す出力例

    nginx version: nginx/1.20.1
    built by gcc 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) 
    built with OpenSSL 1.1.1k  FIPS 25 Mar 2021
    TLS SNI support enabled
    configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-compat --with-debug --with-file-aio --with-google_perftools_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_degradation_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_mp4_module --with-http_perl_module=dynamic --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_xslt_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' --with-ld-opt='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E'
    
    説明
    • 2011 年にリリースされた NGINX 1.0.4 以降は、http_realip_module モジュールをサポートしています。NGINX のバージョンが 1.0.4 より前の場合は、データをバックアップし、新しいバージョンにアップグレードすることをお勧めします。

    • http_realip_module モジュールが NGINX サーバーにインストールされていない場合は、NGINX を再コンパイルおよびインストールしてから、http_realip_module をインストールします。YUM などのパッケージマネージャーを使用して NGINX をインストールおよび管理することをお勧めします。パッケージマネージャーはプロセスを簡素化します。

  2. NGINX 構成ファイルを変更して保存します。次のコードブロックは例を示しています。nginx -t コマンドを実行して、構成ファイルのパスをクエリします。デフォルトでは /etc/nginx/nginx.conf です。パスは、使用する環境によって異なる場合があります。

    http {
      # X-Forwarded-For の値を記録するために使用される変数 $http_x_forwarded_for を設定します。
      log_format  main  '$remote_addr- $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$http_x_forwarded_for"';
      
      # ...
    }
    
  3. sudo nginx -s reload コマンドを実行して、NGINX 構成ファイルを再読み込みします。

Apache サーバーを構成する

この例では、CentOS 7.9 オペレーティングシステムと Apache 2.4.6 を使用します。使用する環境に基づいて構成を調整してください。

  1. Apache サーバーで httpd -M | grep remoteip_module コマンドを実行して、remoteip_module モジュールが Apache サーバーにインストールされているかどうかを確認します。Apache は remoteip_module を使用して X-Forwarded-For の値を解析します。

    出力に remoteip_module (shared) が含まれている場合、モジュールが Apache サーバーにインストールされていることを示しており、次のステップに進むことができます。

    説明
    • 2012 年にリリースされた Apache 2.4.0 以降は、remoteip_module モジュールをサポートしています。Apache のバージョンが 2.4.0 より前の場合は、データをバックアップし、新しいバージョンにアップグレードすることをお勧めします。

    • remoteip_module モジュールが Apache サーバーにインストールされていない場合は、Apache を再コンパイルおよびインストールしてから、remoteip_module をインストールします。YUM などのパッケージマネージャーを使用して Apache をインストールおよび管理することをお勧めします。パッケージマネージャーはプロセスを簡素化します。

  2. Apache 構成ファイルを変更して保存します。次のコードブロックは例を示しています。構成ファイルのデフォルトパスは /etc/httpd/conf/httpd.conf です。パスは、使用する環境によって異なる場合があります。

    # ...
    <IfModule log_config_module>
    	

  3. sudo systemctl restart httpd コマンドを実行して、Apache を再起動します。

IIS サーバーを構成する

この例では、Windows Server 2016 オペレーティングシステムを使用します。使用する環境に基づいて構成を調整してください。

  1. F5XForwardedFor ファイル をダウンロードして解凍します。

  2. F5XFFHttpModule.dll ファイルと F5XFFHttpModule.ini ファイルを x86\ または x64 ディレクトリから IIS サーバーのディレクトリにコピーします。IIS プロセスがディレクトリに対する読み取りおよび書き込み権限を持っていることを確認してください。

  3. [サーバーマネージャー][IIS マネージャー] を開きます。

  4. IIS サーバーを選択し、[モジュール] をダブルクリックします。

  5. [ネイティブモジュールの構成] をクリックし、表示されるダイアログボックスで [登録] をクリックします。

  6. ダウンロードした .dll ファイルを追加します。

    1. ファイル名を入力し、パスを選択して、[OK] をクリックします。

    2. 登録するモジュールが自動的に選択されます。[OK] をクリックします。

  7. IIS マネージャーのホームページに戻り、[ログ] をダブルクリックします。X-Forwarded-For に関する情報を記録するログ形式を構成します。

    1. [フィールドの選択] をクリックします。

      image.png

    2. 左下隅にある [フィールドの追加] をクリックし、次のフィールドを追加して、[OK] をクリックします。

      image.png

    3. 右側のアクションペインで [適用] をクリックします。

  8. IIS サーバーを再起動し、構成が有効になるまで待ちます。

ステップ 3: バックエンドサーバーがクライアント IP アドレスを取得できるかどうかをテストする

以下の手順は、テストを実行する方法を示しています。使用するバックエンドサーバーのタイプに基づいて手順を選択してください。

NGINX サーバー

NGINX サーバーを使用している場合は、NGINX ログを確認して、バックエンドサーバーがクライアント IP アドレスを取得できるかどうかを判断できます。

NGINX ログのデフォルトパスは /var/log/nginx/access.log です。

各ログエントリで、$http_x_forwarded_for 変数の一番左側の IP アドレスがクライアント IP アドレスです。

image.png

Apache サーバー

Apache サーバーを使用している場合は、Apache ログを確認して、バックエンドサーバーがクライアント IP アドレスを取得できるかどうかを判断できます。

Apache ログのデフォルトパスは /var/log/httpd/access_log です。

各ログエントリで、%{X-Forwarded-For}i 変数の一番左側の IP アドレスがクライアント IP アドレスです。

image.png

IIS サーバー

IIS サーバーを使用している場合は、IIS ログを確認して、バックエンドサーバーがクライアント IP アドレスを取得できるかどうかを判断できます。

ログファイルへのパスは、ログモジュールにあります。

image.png

各ログエントリで、X-Forwarded-For の一番左側の IP アドレスがクライアント IP アドレスです。

image.png

FAQ

100 で始まる IP アドレスがバックエンド ECS インスタンスに頻繁にアクセスするのはなぜですか?

CLB は、システムサーバーのプライベート IP アドレスを使用して、外部リクエストをバックエンド ECS インスタンスに転送します。また、CLB は ECS インスタンスにアクセスして、ヘルスチェックを実行し、サービスの可用性を監視します。

CLB のシステム CIDR ブロックは 100.64.0.0/10 で、Alibaba Cloud によって予約されています。セキュリティの問題を防ぐため、この CIDR ブロックは他のネットワーク要素に割り当てられていません。その結果、バックエンド ECS インスタンスは 100 で始まる IP アドレスからアクセスされます。

サービスの可用性を確保するために、これらの IP アドレスからのアクセスをすべてのバックエンドサーバーに許可するセキュリティルールを追加することをお勧めします。

Web Application Firewall(WAF)、Content Delivery Network(CDN)、または Global Accelerator(GA)と組み合わせて使用する場合、CLB はどのようにクライアント IP アドレスを保持しますか?

リクエストが CLB に到達する前に WAF、CDN、または GA によってフィルタリングされる場合、X-Forwarded-For ヘッダーを使用してクライアント IP アドレスを保持できます。WAF、CDN、および GA は、デフォルトで X-Forwarded-For ヘッダーをバックエンドサーバーに渡すことができます。追加の構成は必要ありません。

サービスのセキュリティを損なう可能性のある X-Forwarded-For なりすましを防ぐには、クライアント IP アドレスを記録するヘッダーを指定できます。たとえば、リクエストがクライアント、CDN、WAF、CLB、および ECS を経由し、CDN が Ali-Cdn-Real-Ip ヘッダーをバックエンドサーバーに渡す場合、Ali-Cdn-Real-Ip を有効にしてクライアント IP アドレスを記録し、$http_Ali_Cdn_Real_Ip 変数を NGINX 構成ファイルに追加できます。$http_Ali_Cdn_Real_Ip によって記録された IP アドレスがクライアント IP アドレスです。

システムのセキュリティを向上させるために、次の対策を講じることもできます。

  • X-Forwarded-For ヘッダーを認証する: バックエンドサーバーが無効または信頼できない X-Forwarded-For ヘッダーを含むリクエストをフィルタリングできるようにします。X-Forwarded-For ヘッダーの形式と IP アドレスを確認して、有効で信頼できるかどうかを判断できます。

  • ファイアウォールとアクセス制御リスト(ACL)を有効にする: CLB とそのバックエンドサーバーの間にファイアウォールと ACL をデプロイして、X-Forwarded-For ヘッダーを操作する可能性のある悪意のあるリクエストをフィルタリングします。

  • SSL/TLS 暗号化を有効にする: SSL/TLS 暗号化を有効にして、X-Forward-For ヘッダーの送信を含むデータ送信を暗号化します。この対策により、中間者攻撃(MITM)とデータ改ざんを防ぎます。

Container Service for Kubernetes(ACK)クラスタにデプロイされている場合、CLB はどのようにクライアント IP アドレスを保持しますか?

CLB は、ACK クラスタにデプロイされている場合、クライアント IP アドレスを保持できます。クライアント IP の保持は、さまざまな方法で実装できます。詳細については、「ポッドがクライアントの実際の IP アドレスを取得するように構成するにはどうすればよいですか?」をご参照ください。

関連情報

Application Load Balancer(ALB)、Classic Load Balancer(CLB)、および NLB は、クライアント IP アドレスを保持するために異なる方法を使用します。