はじめに（この記事で分かること）#

VPNにつないで確認サイトを開いたら、「WebRTC」の欄に見覚えのないIPアドレスが出ていた。それはVPNの出口なのか、自宅の回線なのか、家庭内LANの番号なのか。表示の意味が分からないまま「WebRTCを切れ」という助言に従う人は多い。

この記事では、WebRTCがIPアドレスを相手に渡す仕組みを、IETFの規格文書（RFC 8828、RFC 8445、RFC 8489）の原文に沿って説明する。そのうえで、RFC 8828が定める4つのモードが各ブラウザの設定とどう対応するか、端末全体のVPNとブラウザ拡張型のVPNで結果が変わるのはなぜかを整理し、Firefox、Chromium系、Safari、Tor Browser、Mullvad Browserでの確認と設定に落とす。ブラウザの挙動は、各ブラウザの公式資料とソースコードで2026-11-08に確認した範囲で書いている。

前提: 脅威モデルの整理#

脅威モデル入門の5種類の相手のうち、WebRTCのリークに関係するのは、ページ上で動くJavaScriptからIPアドレスを受け取れる相手に限られる。WebRTCが集めたアドレスは、通信を始めたWebアプリケーションに渡される。RFC 8828は、これによってアプリケーションが「通常のHTTPの場合よりも多く」ローカルのネットワーク構成を知りうると書いている。

受け取れる立場にあるのは、訪れたサイトの運営者（プラットフォーム）と、そのページに埋め込まれたスクリプトを配る広告網やトラッカーである。プラットフォームが本物の回線のIPアドレスを記録すれば、IPアドレスの記事で扱った開示請求の連鎖が、VPNを使っていたにもかかわらずISPまで届く。広告網にとっては、家庭内LANの番号のような変わりにくい値が、同じ端末を見分ける材料になる。

逆に、ISPに対してはこの記事の対策はほとんど意味を持たない。WebRTCのリークは「サイトに何が見えるか」の問題であり、回線上で何が見えるかの問題ではないからだ。法執行機関については、プラットフォームの記録を取り寄せる経路では関係するが、ブラウザの脆弱性を突くような手段にはWebRTCの設定は効かない。そちらはTor Browserの記事のセキュリティレベルの話になる。

WebRTCがIPを伝える仕組み#

WebRTCは、ビデオ通話やファイル転送を、サーバーを経由せずブラウザ同士で直接やり取りするための仕組みだ。直接つながるには、互いに「自分にはこのアドレスで届く」という候補を交換する必要がある。この交換と疎通確認の手順がICE（Interactive Connectivity Establishment、RFC 8445）である。RFC 8828は、ICEが「STUNやTURNといった技術を使って複数のIPアドレスを発見し」、集めたアドレスは通常、端末の物理または仮想のプライベートアドレスと、インターネット上の公開アドレスから成ると説明している。

候補には種類がある。RFC 8445の定義をそのまま訳すと、ホスト候補は「ホスト上のIPアドレスから得た候補」で、物理インターフェースのアドレスに加えて「VPNで得たもののような論理的なアドレス」を含む。サーバー反射型（server-reflexive）候補は、STUNサーバーなどに向けてNATの外へパケットを送ったときに、NATが割り当てたアドレスとポートである。リレー候補は、TURNサーバーから得た中継用のアドレスだ。

STUN（RFC 8489）は、端末が「NATによって自分に割り当てられたIPアドレスとポート」を知るための手順である。端末がSTUNサーバーに問い合わせると、サーバーは届いたパケットの送信元アドレスを送り返す。家庭のルーターの内側にいる端末は自分の公開アドレスを知らないが、STUNを使えば外から見えている自分のアドレスが分かる。そしてICEは、こうして集めた候補をWebアプリケーションに渡し、アプリケーションが相手に送る。

ここで漏れる経路が2つ生まれる。1つはホスト候補で、192.168.0.2のような家庭内LANのアドレスがそのまま相手に渡る。もう1つはサーバー反射型候補で、STUNの問い合わせがどの経路でインターネットに出たかによって、VPNの出口のアドレスにも、VPNを通らない回線そのもののアドレスにもなる。後者が、VPN利用者にとってのWebRTCリークの本体である。

家庭内LANのアドレスは、それだけでは住所や名前にならない。それでもRFC 8828は、プライベートなIPv4アドレスは最悪の場合24ビットの情報量を持ち、期限なく変わらないことがあるため「かなり大きなフィンガープリントの材料」になりうると書いている。通常の閲覧とプライベート閲覧のように切り離したつもりのセッションが、同じ端末だと結び付けられる手がかりにもなる。

