Forwarded Inspect
HTTPヘッダー/経路情報をブラウザ内で整理・診断します。入力はサーバーへ送信しません。観測差分の一次切り分けに使えます。
状態
ブラウザ内で処理します。入力はサーバーへ送信しません。まずはここで一次切り分けしてください。
使い方
Forwarded を貼り付けて「解析」。エントリと for/by/host/proto を一覧表示します（Forwarded: 行/複数行貼り付け/ヘッダー全体貼り付けOK）。
注意（このツール）
- Forwarded は信頼境界の外では偽装され得ます。信頼できるプロキシで上書き・検証する前提で扱ってください。
このページについて
何をするツール？
Forwarded ヘッダーを分解し、for/by/host/proto などの転送経路情報を一覧表示します。
「クライアントIPが取れない」「HTTPSなのにhttp判定になる」「Hostが変わる」などの原因切り分けに役立ちます。
Forwardedの基本
- Forwarded はプロキシ/ゲートウェイが付与する標準ヘッダーです。
- for/by/host/proto などのパラメータを複数エントリで持てます。
- 旧来の X-Forwarded-For などより標準的な形式です。
構文（読み方）
Forwarded は「key=value」のセミコロン区切りのエントリが、カンマ区切りで並びます。
- Forwarded: for=203.0.113.10;proto=https;host=example.com
- Forwarded: for=192.0.2.43, for=198.51.100.17;proto=http
- Forwarded: for="_gazonk"
例（よくあるパターン）
Forwarded は「中間者が付け足す」前提なので、複数エントリになることがあります。どの値を採用するかは信頼できるプロキシの範囲で決めます。
- TLS終端あり: proto=https が付く（アプリがhttps判定できる）
- host の付け替え: host= が想定とズレるとリダイレクト/URL生成が壊れる
- 匿名化: for=unknown や for=\"_...\" になる（ポリシー上の仕様）
用語（このページの前提）
- for: 送信元（クライアント）情報のヒント。
- by: 受け取ったプロキシ/ゲートウェイ情報。
- host: 受信時のホスト名。
- proto: 受信時のスキーム（http/https）。
なぜ役立つ？（経路と判定のズレ）
アプリの「IP/Host/Protocol判定」は中間者の挙動に依存します。Forwarded を見ると、どこで変わったかを推測しやすくなります。
- HTTPSなのに http 判定 → proto=https が届いているかを確認
- Host が想定と違う → host= の値が正しいかを見る
- IP が取れない → for= が潰されていないか/匿名化されていないかを確認
一緒に見るべきヘッダー（実務）
Forwarded だけで判断せず、古いヘッダー（X-Forwarded-*）や経路ヘッダー（Via）と整合を取ると切り分けが速くなります。
- X-Forwarded-For: クライアントIPの慣習的ヘッダー（多段になる）
- X-Forwarded-Proto: https/http判定で頻出
- X-Forwarded-Host: hostの付け替えがある環境で出ることがある
- Via: 経由プロキシの痕跡
よくある落とし穴
- X-Forwarded-For と Forwarded が両方あり、値が食い違う
- 複数エントリの順序を誤解する（左がクライアントに近いとは限らない実装もある）
- 信頼できないヘッダーをアプリがそのまま信じる（セキュリティ事故）
セキュリティ注意点（信頼境界）
Forwarded はクライアントが偽装可能です。信頼できるプロキシの手前でヘッダーを上書き/削除し、信頼境界を明確にする運用が必要です。
確認のしかた（実測）
最短は DevTools の Network でリクエストヘッダーを確認することですが、curl で再現すると共有しやすくなります（URLは置き換えてください）。
- curl -I https://example.com/ でレスポンスヘッダーを確認
- Forwarded は通常リクエスト側なので、サーバーログ/アプリのデバッグ出力も合わせて確認
切り分け手順（おすすめ）
- Request Headers Parser で Forwarded を抽出
- このツールで for/by/host/proto を分解
- X-Forwarded-For / X-Forwarded-Proto と値が一致しているか確認
トラブル別チェックリスト
- https判定が壊れる: proto=https が来ているか、ロードバランサの設定、X-Forwarded-Proto との整合を確認
- IPが全部プロキシになる: for= が上書きされている/最後の値だけ見ている/信頼境界の設定ミスを疑う
- Host/URL生成が壊れる: host= の値、X-Forwarded-Host、アプリ側の“プロキシ信頼設定”を確認
関連ツール
- Request Headers Parser
- Via Inspect
- Age Inspect
- Vary Inspect
このツールでできること
- Forwarded のエントリをカンマ区切りで分解
- for/by/host/proto を抽出して一覧表示
- ヘッダー全体から Forwarded 行を抽出
注意（運用）
- 中継機器でヘッダーが書き換わることがあります。取得地点を揃えて比較してください。
- 最終判断はサーバーログと設定（信頼プロキシ、ルーティング）で確認してください。
参照仕様
- RFC 9110（HTTP Semantics）
- RFC 7239（Forwarded）
- MDN: Forwarded
FAQ
Forwarded と X-Forwarded-For どちらを使うべき？
標準は Forwarded ですが、環境によっては X-Forwarded-* の方が普及しています。両方を見る設計が現実的です。
for=unknown や for="_gazonk" とは？
匿名化や内部的な識別子として使われることがあります。実IPが出ないのは仕様/ポリシーの可能性があります。
参考リンク
次に見る（診断順）
site_map ルールに基づいて、次に確認すべきページを表示しています。
- X-Forwarded-For Inspect — X-Forwarded-For / X-Real-IP を解析して送信元連鎖を確認
- Via Inspect — Via を解析して経由プロキシ経路を確認
- X-Forwarded-Proto Inspect — X-Forwarded-Proto / Host を解析して外形URL判定を確認