このページはコミュニティーの尽力で英語から翻訳されました。MDN Web Docs コミュニティーについてもっと知り、仲間になるにはこちらから。

View in English Always switch to English

X-Forwarded-For ヘッダー

HTTP の X-Forwarded-For (XFF) リクエストヘッダーは、プロキシーサーバーを通してウェブサーバーへ接続したクライアントの、送信元 IP アドレスを特定するために事実上の標準となっているヘッダーです。

このヘッダーの標準化されたバージョンは HTTP の Forwarded ヘッダーですが、使用頻度はかなり少ないです。

警告: このヘッダーを適切に使用しない場合、セキュリティリスクがあります。 詳細は セキュリティーとセキュリティの考慮事項 の項を確認してください。

ヘッダー種別 リクエストヘッダー
禁止リクエストヘッダー いいえ

構文

http
X-Forwarded-For: <client>, <proxy>
X-Forwarded-For: <client>, <proxy>, …, <proxyN>

例えば、最初のヘッダーには IPv6 のクライアント IP アドレス、2 つ目のヘッダーには IPv4 のクライアント IP アドレス、3 つ目の例には IPv4 のクライアント IP アドレスと、IPv6 のプロキシー IP が指定されています。

http
X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348
X-Forwarded-For: 203.0.113.195
X-Forwarded-For: 203.0.113.195, 2001:db8:85a3:8d3:1319:8a2e:370:7348

ディレクティブ

<client>

クライアントの IP アドレス

<proxy>

プロキシーの IP アドレスです。 リクエストが複数のプロキシーを通して行われる場合、それぞれの通過するプロキシーの IP アドレスが書き出されます。 つまり、最も右側の IP アドレスが最も最近のプロキシーであり、最も左側の IP アドレスが元のクライアントのアドレスです(クライアントとプロキシーの動作が正常な場合)。

解説

クライアントがサーバーに直接接続すると、クライアントのIPアドレスがサーバーに送信され、たいていの場合、サーバーのアクセスログに記録されます。 クライアント接続がフォワードプロキシーまたはリバースプロキシーを経由した場合、サーバーが認識するのは最終のプロキシーの IP アドレスのみであり、これは多くの場合ほとんど有益ではありません。 特に、最終プロキシーがサーバーと同じ配信環境の一部であるロードバランサーである場合には、その傾向が顕著です。 より有益なクライアント IPアドレスをサーバーに提供するために、X-Forwarded-Forリクエストヘッダーが使用されます。

このヘッダーの詳しい使用方法は 構文解析IP アドレスの選択の項を確認してください。

セキュリティーとセキュリティの考慮事項

このヘッダーは設計上、クライアントの IP アドレスなどプライバシーに関わる情報を公開します。 したがって、このヘッダーを利用する場合はユーザーのプライバシーに留意する必要があります。

リクエストチェーン内のすべてのプロキシーが信頼できる(つまり、自身が制御している)ものであり、正しく設定されていることが分かっている場合、プロキシーによって追加されたヘッダーの部分は信頼できます。 悪意のあるプロキシーや設定が誤っているプロキシーが存在する場合、信頼できるプロキシーによって追加されていないヘッダーの一部は、偽装されたり、予期しない形式やコンテンツになったりする可能性が常にあります。 サーバーがインターネットから直接接続可能な場合(信頼できるリバースプロキシーの背後にある場合でも)、X-Forwarded-For の IP リストのいかなる部分も、セキュリティ関連の用途において信頼できる、あるいは安全であるとは考えることはできません。

X-Forwarded-For のセキュリティ関連の用途(レート制限や IP ベースのアクセス制御など)では、信頼できるプロキシーによって追加された IP アドレスのみを使用しなければなりません。 信頼できない値を使用すると、レート制限の回避、アクセス制御のバイパス、メモリーの枯渇、それ以外にもセキュリティや可用性への悪影響が生じる可能性があります。

左端の(信頼できない)値はなりすましによる悪影響が無い場合にのみ使用してください。

構文解析

X-Forwarded-For ヘッダーを不適切に構文解析すると、前回説明したような結果を招き、セキュリティに悪影響を及ぼす可能性が考えられます。 このため、ヘッダー値を構文解析する際には次の点を考えてみる必要があります。

リクエストには複数の X-Forwarded-For ヘッダーが含まれる可能性があります。 それらのヘッダーの IP アドレスは、最初のヘッダーの最初の IP アドレスから最後のヘッダーの最後の IP アドレスまでをひとつながりの単一のリストとして扱う必要があります。 これらを単一のリストとして扱うには 2 つの方法があります。

  • 全ての X-Forwarded-For ヘッダーをカンマで結合してからカンマ区切りのリストにする、もしくは
  • 各々の X-Forwarded-For ヘッダーをカンマ区切りのリストにしてから結合する

複数の X-Forwarded-For ヘッダーのうち 1 つだけ使用するのは不十分です。

いくつかのリバースプロキシーは自動的に複数の X-Forwarded-For ヘッダーを 1 つに結合します。しかし、そうであると期待しない方が安全です。

IP アドレスの選択

アドレスを選択するときは、 IP の完全なリスト(全ての X-Forwarded-For ヘッダー)を使用する必要があります。

クライアントから最も近い X-Forwarded-For の IP アドレスを選択する場合(信頼できない、かつ、セキュリティに関係の ない 目的で)は、左端から 有効プライベート/内部 ではない最初の IP アドレスを選択する必要があります。

メモ: 上記で「有効なアドレス」と書いたのは、偽装された値が実際の IP アドレスではないことがあるためです。 さらに、クライアントが内部ネットワーク上でプロキシーを使用している可能性があり、そのプロキシーがプライベート IP アドレス空間のアドレスを追加している可能性があるため、「内部/プライベートではない」と書いています。

信頼できる 最初の X-Forwarded-For クライアント IP アドレスを選択するには、追加の構成が必要です。これらは一般的に 2 つの方法があります。

信頼できるプロキシーの数

インターネットとサーバーの間のリバースプロキシーの数が設定されています。 X-Forwarded-For IP リストは右端から 1 を引いて位置から検索されます。 例えば、リバースプロキシーが 1 つの場合は、そのプロキシーはクライアントの IP アドレスを追加するため右端の IP アドレスを使用するべきです。 もし、リバースプロキシーが 3 つある場合、最後の 2 つの IP アドレスは内部のものになるでしょう。

信頼できるプロキシーのリスト

信頼できるリバースプロキシーの IP リストもしくは IP の範囲が設定されています。 X-Forwarded-For IP リストは右端から検索されますが、この時に信頼できるプロキシーリストのアドレスはスキップされます。 信頼できるリストに一致しなかった最初のアドレスが目的のアドレスです。

最初の信頼できる X-Forwarded-For IP アドレスは実際のクライアントコンピューターではなく信頼できない中間プロキシーのものかもしれません、しかし、それはセキュリティ用途のための唯一適した IP アドレスです。

クライアントとプロキシーの IP

次の X-Forwarded-For リクエストヘッダーから、クライアント IP アドレスが 203.0.113.195 であり、リクエストが 2 つのプロキシーを経由したことが推測できます。 まず最初のプロキシーの IPv6 アドレスは 2001:db8:85a3:8d3:1319:8a2e:370:7348 であり、リクエストチェーンの最後のプロキシーが持つ IPv4 アドレスは 198.51.100.178 です。

http
X-Forwarded-For: 203.0.113.195,2001:db8:85a3:8d3:1319:8a2e:370:7348,198.51.100.178

仕様書

現行のどの仕様書にも含まれていません。このヘッダーの標準化版は Forwarded ヘッダーです。

関連情報