ホスト候補を隠す仕組みとして、IETFのMMUSIC作業部会でmDNS候補が提案された。ローカルのIPアドレスの代わりに、バージョン4のUUIDに.localを付けたランダムな名前を候補として相手に渡し、同じLAN内の相手だけがマルチキャストDNSで実際のアドレスを引ける、という方式である。この文書（draft-ietf-mmusic-mdns-ice-candidates-03、2021-12）はRFCにならないまま2022-06に失効しているが、後述するとおり主要ブラウザは実装している。注意したいのは、この方式が隠すのはホスト候補だけで、同じドラフト自身が、mDNS候補を出す場合もサーバー反射型候補は通常どおり生成されると書いている点だ。確認サイトで.localで終わる名前が表示されるのは、LANのアドレスが隠されている状態であり、それ自体は公開アドレスの漏れではない。

RFC 8828の既定と、漏れる条件#

RFC 8828（2021-01、Standards Track）は、WebRTCの実装がIPアドレスをどう扱うべきかを定めた文書である。性能とプライバシーの釣り合いが違う4つのモードを定義し、どれを既定にすべきかを勧告している。原文の定義を、読者の言葉に置き換えると次のようになる。

モードRFCの名称何が起きるか相手に渡りうるもの
Mode 1Enumerate all addressesすべてのネットワークインターフェースを使って、STUN・TURNサーバーや相手との通信を試みるすべてのインターフェースのローカルアドレスと、それぞれの経路の公開アドレス
Mode 2Default route + associated local addressesカーネルのルーティング表に従い、通常はHTTPの通信と同じ経路を使う。選んだインターフェースのプライベートアドレスはホスト候補として渡す既定経路の公開アドレスと、そのインターフェースのローカルアドレス
Mode 3Default route onlyMode 2と同じだが、プライベートアドレスを渡さない。集めるのはSTUNやTURNで見つけたアドレスだけ既定経路の公開アドレス
Mode 4Force proxyMode 3と同じだが、HTTPの通信がプロキシ経由なら、WebRTCのメディア通信もプロキシに通す。プロキシがUDPに対応していなければTCPを使うプロキシ側から見えるアドレス

RFCは、Mode 1を「ユーザーの同意がない限り使ってはならない（MUST NOT）」とし、同意の一例としてカメラ・マイクの使用許可（getUserMedia）に結び付ける方法を挙げている。同意がない場合はMode 2を使うべき（SHOULD）とし、利用者が望むなら実装がより厳しいモードを選んでもよい（MAY）とも書く。プライベートアドレスを隠すことを既定にしなかった理由についてRFCは、直接のP2P接続を許すという要件とそれを両立させる仕組みが当時は定義されていなかったからだと説明している。mDNS候補は、この隙間を埋める試みだったと読める。

漏れる条件について、RFC 8828は3つの懸念を挙げている。

1つ目は、端末が複数の経路を持つ場合だ。原文は、利用者が物理的な位置を隠すためにVPNを使っていて、VPNとOSが複数のインターフェースにまたがるルーティングに対応している場合（split-tunnel VPN）、WebRTCは「VPNの公開アドレスだけでなく、VPNが乗っているISPの公開アドレスも」発見できると書く。RFCは3つの懸念のうちこれを「最も大きい」とし、その理由を「一部の利用者にとってVPNを使う目的は匿名性だから」と述べている。同時に、社内VPNの利用者のように、メディアをVPNに通さず直接送るほうを好む人もいるとも付け加えている。

NATの内側のプライベートアドレスが知られることは、2番目の懸念に置かれている。前節で触れたフィンガープリントの問題で、RFCは1つ目より小さいが妥当な懸念としている。

3つ目は、利用者がブラウザにプロキシを設定しているが、インターネットへの直接の接続も許されている場合だ。RFCは、このときWebRTCのSTUNの確認はプロキシを迂回し、クライアントの公開IPアドレスを明かすと書いている。RFCが3つのうち最も少ないとしているのは、企業のプロキシ管理者がファイアウォールで制御できる場面を念頭に置いているためで、個人がブラウザにプロキシを設定する場面はその前提に当てはまらない。

端末全体のVPNと、ブラウザ拡張型VPNで結果が違う理由#

この3つの懸念を並べると、VPNの方式によって結果が変わる理由が見えてくる。

