ブラウザのHTTPプロキシ設定は、WebRTCに自動で適用されるわけではありません。通常のIP確認ページが調べるのはWebリクエストです。通話では、接続やアドレス探索に別の経路が使われることがあります。

SOCKS5を使っても、この違いは解消しません。Chromiumに組み込まれたSOCKS5 URLプロキシの実装が対応するのはTCPで、汎用的なUDPアソシエーションではありません。プロトコル自体の機能は、ブラウザのそのインターフェースより広いものです。

ブラウザにはWebRTC専用のネットワーク制御があります。Chromeはプライバシー拡張APIで、disable_non_proxied_udp などのIP処理ポリシーを公開しています。MozillaにもWebRTCのネットワークプライバシー設定の文書があります。Chromeのこの値はAPIのポリシーであり、どのブラウザにも共通するチェックボックスでも、あらゆるアドレスを隠す保証でもありません。

まず通常のWeb通信の出口を確認し、次に実際の会議アプリでWebRTCの挙動を調べてください。報告される各項目の意味が分かる診断ツールを使います。ローカルアドレス、中継アドレス、外部から観測した公開アドレスは、接続の異なる部分を表します。ブラウザとテスト条件も記録しましょう。ポリシー、拡張機能、プライバシー動作、利用可能な経路で結果は変わるので、「必ず漏れる」という断定も、WebのIP確認が成功したという事実も、それだけでは十分な結論になりません。

WebRTCの経路を制限したら、必要な通話をもう一度試してください。アドレスの露出を減らすことで、通話が接続できなくなる場合もあります。この兼ね合いは、HTTPプロキシのエンドポイントが稼働しているかどうかとは別です。

関連記事