X-Forwarded-For Inspect

HTTPヘッダー/経路情報をブラウザ内で整理・診断します。入力はサーバーへ送信しません。観測差分の一次切り分けに使えます。

状態

ブラウザ内で処理します。入力はサーバーへ送信しません。まずはここで一次切り分けしてください。

使い方

X-Forwarded-For（必要ならX-Real-IP）を貼り付けて「解析」。IP列と候補を一覧表示します（ヘッダー行/複数行貼り付け/ヘッダー全体の貼り付けOK）。

注意（このツール）

  • 信頼境界を超えた値は偽装され得ます。最終的な採用ルールはプロキシ構成に合わせて決めてください。

このページについて

何をするツール？

X-Forwarded-For のIPリストを分解し、先頭/末尾の意味を整理して表示します。X-Real-IP もあれば併せて表示します。

「どれが本当のクライアントIP？」という実務の混乱を整理するためのツールです。

X-Forwarded-For の基本

  • X-Forwarded-For は非標準ですが広く使われる転送ヘッダーです。
  • IPがカンマ区切りで並びます（多段プロキシで増える）。
  • 先頭が「元のクライアント」に近いことが多いが、信頼境界次第で解釈が変わります。

構文（読み方）

X-Forwarded-For は「IP, IP, IP」の形で並びます。スペースが混ざることもあります。

  • X-Forwarded-For: 203.0.113.1
  • X-Forwarded-For: 203.0.113.1, 198.51.100.2
  • X-Forwarded-For: 203.0.113.1, 198.51.100.2, 10.0.0.10

どのIPを採用する？（現実的な考え方）

結論は「信頼できるプロキシの範囲を決めて、その外側のIPだけを採用する」です。X-Forwarded-For の見た目だけで決めると偽装に弱くなります。

  • 信頼できる最終プロキシ（LB/CDN）だけが X-Forwarded-For を付与/上書きする運用にする
  • アプリは「信頼できるプロキシの数/範囲」を設定し、そこから外側のIPを採用する
  • private/loopback が混じる場合は、内部ホップか設定ミスの可能性があるため要注意

用語（このページの前提）

  • Client IP: 実際の利用者に近いIP（ただし信頼境界内で判断）。
  • Proxy chain: 中間者の並び。X-Forwarded-For が長くなる原因。
  • Trust boundary: 信頼できるプロキシの範囲。ここを超えた値は信用できない。

なぜ役立つ？（実務での混乱を解く）

X-Forwarded-For は「誰が追加したか」に依存します。正しい解釈には、信頼できるプロキシの範囲を明確にすることが重要です。

  • 左端が常にクライアントとは限らない（偽装可能）
  • 右端が常に自社の最終プロキシとは限らない（経路差/設定差）

X-Real-IP との関係

X-Real-IP は単一のIPを持つことが多く、X-Forwarded-For の先頭と一致する設計が多いです。どちらを信頼するかはプロキシ構成次第です。

よくある落とし穴

  • アプリがヘッダーをそのまま信じてIP制限をしてしまう（偽装で突破）
  • 信頼境界の設定ミスで「プロキシのIP」がクライアント扱いになる
  • ローカル/プライベートIPが混ざる（10.x / 192.168.x など）

セキュリティ注意点（信頼境界）

X-Forwarded-For はクライアントが偽装できます。信頼できるプロキシで上書き・検証した値だけを使用してください。

トラブル別チェックリスト

  • IP制限が突破される: XFFを信じすぎている可能性。信頼境界の外の値を採用していないか確認
  • 常に同じIPになる: 最終プロキシのIPを見ている/上書きされている/アプリの信頼設定が不足を疑う
  • プライベートIPが出る: 内部経路の露出/誤設定の可能性。どこで付与されているか調査

確認のしかた（実測）

X-Forwarded-For は通常リクエスト側なので、ブラウザのDevToolsやサーバーログで確認するのが確実です。

  • DevTools → Network → Request Headers で X-Forwarded-For / X-Real-IP を確認（見えない場合は中間者のみ付与の可能性）
  • アプリ/プロキシのアクセスログで「採用したクライアントIP」とヘッダー値を突き合わせる
  • Forwarded も併せて確認（Forwarded Inspect）して矛盾がないか見る

切り分け手順（おすすめ）

  • Request Headers Parser で X-Forwarded-For / X-Real-IP を抽出
  • このツールでIP列を分解して順序を確認
  • Forwarded ヘッダーと整合が取れているか確認
  • Forwarded Inspect
  • Via Inspect
  • Request Headers Parser
  • What is my IP

このツールでできること

  • X-Forwarded-For のIP列を分解して一覧表示
  • X-Real-IP を併せて表示
  • ヘッダー全体から X-Forwarded-For / X-Real-IP を抽出

注意（運用）

  • 中継機器でヘッダーが書き換わることがあります。取得地点を揃えて比較してください。
  • 最終判断はサーバーログと設定（信頼プロキシ、ルーティング）で確認してください。

参照仕様

  • RFC 9110（HTTP Semantics）
  • MDN: X-Forwarded-For

FAQ

どのIPをクライアントとして採用すべき？

信頼できるプロキシの範囲を定義したうえで、その外側の最左（または最初の未信頼）IPを採用するのが一般的です。

X-Real-IP と X-Forwarded-For が違う

中間者の付与順やポリシー差で不一致が起こります。信頼境界を明確にして採用ルールを決める必要があります。

参考リンク

  1. RFC 9110
  2. MDN: X-Forwarded-For
  3. MDN: Proxy servers and tunneling

site_map ルールに基づいて、次に確認すべきページを表示しています。

  1. X-Forwarded-Proto Inspect — X-Forwarded-Proto / Host を解析して外形URL判定を確認
  2. Forwarded Inspect — Forwarded を解析して転送経路情報を確認
  3. Via Inspect — Via を解析して経由プロキシ経路を確認