VPNは接続ボタンを押せば、すべての通信が自動的に安全になるわけではありません。VPNトンネルが確立していても、DNS問い合わせだけが通常の回線へ送られたり、ブラウザーのWebRTC機能から別のIPアドレスが見えたりすることがあります。このような状態はDNSリーク、WebRTCリークとして扱われます。

本記事では、VPN接続後にどの情報が外部へ見える可能性があるのか、ブラウザーとアプリでどのように確認するのかを順番に説明します。Windows、macOS、Android、iOS、Linuxの公式クライアントだけでなく、Clash Verge、sing-box、Shadowrocketのような互換クライアントを使う場合にも応用できる内容です。速度だけで判断せず、DNS、IPv6、ルール分岐、キルスイッチまで確認することが、公共Wi-Fiでのプライバシー対策につながります。

DNSリークとは何か

DNSは、ドメイン名をIPアドレスへ変換する仕組みです。ブラウザーでウェブサイトを開くと、端末または設定されたDNSリゾルバーへ「このドメインはどのIPアドレスか」という問い合わせが送られます。VPN接続中は、通常この問い合わせもVPNトンネルを通るか、VPN側が指定したDNSサーバーへ送られることが望まれます。

しかし、OSのネットワーク設定、ブラウザーのセキュアDNS、IPv6経路、アプリ独自の名前解決処理などが原因で、DNS問い合わせだけが通常のWi-Fiや携帯回線へ出ることがあります。ウェブページ自体はVPNの出口IPからアクセスしていても、DNSの問い合わせ先から利用地域や通信先の傾向を推測される可能性があります。

DNS

ドメイン名の名前解決

WebRTC

ブラウザーの接続機能

IPv6

別経路になる可能性

VPN

通信経路の保護

DNSリークは、VPNプロトコルそのものの優劣だけで決まる問題ではありません。WireGuard、OpenVPN、IKEv2、Shadowsocks、VMess、Trojan、Hysteria2など、どの方式を使っていても、端末側のDNS設定やクライアントのルールが適切でなければ名前解決が別経路になることがあります。プロトコル名だけを見て安全だと判断しないことが大切です。

確認前にそろえる条件

リークを調べる前に、VPNを切断した状態と接続した状態の両方で同じ検査を行えるようにします。使用するネットワーク、ブラウザー、開いているタブをできるだけそろえ、結果を記録してください。VPN接続前の結果がないと、どのDNSサーバーやIPアドレスが変化したのかを比較しにくくなります。

最初にVPNクライアントの接続ログを確認します。接続先のノード、トンネルの状態、DNS保護、キルスイッチ、IPv6処理の項目が表示されていれば、設定内容を控えておきます。Clash VergeではDNS設定とルールによる分流、sing-boxではDNSサーバー、ルール、ルート設定、ShadowrocketではDNS、プロキシ、ルールの関係を確認します。名称や配置はバージョンにより異なるため、表示される説明文も読んでください。

DNSリークを確認する手順

まず、ブラウザーで「DNS leak test」などの検査サービスを開きます。サービスの利用規約とプライバシーポリシーを確認したうえで、標準検査または拡張検査を実行してください。検査ページに表示されるDNSサーバーの国、組織、IPアドレスを確認し、VPN接続前の結果と比較します。

  1. VPNを切断し、現在のWi-Fiまたはモバイル回線で検査を実行します。
  2. 検査ページを閉じずにVPNへ接続し、必要に応じてページを再読み込みします。
  3. 表示された出口IPがVPN接続時のものに変わっているか確認します。
  4. DNSサーバーが通常の回線事業者のものではなく、VPN設定で想定した経路になっているか確認します。
  5. VPNを切断してから再検査し、表示結果が元のネットワークへ戻るかを確認します。

VPN接続後も、接続前と同じインターネットサービスプロバイダーのDNSサーバーが表示される場合は、DNSリークの可能性があります。ただし、VPN事業者が外部のDNSサービスを利用している場合、表示される組織名がサービス名と一致しないこともあります。判定は名前だけでなく、クライアントのDNS設定、接続ログ、検査結果を組み合わせて行ってください。