端末全体のVPN（WireGuardやOpenVPNのアプリで、OSの既定経路をトンネルに向けるもの）では、既定経路そのものがVPNのインターフェースになる。Mode 2やMode 3で動くブラウザは、カーネルのルーティング表に従ってSTUNの問い合わせを送るので、その問い合わせもトンネルを通り、サーバー反射型候補にはVPNの出口のアドレスが入る。ホスト候補に出るのは、VPNのインターフェースに割り当てられたトンネル内のアドレスである。RFC 8445がホスト候補の定義に「VPNで得たもののような論理的なアドレス」を明記しているのはこの場面に当たる。

ブラウザ拡張型のVPNは製品ごとに仕組みが違い、本記事では個別の製品を確認していない。ただ、拡張機能がブラウザのプロキシ設定として働く方式であれば、OSの既定経路は自宅の回線のままになる。HTTPの通信だけがプロキシを通り、WebRTCのSTUNは既定経路から出ていく。RFC 8828の3つ目の懸念がそのまま当てはまり、サーバー反射型候補には自宅の回線の公開アドレスが入る。VPNが接続済みと表示されていても、WebRTCの欄に自宅のIPが出るのはこの構造による。ChromeやFirefoxの拡張機能APIに、WebRTCの扱いを変える設定（後述のwebRTCIPHandlingPolicy）が用意されているのは、拡張機能側でこの経路を塞げるようにするためだと考えられる。

split-tunnel（特定のアプリやあて先だけをVPNから外す設定）を使っている場合は、RFCの1つ目の懸念に近づく。ブラウザがMode 2やMode 3で動いている限りは既定経路しか使わないが、後述のとおり、FirefoxもChromiumもカメラやマイクの使用を許可したページでは制限を外す。そのときに複数の経路が使える状態だと、VPNの外の回線の公開アドレスも候補に入りうる。

最後に、VPNの接続が切れている間は、どの方式でもWebRTCを含むすべての通信が自宅の回線から出る。これはWebRTC固有の問題ではなく、キルスイッチの記事で扱う領域である。IPv4だけをトンネルに通し、IPv6を素通しにしているVPN設定でも、IPv6の既定経路がVPNの外にあれば同じことが起こりうると考えられる（RFC 8828のMode 2はIPv4とIPv6の両方のアドレスを扱う）。

ブラウザ別の確認と設定#

確認のしかた#

確認には、BrowserLeaksのWebRTC Leak Testやipleak.netが使える。どちらもページ上でWebRTCの接続を試み、STUNサーバーとのやり取りで得た候補を表示する。

確認サイトの運営者も見ておく。ipleak.netのページ下部には「powered by AirVPN」とあり、VPN事業者のAirVPNが提供している（LamerzではAirVPNのレビューを掲載しているが、アフィリエイト契約はない）。VPN事業者が運営する確認ツールは、その事業者の製品を勧める動機を持ちうる点を割り引いて使いたい。BrowserLeaksは、サイト上で運営者の名義を確認できなかった。同サイトは個人データを収集せず指紋を保存しないと掲げているが、これは自己申告である。どちらのサイトも、確認の過程で利用者のIPアドレスを当然受け取る。

結果は次の順で読む。

  1. VPNを切った状態で一度開き、自宅の回線の公開IPアドレスを控える
  2. VPNにつないでからページを再読み込みし、ページ上部の「あなたのIPアドレス」がVPNの出口に変わったことを確かめる
  3. WebRTCの欄に、手順1で控えた自宅のアドレスが出ていないかを見る。出ていれば、それがRFC 8828のいう公開アドレスの漏れである
  4. 192.168.や10.で始まるアドレス、またはVPNのトンネル内のアドレスが出ている場合は、ホスト候補が隠されずに渡っている。.localで終わる名前ならmDNSで隠されている
  5. カメラやマイクの許可を与えたことがあるサイトでの挙動は、許可のない確認サイトでは再現されない点を覚えておく

手順5は、以下で見るブラウザの仕組みから来る。

Firefox#

Firefoxは、カメラ・マイクの許可の有無で候補の扱いを変えている。ソースコード（PeerConnectionImpl.cpp）では、ページがカメラやマイクを使用中でも許可を得てもいない場合、media.peerconnection.ice.default_address_onlyの設定値にかかわらず既定経路だけを使い、ホスト候補をmDNSで隠す（media.peerconnection.ice.obfuscate_host_addressesの既定値はtrue）。許可を与えたページでは、この2つの制限が外れる。コードから読み取れる限りでは、許可のないページはRFC 8828のMode 2にmDNSを重ねた状態、許可したページはMode 1に近い状態と整理できる。モードとの対応は筆者の読みだが、2016年のBug 1304600でも、カメラ・マイクの許可がない場合の既定をMode 2とする前提で議論されている（mDNSの導入はその後である）。

