Forwardedヘッダー解析

標準Forwardedヘッダー

RFC 7239 Forwardedプロキシチェーンを解析し、各ホップのfor / by / host / protoの値を表示します。

Hop #1
for203.0.113.43
protohttps
hostapp.geekformat.com
Hop #2
for10.0.0.9
byingress

X-Forwarded-*互換ヘッダー

多くのゲートウェイはまだX-Forwarded-For / Host / Protoを使用します。これはチェーン順序でクライアントとプロキシアドレスを解析します。

2個のX-Forwarded-Forノードこれらのヘッダーは信頼できるプロキシチェーンでのみ意味を持ち、本当のクライアントIPとして扱うべきではありません。
#1203.0.113.43
#210.0.0.9

JSONプレビュー

{
  "standardized": [
    {
      "index": 0,
      "pairs": {
        "for": "203.0.113.43",
        "proto": "https",
        "host": "app.geekformat.com"
      }
    },
    {
      "index": 1,
      "pairs": {
        "for": "10.0.0.9",
        "by": "ingress"
      }
    }
  ],
  "legacy": {
    "x-forwarded-for": [
      "203.0.113.43, 10.0.0.9"
    ],
    "x-forwarded-proto": [
      "https"
    ],
    "x-forwarded-host": [
      "app.geekformat.com"
    ]
  }
}

プロキシヘッダーをオンライン解析。まず真の送信元・転送順序を把握。

関連おすすめ

Content-Disposition解析

CORS インスペクター

CSP生成

HTTPクッキー解析ツール

時間ツール

Meta Tag ジェネレーター

ユースケース

  • バックエンドで取得したクライアントIPが正しくない場合、まずForwarded・X-Forwarded-Forを分解して確認
  • リクエストが経由したCDN・Nginx・ゲートウェイなどのプロキシノード順序を分析し、転送パスを確認
  • リバースプロキシ設定をデバッグし、Host・Protoの透過伝送が正しいか確認してプロトコルダウングレードを回避
  • マルチレイヤープロキシ環境でリクエストヘッダーが書き換えまたは消失した原因をトラブルシューティングし、解析結果をチケット用にコピー

使い方

  1. Forwarded・X-Forwarded-For・X-Forwarded-Host・X-Forwarded-Protoなどのリクエストヘッダー内容を貼り付け
  2. ツールがプロキシチェーン・真のIP・Host・Protoフィールドを自動解析し構造化表示
  3. プロキシノード順序・プロトコル変換情報を確認し、転送パスが期待通りか検証
  4. 解析結果をコピーし、チケット・ログ分析・連携記録に使用

特徴

  • マルチレイヤープロキシチェーンを直接展開：誰が誰に転送したか・プロトコルがどう変化したか一目瞭然
  • 送信元特定がより安定：CDN・ゲートウェイ・リバースプロキシ・マルチレイヤープロキシのトラブルシューティングに適している
  • ゲートウェイ・CDNシーンに友好的：Nginx・Ingress・リバースプロキシ・CDN・APIゲートウェイの問題特定に適用
  • 結果を構造化表示：フィールド分解が明確で、チケット・ログ分析・連携記録へのコピーに便利

よくある質問

リクエストがどのプロキシノードを経由したか確認するには？

関連リクエストヘッダーを貼り付けるだけで、プロキシチェーンの順序と各ホップの転送情報を確認できます。特に真のIP消失・プロトコル識別エラーのトラブルシューティングに適しています。

なぜバックエンドで取得したクライアントIPが正しくないのですか？

一般的な原因として、プロキシレイヤーでの透過伝送未設定・ゲートウェイによるリクエストヘッダー上書き・マルチレイヤーCDN/リバースプロキシの重複が挙げられます。これらのヘッダー情報を解析することで、IPがどのレイヤーで書き換えられたかを判断できます。

Nginx・Ingress・APIゲートウェイ・CDN問題のトラブルシューティングに適していますか？

非常に適しています。特にオリジンフェッチパスが複雑・リクエストがマルチレイヤープロキシを経由する場合、ヘッダー情報の構造化表示によりトラブルシューティング効率が大幅に向上します。

IP以外にどのような情報を確認できますか？

送信元IP以外に、Host・Proto・byなどのフィールドも検査可能で、プロトコル変換・ドメイン透過伝送・プロキシ動作が期待通りか確認するのに役立ちます。