WebRTC漏洩テスト：VPNから本物のIPアドレスが漏れていませんか？
このWebRTC漏洩テストは、追跡スクリプトと同一のP2P接続メカニズムを利用して、ブラウザが取得するアドレス群の中にVPNで隠蔽すべき本来のIPが含まれていないかを検証します。カメラやマイクの権限確認なしに空のデータチャネルで RTCPeerConnection を確立し、2台の公開STUNサーバーへ外部からの接続見え方を問い合わせ、通常のHTTPSアクセス元IPと厳密に照合します。
テストで検出されたICE候補の読み解き方
WebRTCは相手方デバイスと直接通信可能な経路を網羅的に探るため、ICE候補（ICE candidates）のリストを自動生成します。このページでは検出された生データをタイプや伝送プロトコルとともに一覧表示し、5秒経過後に検出を完了します。
その上部に表示されているのが、HTTP経由で検出された標準的なIPv4およびIPv6アドレスです（私のIPアドレス確認と同一の数値）。これらが判定の基準値となり、両者を突き合わせることで漏洩の有無を診断します。
host・srflx・relay — 各種バッジの意味
- ローカル（host） — ご自身のネットワークカードが保持するアドレス：
192.168.1.14などのLAN内IP、またはランダムな.local名。 - パブリック（STUN経由） —
srflx（Server Reflexive）候補。STUNサーバーがパケットを受信した公開IPであり、VPN利用時に最も注示すべき値です。 - リレー（TURN） — 中継サーバーを経由した通信。当ツールはSTUNのみを使用するため、relayの行が表示されるのは稀です。
各診断結果の意味
- 漏洩を検出 — STUN経由のパブリック候補がHTTP IPと一致しません。VPN接続時、WebRTCのパケットが暗号化トンネルをバイパスしています。
- 漏洩なし — 両者のIPアドレスが完全に一致しています。
- ローカルIP露出 — mDNS名ではなく、生のプライベートLANアドレスがそのまま表示されています。
- 保護済み — ローカルIPはランダムな
.localホスト名によって適切に難読化されています。 - パブリックIPなし / WebRTCブロック中 — STUNに到達できないか、ブラウザでWebRTCが無効化されています。
なぜWebRTCによってVPNが隠すIPが漏れるのか
WebRTCはブラウザ間での音声通話やビデオ会議、ファイル共有を直接実現するために策定されました。個別のルーター背後にある2台の端末を繋ぐにはNAT越えが不可欠であり、「この接続は外部から見てどのIPから発信されているか」をSTUNサーバーに問い合わせる必要があります。任意のWebサイトはこの通信をJavaScriptから静かに開始できます。
これがプライバシー保護の落とし穴となります。VPNは通常のWebトラフィック（HTTP）をトンネルへ迂回させますが、WebRTCは独自のUDPパケットを直接STUNサーバーに送信します。スプリットトンネルやブラウザ拡張機能型VPNの場合、UDP通信がトンネルを通らず直接プロバイダ回線へ抜けてしまいます。そのため、HTTPベースの VPNチェック とは矛盾する結果が生じることがあります。
ランダムな .local ホスト名は漏洩ではありません
ホスト候補欄に 192.168.1.14 ではなく 7b3f9c21-4d0a-48e7.local のような値が表示されている場合、保護機能は正常に動作しています。これはmDNS難読化と呼ばれ、ブラウザがローカルインターフェース用に一時的なマルチキャストDNS名を生成してIPの代用とします。Chrome、Edge、Brave、Firefox、Safariはこれを標準で採用しています。留意点として、これはLAN内アドレスを保護するものでVPN漏洩を防ぐものではない点、カメラ等の許可を与えたサイトには実際のローカルIPが開示される点があります。
ChromeおよびEdgeでWebRTC漏洩を防ぐ方法
どちらのブラウザも設定画面に直接のOFFスイッチは存在せず、chrome://flags や edge://flags 内の関連フラグも廃止されています。実効性のある対策は以下の3点です：
- ブラウザ拡張機能ではなくOS常駐型のフル機能VPNクライアントを使用する。全UDPパケットがトンネルを通過すれば、STUN側もVPNサーバーのIPしか検知できません。
- 拡張機能でIP処理ポリシーを固定する。WebRTC Leak Prevent等のツールを使い、
chrome.privacy.network.webRTCIPHandlingPolicyをdefault_public_interface_onlyまたはdisable_non_proxied_udpに設定してローカル露出を防ぎます。 - OSのグループポリシーで制御する。Windowsのレジストリ
SOFTWARE\Policies\Microsoft\EdgeでWebRtcLocalhostIpHandling（ChromeはWebRtcIPHandling）をAllowPublicInterfaceOnlyやDisableNonProxiedUdpに指定します。反映にはブラウザ再起動が必要です。
FirefoxでWebRTCを完全に無効化する手順
Firefoxは主要デスクトップブラウザの中で唯一、完全な無効化スイッチを備えています。アドレスバーに about:config と入力して警告を承諾し、media.peerconnection.enabled を検索してダブルクリックで false に切り替えます。再起動なしで即座に全サイトでWebRTCが無効化されます。
ただしこれは極端な措置であり、Google MeetやTeams、Discord、Zoomなどのブラウザ通話が接続できなくなります。通話機能を維持したい場合は上記をtrueのままにし、代わりに media.peerconnection.ice.default_address_only を true に変更してください。FirefoxはVPN出口となるデフォルトルートのIPのみを提供するようになります。
BraveブラウザでWebRTC漏洩を防止する設定
BraveはChromeが隠している設定項目をわかりやすく公開しています。brave://settings/privacy を開き、WebRTC IP handling policy を確認してください。VPN利用時は次の設定が推奨されます：
- Default — すべてのインターフェースを検索し、ローカルIPが漏れる可能性があります。
- Default Public and Private Interfaces — デフォルトルートを使用しますが、プライベートIPは開示されます。
- Default Public Interface Only — デフォルトルートのみを用い、ローカルアドレスを秘匿します。通話も維持できるため常用に最適です。
- Disable Non-Proxied UDP — プロキシがUDP非対応の場合TCPを強制します。最も厳格ですが（Torウィンドウの標準挙動）、P2P接続を阻害する場合があります。
Safari・iPhone・Android端末での注意点
モバイル環境やWebKitエンジンでは、デスクトップ向けの一般的なノウハウが通用しません。
macOS版Safari
現行のSafariには恒久的な全体OFFスイッチがありません。開発メニューのWebRTC項目もセッション終了でリセットされます。Safariはカメラ等を許可するまでローカルIPをmDNSで隠すため、Safari > 設定 > Webサイト でのサイト権限管理とシステム全体でのVPN併用が最も効果的です。
iPhoneおよびiPad (iOS/iPadOS)
iOS上の全ブラウザはWebKitエンジン使用が義務付けられており、ChromeやFirefoxでも about:config や拡張機能は使えません。コンテンツブロッカーもWebRTC通信は防げません。漏洩を防ぐには 設定 > VPN でUDPトラフィックを完全に通すシステムVPNを導入してください。
Android
Android版ChromeにはWebRTC関連のフラグや拡張機能がありません。Android版Braveは前述のIPポリシー設定を備えています。FirefoxはBetaやNightly版でのみ about:config を利用できます。全般的な対策として、Android設定で 常時接続VPN と VPN不使用の接続をブロック を有効化してください。
この診断テストで検知できない範囲
当ページは、ブラウザがJavaScriptに対して提供する範囲内の情報のみを検査します。OSレベルでのルーティングの狂いやVPNが対応していないIPv6経路の漏洩など、ブラウザ下位層のトラブルは把握できません（DNS漏洩も対象外です）。ファイアウォールがSTUNを遮断している場合は「パブリックIPなし」と出ますが、単に応答がなかったことを意味します。また、IPは個人識別の要素の一つに過ぎません。私のブラウザは何？ で確認できる画面情報やフォント一覧などの指紋情報により、VPN利用時でも個体が特定される場合があります。
よくある質問（FAQ）
VPN接続中でもWebRTCから本来のIPアドレスが漏洩することはありますか？
はい、十分にあり得ます。WebRTCはSTUNサーバーへ独自のUDPパケットを直接発信します。スプリットトンネルやブラウザ拡張機能型VPNでは、このUDPパケットがトンネルを通らず通常のプロバイダ回線を通ってしまうことがあります。STUNサーバーには実際のIPが通知され、サイト側はJSでそれを取得できます。OS全体のフルVPN導入が根本的な対策です。
EdgeブラウザでWebRTCを完全にオフにする方法はありますか？
通常の設定画面からはオフにできません。Edgeにトグルスイッチはなく、about:flags の古いフラグも撤廃されました。Windowsであればレジストリ SOFTWARE\Policies\Microsoft\Edge 内のポリシー WebRtcLocalhostIpHandling を AllowPublicInterfaceOnly や DisableNonProxiedUdp に設定することで制御可能です。再起動後、edge://policy で確認してください。
FirefoxでWebRTCやPeerConnectionを無効にする設定場所はどこですか？
アドレスバーに about:config と入力し、media.peerconnection.enabled を探して値を false に変更します。再起動なしでWebRTCが完全に無効化されますが、ブラウザでのオンライン会議が利用できなくなります。通話を維持したい場合は上記をtrueのまま、media.peerconnection.ice.default_address_only を true にしてください。
SafariでWebRTCを永久に無効化することは可能ですか？
現行のSafariでは恒久的に無効化することはできません。過去の実験的機能メニューは廃止され、開発メニューの項目もブラウザ終了時に初期化されます。SafariはLAN内IPをmDNSでマスクしているため、「Safari > 設定 > Webサイト」でサイトごとの権限を絞り込み、システム全体をカバーするVPNを利用するのが最善の対策です。
BraveでWebRTC漏洩を止める最適な設定は何ですか？
brave://settings/privacy を開き、VPNやプロキシ使用時は WebRTC IP handling policy を「Disable Non-Proxied UDP」に設定してください。WebRTCがプロキシ経由のTCP通信に制限され、STUNに本物のIPが見えるのを確実に防ぎます。通話への影響を抑えたい場合は「Default Public Interface Only」が扱いやすい選択肢です。
WebRTCのIPハンドリングポリシーはどれを選ぶべきですか？
一般的な利用では「Default Public Interface Only」が推奨されます。ローカルインターフェースを隠しつつUDP通信を維持し、ビデオ通話を正常に継続できます。高い匿名性を求める場合のみ「Disable Non-Proxied UDP」を選択してください。初期設定の2つのオプションは依然としてローカルIPを開示するため注意が必要です。
なぜWebRTCによってプライベートIPアドレスが外部に公開されてしまうのですか？
現代のブラウザではそのまま公開されることは基本的にありません。Chrome、Edge、Brave、Firefox、Safariは実際のLANアドレスを .local で終わる使い捨てのmDNS名に置き換えています。外部サイトには 192.168.1.14 ではなくその仮名が渡されます。もし生のIPが表示されている場合、この難読化保護が無効になっています。