プロキシの先にある「真実」を見極める：X-Forwarded-Forの深淵と実装の鉄則
ネットワークエンジニアとして現場に立っていると、必ず一度は頭を抱える問題がある。「ログに出ているクライアントIPが、なぜかすべてロードバランサーのIPアドレスになっている」という現象だ。
WebアプリケーションのフロントにリバースプロキシやCDNを置くのは現代のインフラ構成における定石だが、その代償として、サーバーサイドは「本当の接続元」を見失うことになる。そこで登場するのが、標準化以前からデファクトスタンダードとして君臨し続ける `X-Forwarded-For` (XFF) ヘッダーだ。
今回は、この「歴史あるお節介なヘッダー」の正体と、現場でやってはいけない危うい実装について、実務的な視点で深掘りしていく。
—
1. X-Forwarded-Forが解決する「アイデンティティの喪失」
HTTP通信において、サーバーはTCPハンドシェイクの相手（直近のIP）しか認識できない。しかし、CDNやプロキシを経由すると、TCPの接続相手はCDNのエッジサーバーになってしまう。これではアクセス制限やジオブロック、あるいは解析のためのログ記録がままならない。
そこで、プロキシが「元々誰からリクエストが来たのか」をHTTPヘッダーに書き込み、サーバーに引き継ぐ。これがXFFの基本的な役割だ。
通信フローの可視化
リクエストが `Client -> Proxy A -> Proxy B -> Web Server` と流れる場合、各ステップでヘッダーは以下のように成長していく。
1. Proxy A到着時: `X-Forwarded-For:
2. Proxy B到着時: `X-Forwarded-For:
3. Web Server到着時: 最終的にカンマ区切りのリストとして渡される
サーバーサイドのアプリケーションは、このヘッダーの「一番左端」を見れば、真のクライアントIPに辿り着けるという仕組みだ。
—
2. 現場で直面する「偽装リスク」という地雷
ここからがシニアエンジニアとしての警鐘だ。「X-Forwarded-Forは、クライアントが自由に書き込めるヘッダーである」という事実を忘れてはならない。
悪意あるユーザーが `curl` でリクエストを送る際、自分で `X-Forwarded-For: 1.2.3.4` というヘッダーを付けて送信したらどうなるか？ サーバーが何も考えずにヘッダーの先頭を信用してログを吐けば、IPの偽装があっさり成立してしまう。
攻撃者が意図的にヘッダーを偽装する例
curl -H “X-Forwarded-For: 8.8.8.8” https://your-service.com/api/login
このリクエストを受けたサーバーは、あたかもGoogleのDNSサーバーからログイン試行があったかのように誤認する。レートリミットをIPベースで行っている場合、この偽装によって制限を回避されてしまうのだ。
—
3. 実践：安全にクライアントIPを特定する構成
では、どうすれば安全にIPを特定できるのか。答えはシンプルで、「信頼できるプロキシ以外からのXFFは信用しない」ことだ。
nginxでの設定例
リバースプロキシ（nginx）を最前線に置く場合、`real_ip` モジュールを使って信頼できるアップストリームを定義するのが定石だ。
nginx.conf の設定例
信頼できるプロキシ（例: 10.0.0.0/24）からのリクエストのみXFFを反映させる
set_real_ip_from 10.0.0.0/24;
ヘッダーとして受け取るべき名前を指定
real_ip_header X-Forwarded-For;
信頼できない経路からのヘッダーを無視し、正しいIPを$remote_addrに上書きする
real_ip_recursive on;
Python (FastAPI/Flask) での確認
アプリケーションコードで直接IPを取得する場合も、リクエストの「信頼性」を担保するミドルウェアを通すのが鉄則だ。
from fastapi import Request
@app.get(“/client-ip”)
async def get_client_ip(request: Request):
# 信頼できるプロキシ環境下であれば、ヘッダーから抽出可能
# ただし、直接request.headers.get(“X-Forwarded-For”)を
# ログに記録するのは厳禁。必ず信頼できるプロキシ経由か確認すること。
xff = request.headers.get(“X-Forwarded-For”)
client_ip = xff.split(‘,’)[0] if xff else request.client.host
return {“client_ip”: client_ip}
—
4. エンジニアへのアドバイス：デバッグの心得
トラブルシューティングの際、XFFの値を鵜呑みにするのではなく、以下の手順で「どこでIPが書き換わっているか」を追跡してほしい。
1. Rawログの確認: プロキシ（ALBやCloudFrontなど）のアクセスログと、バックエンドのアプリケーションログを突き合わせる。
2. ヘッダーの増殖を確認: XFFヘッダーが二重、三重に追加されていないか確認する。特に、プロキシが複数段ある場合、設定ミスでヘッダーが連結されず上書きされているケースがある。
3. 信頼の境界線を見極める: 「インターネットから直接Webサーバーにアクセスできる経路がないか」を確認する。もしWebサーバーがグローバルIPを公開しているなら、XFFによるIP特定はそもそも成立しない。
最後に
X-Forwarded-Forは、HTTPの歴史の中で「必要悪」として育ってきた仕様だ。標準化（RFC 7239の `Forwarded` ヘッダーなど）の動きもあるが、未だにXFFが主流であることに変わりはない。
このヘッダーを扱うときは、「これはユーザーから送られてきた単なる文字列である」という前提を常に持ち続けてほしい。その冷徹な視点こそが、堅牢なインフラを守る唯一の手段となるはずだ。
コメント