about:configで変えられる主な項目は、Mozillaのソースコードと資料で次のように確認できた。

項目既定値公式資料での説明
media.peerconnection.enabledtrueRTCPeerConnectionを有効にする。falseにするとWebRTCの接続そのものが作れなくなる（StaticPrefList.yaml）
media.peerconnection.ice.default_address_onlyfalseICE候補を既定のインターフェースに限る（MozillaWiki）
media.peerconnection.ice.no_hostfalse候補からローカルアドレスをすべて除く（MozillaWiki）
media.peerconnection.ice.proxy_only_if_behind_proxyfalse上の2項目と合わせてtrueにした状態が、拡張機能APIのdisable_non_proxied_udpと同等（Bug 1452713）
media.peerconnection.ice.relay_onlyfalseTURNのリレー候補だけを生成する（MozillaWiki）
media.peerconnection.ice.obfuscate_host_addressestrueホスト候補をmDNSの名前で隠す（Bug 1588817）

選び方は、脅威モデルとWebRTCを使う必要があるかで分かれる。ブラウザでビデオ通話をしないなら、media.peerconnection.enabledをfalseにするのが最も単純で、Mullvad VPNのヘルプもFirefoxではこの方法を案内している。ブラウザ拡張型のVPNやプロキシを使いながらWebRTCも残したい場合は、default_address_only、no_host、proxy_only_if_behind_proxyの3つをtrueにする。MozillaのBug 1452713の議論では、拡張機能APIのdisable_non_proxied_udpがRFC 8828のMode 4に当たると説明され、Firefox 70でこの3項目の組み合わせと同等になったと記録されている。

about:configの項目は将来の版で名前や意味が変わることがある。MozillaWikiのページは2020-01-03が最終更新である。2016年のBug 1304600では、Wikiの説明どおりdefault_address_onlyをtrueにしてもローカルアドレスが出るという報告に対し、Mozillaの開発者が「ドキュメントが古い」と認め、この項目は既定経路以外を使わせないだけで、ホスト候補をなくすにはno_hostかrelay_onlyを使うと答えている。設定を変えたら、上の手順で確認サイトの表示が変わったことを必ず見ておく。

Chromium系（Chrome・Edgeなど）とBrave#

Chromiumも、カメラ・マイクの許可でローカルアドレスの扱いを分けている。ソースコード（filtering_network_manager.h）のコメントは、マイクかカメラの少なくとも一方の許可があることを確かめてから、ローカルIPアドレスをICE候補に使わせると書いている。許可がない場合はホスト候補のアドレスを.localの名前に置き換える機能（kWebRtcHideLocalIpsWithMdns）が、既定で有効になっている。

WebRTCの扱いを変える公式の手段として資料で確認できたのは、拡張機能APIと企業向けポリシーの2つである。Chromeの設定画面から切り替える方法は、公式の資料では確認できなかった。拡張機能APIのchrome.privacy.network.webRTCIPHandlingPolicy（Chrome 48以降）は、メディアの性能とプライバシーの釣り合いを利用者が指定するためのものとして説明されている。企業向けポリシーのWebRtcIPHandling（Chrome 91以降）は、ポリシー定義の本文でRFC 8828の5.2節を参照している。

値は4つあり、Chromiumのソースコードのコメントとポリシー定義では次のように説明されている。

値Chromiumの説明RFC 8828との対応
defaultWebRTCはすべてのインターフェースを列挙し、公開インターフェースを見つけるためにバインドできるMode 1（許可のないページでは上記の制限がかかる）
default_public_and_private_interfacesHTTPと同じ既定経路だけを使い、それに対応するプライベートアドレスも明かすMode 2
default_public_interface_only既定経路だけを使い、ローカルアドレスを明かさないMode 3
disable_non_proxied_udpプロキシがUDPに対応していない限りTCPで通信する。ローカルアドレスも明かさないMode 4

対応の列は、MozillaのBug 1452713で、仕様の策定段階の文書がこれら4つの値をMode 1から4に順に対応させていると説明されていることによる。

