VPNに接続したのに、確認サイトへアクセスすると本来のIPアドレスや利用中のDNSサーバーが表示されることがあります。また、ブラウザーのWebRTC機能によって、VPNとは別のネットワーク情報が推測される場合もあります。これは、VPNそのものが必ず危険という意味ではありません。VPNが担当する範囲、ブラウザーが独自に行う通信、OSやルーターが提供する名前解決を分けて確認することが重要です。

この記事では、VPN接続前後の比較、DNSリークの確認、WebRTC漏洩の調べ方、Windows・macOS・Android・iOS・Linuxでの対処方針を整理します。特定のチェックサイトの表示だけを見て慌てるのではなく、どの情報が表示され、どの通信がVPNを経由しているのかを順番に確認しましょう。結果が期待と違う場合も、設定を一度にすべて変更せず、原因を切り分けるほうが安全です。

DNSリークとWebRTC漏洩の違いを理解する

DNSリークは名前解決の経路に関する問題

DNSは、ドメイン名を接続先のIPアドレスへ変換する仕組みです。ブラウザーでWebサイトを開くとき、端末は最初にDNSへ問い合わせを行います。VPNトンネルが有効でも、端末やルーターが提供するDNSを使い続けていると、アクセス先のドメイン名がVPNの外側にあるDNS事業者へ送られる可能性があります。この状態が一般にDNSリークと呼ばれます。

DNSリークで直ちにWebページの内容すべてが見られるとは限りません。しかし、どのドメインを名前解決したかという情報は、利用状況や接続先を推測する材料になります。VPNクライアントがDNSをトンネル内へ切り替える設計になっているか、OSのDNS設定が接続後に変わっているか、IPv4とIPv6の両方が同じ方針で処理されているかを確認する必要があります。

WebRTC漏洩はブラウザー機能から生じる情報表示

WebRTCは、ブラウザー上で音声通話やビデオ通話、リアルタイム通信を実現するための機能です。接続相手との通信経路を確立するため、ブラウザーはICE候補と呼ばれるネットワーク情報を確認します。その過程で、VPNが通常のブラウザー通信を中継していても、ローカルネットワークのアドレスや別の接続候補が表示されることがあります。

WebRTCの表示内容はブラウザー、OS、VPNクライアント、通信方式によって異なります。プライベートアドレスだけが表示される場合と、公開アドレスに見える情報が表示される場合を同じ問題として扱わないでください。WebRTCを使う通話や会議サービスを利用している場合は、機能を無効にすることで別の不便が生じるため、必要性とプライバシーの優先順位を決めてから変更します。

2

主に分けて確認する項目

90+

VPN TXの対応国

200+

VPN TXの回線

不限

同時接続台数

確認の基本:

DNSは名前解決の経路、WebRTCはブラウザーが示す接続候補として別々に検査します。一方の結果だけでVPN全体の安全性を評価しないことが大切です。

チェックサイトでVPN接続前後を比較する

確認作業は、VPNを接続する前の状態を記録してから始めます。VPNを先に有効にすると、何が変化したのか判断できません。通常の接続でIP確認サイトとDNSリーク検査サイトを開き、表示されたIPアドレス、国や地域の表示、DNSサーバーの事業者名、IPv4とIPv6の有無を記録します。スクリーンショットを保存してもよいですが、公開チャットやSNSへ貼り付けると接続情報を意図せず共有する可能性があります。

次にVPNを接続し、同じブラウザーの同じタブで再読み込みします。IPアドレスがVPN側の接続先に変わっているか、DNS検査結果に本来のインターネット事業者が残っていないかを確認してください。DNS事業者名がVPNサービス名と一致しないこと自体は、必ずしも異常ではありません。VPNが外部のDNSサービスをトンネル内で利用する構成もあるため、重要なのは問い合わせがVPNの外側へ出ているかどうかです。

WebRTCの検査では、検査ページが表示する候補アドレスを読みます。ローカルアドレスだけが見える場合、家庭内ネットワークの構成が表示されているだけのことがあります。VPN接続前と同じ公開アドレスが、VPN接続後にもWebRTC候補として現れるなら、ブラウザーの設定、拡張機能、VPNクライアントの対応範囲を調べます。検査サイトは広告や計測スクリプトを含む場合があるため、信頼できるサイトを選び、不要な拡張機能を一時的に停止して再確認しましょう。

