図でわかるX-Forwarded-For(XFF)とは

X-Forwarded-For(XFF)について、図を用いて簡単に説明します。MDNを見れば理解できるものの、とっつきづらさがあるため再整理します。

XFFをひとことで言うと

クライアントとサーバ間にプロキシやロードバランサ(LB)が存在した場合に、サーバでクライアントのIPアドレスを取得するための仕組み(ヘッダ)です。

正確には、MDNの記述を確認すると良いでしょう。

X-Forwarded-For (XFF) ヘッダーは、 HTTP プロキシ又はロードバランサーを通過してウェブサーバーへ接続したクライアントの、送信元 IP アドレスを特定するために事実上の標準となっているヘッダーです。クライアントとサーバーとの間でトラフィックに何かが介在すると、サーバーのアクセスログにはプロキシ又はロードバランサーのアドレスしか残りません。クライアントの元 IP アドレスを記録するために、 X-Forwarded-For 要求ヘッダーが使用されます。

https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/X-Forwarded-For

具体的には以下のようなヘッダが追加されます。

X-Forwarded-For: <client>, <proxy1>, <proxy2>

https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/X-Forwarded-For

一番左がクライアントIPで、プロキシを経由するごとに右にプロキシのIPアドレスが追加されていきます。

XFFを図で表すと

例えば、クライアント→プロキシサーバ→ロードバランサ→WEBサーバの経路の場合は、各サーバで受信するX-Fowarded-Forヘッダは以下のようなイメージになります。

上図のWEBサーバでは、「X-Fowarded-For: xxx.xxx.1.10, xxx.xxx.2.21, xxx.xxx.2.22」を受け取ります。一番左がクライアントIP(xxx.xxx.1.10)で、サーバを経由するごとに経由サーバのIPアドレスが右に追加されていることがわかりますね。

XFFがないとどうなるの

クライアントIPを受け取れない場合にどうなるのかと同義です。当たり前過ぎて言及されていないのであえて記載してみます。

WEBサーバの例であげると、アクセス元が特定できないため、IPアドレスをもとにアクセス制限をかけることができなかったり、出力するログが全てローカルIPアドレスになったりします。それらの影響について、アクセス制限は言わずもがな、ログの場合はクライアント別でのアクセス集計をする時や障害調査をするときに困ってしまいます。そのため、XFFがあるんですね。

XFFがない場合、上図のWEBサーバでは、ロードバランサのIPアドレス(xxx.xxx.2.22)だけが情報として渡ってきます。そのIPをアクセス制限するわけにはいかないですし、クライアント別でログ集計したところで全て接続元がロードバランサになってしまいます。

あとがき

以上がXFFについての説明です。XFFがないと、プロキシサーバやロードバランサを挟んだ場合にWEBサーバなどでクライアントIPが取得できないことがわかりました。

XFFはHTTPレイアでの仕組みで、クライアントから詐称が容易です。そのためアクセス制限を実施する際は、XFFだけで判断するのではなく、適切な設定を行う必要があります。別の記事では、Nginxにおいての設定を確認します。