# WebRTCリークテスト

VPNやプロキシで隠しているはずのIPアドレスを、ブラウザがWebRTC経由で明かしていないかを調べます。テストはブラウザの中で動き、たいてい数秒で終わります（待つのは最長8秒です）。

## 要点

WebRTCリークとは、いま接続に使っているものとは別のグローバルIPアドレス（VPNをオンにしているときの本来のアドレスなど）を、どのページでも許可の確認なしにWebRTC経由で読み取れてしまう状態です。このテストはstun.cloudflare.com:3478にSTUNリクエストを1回送り、最大8秒待って、返ってきたグローバルアドレスをすべて、サーバーから見えるアドレスと比べます。ブラウザがこの方法で明かしてよいもの、明かすべきでないものはRFC 8828に書かれています。

### 調べ方

ページは、STUNサーバー1つとデータチャネルを指定して`RTCPeerConnection`を作ります。するとブラウザがICE候補を集めます（RFC 8445）。ホスト候補にはローカルアドレスが入りますが、現在のブラウザはたいていランダムな`.local`名に置き換えます。サーバーリフレクシブ（`srflx`）候補には、STUNサーバーから見えたグローバルアドレスが入ります（RFC 8489）。各グローバルアドレスは、あなたのHTTPリクエストのアドレスと比べます。IPv6アドレス同士は、先頭64ビットが一致すれば同じネットワークとみなします。

### 例

VPNを使っている人が198.51.100.7から接続していて、STUNの応答には203.0.113.25が入っていたとします。どちらもIPv4で値が違うので、結果は**「リーク：WebRTCから別のグローバルIPが見えています」**になります。203.0.113.25は、おそらくVPNで隠すはずだったアドレスです。応答が198.51.100.7だったなら、リークはなしと判定します。IPv4で届いた接続に対してIPv6アドレスが返ってきた場合は、WebRTCがIPv6アドレスも明かしていると表示します。VPNを使っていないデュアルスタックの回線なら、これは想定どおりです（例に使ったアドレスはいずれもRFC 5737の説明用アドレスです）。

### 制限事項

- テストの対象は、このブラウザとこのプロファイルだけです。同じデバイスでも、ほかのブラウザは違う動きをすることがあります。
- STUNのポートへのUDPが遮断されていたり、ネットワークが遅かったりした場合は、安全とは判定せず、判定不能として扱います。
- DNSリークや、ほかのアプリケーションの通信は調べません。

### 出典

