出口IPが変わっても匿名とは限らない｜Forwarded・X-Forwarded-For・Viaの確認手順

日本IPプロキシの確認画面で出口IPが変わっていても、それだけで元のIPや経路情報が取得先へ伝わっていないとは判断できません。試用期間中は、取得先が実際に受信した送信元IPとHTTPヘッダーを確認する必要があります。

出口IP以外も確認すべき理由

Forwardedは、プロキシ経由で変更または失われた情報を開示するための任意のリクエストヘッダーです。元のリクエストIP、プロキシの受信側IP、HTTPとHTTPSのどちらが使われたかなどが含まれる可能性があります。RFC 7239

特にforパラメーターは、リクエストを開始したクライアントや後続のプロキシに関する情報の伝達に使われます。クライアントIPは、利用者や事業者、概略所在地の識別につながり得るため、プライバシー上センシティブな情報です。RFC 7239

標準化されたForwardedだけでなく、広く使われているX-Forwarded-Forによって利用者のIPが転送されている場合もあります。RFC 7239 したがって、「表示されたIPが日本だった」という一点ではなく、取得先から見える情報全体を比較するのが実用的です。

試用前に事業者へ確認する項目

契約前または試用開始前に、次の点を文書で確認します。

ForwardedとX-Forwarded-Forを付加、維持、削除する条件
元IP、内部IP、内部ホスト名を次の接続先へ渡す可能性
HTTPとHTTPSで挙動が異なるか
匿名化に関する設定を利用者側で変更できるか
不適合だった場合に利用できる試用終了・返金手続き

Forwardedは内部ネットワーク構造を露出する可能性があります。RFCでは対策として、識別子の難読化、内部ノードによる更新の抑止、出口プロキシでの該当情報削除が挙げられています。また、プロキシがforを使う場合、デフォルト設定に難読化識別子を含めることが推奨されています。RFC 7239

直結時とプロキシ経由時を同じ条件で比べる

機密情報を含まない、自分で管理できるHTTPSエコーエンドポイントを用意し、受信した送信元IPとリクエストヘッダーを記録します。認証情報、Cookie、業務データは送らず、同じURL・メソッド・任意ヘッダーで次の2回を実行してください。

プロキシを使わない直結リクエスト
試用中のプロキシを経由したリクエスト

比較対象は、取得先が観測した送信元IP、Forwarded、X-Forwarded-For、Via、そのほかClient-IP系のヘッダーです。転送内容の調査時には、curlのグローバルオプション--trace-asciiで通信トレースを保存できます。curl公式マニュアルトレースには秘密情報が入り得るため、共有用データでは認証情報などを扱わない構成にします。

判定の目安

観測結果	判断と対応
元のクライアントIPがヘッダーに残る	送信元IPの秘匿が目的なら不適合。設定変更を依頼し、解消できなければ不使用を検討
内部IPや内部ホスト名が残る	内部構成の露出として扱い、削除または難読化できるか確認
`Via`だけが見える	直ちに元IP漏えいとは判定しない。Viaはプロキシ自体の情報を示しますが、接続したクライアントの情報は含めません。RFC 7239
対象ヘッダーに漏えいがない	今回確認したHTTP情報の範囲では目的に近い。ただし、匿名性全体を証明したとは扱わない

ForwardedとViaは各プロキシで更新のされ方が異なるため、両者を単純に結合して経路を復元することはできません。RFC 7239 また、Forwardedはクライアントや途中のノードにより誤って、または悪意をもって変更され得るので、記載内容を無条件に真実とは扱えません。RFC 7239

デメリットと向いていない条件

この検証には、受信側でヘッダーを確認できる管理下の環境が必要です。出口IPだけを表示する外部サイトでは、取得先が受け取った全情報を比較できない場合があるため、匿名化要件の厳しい用途には向きません。

さらに、固有のクライアント識別子がなくても、Forwardedがプロキシ列を露出するとフィンガープリンティングを容易にする可能性があります。RFC 7239 ヘッダー検査は重要ですが、確認範囲をHTTP転送情報に限定した試験です。目的を「日本IPの利用」と「元IP・内部情報の秘匿」に分け、後者を必須条件にするなら、一度でも元情報が観測されたサービスを出口IP表示だけで採用しないことが安全側の判断です。