確認項目 VPN接続後に期待する状態 表示が変わらない場合の確認先
公開IP VPN側の接続先として表示される VPN接続状態、対象アプリ、キルスイッチ、別の通信経路
DNSサーバー VPNトンネル内で処理される構成になっている OSのDNS、IPv6、ルーター、クライアントのDNS設定
WebRTC候補 本来の公開IPが候補として表示されない ブラウザー設定、拡張機能、VPNのWebRTC対応
IPv6 VPN側で処理されるか、必要に応じて明確に制御される OSのIPv6設定、VPNクライアントの対応、回線事業者

実際にリークを切り分けて対処する手順

ここでは、設定を変更する順番を整理します。すべての項目を同時に変更すると、どの対策が有効だったのか分からなくなります。まずVPNクライアントを最新版にし、接続を切断してから再接続します。その後、同じ検査サイトを再読み込みし、結果を記録してください。サブスクリプションを利用している場合は、クライアント内の更新操作も行い、古いサーバー設定が残っていないか確認します。

  1. VPN接続前に公開IP、DNS、IPv6、WebRTCの結果を記録する。
  2. VPNクライアントを起動し、接続先と接続方式が表示されていることを確認する。
  3. VPN接続後に、同じ検査サイトを新しいタブで開いて比較する。
  4. DNSだけが変わらない場合は、OSとルーターのDNS設定を確認する。
  5. WebRTCだけに本来の公開情報が出る場合は、ブラウザー単位で設定を見直す。
  6. 設定変更後にDNSキャッシュを消去し、ブラウザーを再起動して再検査する。

DNSキャッシュが残っていると、設定変更直後の結果が古い状態に見えることがあります。WindowsではコマンドプロンプトからDNSキャッシュを消去できます。macOSやLinuxでもOSやディストリビューションに応じた名前解決サービスの再起動方法がありますが、コマンドは環境によって異なります。管理者権限が必要な操作を実行する場合は、公式ドキュメントで対象バージョンを確認してから行ってください。

VPNが提供するキルスイッチは、VPN切断時に通常回線へ自動的に戻さないための機能です。ただし、キルスイッチがあるからDNSやWebRTCの表示が必ず解決するわけではありません。キルスイッチは切断時の通信停止、DNS設定は名前解決の経路、WebRTC対策はブラウザーの候補表示というように、役割が異なります。

  • ✅ VPN接続前後で同じ検査項目を比較する。
  • ✅ DNSとWebRTCを別々の問題として調べる。
  • ✅ IPv4だけでなくIPv6の表示も確認する。
  • ✅ クライアントの更新後にサブスクリプションを更新する。
  • ❌ 検査サイトの表示をSNSや公開チャットへそのまま投稿しない。
  • ❌ 複数のVPNクライアントを同時に起動しない。
切り分けの順番:

最初にVPN接続そのもの、次にDNS、最後にWebRTCを確認します。問題が一つだけなら、すべてのネットワーク設定を初期化する必要はありません。

端末別に確認するポイント

Windows

Windowsでは、VPNクライアントの接続状態に加えて、ネットワークアダプターのDNS設定、IPv6、ブラウザーのWebRTC設定を確認します。複数の仮想アダプターがインストールされている場合、別のクライアントや古いネットワークソフトウェアが経路を変更することがあります。不要なクライアントを終了し、ブラウザーのプロキシ設定が意図した状態かを調べてください。ブラウザーのプロキシだけを設定しても、OS全体のDNSや他のアプリの通信まで同じ経路になるとは限りません。

macOS

macOSでは、「ネットワーク」設定に登録されたサービスの順番、DNSサーバー、IPv6の構成を確認します。VPNクライアントが独自のDNSを設定する場合、手動で入力したDNSが優先されることがあります。ブラウザーのプライバシー設定やWebRTC関連の拡張機能を確認し、変更後はブラウザーを完全に終了してから再検査します。Wi-Fiと有線接続を切り替えた後に設定が変わることもあるため、普段使う接続ごとに確認しましょう。

AndroidとiOS

モバイル端末では、VPNプロファイル、常時接続、VPN未接続時の通信をブロックする設定を確認します。AndroidのプライベートDNSは、VPNクライアントのDNS処理と競合することがあります。iOSでは、VPN構成プロファイルやiCloud Private Relayなど、通信経路を変更する機能が同時に有効になっていないかを調べます。アプリごとの通信方式はOS標準のVPNと異なる場合があるため、ブラウザーだけでなく、必要なアプリの接続状態も確認してください。

