X-Forwarded-Proto Inspect

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

状態

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

使い方

X-Forwarded-Proto（必要なら X-Forwarded-Host）を貼り付けて「解析」。値と順序を一覧表示します（ヘッダー行/複数行貼り付け/ヘッダー全体貼り付けOK）。

注意（このツール）

  • 信頼境界の外から来る値は偽装され得ます。最終的な採用ルールはプロキシ構成に合わせて決めてください。

このページについて

何をするツール？

X-Forwarded-Proto と X-Forwarded-Host を分解し、HTTPS判定やホスト判定の材料をわかりやすく表示します。

「httpsなのにhttp扱い」「リダイレクトループ」「URL生成が壊れる」などの原因切り分けに役立ちます。

X-Forwarded-Proto の基本

  • X-Forwarded-Proto は「元のスキーム（http/https）」のヒントです。
  • TLS終端がロードバランサにあるとき、アプリが https を判定するために使われます。
  • X-Forwarded-Host は元のHost情報のヒントです。

構文（読み方）

単一値のこともあれば、カンマ区切りで複数値になることもあります（多段プロキシ）。

  • X-Forwarded-Proto: https
  • X-Forwarded-Proto: https, http
  • X-Forwarded-Host: example.com

例（よくあるパターン）

  • TLS終端（LB）: X-Forwarded-Proto: https が付与され、アプリは https と判定できる
  • 二重プロキシ: X-Forwarded-Proto が複数値になり、どれを採用するかが問題になる
  • Host書き換え: X-Forwarded-Host が想定外 → リダイレクト/URL生成が壊れる

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

  • Scheme: http/https などのプロトコル。
  • TLS termination: HTTPSをロードバランサで終端する構成。
  • Redirect loop: スキーム判定のズレで無限リダイレクトになる状態。

なぜ役立つ？（https判定のズレ）

プロキシ配下では、アプリが見ている「実際のスキーム/ホスト」と利用者が見ているものがズレることがあります。X-Forwarded-Proto/Host はその橋渡しです。

  • https なのに http 判定 → X-Forwarded-Proto が欠落/上書き
  • リダイレクトループ → https判定のミスマッチ
  • ホストがずれる → X-Forwarded-Host の値を確認

どの値を採用する？（信頼境界）

複数値になる場合、順序だけで決めるのは危険です。信頼できる最終プロキシが上書きした値のみを採用する、という運用設計が基本です。

  • 信頼できるプロキシの数/範囲をアプリに設定して “正しいスキーム” を決める
  • Forwarded: proto と整合するかも確認して矛盾を検出

よくある落とし穴

  • アプリが X-Forwarded-Proto を無視している（プロキシ信頼設定が無い）
  • プロキシが複数あって値が上書き/不一致になる
  • X-Forwarded-Host が複数値になっているのに先頭/末尾の扱いが不明

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

これらのヘッダーはクライアントが偽装可能です。信頼できるプロキシが上書きする前提で使うべきです。

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

  • Request Headers Parser で X-Forwarded-Proto / Host を抽出
  • このツールで値を分解して順序を確認
  • Forwarded（proto/host）との整合を確認

確認のしかた（実測）

X-Forwarded-Proto/Host は通常「中間者→アプリ間」で付与されるため、ブラウザからは見えないことがあります。アプリ側ログやLB/CDNのログで確認するのが確実です。

  • DevToolsで見えない場合: それは“付いていない”ではなく“ブラウザに来ていない”可能性
  • アプリのアクセスログで「採用したスキーム/ホスト」とヘッダー値を突き合わせる

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

  • リダイレクトループ: https判定が一致していない（X-Forwarded-Proto / Forwarded: proto / アプリの信頼設定）
  • 常にhttp扱い: TLS終端の位置、X-Forwarded-Proto が付与されているか、上書きされていないか
  • URL生成が壊れる: X-Forwarded-Host/Host、アプリ側の proxy-trust 設定、複数値の扱い
  • Forwarded Inspect
  • X-Forwarded-For Inspect
  • Via Inspect
  • Request Headers Parser

このツールでできること

  • X-Forwarded-Proto / X-Forwarded-Host を分解して一覧表示
  • 複数値の順序を表示
  • ヘッダー全体から該当行を抽出

注意（運用）

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

参照仕様

  • RFC 9110（HTTP Semantics）
  • MDN: X-Forwarded-Proto / X-Forwarded-Host

FAQ

どの値を採用すべき？

信頼境界を超えた値は偽装されるため、信頼できる最終プロキシが付与した値だけを採用します。

X-Forwarded-Proto と Forwarded: proto が矛盾する

中間者の付与順や上書きの有無で不一致が起こります。信頼境界を決め、優先順位をルール化してください。

参考リンク

  1. RFC 9110
  2. MDN: X-Forwarded-Proto
  3. MDN: X-Forwarded-Host
  4. MDN: Proxy servers and tunneling

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

  1. X-Forwarded-For Inspect — X-Forwarded-For / X-Real-IP を解析して送信元連鎖を確認
  2. Forwarded Inspect — Forwarded を解析して転送経路情報を確認
  3. Via Inspect — Via を解析して経由プロキシ経路を確認