Ubuntu 26.04でGoogle Chromeを使っている場合、ポリシーはJSONファイルで与えられる。ChromiumのLinux Quick Startは、Google Chrome用の配置先として/etc/opt/chrome/policies/managed/を挙げている。

sudo mkdir -p /etc/opt/chrome/policies/managed
echo '{ "WebRtcIPHandling": "disable_non_proxied_udp" }' | sudo tee /etc/opt/chrome/policies/managed/webrtc.json

Chromeを再起動したらchrome://policyを開き、WebRtcIPHandlingが読み込まれたかを確かめる（Googleのヘルプ「View a device's current Chrome policies」に手順がある）。ディストリビューションが配布するChromiumはポリシーの配置先が異なり、同じ資料はChromiumの既定を/etc/chromium/policies、Ubuntuのパッケージでは/etc/chromium-browser/policiesとしている。Ubuntu 26.04のsnap版Chromiumでの配置先は今回確認していない。ポリシーを置くと、ブラウザは「組織によって管理されている」と表示するようになる。

Braveは、Chromiumの同じ4つの値を設定画面から選べる。BraveのGitHub Wiki「WebRTC Custom Settings」は、brave://settings/privacyで変更できるとし、フィンガープリント防止がオフの場合はdefault、オンの場合とTorウィンドウではdisable_non_proxied_udpが既定だと説明している。ただしこのWikiは2018-10-02の編集が最後で、現行版の既定値と一致するかは確認できなかった。Braveを使う場合は、設定画面の「WebRTC IP処理ポリシー」で現在の値を自分の目で確かめるのが確実である。なお現行のbrave-coreのソースコードでは、Torウィンドウ内でRTCPeerConnectionの作成そのものを拒否する処理が入っている。

Safari#

WebKitの公式ブログ（2017-07-03、Safari 11の時期）は、ホストIPアドレスは追跡に使われうるとして、カメラなどのキャプチャ機器へのアクセスがない場合はサーバー反射型とTURNの候補だけを公開し、許可が与えられたときにホスト候補を公開すると説明している。2018年のSafari Technology Preview 54のリリースノートには、データチャネルのP2P接続でのmDNS候補が実験的機能として追加されたとある。

現行のSafariがこの2つをどう組み合わせているかを明記した公式資料は見つからなかった。また、一般の利用者向けにWebRTCを止めるSafariの設定も、公式資料では確認できなかった（ブログが挙げている「Disable ICE Candidate Restrictions」は開発者向けメニューの項目で、制限を外す方向の設定である）。Safariでは、サーバー反射型候補が既定経路から出る前提で、端末全体のVPNを使うことが現実的な対策になる。

Tor BrowserとMullvad Browser#

Tor Browserは、WebRTCを既定で無効にしている。Tor Projectが公開しているTor Browser 16.0系のソースコード（tor-browser-153.7.0esr-16.0-1ブランチの001-base-profile.js）では、「Disable WebRTC interfaces」というコメントの下でmedia.peerconnection.enabledがfalseに、カメラやマイクの取得を担うmedia.navigator.enabledもfalseに設定されている。そのうえで多層防御として、mDNSによる隠蔽、TURNのリレー候補だけの使用（relay_only）、default_address_only、no_host、proxy_only_if_behind_proxyをすべて有効にしている。コメントには、利用者が自分でWebRTCを有効にした場合でもIPの漏れを防ぐためとある。

Tor Browserの利用者にとって、この設定は触らないのが合理的である。about:configを変えれば、ブラウザフィンガープリントの記事で扱う「全員が同じに見える」状態から自分だけが外れる。

Mullvad Browserは扱いが違う。同じTor Projectが開発するMullvad Browserのソースコード（mullvad-browser-153.7.0esr-16.0-1ブランチ）では、media.peerconnection.enabledをfalseにする行がなく、上の5つの防御設定だけが同じ値で入っている。コメントには「Mullvad BrowserはWebRTCを既定で有効にしているので、これらの設定は多層防御ではなく第一の防御になる」と書かれている。つまりMullvad BrowserではWebRTCの接続自体は作れるが、候補はTURNのリレー経由に限られ、ローカルアドレスは出ない。

ここで残るのは、TURNサーバーへの通信がどこから出るかである。Mullvad BrowserはIPアドレスを隠さず、VPNと組み合わせる前提のブラウザなので、端末全体のVPNが既定経路を握っていれば、TURNサーバーに見えるのもVPNの出口になる。VPNを切ったままMullvad Browserを開けば、WebRTCに限らずすべての通信が自宅の回線から出る。

