VPNを使っていてもWebRTCという機能を通して接続元のIPアドレスが漏れてしまう事例が幾つも確認されています。Chrome, Firefox等の普段使うブラウザにWebRTCは組み込まれており、プライバシーを脅かす1つの問題となっています。
漏れるかどうかは「VPNの種類」と「ブラウザの設定」の組み合わせで決まります。
仕組み、テストのやり方、拡張機能3種（WebRTC Leak Prevent／Network Limiter／Leak Shield）の設定値の順に整理します。
WebRTCとは？
WebRTCとは「Web Real-Time Communication」の略で、ビデオチャットや音声、ファイル転送やライブストリーミングをブラウザ間でやり取りすることを可能にする規格です。
Googleがオープンソース化した技術で、現在Chrome, FireFox, Safari, Opera, Edgeなどの主要ブラウザに実装されています。
通信方法の大きな特徴の1つはTorrentのように端末間で直接通信をやり取りするP2P (ピア・ツー・ピア) 方式を採用している点です。従来のWebSocketなどの通信方法は次のようにサーバーを介して通信されます。
しかし、WebRTCはメインのやり取りはユーザー間で行われます。そのために、低い遅延や速度の低下を防いだり、サーバーの負担を減らす事が出来ます。
Google MeetやZoom（ブラウザ版）、Wherebyなどがこの規格を採用しており現在もWebRTCを使用したサービスは増え続けています。
普及している一方で、プライバシーの面で大きな問題が見つかっています。
どんな問題が生じているの？
VPNを使っていても接続元のIPアドレスが第三者に渡っている可能性があります。この問題はWebRTC漏れ、もしくはWebRTCリークと呼ばれています。
P2Pという通信方法を採用している為に、電話番号を知らないと電話をかけられない事と同じく、お互いのIPアドレスを知ることによって初めて通信が成立します。
WebRTCを使ったサービスや、ウェブサイト自体がWebRTCを使って使用者のリアルIPアドレス（VPNのIPではなく、接続元のパブリックIP）を知る事が出来ます。このパブリックIPは家の住所のような個人情報で、相手に知られるとおおよその地域や契約している回線事業者が分かってしまいます。
何故IP漏れが生じる？
WebRTCで通話を始めるとき、ブラウザは「自分に届く可能性のあるアドレス」の候補を集めます。
候補は大きく2種類です。端末のネットワークに付いているアドレスと、STUNサーバーに問い合わせて分かる「外から見えたアドレス」です。
この候補の一覧は、ページ側のJavaScriptがそのまま受け取れます。
通話をしなくても、候補を集めさせて自社のサーバーへ送れば、アクセスした人のアドレスが分かります。
STUNサーバーが情報を溜めているのではなく、ブラウザが候補をページへ渡す仕組みそのものが漏れ口です。
VPNを使っていても実IPが出てしまうのは、主に次の2つの状況です。
- ブラウザが、VPN以外のネットワーク（ISP側の回線）も候補として使ってしまう
- Web閲覧はプロキシを通しているが、WebRTCのUDP通信はプロキシを通らず直接出ていく
漏れやすい接続方式と、選ぶ設定値
■ OSにインストールしたVPNアプリ（全通信をVPNに流す方式）
- 漏れ方：VPN以外のネットワークが同時に生きていると、そちらのアドレスが候補に混ざることがある
- 選ぶ設定：Use only my default public IP address（default_public_interface_only）
■ ブラウザのプロキシ設定・拡張機能型VPN（Shadowsocks系をシステムプロキシとして使う場合を含む）
- 漏れ方：Web閲覧はプロキシを通るが、WebRTCのUDPは直接出ていくため実IPが見える
- 選ぶ設定：Use my proxy server（disable_non_proxied_udp）
- 通話への影響：ブラウザでの通話が不安定になる、つながらないことがある
■ VPNもプロキシも使っていない
- 漏れ方：実IPはもともと見えている。気にするのは端末のローカルアドレス
- 選ぶ設定：Use only my default public IP address（default_public_interface_only）
中国からShadowsocks系のクライアントを使っている場合、「全通信を流すモード」か「システムプロキシのモード」かで選ぶ設定が変わります。
プロトコル自体の仕組みはShadowsocksの仕組みとVPNとの違いで解説しています。
現在のWebRTCの仕様について
近年のブラウザは、ローカルアドレス（192.168.x.xなど）を「ランダムな文字列.local」という名前（mDNS）に置き換えて渡すようになりました。
端末のローカルアドレスは見えにくくなった一方、前の節の2つの状況で実IPが出る問題はブラウザ側の既定値では解消されていません。
なお、VPN接続中に漏れうるのはWebRTCだけではありません。名前解決の問い合わせ先から接続元が分かる問題はDNSリークの確認方法と対策で別に扱っています。
WebRTCリークのテスト手順
手順（4ステップ）
- VPN・プロキシを切った状態で、自分のパブリックIPを控える
参考BrowserLeaks（IPアドレス確認） - VPNにつなぎ、ブラウザを開き直してから WebRTCテストのページを開く
参考BrowserLeaks WebRTC Leak Test - 下の「結果の読み方」で判定する
- 対策（拡張機能・ブラウザ設定）を入れたら、ページを再読み込みしてもう一度判定する
日本語で結果を見たい場合は、ExpressVPNのテストページも使えます。
参考WebRTC漏れテスト（ExpressVPN公式サイト）
結果の読み方（BrowserLeaksの場合）
■ Your Remote IP（IPv4／IPv6）
Web閲覧で相手に見えているアドレス。VPNのIPになっていれば、Web閲覧自体は正しくVPNを通っています。
■ Your WebRTC IP → Public IP Address
手順1で控えた実IPが出ていたら漏れています。
空欄、またはRemote IPと同じVPNのIPなら問題ありません。
■ Your WebRTC IP → Local IP Address
「ランダムな文字列.local」ならmDNSで隠れています。
192.168.x.x などがそのまま出ている場合、実IPほどの実害はないものの、端末を見分ける材料になります。
■ IPv6
VPNがIPv4だけを通す設定だと、IPv6側から契約回線のアドレスが見えることがあります。
Public IP Address と Remote IP の両方で、IPv6の行も確認してください。
見落としやすい点
- 拡張機能は、シークレットモードでは既定で動きません。拡張機能の設定で「シークレットモードでの実行を許可」を入れてからテストします
- Chromeと別のブラウザを併用しているなら、ブラウザごとにテストが必要です。設定はブラウザ単位で効きます
拡張機能3種の現況と設定
Chrome・Edge（デスクトップ）でよく名前が挙がる3つを、提供元と設定値で整理します。
3つとも中身はChromeの同じ設定（WebRTC IP handling policy）を切り替える仕組みです。複数を同時に入れず、1つに絞ってください。
■ WebRTC Network Limiter
- 提供元：Google
- 対応：Chrome（Firefox版はなし）。Manifest V3対応版が配布中
- 設定の場所：拡張機能のアイコンを右クリック →「オプション」
- 選択肢（4つ）：Give me the best media experience（既定。制限なし）／Use my default public and private IP addresses／Use only my default public IP address／Use my proxy server (if present)
- 選ぶ設定：OSのVPNアプリなら3つ目、プロキシ・拡張機能型VPNなら4つ目
参考WebRTC Network Limiter（Chromeウェブストア）
■ WebRTC Leak Prevent
- 提供元：Questionably Secure（ソース公開）
- 対応：Chrome 88以降（Firefox版・Safari版はなし）。Manifest V3対応版が配布中
- 設定の場所：拡張機能のアイコンをクリック
- 選択肢（3つ）：Use the default public interface only（導入直後の状態）／Use both public and private interfaces／Disable non-proxied UDP (force proxy)
- 選ぶ設定：OSのVPNアプリなら導入直後のままでよい。プロキシ・拡張機能型VPNなら「Disable non-proxied UDP」
- ほかに「Incognito protection」の欄があり、シークレットモードでの実行が許可されているか（Enabled／Not enabled）を確認できる
参考WebRTC Leak Prevent（Chromeウェブストア）
■ WebRTC Leak Shield
- 提供元：Hoxx（hoxx.com）
- 対応：Chrome、Firefox（デスクトップ版。Android版Firefoxは対象外）
- 動作：WebRTCの漏れを止める設定をオン／オフで切り替える
- 注意：Chromeウェブストアには、同じ名前で提供元が違う拡張機能があります。提供元が hoxx.com になっている方を選んでください
参考WebRTC Leak Shield（Chromeウェブストア）
参考WebRTC Leak Shield（Firefox Add-ons）
どれを選ぶか
- Chromeだけ使う：WebRTC Network Limiter（Google提供で、4つの設定を選べる）
- シークレットモードでも使う：WebRTC Leak Prevent（シークレットモードでの実行が許可されているかを画面で確認できる）
- Firefoxでも同じ拡張機能を使いたい：WebRTC Leak Shield
拡張機能を入れたくない場合（Chromeのポリシー）
Chrome 91以降は、企業向けポリシー「WebRtcIPHandling」で同じ設定を固定できます。
値は default／default_public_and_private_interfaces／default_public_interface_only／disable_non_proxied_udp の4つです。
Windowsではレジストリ（HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome）に文字列値として追加し、chrome://policy で反映を確認します。
ブラウザ別の止め方
ExpressVPNやNordVPNのように、ブラウザ拡張機能でWebRTCを止められるVPNもあります。
ただ、プロキシ型の接続や、拡張機能を入れていないブラウザでは効きません。設定はブラウザごとに入れるのが確実です。
WebRTC漏れに対応しているブラウザはGoogle Chrome, Firefox, Opera, Safari, Brave, Microsoft Edgeになります。以前の古いEdgeは対策が困難でしたが、現在のChromium版EdgeであればChrome同様に対策できます。
WebRTCを制限、無効化する事によって使えなくなるウェブサービスが出てくる可能性があります。
Google Chrome / Microsoft Edge（デスクトップ）
ChromeとEdge（Chromium版）は、ブラウザ本体の設定画面にWebRTCの項目がありません。
上で紹介した拡張機能3種のいずれか、またはChromeのポリシーで設定します。EdgeでもChromeウェブストアの拡張機能を入れられます。
ここではGoogle提供のWebRTC Network Limiterの手順を示します。
NordVPNなど、OSにインストールするVPNアプリを使っている場合は上から3つ目（Use only my default public IP address）を選びます。
Shadowsocks系をブラウザのプロキシとして使っている場合は4つ目（Use my proxy server (if present)）を選びます。
Google Chrome (Android)
Android版Chromeには、WebRTCの設定項目がなく、拡張機能も入れられません。
端末のVPNアプリで全通信をVPNに流している場合は、上のテスト手順で実IPが出ていないかを確認してください。
Firefox
アドレスバーに "about:config" を入力し、警告画面のボタンを押して先へ進みます。
検索欄に "media.peerconnection.enabled" を入力し、true をダブルクリックして false に変えます。
これでWebRTC自体が止まるため、ブラウザ版のビデオ会議は使えなくなります。
ビデオ会議を使う日だけ戻すのが面倒なら、拡張機能のWebRTC Leak Shield（Firefox版）でオン／オフを切り替える方法もあります。
Android版Firefoxは、通常版では about:config が開けません（Beta版・Nightly版のみ）。
Safari
Safari（iPhone・Mac）は、カメラ・マイクの使用を許可していないページには端末のローカルアドレスを渡しません。
一方、STUNサーバー経由の外向きのアドレスは渡るため、プロキシ型の接続で実IPが出るかは使い方次第です。上のテスト手順で一度確認しておくと確実です。
なお、WebRTC Leak Prevent・Network LimiterにはSafari版がありません。
Brave
アドレスバーに brave://settings/privacy を入力し、WebRTCの項目（WebRTC IP handling policy）を開きます。
選択肢はChromeのポリシーと同じ4つです。OSのVPNアプリなら「Default public interface only」、プロキシ型なら「Disable non-proxied UDP」を選びます。
以前あった「すべての指紋をブロック」（Strictモード）は、Brave 1.64で廃止されました。
Opera
OperaもChromiumベースのため、設定の考え方はChromeと同じです。
Opera内蔵のVPN（ブラウザVPN）はプロキシとして扱われるため、WebRTCのUDPが直接出ていかない設定にしておく必要があります。
対策後は、上のテスト手順で結果を確認してください。
管理人の一言
WebRTCの漏れは、VPNの性能よりも「接続の方式」と「ブラウザの設定」で決まる部分が大きい問題です。
まずテストで現状を確かめ、漏れていたら拡張機能かブラウザの設定で止める、の順で十分に対処できます。
VPN選びの段階で手間を減らしたいなら、ExpressVPNやNordVPNのように、ブラウザ拡張機能でWebRTCを止める機能を用意しているサービスを選ぶのが手堅い選択です。
管理人のおすすめVPNサービスはこちらから。
-
-
【目的・状況別】管理人オススメの有料VPN｜2026年版
続きを見る
