WebRTCリークテスト
WebRTCは、ブラウザーが通常は送らないアドレスをWebサイトに渡すことがあります。VPNの背後にある本当のアドレスも例外ではありません。このテストはCloudflareとGoogleが運用する3つのSTUNサーバーに尋ね、返ってきたすべてのアドレスとそれぞれの種類を示して、Webサイトにすでに見えているアドレスと比較します。テストできないことがあれば、緑のチェックマークを出す代わりに、そう伝えます。
WebRTCが示すアドレスは、STUNサーバーが応答するたびに、1つずつ1行でここに表示されます。
WebRTCが見つけたアドレスが当サイトに送られることはありません。ビデオ通話と同じように、ブラウザー自身がSTUNサーバーに尋ねます。Webサイトに何が見えるかを示すため、ページはipify.orgと当サイトのサーバーに、あなたのアドレスとそのネットワークを問い合わせます。DNSリークテストと同じ仕組みです。
WebRTCリーク（WebRTC漏洩）とは何ですか？
WebRTCは、ビデオ通話を支えるブラウザーの機能です。2人を直接つなぐため、お使いのデバイスに到達できるすべてのアドレスを集めてページに提示します。そこには、ブラウザーが通常のリクエストでは決して送らないアドレスも含まれます。
この収集はICE候補の収集と呼ばれ、RFC 8445で規定されています。ブラウザーはまず自分のネットワークインターフェースにあるアドレスを列挙し、次にSTUNサーバーに「私はどのアドレスから来ているように見えますか？」と尋ねて、その答えも加えます。インターネット上のどのページでも、数行のJavaScriptでこれを開始し、届いた候補をすべて読み取れます。許可を求める画面は出ません。通話は許可なしで成立しなければならないため、それが設計なのです。
それがリークになるのは、そのアドレスのどれかが、あなたが隠していたものである場合です。VPNはブラウザーのリクエストが通る経路を変えますが、WebRTCはOSにすべてのインターフェースについて尋ねることができます。そのため、物理的な接続がまだ有効なデバイスでは、VPNのアドレスと並んで本当のアドレスが現れることがあります。何かが壊れたわけではありません。この機能は、設計どおりに動いているだけです。
どのページでも開始できること1回の収集を順に追う
const pc = new RTCPeerConnection({
iceServers: [{ urls: "stun:stun.cloudflare.com:3478" }],
});
pc.createDataChannel("");
pc.onicecandidate = (e) => e.candidate && console.log(e.candidate.candidate);
await pc.setLocalDescription(await pc.createOffer());candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0candidate:1467250027 1 udp 1686052607 203.0.113.7 54400 typ srflx raddr 0.0.0.0 rport 9 generation 0
各行の意味
hostこのデバイス上8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.localブラウザーがマスクsrflxSTUNサーバーから見たアドレス203.0.113.7インターネットでルーティング可能
判定リーク、リークなし、または正直に「テストできず」を、その理由とともに示します。すべてのアドレス候補の種類とともに表示します。ホスト候補とサーバーリフレクシブ候補では、意味が違うからです。アドレスの種類プライベート、キャリアグレードNAT、トンネル、ルーティング可能。リークになりうるのは、ルーティング可能なアドレスだけです。サーバーSTUNサーバーごとに1行です。応答しなかったサーバーは、実行されなかったテストです。Webサイトに見えるものブラウザーがそもそも送っているアドレスで、WebRTCのアドレスはこれと比較します。WebRTCリークを確認するには？
上のテストを開始してください。3つのSTUNサーバーから候補を集め、各アドレスの種類を判断し、ルーティング可能なものをWebサイトにすでに見えているアドレスと比較します。
ありうる結果は、2つではなく3つです。リークなしは、WebRTCが示したルーティング可能なアドレスがどれも、サイトがすでに持っているものだという意味です。リークは、少なくとも1つがそうではない、またはデバイス自体のアドレスが直接提示されたという意味です。テストできずは、WebRTCがオフかブロックされているか、どのSTUNサーバーも応答しなかったという意味で、ほとんどのツールがこっそり合格に変えてしまう結果です。
VPNを使っているなら、2回実行してください。1回目はVPNをオフにして通常のアドレスを確認し、2回目はオンにして実行します。重要なのは2回目で、2回の違いが答えです。ページは最初の結果を保存するので、何も書き留めずに比較できます。
結果は2つではなく3つそれぞれの意味
- リークなし
WebRTCが示したルーティング可能なアドレスは、どれもWebサイトがすでに持っているものです。
WebRTCが示したもの
198.51.100.23STUNサーバーから見たアドレスWebサイトにすでに見えている8b7f4e2a-….localこのデバイス上ブラウザーがマスク
Webサイトに見えるもの
198.51.100.23 - リーク
Webサイトがすでに持っているものではないアドレスが少なくとも1つあるか、デバイス自体のアドレスが直接提示されました。
WebRTCが示したもの
198.51.100.23STUNサーバーから見たアドレスWebサイトにすでに見えている2001:db8:4a1f:7c00::1cこのデバイス上Webサイトには見えていない
Webサイトに見えるもの
198.51.100.23 - テストできず
WebRTCがオフかブロックされているか、どのSTUNサーバーも応答しませんでした。何も測定されていません。
stun.cloudflare.com応答なしstun.l.google.com応答なしほとんどのツールがここで表示するもの
リークなし
2回実行する
VPNオフ
WebRTCが示したもの203.0.113.7
Webサイトに見えるもの203.0.113.7
VPNオン
WebRTCが示したもの198.51.100.23203.0.113.7
Webサイトに見えるもの198.51.100.23
VPNをオンにしても残ったもの
リークVPNでWebRTCリークは防げますか？
VPNだけでは防げません。VPNは通信の行き先を変えますが、WebRTCはOSにどんなインターフェースがあるかを尋ねることができ、物理的なインターフェースは通常まだ存在しています。
IETF自身の説明は正確です：「クライアントが仮想プライベートネットワーク（VPN）で物理的な位置を隠そうとし、VPNとローカルOSが複数のインターフェースでのルーティングに対応している場合、WebRTCはVPNのパブリックアドレスだけでなく、VPNが動作しているISPのパブリックアドレスも検出できる」。両方のアドレスが提示され、それを探しているページは両方を読み取れます。
VPNクライアントの中には、OSレベルですべての通信をルーティングしたり、WebRTCを制限するブラウザー拡張機能を提供したりして、この穴をふさぐものもあります。どちらも効果がありますが、どちらも思い込まずに確認すべきもので、このページはそのためにあります。VPN自身のリークテストページが保護されていると表示しても、それは独立した証拠ではありません。
VPNはオン、Wi-Fiも接続中2つのインターフェース、2つの答え
ページが受け取るもの
198.51.100.23srflxSTUNサーバーから見たアドレスVPN経由Webサイトにすでに見えている203.0.113.7srflxSTUNサーバーから見たアドレスWi-Fi経由、トンネルの外Webサイトには見えていない
穴をふさぐもの
- OSレベルでのルーティングトンネルの外に出るものがないため、STUNサーバーにはVPNのアドレスしか見えません。
- VPNのブラウザー拡張機能ブラウザー内でWebRTCを制限するため、もう一方のインターフェースには尋ねません。
- 思い込まず、確認するVPNをオンにしてこのテストを実行してください。VPN自身のリークテストページは、独立した証拠ではありません。
ホスト候補、サーバーリフレクシブ候補、リレー候補の違いは？
ホスト候補は、お使いのデバイス自体のアドレスです。サーバーリフレクシブ候補は、STUNサーバーに見えたアドレス、つまりNATのパブリック側です。リレー候補はTURNサーバーのアドレスで、あなたのものではありません。
この区別は重要ですが、ほとんどのリークテストはこれを捨ててしまいます。パブリックIPv4を持つサーバーリフレクシブ候補は、通常は目新しいものではありません。今使っている接続からWebサイトが得ているのと同じアドレスです。ルーティング可能なアドレスを持つホスト候補は別物です。デバイス自体のアドレスがページに直接提示されたものです。家庭のルーターだけでなく、このデバイスそのものを特定し、ネットワークが変われば変わります。
ページは各アドレスの横に種類を表示し、トランスポート、ポート、そしてリフレクシブ候補が示す関連アドレスも表示します。リレー候補はTURNサーバー自身のアドレスで、あなたについては何も明かしません。このテストはTURNサーバーを使わないため、もしリレー候補が現れたら、ページ上の別の何かがそれを設定したということです。
1つの候補を項目ごとにページが受け取るとおり
candidate:1467250027ファウンデーション1コンポーネントudpトランスポート1686052607優先度203.0.113.7アドレス54400ポートtyp srflx種類raddr 0.0.0.0 rport 9関連アドレスgeneration 0拡張
ローカルアドレスがマスクされる環境では、0.0.0.0、ポート9に置き換えられます
4つの種類
typ hostこのデバイス上お使いのネットワークインターフェースのいずれかにあるアドレス。
プライベートなものはマスクされます。ルーティング可能なものはデバイスそのもので、最も深刻な発見です。
ルーティング可能なら最も深刻
typ srflxSTUNサーバーから見たアドレスルーターのパブリック側を、STUNサーバーから見たもの。
通常は、Webサイトがお使いの接続からすでに得ているアドレスです。
通常は目新しくない
typ prflx通信相手から見たアドレスルーターのパブリック側を、通話の相手側から見たもの。
相手側への接続中にしか見つからないため、通話のないテストでは現れません。
通話中のみ
typ relayリレーサーバー自身のアドレスあなたの通信を中継するTURNサーバーのアドレス。
あなたのものではなく、サーバーのアドレスです。このテストはTURNサーバーを使わないため、ここに現れたものは別の何かが設定したものです。
あなたについての情報なし
mDNSの.localアドレスとは？プライバシーは守られますか？
最近のブラウザーは、プライベートアドレスをページに提示する前に、末尾が.localのランダムな名前に置き換えます。これは機能します。ただし、プライベートアドレスに対してです。パブリックアドレスを隠すためのものでは、もともとありません。
Chromeはバージョン76以降これを既定で行い、Firefoxではmedia.peerconnection.ice.obfuscate_host_addressesがtrueに設定されています。そのため、ページには192.168.1.20の代わりに8b7f4e2a-….localのようなものが渡され、ネットワークの外の人には何の意味もありません。Safariはさらに踏み込み、サイトがカメラやマイクの許可を得るまでは、ホスト候補を一切提示しません。上のテストはこうした.local名を認識し、発見事項ではなく、保護が機能しているものとして報告します。
これを定義するIETFのドラフトは、何をしないかを明言しています：「すでにインターネットに公開されているアドレスは、Webサーバーから簡単に観測できるため、mDNSで保護する必要はない」。そのため、サーバーリフレクシブ候補にはパブリックIPv4が引き続き含まれます。そして意外に思われる点ですが、ルーティング可能なIPv6アドレスを持つデバイスは、そのアドレスを依然としてホスト候補として提示できます。もう1つ知っておくべき穴があります。Chromeはカメラやマイクの許可をすでに持つサイトでは保護をオフにするため、以前使ったことのあるビデオ通話サイトには、本当のローカルアドレスが見えます。
.local名が置き換えるものそして、そのまま残すもの
ブラウザーが持っているもの
candidate:3442447574 1 udp 2122260223 192.168.1.20 54400 typ host generation 0
ページが受け取るもの
candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0
各ブラウザーの既定の動作
- Chromeバージョン76、2019年8月
- Firefox
media.peerconnection.ice.obfuscate_host_addresses = true - Safariサイトがカメラやマイクの許可を得るまで、ホスト候補なし
この仕組みはIETFのドラフトで、最終改訂は2021年12月、RFCとしては公開されていません。 draft-ietf-mmusic-mdns-ice-candidates-03
192.168.1.20プライベートIPv4（ホスト候補）マスクされるランダムな名前に置き換えられます。ページにはネットワークについて何もわかりません。203.0.113.7パブリックIPv4（STUNサーバーの候補）表示されるすでにパブリックなので、そのまま残ります。関連アドレスだけが消されます。2001:db8:4a1f:7c00::1cルーティング可能なIPv6（ホスト候補）表示されるこれもパブリックなので、マスクはもともと対象にしていません。2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07一時IPv6アドレス表示されることもドラフトは、ブラウザーが選択によりマスクしないことを認めています。192.168.1.20カメラやマイクの許可を持つサイトでの、あらゆるローカルアドレスマスクがオフChromeはそこでマスクをオフにします。サイトには本当のローカルアドレスが見えます。IPv6が最後に残るリークである理由
グローバルIPv6アドレスは、NATの背後の家庭全体ではなく1台のデバイスのもので、mDNSは意図的にそれに手を付けません。WebRTCが今も渡すものの中で、最も個人を特定しやすいものです。
IPv4では、家庭のルーターのNATがすべてを1つのアドレスの背後にまとめるため、サーバーリフレクシブ候補がページに伝える内容は、通常の接続がすでに伝えている内容とほぼ同じです。IPv6にはNATがありません。各デバイスが独自のルーティング可能なアドレスを持ち、それを含むホスト候補は、回線ではなくデバイスを特定します。VPNがIPv4しか運ばない場合（多くのVPNがそうです）、そのIPv6アドレスはトンネルの完全に外にあります。
プライバシー拡張は役立ちます。一時IPv6アドレスは入れ替わるからです。ただし、アドレスを隠すわけではありません。mDNSのドラフトは、そうしたアドレスをマスクしないままにしてもよいとしています。上のテストは、ルーティング可能なIPv6のホスト候補を、見つかりうる最も深刻なものとして示します。お使いの接続にそもそもIPv6があるかは、IPv6接続確認テストでわかります。
アドレスが特定するもの同じ3台のデバイスで2通り
192.168.1.202001:db8:4a1f:7c00::1c 192.168.1.212001:db8:4a1f:7c00::2b 192.168.1.222001:db8:4a1f:7c00::3d 203.0.113.7回線全体で1つのアドレスデバイスごとに1つのアドレスグローバルIPv6アドレスの2つの部分
2001:db8:4a1f:7c00ネットワークプレフィックス：回線 /64:8d3:5e2f:a41c:9b07インターフェースID：このデバイス
- 固定
2001:db8:4a1f:7c00::1c - 一時的：入れ替わる
2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07
IPv4しか運ばないVPN
- IPv4
198.51.100.23トンネルの中 - IPv6
2001:db8:4a1f:7c00トンネルの外::1c
ブラウザー別にWebRTCリークを防ぐ方法
Firefoxには効果のある設定があります。Edgeにはエンタープライズポリシーがあります。Safariはすでに候補を制限しています。今もよく勧められるブラウザー拡張機能は、もう何もしません。
Firefoxでは、about:config → media.peerconnection.ice.default_address_onlyで、すべてのアドレスではなく1つだけを送るようになり、media.peerconnection.ice.relay_onlyで収集をリレー候補だけに制限できます。後者は直接の通話を壊しますが、それ以外はすべて隠せます。どちらも既定ではオフで、プライベートアドレスのmDNSによるマスク（media.peerconnection.ice.obfuscate_host_addresses）はすでにオンです。Edgeでは、WebRtcLocalIpsAllowedUrlsポリシーで、ローカルアドレスを見てよいサイトを指定します。Microsoft自身のドキュメントは、サイトを追加すると「保護が弱まる」と注記しています。Chromeには、一般のユーザー向けの同等の設定がありません。Safariは、何もしなくても最も厳格です。カメラやマイクの許可がなければ、WebKitはサーバーリフレクシブ候補とリレー候補だけを提示し、ホスト候補は一切提示しません。
今も広く勧められている2つの方法は、もう機能しません。uBlock Originの「ローカルIPアドレスの漏洩をもたらすWebRTCを防止する」オプションはバージョン1.38で削除され、その際「Android版Firefoxを除き、最新のブラウザーではもはや不要」と説明されました。また、GoogleのWebRTC Network Limiter拡張機能は、ストアにまだ掲載されていますが動作しません。2025年7月のChrome 138以降、すべてのChromeユーザーでManifest V2の拡張機能が無効になっているためです。どちらかをインストールするよう勧めるページは、何年も更新されていません。
各ブラウザーが提供するもの各ベンダーのドキュメントで確認
Firefox効果のある設定
about:configmedia.peerconnection.ice.obfuscate_host_addresses既定値trueプライベートアドレスをマスク。すでにオン。media.peerconnection.ice.default_address_only既定値false設定値trueすべてのアドレスではなく1つだけを送ります。media.peerconnection.ice.relay_only既定値false設定値trueリレー候補のみ。最も多くを隠せますが、直接の通話が壊れます。
Edgeエンタープライズポリシー
WebRtcLocalIpsAllowedUrlsローカルアドレスを見てよいサイトを列挙します。
未設定：ローカルアドレスはマスクされたままです。
Microsoft自身の注記：サイトを追加すると保護が弱まります。
WindowsとmacOS、バージョン80以降
Chrome設定なし
一般のユーザー向けの設定はありません。
バージョン76以降、プライベートアドレスを既定でマスク。
カメラやマイクの許可を持つサイトでは無効。
Safari既定で厳格
カメラやマイクの許可がなければ、STUNサーバーの候補とリレー候補のみ。
ホスト候補は一切なし。
もう機能しないアドバイス
Prevent WebRTC from leaking local IP addressesuBlock Origin
バージョン1.38で削除uBlock Originによれば、Android版Firefoxを除き、最新のブラウザーではもはや不要です。
WebRTC Network LimiterGoogle · Chrome Web Store
掲載中だが動作不可2025年7月のChrome 138以降、すべてのChromeユーザーでManifest V2の拡張機能が無効になっています。
WebRTCリーク、DNSリーク、IPリークの違いは？
VPNを迂回する3つの異なる経路です。WebRTCリークはアドレスを示し、DNSリークは誰があなたの問い合わせに応答しているかを示し、IPリークは通信がそもそもトンネルに入らなかった単純なケースです。
WebRTCリークは、アドレスを自ら差し出すように設計された機能を通じて、ブラウザーが差し出すアドレスの問題です。DNSリークは、どのリゾルバーが問い合わせに応答するかの問題です。通信がVPNを通っていても、問い合わせがプロバイダーのリゾルバーに送られ続けることがあり、そうなるとプロバイダーには、あなたが訪れるすべてのサイトがわかります。当サイトのDNSリークテストは、当サイト独自のネームサーバーでこれを確認するため、どのリゾルバーが問い合わせてきたかを正確に把握できます。
一般的な意味でのIPリークとは、Webサイトにそのまま見えるアドレスのことで、自分のIPアドレス確認や自分のISPを確認で確認できます。VPNの設定を変えたら、3つをまとめて実行してください。それぞれ独立して失敗するため、1つの結果が問題なしでも、ほかについては何もわかりません。
VPNを迂回する3つの経路それぞれ独立して失敗する
IPリーク
漏れるものすべてのリクエストに含まれるアドレス
それを知る相手訪問するすべてのサイト
確認するツール自分のIPアドレス確認自分のISPを確認
DNSリーク
漏れるものどのリゾルバーが問い合わせに応答するか
それを知る相手プロバイダー（調べるすべてのサイトについて）
確認するツールDNSリークテスト
WebRTCリーク
漏れるものブラウザーがページに提示するアドレス
それを知る相手尋ねたページすべて（確認なしで）
確認するツールWebRTCリークテスト
このテストが複数のSTUNサーバーに尋ねる理由
「アドレスが返ってこなかった」と「アドレスが存在しない」は同じに見えますが、良い知らせなのは一方だけだからです。
企業のファイアウォール、制限の厳しいVPN、UDPをブロックするネットワークは、STUNサーバーの応答を止めることがあります。1社にだけ尋ねて何も見えなかったテストは、何もわかっていません。それなのに、よくある対応は緑のチェックマークを表示することです。このテストは、Cloudflareが文書化しているSTUNエンドポイントとGoogleのものに尋ね、それぞれを個別に報告し、どれも応答しなかった場合は、テストできなかったと伝えます。
サーバーの選択は意図的です。Cloudflareはstun.cloudflare.com:3478を製品の一部として公開しているため、読むべき規約があります。Googleのstun.l.google.com:19302は、Google自身のWebRTCバリデーターの既定値としてしか文書化されておらず、公開された規約がないため、唯一の情報源ではなく、セカンドオピニオンとして使います。Twilioのものは認証情報が必要で、Mozillaについては、よく名前が挙がるにもかかわらず、文書化された公開STUNサーバーはありません。
公開STUNサーバーこのテストが尋ねるもの
Cloudflare尋ねる
stun.cloudflare.com:3478文書化されたエンドポイントで、製品の一部として読むべき規約があります。
Google尋ねる（セカンドオピニオン）
stun.l.google.com:19302Google自身のWebRTCバリデーターの既定値としてのみ文書化。公開された規約なし。
Twilio尋ねない
global.stun.twilio.com:3478TwilioのAPIからの認証情報が必要。すべてのページに開かれてはいません。
Mozilla尋ねない
公開サーバーなし文書化された公開STUNサーバーはありません。FirefoxにはICEサーバーの既定値が一切ありません。
サーバーが応答しないとき
IPアドレスは個人データですか？
EUでは、動的IPアドレスは、プロバイダーが持つ情報であなたを特定できるWebサイト運営者にとって、個人データです。欧州連合司法裁判所が2016年にそう判断しました。
この事件はBreyer事件（C-582/14）で、2016年10月19日に判決が出ました。裁判所のプレスリリースは、次のように要約しています：「訪問者の動的インターネットプロトコルアドレスは、Webサイトの運営者が、インターネットアクセスプロバイダーが保有する当該訪問者に関する追加情報によって訪問者を特定できる法的手段を有している場合、その運営者との関係において個人データを構成する」。同じプレスリリースは、サイトが攻撃から身を守るために、その一部を保存する正当な利益を持ちうることにも触れています。
このページがブラウザーの中で処理を行うのは、まさにそのためです。ICE候補はブラウザーが収集し、ブラウザーの中で比較し、あなたに表示します。WebRTCが見つけたアドレスが当サイトに送られることはないため、当サイトには保存したり、引き渡したり、紛失したりしうるものが何もありません。テストの実行中に、ネットワークパネルで確認できます。
Breyer判決欧州連合司法裁判所
C-582/14Breyer v Bundesrepublik Deutschland2016年10月19日
- Webサイト運営者ログにあるアドレスと時刻
203.0.113.7 · 14:02:37 - それを入手する法的手段
- インターネットアクセスプロバイダーその時刻にそのアドレスを誰が使っていたか
203.0.113.7 · 14:02:37 → - その運営者にとっては個人データ
裁判所のプレスリリース：サイトは攻撃から身を守るため、その一部を保存する正当な利益を持ちうる。
このページでは
お使いのブラウザー
- 収集
- 分類
- 比較
- 表示
- 通話と同じく、パブリックアドレスが見える
- dnsrobot.net候補は送信されない
WebRTCリークテスト：よくある質問
WebRTCリーク（WebRTC漏洩）とは何ですか？
WebRTCリークを確認するには？
VPNでWebRTCリークは防げますか？
結果に表示される.localアドレスとは何ですか？
.localのランダムな名前に置き換えるため、サイトはそこから家庭のネットワークについて何も知ることができません。Chromeはバージョン76以降これを行っており、Firefoxも同様です。Safariはさらに踏み込み、サイトがカメラやマイクの許可を得るまでは、ホスト候補を一切提示しません。テストはこれを、発見事項ではなく、保護が機能しているものとして示します。mDNSがローカルIPを隠していれば安全ですか？
テストが「テストできず」と表示するのはなぜですか？
FirefoxでWebRTCを無効にするには？
about:configで、media.peerconnection.ice.default_address_onlyはすべてのアドレスではなく1つだけを送るようにし、media.peerconnection.ice.relay_onlyは収集をリレー候補に制限します。後者は最も多くを隠せますが、直接の通話が壊れます。プライベートアドレスのマスク（media.peerconnection.ice.obfuscate_host_addresses）は、既定ですでにオンです。1つ変えるたびにテストを再実行して、実際に何が得られたかを確認してください。ChromeでWebRTCリークを防ぐには？
WebRtcLocalIpsAllowedUrlsというエンタープライズポリシーがあります。今も広く勧められている拡張機能は機能しません。uBlock Originはバージョン1.38でWebRTCのオプションを削除し、GoogleのWebRTC Network Limiterは、Chrome 138でManifest V2が無効になって以来、動作できません。ホスト候補とサーバーリフレクシブ候補の違いは何ですか？
WebRTCリークとDNSリークは同じですか？
このテストはIPアドレスをどこかに送りますか？
IPアドレスはEU法上の個人データですか？
足りないものはありますか？機能や新しいツールを提案する