対策の限界#

WebRTCを止めることには代償がある。RFC 8828は、WebRTCの安全なP2P接続は分散型のシステムを可能にし、プライバシー上の利点もありうるとして、WebRTCを無効にしたり著しく使いにくくしたりする「乱暴な解決策」は望ましくないと書いている。Mode 3やMode 4についても、通信がNATで折り返されたり、アプリケーションのTURNサーバーに頼ったり、接続そのものに失敗したりしうること、TCPを使うとメディアの品質が落ちることを、RFC自身が認めている。

実務では、ブラウザで動くビデオ通話、画面共有、P2Pのファイル転送が使えなくなるか、品質が落ちる。WebRTCを使うサービスと匿名で使う閲覧を同じブラウザで済ませていると、通話のたびに設定を戻すことになり、戻し忘れが新しい穴になる。通話用と匿名閲覧用でブラウザやプロファイルを分けておくほうが、設定を行き来するより事故が起きにくい。この区画の考え方はカンパートメント化の設計書で扱っている。

もう1つの限界は、カメラ・マイクの許可である。FirefoxもChromiumも、許可を与えたページではローカルアドレスの制限を外す。RFC 8828がMode 1の同意をgetUserMediaの許可に結び付けることを例示している以上、これは仕様に沿った挙動だ。匿名で使う区画では、ビデオ通話のためにカメラやマイクを許可したサイトが残っていないかを、ブラウザのサイト設定で見直しておきたい。

限界と残るリスク#

WebRTCのリークを塞いでも、サイトに見えるIPアドレスがVPNの出口に揃うだけである。IPアドレスを変えても、画面の大きさ、フォント、Canvasの描画結果といったブラウザの特徴が同じなら、サイトや広告網は同じブラウザだと判定できる。RFC 8828がプライベートアドレスを指紋の材料として挙げたのは、指紋全体のうちの一部の話にすぎない。この問題はブラウザフィンガープリントの記事で扱う。

WebRTCを無効にしたこと自体が、ブラウザの特徴の1つとして観測されうる点にも触れておく。RTCPeerConnectionが存在しないブラウザは少数派なので、普通のFirefoxやChromeで個別にWebRTCを切ると、その設定が目印になる可能性がある（推測であり、観測データでは確認していない）。Tor Browserのように全員が同じ設定を共有するブラウザでは、この問題は小さくなる。

DNSの問い合わせがトンネルの外に出るDNSリーク、VPNが切れた瞬間の通信、ログインしたアカウントやCookieは、WebRTCの設定とは独立した経路である。確認サイトで「漏れなし」と表示されても、それは確認した時点・確認したブラウザ・確認サイトが試した方法の範囲での結果であって、匿名であることの保証ではない。ブラウザの更新で設定の意味が変わることもあるので、大きな更新の後には確認をやり直す。点検の全体像は自分の匿名性を自己点検するにまとめている。

まとめ#

VPNを使い始めたばかりなら、今日やることは1つでよい。VPNを切った状態とつないだ状態でBrowserLeaksかipleak.netのWebRTCの欄を見比べ、自宅の回線のアドレスがVPN接続中にも出ていないかを確かめる。出ていなければ、端末全体のVPNと現行ブラウザの既定設定の組み合わせで、少なくとも確認した範囲では公開アドレスは渡っていない。出ていれば、使っているのがブラウザ拡張型のVPNやプロキシではないかをまず疑う。

ブラウザ拡張型のVPNやプロキシを使い続けたい人は、Firefoxならdefault_address_only・no_host・proxy_only_if_behind_proxyの3項目、ChromeならWebRtcIPHandlingポリシーのdisable_non_proxied_udp、Braveなら設定画面の同じ値を選び、確認サイトで結果が変わったことを見届ける。ブラウザで通話をしないなら、Firefoxのmedia.peerconnection.enabledをfalseにするほうが単純である。

匿名で使う区画を持つ人や開発者は、設定より区画の分け方から手を付けたほうが効く。匿名用にはTor BrowserかMullvad Browser＋端末全体のVPNを使い、WebRTCの設定には触らない。通話や画面共有は別のブラウザかプロファイルに分け、匿名用の区画ではカメラとマイクの許可を残さない。そのうえで、IPを揃えても残る指紋についてはブラウザフィンガープリントの記事を、VPN全体の選び方はVPN完全ガイドを読んでほしい。

出典#