検査項目 確認する内容 注意すべき状態
出口IP ウェブサイトから見える送信元IP VPN接続前と同じIPが表示される
DNSサーバー ドメイン名を解決したサーバーの情報 通常回線の事業者や自宅ルーターが表示される
IPv6 IPv6アドレスと経路の有無 VPNがIPv6を処理しないまま別経路で通信する
接続状態 VPNクライアントのトンネルとログ 接続済みでもDNS保護やルールが無効になっている
判断のポイント:出口IPが変わったことと、DNS問い合わせが保護されたことは別の確認項目です。必ず両方を検査してください。

WebRTCリークを確認する方法

WebRTCは、ブラウザー上で音声通話、ビデオ通話、ファイル共有などを実現するための通信機能です。接続相手を見つける過程で、ブラウザーがローカルネットワークの候補や通信に使えるアドレス情報を取得することがあります。VPNの設定やブラウザーの実装によっては、通常のウェブアクセスとは異なる情報が検査ページに表示されます。

WebRTC検査に対応したプライバシー診断ページを開き、VPN接続前後で表示される候補アドレスを比較します。VPN接続後に、通常回線のグローバルIPや、意図していないネットワークの候補が表示される場合は、ブラウザーのWebRTC設定を見直してください。ローカルIPが表示されることだけで直ちに重大な漏えいと断定するのではなく、公開IP、VPN出口IP、ローカル候補を分けて確認します。

Chromium系ブラウザーでは、WebRTCのIP処理を制限する拡張機能やプライバシー設定が提供される場合があります。FirefoxではWebRTC関連の保護設定を確認できますが、設定名や挙動はバージョンによって変わります。拡張機能を追加する場合は、開発元、権限、更新状況を確認し、不要になったものは削除してください。ブラウザーの保護設定を変更した後は、音声会議やブラウザー通話が正常に動作するかも確認が必要です。

DNSリークが見つかったときの直し方

最初にVPNクライアントのDNS保護機能を有効にします。「VPN経由のDNS」「DNSリーク防止」「トンネル内DNS」「ルーティングされたDNS」など、アプリによって表記は異なります。設定を変更したら、VPNを完全に切断して再接続し、DNS検査を繰り返します。接続中に設定だけを変えて結果が変わらない場合は、アプリや端末を再起動すると切り分けやすくなります。

次に、OS側の手動DNS設定を確認します。自宅ルーターや公共Wi-FiのDNSを固定している場合、VPNクライアントの設定と競合することがあります。ブラウザーのセキュアDNS、AndroidのプライベートDNS、macOSやLinuxのネットワークサービス設定も確認してください。特にブラウザーが独自のDNS over HTTPSを使う構成では、VPNトンネル内のDNS制御を迂回する場合があります。プライバシーと接続性を比較し、どの層で名前解決を行うかを一つに整理してください。

IPv6を利用している場合は、VPNクライアントがIPv6トラフィックとIPv6 DNSを処理できるか確認します。対応が不明なままIPv6だけ別経路へ流れると、IPv4の検査では問題が見えないことがあります。IPv6を一時的に無効にする方法もありますが、これは根本的な解決とは限りません。VPN側がIPv6に対応している場合は、その設定を優先し、無効化する場合は端末やネットワークの必要な機能が失われないか確認します。

クライアント別に見るべき設定

公式クライアントでは、VPN接続、DNS保護、キルスイッチ、ネットワーク切り替え時の再接続が一つの画面にまとめられていることがあります。WindowsとmacOSでは、スリープ復帰後やWi-Fi切り替え後にトンネルが再確立されるかを確認してください。Androidでは省電力設定がVPNアプリのバックグラウンド動作を制限することがあります。iOSではVPN構成の許可、オンデマンド接続、アプリを切り替えた後の状態を確認します。LinuxではNetworkManager、systemd-resolved、使用中のデスクトップ環境がDNSを管理している場合があるため、設定元を特定してください。

Clash Vergeなどのルール型クライアントでは、プロキシ対象外にしたドメインのDNS処理がどの経路を使うかを確認します。ルール分岐は便利ですが、DIRECT指定が多すぎると、必要な通信まで通常回線へ送られます。sing-boxではDNSサーバー、DNSルール、最終サーバー、ルート設定の関係を確認し、設定ファイルを一部だけ書き換えないようにします。Shadowrocketでは、グローバル、ルール、ダイレクトのモードを切り替えた後、それぞれで出口IPとDNSを再検査してください。

