VPNクライアントに「接続済み」と表示されていても、すべての通信が同じ経路を通っているとは限りません。ウェブサイトの名前を調べるDNS問い合わせが通常の回線へ送られていたり、ブラウザーのWebRTC機能がローカルネットワークや実際の接続情報を公開したりする場合があります。これはVPNそのものが暗号化に失敗しているという意味ではなく、ブラウザー、OS、クライアントのルーティング設定が別々に動作していることから起こります。
DNSリーク検査とWebRTC漏洩検査は、接続ボタンを押した直後に一度だけ実行すれば終わる作業ではありません。通常回線、VPN接続中、サーバー切り替え後、スリープ復帰後など条件を分けて確認し、表示された事業者名やIPアドレスが自分の期待する経路と一致しているかを読み取る必要があります。本記事では、検査の意味、パソコンとスマートフォンで見直す設定、異常が見つかったときの切り分け方を順番に整理します。
DNSリークとWebRTC漏洩の違い
DNSは、入力したドメイン名を接続先のIPアドレスへ変換する仕組みです。VPN接続中でも、OSやブラウザーがインターネットサービスプロバイダーのDNSサーバーを使い続けると、アクセス先の名前解決だけが通常回線へ送られる可能性があります。ウェブページの本文がVPNトンネルを通っていても、名前解決の経路が別になれば、プライバシーの確認項目が増えます。
一方、WebRTCはブラウザーで音声通話、ビデオ会議、画面共有などを実現する技術です。接続相手との通信経路を確立するため、ブラウザーはICE候補と呼ばれる接続情報を扱います。設定やブラウザーの実装によっては、ローカルIPアドレス、VPN接続前のアドレス、ネットワークインターフェースに関する情報がページ側から読み取れることがあります。WebRTCの検出結果にアドレスが表示されたからといって、必ずしも通信内容全体が漏れているわけではありませんが、意図しない情報公開として確認する価値があります。
DNS
名前解決の経路
WebRTC
ブラウザーの接続候補
2段階
検査と再確認
5
切り分けの基本観点
検査前にそろえる条件
検査結果を比較するには、最初に条件を固定します。ブラウザーを複数開いたままにすると、古いページのキャッシュや拡張機能の影響が残ることがあります。検査用のブラウザーを1つ決め、不要な拡張機能を一時停止し、VPNクライアントの接続先とモードを記録しましょう。ブラウザー拡張機能型のプロキシと、OS全体に適用するVPNクライアントでは、対象になる通信範囲が異なります。
- 通常回線の状態で、IPアドレス、DNSサーバー名、WebRTCで表示される候補を記録します。
- ブラウザーのタブを閉じ、VPNクライアントを起動してから接続します。
- 接続後に数分待ち、同じ検査ページを再読み込みして結果を保存します。
- 別のサーバーやプロトコルへ切り替えた場合は、古いページを再利用せず再検査します。
- VPNを切断して通常回線へ戻し、表示が元の状態へ戻るかも確認します。
通常回線の結果を先に記録する理由は、VPN接続後に表示が変わったかを比較するためです。VPN接続前のDNS事業者やIPアドレスを知らないまま検査すると、VPN側の表示を正しく解釈できません。また、企業ネットワーク、学校、ホテル、携帯回線ではDNSが管理者によって指定されていることがあるため、家庭の回線とは異なる結果が出ても、直ちにクライアントの不具合とは限りません。
- ✅ 検査前後で同じブラウザーと同じ端末を使う
- ✅ VPN接続前のDNSとIPアドレスを記録する
- ✅ サーバー変更後とネットワーク変更後に再検査する
- ❌ 検査サイトを複数同時に開き、結果を混ぜて判断しない
DNSリークを検査する方法
DNS検査ページでは、現在の通信元IP、検出されたDNSサーバー、事業者名、地域などが表示されます。重要なのは、表示されたサーバーがVPN接続で想定した提供者や経路に属しているかです。VPN接続中にもかかわらず、通常回線のインターネットサービスプロバイダー名が表示される場合は、DNS問い合わせがVPNの外へ出ている可能性があります。
ただし、DNS事業者名だけを見て結論を出すのは危険です。VPNサービスが外部のDNSリゾルバーを採用している場合、接続元のISPとは異なる第三者名が表示されることがあります。反対に、同じ事業者名が表示されても、問い合わせが暗号化されているか、VPNトンネル内を通っているかまでは検査ページだけで完全に判断できない場合があります。サービスの説明、クライアントのDNS設定、検査サイトの結果を組み合わせて確認してください。
| 表示された結果 | 考えられる状態 | 次に確認する項目 |
|---|---|---|
| VPN側で想定したDNSが表示される | DNSがVPN経路へ切り替わっている可能性が高い | サーバー変更後と再接続後の再現性 |
| 通常回線のISP名が表示される | DNS問い合わせがVPN外へ出ている可能性 | DNS保護、キルスイッチ、OS設定 |
| 複数の事業者や想定外の地域が表示される | 複数インターフェース、暗号化DNS、ネットワーク管理の影響 | ブラウザーとOSのDNS設定の優先順位 |
| 検査結果が毎回大きく変わる | 自動サーバー選択やネットワーク切り替えの影響 | 接続先固定、再接続、他のクライアント停止 |
Windows・macOSでの確認
Windowsでは、VPNクライアントのDNS保護またはDNSリーク防止の項目を確認し、接続中のネットワークアダプターに通常回線のDNSが残っていないかを調べます。複数のVPNクライアント、仮想マシン、コンテナ、広告ブロッカーが同時にDNSを管理していると、優先順位が複雑になることがあります。macOSでも、VPNサービスのDNS設定だけでなく、システム設定のネットワーク項目に手動DNSが残っていないかを確認してください。
DNS over HTTPSやDNS over TLSをブラウザーやOSで有効にしている場合、その問い合わせがVPNトンネルを通るかどうかは構成によって異なります。プライバシー機能を追加すれば必ず問題が解決するわけではなく、VPNの仮想インターフェース、ファイアウォール、クライアントのDNS保護が互いに干渉することもあります。
WebRTC漏洩を検査する方法
WebRTC検査ページを開くと、ブラウザーが公開可能なローカル候補やパブリック候補が表示されます。VPN接続中にVPNと無関係な実際の回線IPが見える場合は、WebRTCの候補収集を通じて接続情報が公開されている可能性があります。ローカルIPだけが表示される場合もありますが、家庭内ネットワークの構成や端末識別に関する情報を減らしたい人は、同じように設定を見直すとよいでしょう。
検査では、VPN接続前、VPN接続中、ブラウザーのWebRTC制限後の3つを比較します。ブラウザーのプライバシー設定や拡張機能によって、WebRTCの候補が完全に非表示になる場合もあります。しかし、非表示になったことだけで音声通話やビデオ会議が正常に動くとは限りません。実際に利用する会議サービスで、マイク、カメラ、画面共有、着信を確認し、必要な機能を壊していないか確かめることが重要です。
ブラウザー設定を見直す
Chromium系ブラウザーでは、WebRTCに関するプライバシー設定や管理ポリシーが使われることがあります。Firefoxでは、WebRTCの候補公開に関係する詳細設定を確認できます。設定名や利用できる項目はバージョンによって変わるため、検索結果の古い手順をそのまま適用せず、現在のブラウザーの公式設定画面で確認してください。ブラウザー拡張機能を導入する場合は、権限、更新元、他の拡張機能との競合も確認します。
スマートフォンでは、ブラウザー単体のWebRTC設定を細かく変更できないことがあります。iOSとAndroidでは、VPNプロファイル、アプリごとの通信制御、ブラウザーの権限管理が関係します。iOSのアプリはシステムのネットワーク制御を受けますが、アプリ独自の接続処理まで同じ動作になるとは限りません。Androidでも、常時接続VPNやVPNなしの接続を遮断する設定が、利用するアプリと両立するかを確認しましょう。
クライアントとルーティングの見直し
DNSとWebRTCの検査結果が期待と異なる場合、最初に2つのVPNクライアントを同時起動していないか確認します。WindowsやmacOSの公式クライアントと、Clash Verge、sing-boxなどの互換クライアントを同時に動かすと、仮想インターフェース、システムプロキシ、DNSポートの設定が競合することがあります。iOSではShadowrocketなどのクライアントを使う場合も、他のVPNプロファイルを停止してから検査してください。
サブスクリプションリンクを複数のクライアントへ導入している場合、同じ設定名でもルール、DNSモード、トンネル方式が一致するとは限りません。Windows、macOS、Android、iOS、Linuxの公式クライアントでは、接続後のDNS保護やキルスイッチの表示を確認します。Clash Vergeやsing-boxでは、DNSモード、Fake-IPまたはRedir-Hostの動作、ルール外通信、システムDNSへのフォールバックを確認してください。Shadowrocketでは、グローバル、ルール、ダイレクトの選択が検査対象の通信に適用されているかを見ます。
WireGuard、OpenVPN、Shadowsocks、VMess、Trojan、Hysteria2など、プロトコルが違えばDNS処理やトンネルの作り方が変わる場合があります。プロトコルを変更した後は、以前の検査結果を流用せず、DNSとWebRTCをそれぞれ再確認してください。IEPL、BGP、CN2などの回線種類は経路品質や混雑の傾向を考える材料ですが、回線名だけでDNSリークやWebRTC漏洩が防止されるわけではありません。
- ✅ クライアントは1つだけ起動し、不要なVPNプロファイルを停止する
- ✅ DNS保護、キルスイッチ、常時接続の状態を確認する
- ✅ ルール分流ではDNSと検査サイトの通信先を意識する
- ✅ プロトコル変更後はDNSとWebRTCをもう一度検査する
- ❌ ブラウザーだけを直して、他のアプリの通信も安全だと決めつけない
異常が見つかったときの切り分け
DNSリークが疑われるときは、まずVPNクライアントのDNS保護を有効にし、再接続してから検査します。改善しない場合は、OSの手動DNS、ブラウザーの暗号化DNS、セキュリティソフト、ルーターのDNSリダイレクトを順番に確認します。変更を一度に多数加えると原因が分からなくなるため、1項目を変更したら接続を切り替え、同じ検査を実行して結果を記録してください。
WebRTC側の異常では、まずブラウザーのプライバシー設定と拡張機能を確認します。その後、別のブラウザー、別のネットワーク、別のVPNクライアントで同じ検査を行います。1つのブラウザーだけで発生するならブラウザーや拡張機能の影響が考えられます。複数のブラウザーと端末で同じ実際のIPが表示されるなら、VPNのルーティング、スプリットトンネリング、アプリ単位の除外設定を優先して調べます。
スリープ復帰、Wi-Fiからモバイル回線への切り替え、端末の再起動後も確認しましょう。接続直後は問題がなくても、ネットワークインターフェースの切り替えでDNS設定が古い回線へ戻ったり、VPNの仮想インターフェースが再作成されなかったりすることがあります。キルスイッチがある場合は、VPNが切断された際に対象通信を停止できるかを、作業に影響しない時間帯に確認します。
DNS・WebRTC検査に関するFAQ
VPN接続中に自分のISP名が表示されたら、必ずリークですか？
必ずしもそうとは限りません。検査サイトの表示方法、暗号化DNSの設定、ネットワーク管理者のDNS、VPNサービスの構成によって見え方が変わります。ただし、VPN接続前と同じDNSサーバーが表示され、クライアントのDNS保護も無効になっているなら、経路を見直すべきサインです。
WebRTCでローカルIPが表示されるのは危険ですか？
ローカルIPは家庭内ネットワークの構成を示す情報で、パブリックIPとは性質が異なります。それでも不要な情報公開を減らしたい場合は、ブラウザーのWebRTC関連設定を確認してください。音声通話やビデオ会議を使う場合は、変更後に必要な機能が正常に動くかを必ず試します。
検査サイトの結果が毎回変わる場合はどうすればよいですか？
自動サーバー選択、ネットワークの切り替え、複数クライアントの競合、検査サイト側の分散処理が考えられます。接続先を固定し、他のVPNやプロキシを停止して、同じブラウザーで再検査してください。時間帯だけでなく、Wi-Fiとモバイル回線の違いも分けて記録すると判断しやすくなります。
DNS検査で問題がなくても、プライバシー対策は必要ですか？
必要です。DNS検査は名前解決の経路を確認するもので、WebRTC、アプリ独自の通信、ブラウザーの指紋、アカウント情報まで確認するものではありません。OS、ブラウザー、VPNクライアントを最新の状態に保ち、不要な拡張機能やアプリの権限を減らし、用途に応じて定期的に再検査することが大切です。
日常利用のための最終チェック
DNSリークとWebRTC漏洩の確認は、特別な知識を持つ人だけの作業ではありません。VPN接続前の状態を記録し、接続後に同じ条件で検査し、結果が想定する経路と一致するかを判断するだけでも、設定の見落としを減らせます。問題が見つかった場合は、DNS保護、ブラウザーのWebRTC設定、分流ルール、複数クライアントの競合を順番に確認してください。
新しい端末を追加したとき、サブスクリプション設定を別のクライアントへ導入したとき、OSやブラウザーを更新したときは、過去の結果をそのまま信頼せず再検査するのが安全です。検査結果は保存日時、利用した回線、VPNクライアント、プロトコル、表示されたDNS事業者を一緒に記録すると、後から変化を比較できます。