WebRTCリーク
WebRTCリークテスト:ブラウザ通話でIPアドレスについて何がわかるか
要点
WebRTCリークテストは、ブラウザがWebRTCを通じてWebページに渡すIPアドレスをすべて一覧にするもので、隠したつもりのアドレスを見つけられます。多いのは、VPNを使っているのにインターネット接続事業者(プロバイダー)のアドレスが見えてしまうケースです[1]。ブラウザから電話番号にかける通話でIPアドレスが見えるのは通話サービスで、電話をかけた相手ではありません。相手に届くのは発信者番号です[2]。このテストは、ブラウザから電話をかける前に私がすすめているプライバシーと安全性のチェックのひとつです。
主なポイント
- IETFのWebRTCに関する規定によると、スプリットトンネルのVPNでは、WebRTCがVPNのアドレスに加えてプロバイダーのパブリックアドレスも検出できることがあります[1]。に確認。
- 私がローカル環境のChrome 156で確認したところ、マイクの許可がないページには私のパソコンがランダムな.localの名前としてしか見えませんでしたが、マイクを許可すると実際のローカルアドレスが取得されました[3][1]。に確認。
- Messengerは、1対1の通話で相手の端末とIPアドレスを共有するとしています[4]。WhatsAppの「通話でIPアドレスを保護」の設定をオンにすると、通話は代わりに同社のサーバーを経由します[5]。に確認。
WebRTCリークとは?
WebRTC通話の前に、ブラウザはICE候補と呼ばれるネットワーク経路の候補を集め、相手側に渡してもらうためにWebページへ引き渡します。それぞれの候補にはIPアドレス、または隠されたローカルアドレスの代わりにランダムな.localの名前が入っています。普通のWebサイトに見えるのはリクエスト元のパブリックアドレスだけですが、WebRTCを通じるとページはそれ以上の情報を得られます[1]。この一覧に、共有するつもりのなかったアドレスが含まれていれば、それがリークです。
通話のそれ以外の流れはWebRTC・SIP・電話網の仕組みで説明しています。リークに関係するのは候補の一覧だけです。MDNは、候補のアドレスは常にページから見えると注記しています[6]。
| 候補の種類 | 表示されるアドレス | プライバシー上のリスク |
|---|---|---|
| host | ローカルネットワーク上の端末のアドレス。ブラウザが隠している場合は.localで終わるランダムな名前[7][3] | パブリックアドレスより低いが、IETFはプライベートIPv4アドレスをかなり重要なフィンガープリンティングの手がかりとしている[1] |
| srflx(server reflexive) | ルーターやVPNがSTUNサーバーに見せているパブリックアドレス[7] | VPNの使用中にプロバイダーのアドレスが出ていれば高い[1] |
| relay | メディアを中継するTURNサーバー上のアドレス[7] | 低い。相手に見えるのは中継サーバーのアドレスで、あなたのアドレスではない[6]。ただし中継サーバーの運営者にはあなたが見える |
IETFは、匿名でいるためにVPNを使う人がいることから、VPNのケースを最も重大としています[1]。ほかの2つは、プライベートアドレスが見えるケースと、WebRTCの接続確認がプロキシを迂回して実際のパブリックアドレスが明らかになるケースです[1]。
ブラウザ通話でIPアドレスは相手に伝わる?
通話サービスには伝わります。どのWebサイトにもあなたのパブリックアドレスは見えており[1]、通話ではさらにサービスのサーバーとのメディア接続が加わります。固定電話や携帯電話にかけた相手には伝わりません。通話は事業者のゲートウェイでインターネットを離れ[8]、電話網が相手に渡すのはIPアドレスではなく発信者番号だからです[2]。アプリ同士の通話では、2台の端末が直接つながることがあります。
| 通話の種類 | サービス | 電話をかけた相手 |
|---|---|---|
| ブラウザから電話番号へ(Google Voice、TwinPhone、Yolla) | 見える:メディア接続を担っている | 見えない:相手には発信者番号が表示される[2] |
| 無料のWebダイヤラー(Call2Friends、Globfone) | 見える:Call2FriendsはIPアドレスごとに無料通話を制限しており、Globfoneのプライバシーポリシーは処理する技術データやログにIPアドレスを挙げている[9][10] | 見えない:相手には発信者番号が表示される |
| Messenger(1対1の通話) | 見える | 見える:MetaはIPアドレスが相手の端末と共有されるとしている[4] |
| 見える | 「通話でIPアドレスを保護」がオンでなければ見えることがある。グループ通話は常に中継される[5] | |
| Telegram | 見える | 見えることがある:Telegramの2017年の発表では、通話は可能な限りピアツーピアでつながる[11] |
実在の電話番号への通話で問題になるのは、サービスが何を知り、何を保存するかです。かけた相手の側に何が見えるかは、ブラウザから電話したときに表示される番号で解説しています。
WebRTCリークテストのやり方
リークテストのページは、ダイヤラーが通話の前に行うのと同じことをします。WebRTC接続を開き、STUNサーバーにどのパブリックアドレスが見えるかを問い合わせ、すべての候補を、通常のHTTPで見えるアドレスと並べて表示します。電話に使うブラウザごとに、まずVPNをオフにして、次にオンにして実行してください。
- VPNをオフにして、BrowserLeaksのWebRTC Leak Testのようなリークテストのページを開きます。上部の「Your Remote IP」と、「Your WebRTC IP」の下の「Public IP Address」が一致するはずです。
- VPNをオンにして再読み込みします。今度は「Your Remote IP」にVPNのアドレスが表示されるはずです。
- WebRTCの欄にまだプロバイダーのアドレスが表示されていれば、WebRTCがトンネルを迂回しています[1]。
- .localで終わるローカルの項目は、アドレスが隠されていることを意味します[3]。192.168.や10.で始まるアドレスがそのまま出ていれば、隠されていません。
- ページにマイクのチェックがあれば、許可してもう一度テストします。ダイヤラーにはマイクへのアクセスが必要で、その許可によってより多くのアドレスが取得できるようになることがあるからです[1]。終わったら、サイトの設定から許可を取り消してください[12]。
マイクを許可するとChromeで何が変わったか
、私はMacのChrome 156でローカルのテストページを読み込みました。STUNサーバーは使っていないので、外部のサーバーにアドレスは送られていません。マイクの許可がない状態でページに見えたのは、.localで終わるランダムな文字列の名前が付いたhost候補1つだけでした[3]。マイクを許可すると、私の実際のローカルIPv4アドレスが取得されました。
これは標準どおりの動作で、標準はマイクの許可などの同意がある場合にだけアドレスの全一覧を認めています[1]。SafariのエンジンであるWebKitも、2017年に同じルールを説明しています[13]。つまり、許可したダイヤラーにはローカルアドレスが見えますが、これはパブリックアドレスより小さなリスクです[1]。
WebRTCリークを抑えるブラウザの設定
Braveは、ユーザー向けのWebRTCのIP設定を公開しています。GoogleはChromeの制御を拡張機能と管理者向けに、MicrosoftはEdgeの制御を管理者向けポリシーとして公開しています。Firefoxは標準でローカルアドレスを隠し、about:configに無効化のスイッチを用意しています。どのブラウザにも共通するルールがひとつあります。WebRTCが通話を運んでいるため、WebRTCをオフにするとブラウザのダイヤラーも使えなくなります[14]。
| ブラウザ | 制御方法 | 変わること | ブラウザ通話への影響 |
|---|---|---|---|
| Brave | Braveのwiki(最終更新は2018年)によると、プライバシー設定のWebRTC IP処理ポリシー[15] | 「Default Public Interface Only」ではローカルアドレスは一切公開されない[15] | メディアが中継サーバー経由に切り替わることがある[1] |
| Chrome | 拡張機能でWebRTC IP処理ポリシーを設定できる[16]。管理者はWebRtcIPHandlingポリシーを設定できる[17] | 値によって、プライベートアドレスを使わなくなるか、メディアをプロキシ経由でのみ送るようになる[17] | プロキシのみの値では音声がTCPに移ることがあり、IETFによると品質が下がる[1] |
| Edge | 管理者向けポリシーWebRtcLocalhostIpHandling[18] | 2つの値でローカルIPアドレスが公開されなくなる[18] | Chromeと同じ |
| Firefox | ローカルアドレスは標準で非表示[19]。about:configのmedia.peerconnection.enabled[20] | この設定をfalseにするとWebRTCがオフになる | ブラウザのダイヤラーが使えなくなる |
| Safari | 組み込みのルール | WebKitが2017年に説明したとおり、マイクやカメラへのアクセスがないページにはhostアドレスが渡されない[13] | なし |
VPNを使うとブラウザ通話はどう変わる?
WebRTCを含むすべての通信をトンネル経由で送るVPNなら、通話サービスに見えるのはあなたのアドレスではなくVPNのアドレスです。スプリットトンネルのVPNでは、WebRTCがプロバイダーのアドレスも見つけてしまうことがあります[1]。だからこそ、VPNをオンにした状態でリークテストを行うのです。VPNには通話への副作用もあります。
通話でIPアドレスを守るには
通話の種類に合わせて対策を選びます。電話番号への通話では相手にIPアドレスは伝わらないので、IPアドレスを預けても信頼できるサービスを選び、VPNを確認しましょう。アプリ同士の通話では相手の端末が直接つながってくることがあるので、アプリに中継の設定があれば使いましょう。
よくある質問
WebRTCリークテストとは何ですか?
ブラウザから電話した相手に自分のIPアドレスは見えますか?
VPNでWebRTCリークは防げますか?
WebRTCを含むすべての通信をトンネル経由で送るVPNなら防げます。スプリットトンネルのVPNでは防げないことがあります。WebRTCがVPNのアドレスに加えてプロバイダーのパブリックアドレスも検出できるからです[1]。確かめるには、VPNに接続した状態で、使うブラウザごとにリークテストを行い、アップデートのたびに繰り返すしかありません。
ローカルIPアドレスの漏えいは危険ですか?
シークレットモードやプライベートブラウズでWebRTCリークは防げますか?
防げません。IETFは、WebRTCで明らかになったプライベートアドレスが識別子として働き、通常のウィンドウとプライベートブラウズのウィンドウが同じ端末にあることをサイトに知らせてしまう可能性があると指摘しています[1]。つまり、プライベートモードだけでは隠せません。上で紹介したブラウザの設定を使い、プライベートウィンドウでもリークテストを実行してください。
WebRTCリーク対策の拡張機能は効果がありますか?
FirefoxでWebRTCをオフにするには?
ChromeでWebRTCリークを防ぐには?
拡張機能かポリシーで設定します。GoogleがChromeのWebRTCのアドレス制御を案内しているのは、この2つだからです。拡張機能はWebRTCのIP処理ポリシーを設定でき[16]、管理者はWebRtcIPHandlingを設定できます。値をdefault_public_interface_onlyにすると、WebRTCはプライベートアドレスを使わなくなります[17]。私がChromeで確認したところ、マイクの許可がないページには、もともとランダムな.local名しか見えていませんでした[3]。VPNを使っている場合、本当の対策はすべての通信をトンネルに通すことです[1]。WebRTCを完全にブロックするものは、ブラウザ通話も止めてしまいます[14]。
ウェブサイトは許可なしにWebRTCで私のIPアドレスを見られますか?
グローバルIPアドレスなら見られますが、それはウェブサイトがもともと見ているものです。たとえばSafariは、マイクへのアクセス権がないページには、サイトがすでに収集できるアドレスしか渡しません[13]。落とし穴はブラウザのプロキシです。インターネットへの直接接続が許されていると、WebRTCのSTUNチェックがプロキシを迂回して、本当のグローバルIPアドレスを明かすことがあります[1]。ローカルアドレスのほうは守りが固く、標準仕様では完全な一覧をマイク許可などの同意と結びつけています[1]。私がChromeで確認したところ、その許可のないページにはランダムな.local名しか見えていませんでした[3]。
この調査についてAIに聞く
各ボタンを押すと新しいタブでAIアシスタントが開き、このページへのリンクを出典として示したうえで要約するよう依頼します。
出典
- RFC 8828: WebRTC IP Address Handling Requirements · IETF (RFC Editor) · 2026年11月1日確認
- 47 CFR 64.1601 -- Delivery requirements and privacy restrictions | eCFR · US Code of Federal Regulations (eCFR) · 2026年11月1日確認
- Using Multicast DNS to protect privacy when exposing ICE candidates (draft-ietf-mmusic-mdns-ice-candidates) · IETF (Internet-Draft, work in progress) · 2026年11月1日確認
- Voice call someone or a group on Messenger - Messenger Help Center (Computer) · 2026年11月1日確認
- How to protect your IP address on WhatsApp calls | WhatsApp Help Center · WhatsApp · 2026年11月1日確認
- RTCIceCandidate: address property - Web APIs | MDN · MDN Web Docs (Mozilla) · 2026年11月1日確認
- RTCIceCandidate: type property - Web APIs | MDN · MDN Web Docs (Mozilla) · 2026年11月1日確認
- Make calls | Sonetel help · 2026年11月1日確認
- Free call | Call2Friends - Online call · 2026年11月1日確認
- Privacy Policy | Globfone · 2026年11月1日確認
- Voice Calls: Secure, Crystal-Clear, AI-Powered | Telegram Blog (30 March 2017) · Telegram · 2026年11月1日確認
- Use your camera and microphone in Chrome - Computer - Google Chrome Help · Google · 2026年11月1日確認
- A Closer Look Into WebRTC | WebKit (3 July 2017) · WebKit (Apple) · 2026年11月1日確認
- WebRTC API - Web APIs | MDN · MDN Web Docs (Mozilla) · 2026年11月1日確認
- WebRTC Custom Settings · brave/brave-browser Wiki · Brave Software (official GitHub wiki) · 2026年11月1日確認
- chrome.privacy | API | Chrome for Developers · Google (Chrome for Developers) · 2026年11月1日確認
- Chrome Enterprise policy list: WebRtcIPHandling (WebRTC IP handling) · Google (Chrome Enterprise) · 2026年11月1日確認
- Microsoft Edge Browser Policy Documentation WebRtcLocalhostIpHandling | Microsoft Learn · Microsoft · 2026年11月1日確認
- Firefox source: modules/libpref/init/all.js (mozilla-firefox/firefox) · Mozilla (official Firefox source repository) · 2026年11月1日確認
- Firefox source: modules/libpref/init/StaticPrefList.yaml (mozilla-firefox/firefox) · Mozilla (official Firefox source repository) · 2026年11月1日確認
- Terms of Use – TextNow · 2026年11月1日確認
- Privacy Policy – Privacy & Terms – Google · Google · 2026年11月1日確認
- Call From Your Browser Without a SIM Card - TwinPhone · 2026年11月1日確認