環境 優先して見る項目 再検査のタイミング
Windows / macOS キルスイッチ、DNS、IPv6、スリープ復帰 Wi-Fi切り替えとスリープ復帰の後
Android 省電力、常時接続VPN、プライベートDNS アプリをバックグラウンドへ移した後
iOS VPN構成、オンデマンド接続、WebRTC Wi-Fiとモバイル通信を切り替えた後
Linux DNS管理サービス、ルート、IPv6 ネットワークサービスを再起動した後
Clash Verge / sing-box / Shadowrocket DNSルール、DIRECT、プロキシモード 設定更新またはモード変更の後

サブスクリプションをClash Verge、sing-box、Shadowrocketなどへ取り込む場合、変換後の設定が元のサービス仕様と一致するとは限りません。DNSの項目が削除されたり、ルールの一部がクライアントで解釈されなかったりすることがあります。取り込みが成功した表示だけで完了とせず、実際の接続ログと検査結果を確認してください。サブスクリプションURLは認証情報を含む場合があるため、コピー、保存、共有の扱いにも注意が必要です。

公共Wi-Fiでの実践的なプライバシー対策

公共Wi-Fiでは、接続前にネットワーク名が正しいか確認し、不要な自動接続を無効にします。VPNを接続する前に、OSやアプリの更新、クラウド同期、ファイル共有が動作していないかを確認すると、意図しない通信を減らせます。VPNが接続済みになるまで、個人情報の入力や重要なアカウントへのログインを急がないことも有効です。

VPN接続後は、出口IP、DNS、WebRTCを確認し、スリープ復帰やネットワーク切り替え後にも同じ検査を行います。キルスイッチがある場合は、VPNが切断された際に通常回線へ通信を継続するのか、通信を停止するのかを理解しておきます。金融機関や社内システムなど、VPN経由を拒否するサービスもあるため、必要なサイトだけをルール分岐する場合は、例外がプライバシー上のリスクにならないか確認してください。

VPNを使っていても、フィッシングサイト、悪意のあるアプリ、弱いパスワード、ブラウザーの保存情報までは自動的に解決されません。HTTPSの証明書警告を無視せず、多要素認証を有効にし、公共端末ではパスワードを保存しないようにします。VPNはネットワーク経路の対策、ブラウザー設定や認証は端末とアカウントの対策として、役割を分けて考えると判断しやすくなります。

一言で結論:公共Wi-Fiでは、VPNの接続表示、DNS検査、WebRTC検査、切断時の挙動を順番に確認し、異常があれば重要な通信を始めないことが安全です。

よくある質問

VPN接続後も自宅のDNSが表示されます。必ずリークですか?

必ずしも断定はできませんが、確認が必要な状態です。VPNクライアントのDNS保護、OSの手動DNS、ブラウザーのセキュアDNS、IPv6経路を確認し、接続前後の結果を比較してください。VPN事業者が外部DNSを利用している場合もあるため、表示名だけでなく接続ログと設定を照合します。

DNS over HTTPSを有効にすればVPNは不要ですか?

DNS over HTTPSはDNS問い合わせを暗号化する仕組みであり、すべての通信の経路や出口IPを変更するものではありません。VPNと同じ役割ではないため、目的に応じて使い分けます。また、ブラウザー独自のDNS処理がVPNのDNSルールと競合することもあります。

WebRTCを無効にすると問題は解決しますか?

WebRTCによる候補アドレスの表示を抑えられる場合はありますが、DNSリークやIPv6リークの解決にはなりません。ブラウザーの通話機能に影響する可能性もあるため、設定変更後に必要なサービスを確認し、DNSと出口IPも別途検査してください。

一度検査して問題がなければ、再確認は不要ですか?

クライアント、OS、ブラウザー、サブスクリプション、ネットワークが変わった場合は再確認してください。特にWi-Fiとモバイル通信の切り替え、スリープ復帰、クライアント更新、ルール変更の後は、DNS、WebRTC、IPv6をもう一度確認するのが安全です。

DNSリーク対策の基本は、VPNを接続することではなく、通信経路を検査して意図した設定と一致させることです。まず出口IPを確認し、次にDNS、WebRTC、IPv6、最後にネットワーク切り替え後の挙動を調べます。設定が複雑なクライアントほど、変更を一度に一つだけ行い、変更前後の結果を記録してください。より詳しいクライアント導入手順は使用ガイドを見るから確認できます。