VPNに接続したあと、検索サイトで表示されるIPアドレスが変わっていれば安心だと思っていませんか。IPアドレスの変更は重要な確認項目ですが、それだけで通信全体のプライバシー状態を判断することはできません。DNS問い合わせがVPNの外へ送られていたり、ブラウザーのWebRTC機能から実際のネットワーク情報が伝わったりすると、接続先のサービスに利用中の回線や地域を推測される可能性があります。

特に公共Wi-Fi、ホテルや空港のネットワーク、管理状態が分からない無料VPNを使う場合は、VPNの接続表示だけを信用せず、DNS、IPアドレス、WebRTCを分けて確認することが大切です。この記事では、DNSリークが起きる仕組み、実際の確認手順、WindowsやmacOS、Android、iOSで見直したい設定、そして確認結果を正しく判断するための考え方を整理します。

DNSリークとは何か

DNSは、ドメイン名をサーバーのIPアドレスへ変換する仕組みです。ブラウザーでウェブサイトを開くとき、端末は最初にDNSリゾルバーへ問い合わせを送り、目的のサーバーを探します。VPNが正常に動作していても、この問い合わせだけが自宅の通信事業者、公共Wi-FiのDNS、またはOSに登録された外部DNSへ送られることがあります。これが一般にDNSリークと呼ばれる状態です。

DNSリークが起きると、アクセスしたページの内容そのものがすべて見られるとは限りません。しかし、どのドメインを調べたか、どのDNSサービスを利用したか、どの地域のネットワークから問い合わせたかを推測される材料になります。HTTPSはウェブページの通信内容を保護しますが、名前解決の経路まで自動的にVPNへ移す機能ではありません。この点を混同しないようにしましょう。

3項目

IP・DNS・WebRTCを確認

5種類

対応プラットフォーム

120+

国の接続先

240+

利用可能な回線

DNSリークの原因は一つではありません。VPNクライアントがDNSをトンネル内へ強制していない、IPv6だけがVPNの対象外になっている、分割トンネルの設定でブラウザーを除外している、ネットワーク切り替え時に古いDNS情報が残っている、といった可能性があります。したがって、テスト結果に一つ見慣れた事業者名が表示されたからといって、すぐにすべての通信が漏れていると決めつけるのも適切ではありません。

確認すべき三つの情報

VPNの状態を確認するときは、同じページを一度開いて終わりにするのではなく、VPN切断時と接続時の結果を比較します。切断時の結果は、現在のネットワークがどの情報を公開しているかを知る基準になります。接続後に出口ノードの情報へ変わり、DNSサーバーもVPN側の構成に沿って変化しているかを確認してください。

確認項目 見る情報 注意したい結果 考えられる対策
公開IP 表示されたIP、国や地域、ネットワーク事業者 自宅回線や携帯回線の情報が残っている VPN接続、出口ノード、ルーティングを確認
DNS 問い合わせを処理したサーバーや事業者 VPNと無関係な通信事業者や公共Wi-FiのDNSが表示される VPNのDNS保護、OSのDNS、IPv6を確認
WebRTC ブラウザーが取得したローカル・公開ネットワーク情報 VPN接続前のアドレスや想定外の候補が表示される ブラウザー設定、拡張機能、WebRTCの扱いを見直す

ここで大切なのは、VPNの出口IPとDNSサーバーの所在地が必ず同じになる必要はないということです。サービスによっては、DNSだけを専用基盤で処理したり、複数地域のDNSを利用したりします。判定では「VPNと同じ国名か」だけでなく、接続中に自分の通信事業者や、利用しているWi-Fiの管理者に紐づくDNSが現れていないかを見ます。

判断の要点 IPアドレスの変更は入口にすぎません。DNSとWebRTCに、VPN接続前のネットワーク情報が残っていないかを組み合わせて判断しましょう。

実際にDNSリークを確認する手順

