Classic Load Balancer (CLB) のレイヤー 4 リスナーを使用すると、バックエンドサーバーはクライアントの IP アドレスを取得できます。ほとんどの場合、追加の設定なしで直接取得できます。ただし、IPv6 クライアントが IPv4 サービスにアクセスする場合、クライアントの IP アドレスを取得するには、CLB のリスナーとバックエンドサーバーの両方で Proxy Protocol を有効にする必要があります。
仕組み

直接取得
CLB のレイヤー 4 リスナーは、通常パススルーモードで動作します。このモードでは、バックエンドサーバーが受信する送信元 IP アドレスは、クライアントの実際の IP アドレスになります。
ただし、この方法は特定のシナリオでは効果がありません。このような場合、クライアントの IP アドレスを取得するには Proxy Protocol を設定する必要があります。詳細については、「Proxy Protocol を使用したクライアント IP アドレスの取得」をご参照ください。
Proxy Protocol を介したクライアント IP アドレスの取得
Proxy Protocol は、プロキシサーバーとバックエンドサーバー間でクライアントの元のネットワーク接続情報を渡すための通信プロトコルです。
通常、プロキシサーバーがクライアントリクエストをバックエンドサーバーに転送する際、リクエストヘッダーを書き換え、クライアントの送信元 IP アドレスとポートを自身のものに置き換えます。
Proxy Protocol を使用することで、プロキシサーバーはクライアントの元のネットワーク接続情報をリクエストヘッダーにカプセル化し、バックエンドサーバーに送信します。バックエンドサーバーは、この Proxy Protocol ヘッダーを解析することで、送信元 IP アドレス、送信元ポート、トランスポートプロトコルなど、クライアントの実際のネットワーク接続情報を取得できます。
Proxy Protocol により、バックエンドサーバーは元のクライアント接続情報を正確に取得でき、より精密なロギング、アクセス制御、トラフィックモニタリングが可能になります。
-
Proxy Protocol が機能するには、プロキシサーバーとバックエンドサーバーの両方がそれをサポートしている必要があります。Proxy Protocol ヘッダーを解析できないバックエンドサーバーでこの機能を有効にすると、解析エラーが発生し、サービスの可用性に影響を与える可能性があります。
-
CLB のレイヤー 4 リスナーは、Proxy Protocol を使用して、送信元 IP、宛先 IP、送信元ポート、宛先ポートなどの元の接続情報を伝送できます。この情報は、既存のデータを破棄したり上書きしたりすることなく、TCP または UDP データヘッダーの先頭に追加されます。
-
CLB は Proxy Protocol v2 のみをサポートしています。Proxy Protocol v2 は、TCP や UDP など、複数のトランスポートプロトコルをサポートしています。詳細については、「The PROXY protocol」をご参照ください。
CLB インスタンスの背後にある IPv4 サービスに IPv6 クライアントがアクセスする場合、クライアントの IP アドレスを取得するには、CLB のレイヤー 4 リスナーとバックエンドサービスの両方で Proxy Protocol を有効にする必要があります。
操作手順
直接取得
このシナリオでは、バックエンドサーバーから直接クライアントの IP アドレスを取得できます。
バックエンドサーバーとして Nginx を使用している場合、Nginx のログを確認して、クライアントの IP アドレスが正しくキャプチャされていることを確認できます。
以下は、Nginx のデフォルトのログフィールド設定の例です。
http {
# Default configuration
log_format main '$remote_addr- $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
#...
}
Nginx ログファイルのデフォルトパスは /var/log/nginx/access.log です。
各ログエントリの最初の IP アドレスが、クライアントの実際の IP アドレスです。
140.205.1xxx - - [xxx, xxx] xxx xxx xxx xxx xxx xxx
xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx
140.205.xx.29 - [27/xxx xxx] xxx xxx xxx xxx xxx xxx xxx
xxx xxx xxx xxx xxx xxx xxx xxx xxx
140.205.xx.29 - - [2xxx xxx] 304 xxx xxx xxx xxx xxx xxx
Proxy Protocol
前提条件
-
CLB インスタンスを作成し、リスナーを追加済みであること。このトピックでは、ポート 80 の TCP リスナーを例として使用します。詳細については、「CLB インスタンスの作成と管理」および「TCP リスナーの追加」をご参照ください。
-
CLB インスタンス用に利用可能なサーバーグループを作成し、バックエンドサーバーを追加済みであること。このトピックでは、バックエンドプロトコルとして TCP を使用し、ポート 80 でリッスンする ECS インスタンスをバックエンドサーバーとする vServer グループを例として使用します。詳細については、「vServer グループの作成と管理」をご参照ください。
説明-
Proxy Protocol を有効にする前に、バックエンドサーバーが Proxy Protocol v2 をサポートしていることを確認してください。サポートしていない場合、新しい接続が失敗する可能性があります。
-
Nginx Plus R16 以降、およびオープンソースの Nginx 1.13.11 以降は、Proxy Protocol v2 をサポートしています。
-
CLB インスタンスの複数のリスナーが同じバックエンドサーバーグループに関連付けられている場合、これらすべてのリスナーで Proxy Protocol を有効にする必要があります。
-
ステップ 1:リスナーでの Proxy Protocol の有効化
-
Classic Load Balancer (CLB) コンソールにログインします。
-
上部のナビゲーションバーで、CLB インスタンスがデプロイされているリージョンを選択します。
-
インスタンス ページで、ターゲットインスタンスを見つけて、その ID をクリックします。
-
インスタンス詳細ページで、リスナー タブをクリックし、ターゲットのレイヤー 4 リスナーを見つけて、その ID をクリックします。
-
リスナー詳細ページで、Proxy Protocol パラメーターが Proxy Protocol を使用して、クライアント IP アドレスをバックエンドサーバーに渡します。 に設定されているか確認します。このパラメーターが表示されない場合は、リスナーの変更 をクリックし、設定ページでこの機能を有効にします。
重要この機能はシームレスな移行をサポートしていません。Proxy Protocol を有効にすると、変更を適用するためにサービスの再起動が必要になります。注意して進めてください。
ステップ 2:バックエンドでの Proxy Protocol の有効化
このセクションでは、CentOS 7.9 と Nginx 1.20.1 を搭載したサーバーを例として使用します。設定はご利用の環境によって異なる場合があります。
-
バックエンドサーバーにログインし、
nginx -tコマンドを実行して設定ファイルのパスを確認します。デフォルトのパスは通常/etc/nginx/nginx.confですが、実際のパスは異なる場合があります。 -
設定ファイルで Proxy Protocol の設定を変更し、変更を保存します。変更内容については、以下の例をご参照ください。
http { # Make sure to set $proxy_protocol_addr. log_format main '$proxy_protocol_addr - $remote_addr- $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; # Use port 80 as an example and add the proxy_protocol parameter. server { listen 80 proxy_protocol; #... } } -
sudo nginx -s reloadコマンドを実行して Nginx の設定ファイルを再読み込みします。
ステップ 3:結果の確認
バックエンドサーバーとして Nginx を使用している場合、Nginx のログを確認して、クライアントの実際の IP アドレスが正常に取得されているかを確認できます。
Nginx ログファイルのデフォルトパスは /var/log/nginx/access.log です。
各ログエントリで、$proxy_protocol_addr 変数に対応する IP アドレスがクライアントの実際の IP アドレスです。
Proxy Protocol v2 ヘッダーのフォーマット
上記の例のサーバーを使用しない場合は、Proxy Protocol v2 ヘッダーのフォーマットと「The PROXY protocol」を参照して、カスタム解析を実装できます。詳細については、ご利用のサーバーの公式ドキュメントをご参照ください。
-
次の図は、クライアントの IPv4 アドレスを伝送する Proxy Protocol v2 のバイナリヘッダーフォーマットを示しています。

-
次の図は、クライアントの IPv6 アドレスを伝送する Proxy Protocol v2 のバイナリヘッダーフォーマットを示しています。

よくある質問
100 から始まる IP からの頻繁なアクセス
負荷分散システムは、外部リクエストをバックエンドの ECS インスタンスに転送し、ヘルスチェックを実行します。どちらのタイプのリクエストもシステムから発信されます。
負荷分散システムは、予約済みの CIDR ブロック 100.64.0.0/10 を使用します。このブロックは Alibaba Cloud 専用であり、セキュリティリスクはありませんが、100 から始まる IP からの頻繁なアクセスが記録される理由となります。
ご利用のサーバー上の iptables やその他のセキュリティソフトウェアが、この CIDR ブロックをブロックしないようにしてください。
ACK 環境でのクライアント IP の取得
Container Service for Kubernetes (ACK) クラスターでは、方法は同じですが、一部の操作の詳細が異なります。「ネットワーク管理に関するよくある質問」をご参照ください。
関連ドキュメント
クライアント IP アドレスを取得する方法は、ロードバランサーの種類によって異なります。
-
NLB インスタンスを使用する場合、サーバーグループでクライアント IP の維持を有効にするか、Proxy Protocol を有効にしてクライアント IP アドレスを取得できます。詳細については、「NLB インスタンスを介したクライアント IP アドレスの取得」をご参照ください。
-
CLB のレイヤー 7 リスナーを使用する場合、X-Forwarded-For ヘッダーを使用してクライアント IP アドレスを取得できます。詳細については、「CLB レイヤー 7 リスナーを使用してバックエンドサーバーがクライアント IP アドレスを取得する方法」をご参照ください。
-
ALB インスタンスを使用する場合、X-Forwarded-For ヘッダーを使用してクライアント IP アドレスを取得できます。詳細については、「クライアント IP アドレスの維持」をご参照ください。