出口IPは接続先側で測ります。プロキシ一覧のアドレスはクライアントが接続する待受先です。NAT、経路、別の外向き中継点によって、接続先から見える送信元アドレスは変わることがあります。

同じIP確認先を使い、プロキシなしとありで比較します。手軽な公開サービスの例はこちらです。

curl --noproxy '*' --connect-timeout 5 --max-time 15 https://httpbin.org/ip
curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 15 https://httpbin.org/ip

文書用のプロキシアドレスを実際の接続先に置き換えます。HTTPプロキシ一覧の項目なら、待受アドレスと観測した出口アドレスを分けて扱ってください。最初のリクエストは直通が許可される環境でプロキシを迂回します。次は迂回ルールを解除してプロキシを選びます。確認サービスは両方のリクエストを受け取るため、個人データ、Cookie、トークンは含めないでください。

HTTP 200だけでなく、報告されたアドレスを見ます。期待どおり別のアドレスになれば、このリクエストの経路を裏付けます。同じ結果なら、一覧が誤りだと判断する前に迂回ルールと設定を確認してください。

IP確認サービスが何を測るか確認する

httpbinの origin は、X-Forwarded-For があるとそれを利用する場合があります。そのため、生のソケット接続相手ではなくアドレスの連なりを含むことがあります。平文HTTP転送のテストでは特に関係します。精度が重要なら、管理下の確認サービスが適しています。既知のネットワーク境界で実際の接続相手を記録し、転送ヘッダーは自分の基盤が生成して検証する場合だけ信頼してください。

curlがすでに把握しているアドレス

curl --proxy http://203.0.113.10:8080 --noproxy '' --output /dev/null --write-out 'peer=%{remote_ip}\n' https://example.com/

remote_ip はcurlの接続相手を示します。この例では通常HTTPプロキシのエンドポイントです。curlがどこへ接続したかは分かりますが、プロキシの外向き送信元アドレスは観測しません。後者に答えるのは接続先側の結果です。

実際にプロキシを使うアプリ内でも確認を繰り返してください。curlの成功はブラウザーを設定してくれません。プロファイル、拡張機能、迂回ルール、システム設定を無視するアプリは別の経路を選び得ます。場所が重要なら観測した出口アドレスを調べ、結果にエンドポイントと出口の両方を保存します。

関連記事