テストは、普段使うブラウザーで行うと実用的です。まずVPNを切断し、IP確認ページとDNSリーク確認ページを開いて結果を記録します。次にブラウザーのタブを閉じず、VPNクライアントを起動して一つのノードへ接続します。接続表示だけでなく、クライアントが保護状態になっていること、システム全体を対象にしていること、分割トンネルでテストページを除外していないことを確認してください。

  1. VPNを切断した状態で、公開IP、DNS事業者、WebRTCに表示される候補を確認します。
  2. VPNクライアントを起動し、接続モード、DNS保護、IPv6の扱い、分割トンネルの設定を確認します。
  3. 同じブラウザーでページを再読み込みし、公開IPが接続先ノード側へ変わったか確認します。
  4. DNS結果に自宅回線、携帯回線、公共Wi-Fiの事業者が残っていないかを確認します。
  5. WebRTCの結果を確認し、VPN接続前の公開アドレスや想定外のネットワーク情報が表示されていないかを調べます。
  6. VPNを一度切断してから別のネットワークへ切り替え、再接続後に同じ確認を行います。

確認ページによって表示項目や判定方法は異なります。テストの一部が失敗した場合は、ブラウザーのキャッシュだけを削除するのではなく、VPNを切断し、クライアントを終了してから再起動します。それでも変化がなければ、別のブラウザーで比較し、拡張機能やプライベートDNSの影響を切り分けます。

端末別に見直したい設定

Windows・macOS

デスクトップでは、VPNクライアントに「DNSリーク保護」「DNSをVPN経由にする」「キルスイッチ」といった項目があるか確認します。名称はクライアントによって異なります。キルスイッチはVPNが切断されたときに通信を止める機能であり、DNSをVPNへ送る設定とは別のものです。両方が用意されている場合は、それぞれの役割を理解して有効化します。

WindowsではネットワークアダプターごとのDNS設定やIPv6設定が残っていないかを確認します。macOSでは、接続中のネットワークサービスとVPNプロファイルの優先順位が影響することがあります。手動DNSを設定している場合も、VPNクライアントがその設定を上書きするのか、ローカル設定を維持するのかを確認してください。設定を変更したあとは、ブラウザーの再起動と再テストを行います。

Android・iOS

AndroidにはプライベートDNS、iOSには構成プロファイルやネットワーク関連の保護機能があります。これらがVPNクライアントのDNS処理と競合すると、接続は成立しているように見えても、名前解決だけ別経路になる場合があります。まずVPNクライアントの説明を確認し、同じ目的の機能を複数重ねないことが基本です。

モバイル端末では、アプリごとのVPN、バッテリー最適化、バックグラウンド制限も確認します。VPNアプリが停止すると、DNS保護も同時に解除されることがあります。特に画面を消したあとに問題が出る場合は、省電力設定からクライアントを除外し、常時接続や接続遮断の設定が使えるか確認してください。

Linuxと互換クライアント

LinuxではNetworkManager、systemd-resolved、ローカルのDNSキャッシュ、VPNクライアントの設定が複数の層で動作します。GUIクライアントだけでなく、ターミナルから名前解決先を確認すると、どのサービスがDNSを受け持っているかを把握しやすくなります。設定変更後はキャッシュを消去し、VPN接続時と切断時の両方で確認してください。

Clash Verge、sing-box、Shadowrocketなどの互換クライアントを使う場合は、サブスクリプションを導入できたことと、DNSが保護されていることを別々に確認します。プロファイルにはDNSモード、Fake-IP、ルール分流、IPv6、トンネルの対象範囲など複数の項目があります。設定を自分で編集する場合は、まずコピーを保存し、一度に一項目だけ変更すると原因を追いやすくなります。

WebRTCリークとブラウザー側の確認

WebRTCは、ブラウザー上で音声通話、ビデオ通話、画面共有などを実現するための通信技術です。接続相手との経路を確立する過程で、ブラウザーがネットワーク候補を取得することがあります。その結果、VPNのプロキシ設定を通っていないアドレスがテストページに表示される場合があります。これはDNSリークとは別の問題なので、DNSだけ正常でもWebRTCの確認は省略できません。

WebRTCの結果にローカルアドレスが表示されても、それがインターネット上の公開IPとして利用できるとは限りません。プライベートアドレスと公開アドレスを区別し、VPN接続前の通信事業者に紐づく情報が露出しているかを確認します。ブラウザーの設定、プライバシー拡張機能、企業や学校の管理ポリシーによって挙動が変わるため、複数のブラウザーで結果が異なることもあります。