- [RFC 8828: WebRTC IP Address Handling Requirements](https://www.rfc-editor.org/rfc/rfc8828)：ブラウザが明かしてよいアドレス。
- [RFC 8445: Interactive Connectivity Establishment (ICE)](https://www.rfc-editor.org/rfc/rfc8445)：host、srflx、relayの各候補。
- [RFC 8489: Session Traversal Utilities for NAT (STUN)](https://www.rfc-editor.org/rfc/rfc8489)：STUNサーバーがグローバルアドレスを伝える仕組み。
- [Using mDNS to protect local addresses in ICE candidates](https://datatracker.ietf.org/doc/draft-ietf-mmusic-mdns-ice-candidates/)：ブラウザが使う.local名。
- [RFC 5737: IPv4 Address Blocks Reserved for Documentation](https://www.rfc-editor.org/rfc/rfc5737)：例に使ったアドレス。

## WebRTCリークとは

WebRTCは、Google MeetやDiscordのようなサイトで、ビデオ通話、画面共有、端末どうしの直接のファイル転送を実現しているブラウザの技術です。2人を直接つなぐために、ブラウザは自分に届きうるアドレスをすべて洗い出さなければなりません。そこで**STUNサーバー**にごく小さなリクエストを送ります。STUNサーバーは、そのリクエストがどのグローバルアドレスから来たかを返します。ブラウザは、ICE候補と呼ばれるこれらのアドレスを、Webページのスクリプトに渡します。

通話には便利でも、プライバシーの面では困ったことになります。この処理は、許可を求める画面も出さず、カメラやマイクも使わずに、どのページでも黙って始められるからです。STUNリクエストがVPNのトンネルの外を通ってパソコンから出ていくと、ページに伝わるのはVPNで表示されるアドレスではなく、プロバイダから割り当てられたアドレスです。これがWebRTCリークです。サイトには2つのアドレスが見え、その片方は隠そうとしていたアドレスです。

## 使い方

1. ふだんネットを見るときと同じようにVPNやプロキシに接続してから、このページを開きます。
2. 上の結果ボックスを待ちます。テストは自動で始まり、*「テスト中」*の行が1行の判定と短い説明に置き換わります。
3. **「比較したアドレス」**で、*「あなたの接続（HTTP）」*と*「WebRTC経由のグローバルIP」*を見比べます。*「使用したSTUNサーバー」*の行には、ブラウザに応答したサーバーが出ます。
4. **「ICE候補」**の表に目を通します。*「種類」*は候補の出どころ（`host`はあなたのデバイス、`srflx`はSTUNサーバーから見えたもの、`relay`はTURNサーバー）を示し、*「区分」*は、そのアドレスがグローバルか、ローカルネットワーク内か、キャリアのNATの内側か、`.local`名で隠されているかを示します。
5. ブラウザの設定や拡張機能を変えたら、**「もう一度テストする」**を押します。VPN自体をオンやオフにした場合は、代わりにページごと読み込み直してください。HTTPのアドレスは、ページを読み込んだときに一度だけ取得しているためです。

一度VPNをオフにして試し、プロバイダから割り当てられたアドレスを控えておきましょう。トンネルを張ったあとは、そのアドレスが出てきてはいけません。

## こんなときに

- **頼る前にVPNを見極める。**トンネルを張った状態では、WebRTCのグローバルアドレスがHTTPのアドレスと一致するか、まったく出ないのが正常です。同じ種類なのに違うアドレスが出たら、対処が必要です。
- **プロキシ拡張機能を確認する。**ブラウザのプロキシ拡張機能は通常のページのリクエストを中継しますが、STUNリクエストはUDPなので、ブラウザにブロックさせない限りプロバイダからそのまま出ていくことがあります。
- **IPv6の抜け穴を見つける。**VPNの構成によっては、IPv4だけをトンネルに通し、IPv6には手を付けないものがあります。その場合、判定はWebRTCがIPv6アドレスも明かしていると伝えます。
- **管理対象ブラウザのポリシーを検証する。**会社のノートPCでWebRTCを制限しているIT担当者は、テスト用のマシンでこのページを開き、ポリシーで許した範囲のものだけが候補の表に出ているかを確かめられます。
- **制限の厳しいネットワークでWebRTCアプリをデバッグする。**表に`host`候補はあっても`srflx`がない場合、ポート3478でSTUNサーバーへ向かうUDPがおそらく遮断されています。そのネットワークで通話するには、TURNによる中継が必要になります。

## テストの仕組み

1. ブラウザはふだんの接続でこのページを読み込むので、当サイトのサーバーにはグローバルアドレスが1つ見えます。上の*「あなたの接続（HTTP）」*がそれです。
2. ページは、誰にも発信しないWebRTC接続を作り、Cloudflareの公開STUNサーバー（`stun.cloudflare.com`）に、見えているアドレスを問い合わせます。
3. ブラウザが生成した候補をすべて一覧にし、そのうちグローバルなものをHTTPのアドレスと比べます。ここまでの手順はどれもあなたのブラウザ内で済ませ、当サイトへは何も送り返しません。

## 結果の読み方

- **リークなし：**WebRTCが報告するグローバルアドレスが接続のものと同じか、1つも出ない状態です。VPNを使っているなら、WebRTCもカバーされています。
- **リーク：**WebRTCが、同じ種類（IPv4とIPv4）で別のグローバルアドレスを報告しています。VPNをオンにしているなら、その2つ目のアドレスはほぼ間違いなくあなたの本来のアドレスです。
- **別のプロトコルが見えている：**IPv6で接続しているのにWebRTCがIPv4アドレスも示している、またはその逆です。ふつうの家庭の回線なら、どちらもあなたのアドレスです。片方のプロトコルしかトンネルに通さないVPNでは、もう片方が漏れています。
- **ローカルアドレスが見えている：**`192.168.x.x`や`10.x.x.x`のアドレスが出る場合、ブラウザが家庭内ネットワークでのデバイスのアドレスを共有しています。現在のChrome、Edge、Firefox、Safariは、初期設定でこれをランダムな`.local`名の陰に隠します。

## WebRTCリークを止めるには

- **ブラウザ拡張機能だけでなく、VPNのアプリを使う。**システム全体にかかるVPNはSTUNの通信もトンネルに通しますが、プロキシ拡張機能は通さないことがよくあります。
- VPNのアプリや拡張機能に**WebRTCリーク防止機能**があれば、オンにします。
- **Firefox：**`about:config`を開いて`media.peerconnection.enabled`を`false`にすると、WebRTCを完全にオフにできます。オンのままにしてVPNに任せる方法もあります。
- **ChromeとEdge：**切り替え用の標準の設定はありません。WebRTCのIP処理ポリシーを「disable non-proxied UDP」（プロキシを通らないUDPを無効化）にする、信頼できる拡張機能を使います。
- **Brave：**「設定」→「プライバシーとセキュリティ」→「WebRTC IP処理ポリシー」で、プロキシを通らないUDP通信を無効にする項目を選びます。
- **Safari：**初期設定でICE候補を制限しているため、リークはまれです。

どれかを変えたら、もう一度テストしてください。WebRTCをオフにするとブラウザ上の通話が使えなくなるので、機能を止めるよりVPN側を直すほうを優先しましょう。

## このテストでわからないこと

問題なしという結果が当てはまるのはWebRTCだけです。DNSの問い合わせ、ブラウザのタイムゾーンや言語、フィンガープリントは別の経路です。タイムゾーンと言語の食い違いは[トップページ](https://iseeu.cc/ja/)で、残りは[フィンガープリントのテスト](https://iseeu.cc/ja/browser-fingerprint/)で確認できます。DNSリークのテストは、専用のDNSサーバーが必要なので行っていません。できるふりはしたくないからです。

## よくある質問

**WebRTCリークとは何ですか？**

Webサイトがブラウザのリアルタイム通信機能を使って、VPNやプロキシで隠しているはずのIPアドレスを知ってしまうことです。ページがSTUNサーバーに、どのアドレスが見えているかを問い合わせると、ブラウザはその答えをページのJavaScriptに渡します。

**WebRTCリークが見つかったら、VPNが故障しているということですか？**

そうとは限りません。しっかりしたVPNアプリの多くは、WebRTCの通信もトンネルに通します。リークが出る場合、たいていはVPNが通信の一部しか守っていない（ブラウザ拡張機能型のプロキシなど）か、IPv4はトンネルに通してもIPv6は通していないかのどちらかです。

**WebRTCは無効にしたほうがいいですか？**

ブラウザ上で通話をしない場合に限ります。Google Meet、Discord、Teamsなどのビデオ通話にはWebRTCが必要です。まずは、VPNに付いているWebRTC保護機能や、WebRTCが共有できるアドレスを制限するブラウザの設定を試すほうがよいでしょう。

**テスト結果に.localで終わるアドレスが出るのはなぜですか？**

最近のブラウザは、ローカルネットワーク上でのデバイスのアドレスを、mDNSで作った.localで終わるランダムな名前に置き換えます。プライバシーを守るための仕組みで、リークとは別物です。

**このテストはIPアドレスを保存しますか？**

いいえ。アドレスの突き合わせは、手元のブラウザだけで済ませます。当サイトのサーバーへのリクエストは、サーバーから見えるIPアドレスを取得する1回だけで、それも記録しません。

**グローバルIPがまったく出てこないのは、どういうことですか？**

ファイアウォール、ブラウザの設定、拡張機能、VPNのいずれかがSTUNリクエストを止めたためです。WebRTCのプライバシーという点では、これ以上ない結果です。

このテストが調べるのは、実行した時点での漏れ道1つだけです。結果はブラウザ、拡張機能、ネットワークによって決まり、そのどれかが変われば変わることがあります。VPNのセキュリティ監査ではありません。

## iseeu.ccのほかのツール

- [IPアドレス確認](https://iseeu.cc/ja/): グローバルIP、おおよその地域、プロバイダ、ヘッダー、TLS、リークテストを1ページで確認できます。
- [ブラウザフィンガープリント](https://iseeu.cc/ja/browser-fingerprint/): Cookieがなくてもブラウザを見分ける手がかりになる特徴を一覧にします。
- [ブラウザ対応機能](https://iseeu.cc/ja/browser-features/): 約60のWebプラットフォーム機能を、いま使っているブラウザで実際に試します。
- [DNSルックアップ](https://iseeu.cc/ja/dns-lookup/): A・AAAA・MX・TXT・NS・CNAME・CAA・SOAレコードをDNS over HTTPSで引きます。

[すべてのツールを見る](https://iseeu.cc/ja/tools/)

最終更新：2026-10-11

元のページ：https://iseeu.cc/ja/webrtc-leak-test/