Linux

Linuxでは、NetworkManager、systemd-resolved、各ディストリビューションの名前解決設定が関係します。VPN接続中にどのインターフェースがDNSを受け持つかを確認し、設定ファイルを直接編集する場合は、再起動やネットワーク再接続で上書きされないか注意してください。ブラウザーのWebRTC設定はデスクトップ環境でも別に存在します。コマンドの出力に表示されるローカルアドレスと公開アドレスを区別し、検査サイトの結果と合わせて判断しましょう。

公式クライアントを使う場合は、まず対応するVPN方式、DNS保護、キルスイッチ、IPv6処理の説明を確認します。Clash Verge、sing-box、Shadowrocketなどの互換クライアントへサブスクリプションを読み込む場合は、クライアント側のDNSモード、TUN、システムプロキシ、ルール設定が結果に影響します。プロファイルを読み込んだだけで、すべてのアプリが同じトンネルを通るとは限りません。

ブラウザー設定とVPNサービスを見直す判断

WebRTCを使わないブラウザー利用が中心なら、WebRTCによる候補情報を制限する設定や拡張機能を検討できます。ただし、拡張機能はブラウザーの更新で動作が変わる場合があります。拡張機能を追加する際は、要求する権限、開発元、更新状況を確認し、不要になったものは削除してください。信頼性が不明な拡張機能で通信を保護しようとすると、別のプライバシーリスクを増やす可能性があります。

DNSについては、VPNクライアントがトンネル内DNS、外部DNS、OS標準DNSのどれを使う設計なのかを確認します。外部DNSの名前が表示されたとしても、VPNトンネル内でそのDNSへ到達しているなら、即座にリークとは言えません。反対に、VPN接続を切り替えるとDNSが本来の回線事業者へ戻り、VPNクライアントにDNS保護の設定がない場合は、サービス提供元の説明と実際の検査結果を照合する必要があります。

複数の検査サイトで結果が食い違う場合は、ブラウザーのキャッシュ、広告ブロッカー、IPv6、WebRTC、検査サイト自身の判定方式が影響している可能性があります。別のブラウザー、プライベートウィンドウ、別のネットワークで再現性を確認してください。どの環境でもVPN接続前の公開IPが見えるなら、クライアントの接続状態やルーティングに問題がある可能性が高くなります。

状況 優先して確認すること 次の対応
公開IPが変わらない VPN接続、対象アプリ、ルーティング 接続を再確立し、別の回線や公式クライアントで比較する
DNSだけ本来の事業者になる OS、IPv6、ルーター、VPNのDNS処理 DNS保護設定とトンネル内処理の説明を確認する
WebRTCだけ情報が残る ブラウザー、拡張機能、WebRTC対応 必要性を判断し、ブラウザー設定を見直す
端末によって結果が違う OSのVPNプロファイルとクライアント設定 端末ごとに同じ条件で検査し、設定を個別に調整する

よくある質問

VPN接続後にDNS事業者名が表示されても問題ですか?

事業者名だけでは判断できません。VPNトンネル内から外部DNSを利用する構成もあります。VPN接続前のDNSと比較し、VPNクライアントの説明、IPv4とIPv6の結果、複数の検査結果を合わせて確認してください。

WebRTCを無効にすればVPNは不要ですか?

不要にはなりません。WebRTC対策はブラウザーが示す接続候補を制限するための設定です。通常のWeb通信、DNS、他のアプリの通信経路を保護するものではありません。VPNの接続範囲とWebRTCの設定は別に考えます。

スマートフォンでDNSリークを防ぐにはどうすればよいですか?

VPNプロファイル、常時接続、VPN未接続時の通信ブロック、プライベートDNSやPrivate Relayなどの関連機能を確認します。設定を変更した後は、Wi-Fiとモバイルデータ通信の両方で再検査し、利用するアプリの通信も意図した経路になっているか確認してください。

検査結果が毎回少し違うのは異常ですか?

DNS事業者、検査サイト、IPv6の有無、ブラウザーの候補収集によって表示が変わることがあります。VPN接続前後で同じ条件を使い、公開IP、DNS、WebRTCを分けて比較してください。再現しない一時的な表示だけで結論を出す必要はありません。

最終確認:

VPNの安全性は、サービス名や一つの検査結果だけで決まりません。公開IP、DNS、WebRTC、IPv6、端末ごとの通信範囲を順に確認し、必要な対策だけを適用するのが現実的な見直し方です。