通話や会議サービスを利用する人は、WebRTCを完全に無効にすると機能や音声品質へ影響する可能性があります。必要なサービスが動作するかを確認しながら、ブラウザーの権限、サイトごとの設定、VPNクライアントのWebRTC対策を調整してください。目的はすべての通信を無条件に止めることではなく、許可していない経路からネットワーク情報が出ない状態を作ることです。

公共Wi-Fiと無料VPNで注意すること

公共Wi-Fiでは、同じネットワークに接続する利用者や管理者が通信環境を把握しやすくなります。HTTPSによってウェブ本文が暗号化されていても、DNS処理、接続先、認証画面の偽装、端末への攻撃など、別のリスクが残ります。自動接続を無効にし、接続先のSSIDを確認し、必要な作業が終わったらネットワークを削除するのが基本です。

無料VPNにも注意が必要です。運営主体、ログの扱い、広告や第三者提供の方針、アプリが要求する権限、更新の仕組みを確認できないサービスは避けたほうがよいでしょう。VPNは通信経路の一部を運営者へ集約するため、「無料だから安全」「暗号化と書いてあるから匿名」とは限りません。公式ストアや公式サイトから入手し、提供元が明確で、設定とプライバシー方針を確認できるサービスを選びます。

SQVPNを利用する場合も、公式クライアントや対応する互換クライアントを使い、サブスクリプション情報を第三者へ渡さないことが重要です。Windows、macOS、iOS、Android、Linuxに対応し、同時接続台数に制限がない構成でも、各端末のDNSやブラウザー設定は個別に確認する必要があります。利用可能な接続先は120以上の国と240以上の回線から選べますが、地域名やプロトコル名だけで、すべての環境に同じ結果が出ると考えないでください。

対策後も漏れが続くときの切り分け

設定を変更しても結果が改善しない場合は、まずVPNクライアントがシステム全体を保護しているかを確認します。ブラウザーだけにプロキシを設定していると、別のアプリやOSのDNS問い合わせが対象外になることがあります。次に、分割トンネル、除外アプリ、IPv6、手動DNS、ブラウザー拡張機能を一つずつ確認します。

複数のVPNアプリやプロキシ、広告ブロッカー、セキュリティソフトを同時に動かすと、仮想アダプターやDNS設定が競合することがあります。原因を探すときは、不要なネットワークツールを一時停止し、公式クライアントの標準設定へ戻してからテストします。改善した場合は、機能を一つずつ戻して、どの設定が影響したかを確認してください。

通信の安全性を高めるには、VPNだけに依存しないことも大切です。OSの更新、ブラウザーの保護設定、強固なパスワード、多要素認証、信頼できない証明書警告を無視しない習慣を組み合わせます。VPNは通信経路を保護する手段の一つであり、フィッシングサイトへの入力、マルウェア、アカウントの使い回しまで自動的に防ぐものではありません。

よくある質問

VPN接続後もDNS事業者の名前が表示されます。すぐにリークですか?

表示されたDNS事業者がVPN側の基盤である可能性もあるため、名前だけで断定しません。VPN切断時の結果と比較し、自宅回線や公共Wi-Fiに固有の事業者が接続中にも表示されるか、複数回確認してください。

IPが変わればWebRTCは確認しなくてもよいですか?

いいえ。IPアドレスの経路と、ブラウザーがWebRTCで取得するネットワーク候補は別の仕組みです。IP、DNS、WebRTCをそれぞれ確認し、不要な公開情報が残っていないかを判断します。

プロトコルを変更すればDNSリークは解消しますか?

通常、プロトコル変更だけでは解消しません。DNS保護、OSのDNS、IPv6、ルーティング、分割トンネルの設定を確認する必要があります。変更前の設定を保存し、一度に一項目ずつ検証してください。

公共Wi-Fiでは何を優先すべきですか?

正しいSSIDを確認し、自動接続を避け、VPNのキルスイッチとDNS保護を確認します。認証情報や決済情報を入力する前に、接続先とブラウザーの警告を必ず確認してください。

最終チェック VPNは安全性を高める有効な手段ですが、接続アイコンだけでは不十分です。IP、DNS、WebRTCを比較し、端末ごとの設定と利用ネットワークのリスクを合わせて見直すことで、より確かなプライバシー保護につながります。