VPNクライアントに「接続済み」と表示されていても、すべての名前解決やブラウザ通信が同じ経路を通るとは限りません。DNSリークが起きると、アクセス先のドメイン名を調べる問い合わせが、VPN事業者ではなく通常のインターネット接続事業者のDNSサーバーへ送られることがあります。WebRTCリークでは、ブラウザのリアルタイム通信機能が、VPN接続後にもローカルネットワークや別のアドレス情報を取得する場合があります。
これらは「VPNの暗号化がすべて破られた」という意味ではありません。しかし、接続先の地域やネットワーク環境を確認する目的でVPNを利用している場合、出口IPアドレスだけを見て安全だと判断すると、見落としが生じます。本記事では、DNSとWebRTCが何を表示するのか、検査サイトでどのように確認するのか、設定を変更した後にどう再テストするのかを、Windows、macOS、Android、iOS、Linuxと互換クライアントの違いを含めて説明します。
DNSリークとWebRTCリークの仕組みを理解する
DNSは、ブラウザが入力したドメイン名をIPアドレスへ変換する仕組みです。VPNを有効にすると、通常はVPNトンネル内のDNSサーバー、またはクライアントが指定した安全なDNS経路を利用します。一方、OSやブラウザが元のネットワークから配布されたDNS設定を優先したり、分割トンネルのルールによってDNSだけが通常回線へ出たりすると、DNSリークと呼ばれる状態になります。
DNSリークで直接表示されるのは、一般にDNS問い合わせを処理したサーバーやそのネットワークの情報です。閲覧したページの本文がそのまま送信されるわけではありませんが、ドメイン名の問い合わせから利用先の傾向を推測できるため、プライバシーを重視する場合は確認する価値があります。DNS検査に表示される事業者名と、VPNの契約先名が一致しないからといって、直ちに異常とは限りません。VPNが別のDNS提供元を使う構成もあるため、接続前後の結果とクライアント設定を合わせて判断します。
WebRTCは、ブラウザで音声通話、ビデオ通話、画面共有などを実現するための標準技術です。接続相手との経路を確立するため、STUNなどの仕組みを利用して、端末が利用できるアドレス候補を調べます。その過程で、ローカルネットワークのアドレス、VPNを使っていない経路のアドレス、またはVPN側の出口アドレスが検査ページに表示されることがあります。
DNS
名前解決の経路を確認
WebRTC
ブラウザの接続候補を確認
2段階
設定変更後に再テスト
重要なのは、DNSリークとWebRTCリークが別の問題だという点です。DNS設定だけを変更してもWebRTCの候補収集は止まりませんし、ブラウザのWebRTC対策だけではOSのDNS問い合わせは変わりません。まず検査結果を項目ごとに分けて記録し、原因に対応した設定を変更してください。
検査前に条件をそろえる
検査は、VPNを切断した状態と接続した状態を比較して行います。最初からVPN接続後の画面だけを確認すると、どの情報が変化したのか判断しにくくなります。検査用のブラウザでは、プライベートウィンドウを使うか、ページを再読み込みして古い結果を残さないようにします。複数のVPNクライアントやシステムプロキシを同時に有効にすると、経路が分かりにくくなるため、一度に一つのクライアントだけを使うのが基本です。
- ✅ VPNを切断し、通常時の外部IPアドレス、DNS事業者、WebRTC候補を記録する
- ✅ VPNを接続し、同じブラウザと同じ検査ページを再読み込みする
- ✅ 外部IP、DNS、WebRTCを別々の項目として比較する
- ✅ Wi-Fiとモバイル通信を混同せず、接続環境を記録する
- ❌ VPN接続済みの表示だけで、DNSとWebRTCも保護されていると判断しない
- ❌ 検査中に別のプロキシ拡張機能や広告ブロッカーを追加して条件を変えない
検査サイトは、DNSリークテストとWebRTCリークテストを提供する一般的なサービスを利用できます。サイトによって表示方法や判定基準が異なるため、一つの「安全」「危険」というラベルだけを信じず、表示されたDNSサーバー、IPアドレス、地域、ネットワーク名を確認しましょう。テストページがブラウザのキャッシュや既存の接続を再利用する場合もあるため、VPNの接続先を切り替えた後はページを完全に再読み込みします。
DNSリークの確認と対策
VPN接続後にDNS検査を実行し、表示されたサーバーが通常回線の通信事業者のものか、VPNクライアントが指定したDNS経路のものかを確認します。ここで「VPNの所在地とDNSサーバーの所在地が違う」ことだけを問題にする必要はありません。DNSサーバーは別の地域に配置される場合があるため、確認すべきなのはVPN切断時と同じDNS経路へ戻っていないか、そしてクライアントの説明と検査結果が矛盾していないかです。
Windowsでは、VPNクライアントのDNS保護、DNSリーク防止、キルスイッチなどの設定を確認します。ネットワークアダプターの優先順位や、手動で設定したDNSがVPNの仮想アダプターより優先されると、意図しない問い合わせが発生することがあります。macOSでも、VPN接続サービスのDNS設定と、Wi-Fiまたは有線接続側のDNS設定を分けて確認します。変更後はVPNをいったん切断し、再接続してから検査してください。
AndroidとiOSでは、システムの「プライベートDNS」や「iCloudプライベートリレー」など、VPNとは別に動作する機能が経路へ影響することがあります。これらを無条件に無効化するのではなく、利用中のVPNクライアントの説明と競合しないかを確認します。モバイルOSはアプリごとのネットワーク制御に制限があるため、デスクトップと同じ設定項目が表示されない場合があります。
Clash Verge、sing-box、Shadowrocketなどの互換クライアントを使う場合は、DNSモード、DNSサーバー、Fake-IPまたはRedir-Host、ルール分流、システムDNSの扱いを確認します。サブスクリプションを読み込んだだけでは、端末全体のDNSが必ずトンネルへ入るとは限りません。TUNモードを使う構成でも、除外ルールや直接接続ルールにDNS通信が含まれていないかを確認する必要があります。設定を一度に多数変更せず、DNSモード、ルール、TUNの順に一項目ずつ切り分けると原因を追いやすくなります。
| 状況 | 確認する項目 | 対策の方向 |
|---|---|---|
| VPN接続後も通常回線のDNSが表示される | DNSリーク防止、DNS優先順位、分割トンネル | クライアントのDNS保護を有効にし、DNS通信が直接接続になっていないか確認する |
| 互換クライアントで結果が毎回変わる | DNSモード、Fake-IP、ルールセット、TUN設定 | 設定を一つずつ固定し、再接続後に同じ検査を行う |
| VPNを切断しても以前の結果が表示される | ブラウザキャッシュ、OSのDNSキャッシュ、既存セッション | ページを再読み込みし、必要に応じてブラウザとクライアントを再起動する |
WebRTCリークの確認と対策
WebRTC検査では、ブラウザが取得したアドレス候補に、通常回線側のグローバルIP、ローカルIP、VPN出口IPのどれが表示されるかを確認します。ローカルIPはプライベートアドレスであり、それだけで外部から端末へ接続できることを意味しません。ただし、ネットワーク構成を知られたくない場合や、VPN接続時に通常回線側の情報を表示したくない場合は、WebRTCの挙動を調整する意味があります。
まず、使用しているブラウザがWebRTCのアドレス候補をどのように扱うかを確認します。ブラウザによっては、プライバシー設定、ローカルネットワークへのアクセス許可、拡張機能の制御項目が異なります。設定を変更した後は、開いていたタブを閉じて新しいタブで検査します。すでに開始された音声通話やビデオ通話のセッションは、設定変更だけでは直ちに更新されないことがあります。
WebRTCを完全に無効化すると、ブラウザ上のビデオ会議、音声通話、画面共有、ブラウザ間のファイル転送などが動作しなくなる可能性があります。そのため、利用目的がある端末では、WebRTC全体を止めるよりも、不要なローカル候補の公開を抑える設定を優先します。拡張機能を使う場合は、提供元、権限、更新状況、他の拡張機能との競合を確認し、重要なアカウントを開くブラウザへ無制限に追加しないようにします。
システム全体をVPNへ通すTUN構成であっても、WebRTCのアドレス候補生成はブラウザ側の機能です。したがって、TUNを有効にしたことだけでWebRTC情報の表示が完全に変わるとは限りません。ブラウザ設定、VPNクライアント、OSのネットワーク権限を別々に確認し、VPN接続前後の検査結果を比較してください。
設定変更後の再テストと切り分け
対策後は、単に検査ページを再読み込みするだけでなく、VPNクライアントを切断してから再接続し、ブラウザの新しいタブでDNSとWebRTCをもう一度確認します。結果が変わらない場合は、VPN接続そのもの、DNS、WebRTC、ブラウザ拡張機能の順に切り分けます。接続先ノードやプロトコルを変えた場合は、同じ設定変更の効果を比較できなくなるため、まず一つの条件を固定します。
- ✅ VPN切断時と接続時の結果を別々に保存する
- ✅ DNS検査では表示された事業者と通常回線時の事業者を比較する
- ✅ WebRTC検査では通常回線側、VPN側、ローカルの候補を区別する
- ✅ DNS設定を変更したら、VPNの再接続とブラウザの再起動を行う
- ✅ 別のブラウザでも同じ結果になるか確認する
- ❌ 一つの検査サイトの判定だけで、通信全体の安全性を断定しない
検査結果が環境によって変わる場合、異常とは限りません。IPv4とIPv6の扱いが異なる、モバイル回線とWi-FiでDNSが変わる、ブラウザのプライバシー設定が別プロファイルに保存されている、あるいはルール分流によって一部の通信だけが直接接続されている可能性があります。特にIPv6を有効にした端末では、VPNクライアントがIPv6を完全にトンネルへ収容できるかを確認します。対応していない場合は、クライアントのIPv6保護設定や、ネットワーク側のIPv6利用方針を確認してください。
また、DNSリークが見つからなくても、アクセス先のアプリが独自の名前解決を使うとは限りません。ブラウザ、ゲーム、メッセージアプリ、業務アプリでは、システムDNS、独自DNS、HTTPS経由のDNSなど動作が異なる場合があります。プライバシーを重視する通信では、検査サイトの結果だけでなく、実際に使うアプリがVPNのルール対象になっているか、スプリットトンネルの除外対象になっていないかも確認しましょう。
日常利用で維持したい確認習慣
VPNの設定は、クライアントの更新、OSのアップデート、サブスクリプションの変更、ネットワーク環境の変更によって挙動が変わることがあります。初回に問題がなかったからといって、すべての将来の接続で同じ結果になるとは限りません。特に、互換クライアントで設定を再インポートした後や、TUN、DNS、ルール分流を変更した後は、DNSとWebRTCを再確認すると安心です。
サブスクリプションを利用する場合は、信頼できる提供元から取得し、内容を不用意に編集しないでください。Clash Verge、sing-box、Shadowrocketなどへ読み込む際は、更新後にDNS設定やルールが置き換わっていないかを確認します。公式クライアントを使う場合も、DNSリーク防止、キルスイッチ、IPv6、スプリットトンネルの設定を自分の用途に合わせて見直します。設定項目の名前はクライアントごとに異なるため、「保護」という表示だけでなく、実際の検査結果で確認することが大切です。