VPNのDNSリークを確認・対策するプライバシーと安全な使い方

VPNを接続すれば、端末から発生するすべての通信が自動的に同じ経路を通るとは限りません。ウェブサイトのアクセス先はVPN経由でも、ドメイン名をIPアドレスへ変換するDNSリクエストだけが通常の回線へ送られる場合があります。これが一般にDNSリークと呼ばれる状態です。また、ブラウザのWebRTC機能によって、VPN接続中でもローカルネットワークや利用中のアドレス情報が表示されることがあります。

DNSリークは、VPNが暗号化に失敗したという意味と必ずしも同じではありません。クライアントの動作モード、OSのDNS設定、IPv6、分割トンネル、ブラウザの独自DNS設定など、複数の要因が関係します。本記事では、接続前後の確認方法、設定変更の順序、再テストの読み方、無料VPNやログポリシーを確認するときの考え方を整理します。表示された結果だけで過度に不安にならず、どのリクエストがどの経路を通ったのかを切り分けることが重要です。

DNSリークとは何か

DNSは、ブラウザへ入力したドメイン名を、接続先のIPアドレスへ変換する仕組みです。たとえばブラウザがサイトを開く前に、対象ドメインの名前解決をDNSサーバーへ依頼します。VPNのトンネルが正常に確立していても、OSやルーターに設定されたDNSサーバーへこの依頼が直接送信される構成では、アクセス先の名前解決だけがVPNの外側で行われます。この状態がDNSリークです。

通常、VPNクライアントは接続時に仮想ネットワークインターフェースを作成し、DNSの送信先やルーティングを変更します。しかし、接続モードがアプリだけを対象にする設定だったり、クライアントがDNS制御に対応していなかったりすると、ブラウザ以外のDNSリクエストが別経路へ流れる可能性があります。WindowsやmacOSのシステムプロキシ、AndroidやiOSのVPNトンネル、LinuxのNetworkManagerやsystemd-resolvedでは、設定画面と実際の経路が異なることもあります。

DNS ドメイン名をIPアドレスへ変換する問い合わせ

WebRTC ブラウザの通信機能がアドレス情報を取得する仕組み

IPv4 / IPv6 片方だけVPNの経路から外れていないか確認する対象

再テスト設定変更が実際の通信へ反映されたかを確認する手順

DNSリークがあると、DNSサーバーの運営者やネットワーク管理者から、少なくとも名前解決を行ったドメインを把握される可能性があります。一方、DNSテストに普段の回線事業者名が表示されたからといって、すべての通信内容がそのまま読まれているとは限りません。DNS、接続先IP、HTTPSの暗号化、VPNトンネルは別々の要素です。結果を正しく解釈するには、テスト時の接続状態とクライアントのモードを記録しておきます。

要点：DNSリークは「DNS問い合わせがVPNの想定経路から外れている状態」です。VPN接続済みという表示だけでは判断できないため、DNSとWebRTCを別々に確認します。

テスト前に確認する条件

正しい比較をするには、まずVPNを切断した状態でDNSリークテストとWebRTCテストを実行し、その結果を控えます。次に同じ端末、同じブラウザ、できれば同じネットワークでVPNを接続し、同じテストを繰り返します。VPNの接続先を変更した場合も、結果が変わることがあります。テストページを一度開いただけではブラウザやOSのキャッシュが残っている可能性があるため、ページを再読み込みし、必要ならブラウザを再起動します。

テスト前には、複数のVPNアプリやプロキシ拡張機能を同時に有効にしないでください。Clash Verge、sing-box、Shadowrocketなどの互換クライアントと、OS公式クライアントを同時に動かすと、DNS設定や仮想インターフェースが競合することがあります。どのアプリが通信を取得しているのか分からなくなるため、検証時は一つのクライアントだけを使うのが基本です。

✅ VPN切断時のDNSサーバーとWebRTC表示を記録する
✅ VPN接続後に、同じブラウザでテストを再実行する
✅ クライアントの接続モードが全体トンネルか、アプリ別プロキシかを確認する
✅ IPv4とIPv6の両方が有効な環境では、片方だけ外れていないか確認する
❌ 複数のVPNクライアントやブラウザ拡張機能を同時に有効にしない

DNSテストの結果を読む

VPN接続後のテストで、VPNサービスが使用するDNSサーバーや、VPNの出口に対応する地域のサーバーが表示されるなら、想定どおりの可能性があります。複数のDNSサーバーが表示されること自体は直ちに問題ではありません。負荷分散やIPv4・IPv6の併用により、複数の応答先が使われる設計もあります。

反対に、VPN接続前と同じネットワーク事業者のDNSだけが表示される、VPNを別地域へ変更しても常にローカルのDNSが表示される、接続をオンにした直後だけ別の結果になる、といった場合は追加確認が必要です。テストサイトのデータベースが古い場合や、DNSキャッシュが残っている場合もあるため、一つの表示だけで断定しないでください。複数回の結果、クライアントのログ、OSのDNS設定を合わせて判断します。

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

ここでは、特定の製品画面に依存しない確認の流れを紹介します。メニュー名はクライアントによって「DNS保護」「DNSリーク防止」「リモートDNS」「トンネルDNS」など異なります。重要なのは名称ではなく、DNSリクエストをどのインターフェースから、どのサーバーへ送る設定になっているかです。

VPNクライアントを完全に終了、または切断し、ブラウザのテストページを開いて通常時のDNSとWebRTCの結果を保存します。
一つのVPNクライアントだけを起動し、サブスクリプションを更新してから、対応するノードまたは回線を選択します。
システムVPN、トンネルモード、または全体保護に相当する設定を有効にします。システムプロキシだけのモードでは、DNSや対応外アプリが別経路になることがあります。
VPN接続後、OSのネットワーク設定を開き、DNSサーバーが元のWi-Fiルーターや通信事業者のまま固定されていないか確認します。設定を変更する場合は、クライアントの推奨値を優先します。
ブラウザを再起動し、DNSリークテストを再実行します。通常テストだけでなく、追加の名前解決を発生させる詳細テストが用意されている場合は、それも実行します。
WebRTCテストを別に実行し、ローカルアドレス、公開アドレス、VPNの出口に関係する情報がどのように表示されるか確認します。
一度VPNを切断してから再接続し、同じ結果になるか確認します。再接続時だけローカルDNSが表示される場合は、接続直後のDNS切り替えやキルスイッチの動作を調べます。

Linuxでは、systemd-resolvedのスタブリゾルバー、NetworkManager、ブラウザのSecure DNSが異なる設定を持つことがあります。Windowsでは、複数のネットワークアダプターやIPv6の優先順位が影響する場合があります。macOSでは、Wi-Fi、Ethernet、VPNインターフェースのサービス順序を確認します。AndroidやiOSでは、アプリごとのVPNやプライベートDNS、iCloud Private Relayなど、VPNとは別の通信保護機能が結果に影響することがあります。

リーク対策を設定する方法

最初に確認したいのは、クライアントにDNS保護またはVPN経由DNSの項目があるかどうかです。対応している場合は、DNSリクエストをトンネル内へ送る設定を有効にし、接続が切れたときに通常のDNSへ戻す動作も確認します。キルスイッチに相当する機能がある場合は、VPNが切断された際に通信を停止するのか、DNSだけを停止するのかを説明文で確認してください。実装によって保護範囲は異なります。

分割トンネルやルールモードを使う場合は、どのアプリとドメインがVPN対象になるかを確認します。特定のアプリだけをプロキシする設定では、対象外アプリのDNSが通常回線から送信される設計もあります。逆に、すべての通信をトンネルへ送るモードでは、ローカルプリンターや社内サービスへ接続しにくくなる場合があります。プライバシーと利便性のどちらを優先するかを決めてからモードを選びましょう。

IPv6を利用している環境では、VPNがIPv4だけを処理し、IPv6通信が直接インターネットへ出ることがあります。DNSテストの結果にIPv6側の情報が表示される、または接続先確認でIPv6の経路だけ異なる場合は、クライアントがIPv6トンネルに対応しているか確認します。対応状況が不明なままOS側の設定を変更するより、まずクライアントの説明と公式サポート情報を確認する方が安全です。

確認対象	起こりやすい状態	確認・対策の方向
DNS保護	通常回線のDNSが表示される	VPN経由DNS、DNSトンネル、キルスイッチの設定を確認する
分割トンネル	一部のアプリだけ通常経路になる	対象アプリと対象外アプリのルールを見直す
IPv6	IPv4とIPv6で経路や表示結果が異なる	クライアントのIPv6対応を確認し、必要なら安全な無効化方法を調べる
ブラウザDNS	ブラウザ独自のSecure DNSが動作する	VPNのDNS設定とブラウザのDNS設定が競合していないか確認する

実践的な結論：DNSリーク対策は、DNSサーバーの変更だけで終わりません。VPNの取得範囲、IPv6、分割トンネル、ブラウザ独自DNSを一つずつ切り分け、設定変更後に必ず再テストします。

WebRTCリークとの違い

WebRTCは、ブラウザ上で音声通話、ビデオ通話、リアルタイム通信などを実現するための技術です。接続相手との通信経路を確立する過程で、ブラウザがネットワークインターフェースや候補アドレスを取得することがあります。そのため、DNSリークが解消されていても、WebRTCテストではローカルアドレスやVPNとは異なる候補が表示される場合があります。

WebRTCの表示結果は、ブラウザ、OS、ブラウザ設定、サイトの実装によって変わります。すべての候補が外部サイトから同じように利用できるわけではなく、ローカルアドレスが表示されたことと、公開IPが完全に露出したことも同じではありません。ただし、WebRTCを使わない場合はブラウザの権限や設定を見直し、信頼できないサイトにマイクやカメラの許可を与えないことが基本です。ビデオ会議などでWebRTCが必要な場合は、単純に無効化するのではなく、利用するサイトへの権限を限定してください。

✅ DNSテストとWebRTCテストを別々の結果として記録する
✅ ブラウザのマイク、カメラ、ローカルネットワーク権限を確認する
✅ VPNクライアントがWebRTC対策を提供している場合は説明範囲を確認する
❌ DNSが保護されたからWebRTCも自動的に保護されたと判断しない

ログポリシーと無料VPNの選び方

DNSリークを防ぐ設定があっても、VPNサービス自体の運用方針を確認しなければ、プライバシーについて十分に判断できません。サービスを選ぶときは「ログなし」という短い宣伝文句だけでなく、何を保存しないのか、接続時に一時的に扱う情報は何か、保存期間、第三者提供、問い合わせ時の手続き、退会やデータ削除の方法を確認します。ログポリシーが具体的で、利用者が読める言葉で説明されていることが重要です。

無料VPNは、料金が無料である理由を確認してください。広告、利用制限、速度や回線の制限、アプリ内課金など、サービスごとに条件が異なります。無料であることだけを理由に危険と断定する必要はありませんが、運営者情報、アプリの配布元、権限要求、プライバシーポリシー、サブスクリプションURLの扱いを確認できないサービスは避けた方がよいでしょう。特に、連絡先や利用規約が不明なアプリへ、ブラウザ履歴や端末上の通信をまとめて任せることには慎重さが必要です。

VPNは、HTTPSの代わりになるものでも、端末のマルウェア対策を代替するものでもありません。偽サイトへログインすれば認証情報は盗まれる可能性がありますし、VPN事業者がすべての通信内容を閲覧できるという意味でもありません。VPN、HTTPS、ブラウザの権限管理、OSの更新、強固なパスワードと多要素認証を組み合わせ、役割ごとに対策を考えると過不足がありません。

よくある質問

DNSテストに複数のサーバーが表示されたらリークですか？

必ずしもそうではありません。負荷分散、IPv4とIPv6の併用、VPN側のDNS構成によって複数表示になることがあります。VPN接続前の事業者DNSが残っているか、VPN接続先や再接続後も同じ状態かを比較してください。

VPN接続中なのに通常のDNSが表示される場合はどうしますか？

まず、システムVPNまたは全体トンネルが有効か、分割トンネルでブラウザが対象外になっていないか確認します。その後、DNS保護、IPv6、ブラウザ独自DNS、複数クライアントの同時起動を順に確認し、設定変更後にブラウザを再起動して再テストします。

WebRTCの結果がDNSテストと違うのはなぜですか？

DNSは名前解決の経路、WebRTCはブラウザのリアルタイム通信候補を確認する仕組みだからです。両者は別の機能なので、DNSが保護されていてもWebRTCに異なるアドレス候補が出ることがあります。ブラウザの権限とVPNクライアントの対応範囲を確認してください。

DNSを手動で変更すれば十分ですか？

十分とは限りません。手動DNSは送信先を変えるだけで、VPNトンネルの外へ流れる経路やIPv6の問題を解決しない場合があります。クライアントのDNS保護、ルーティング、分割トンネルを確認し、変更後のテスト結果で効果を判断してください。

DNSリークの確認は、特別な知識を一度に身につける作業ではありません。VPN切断時の状態を記録し、一つのクライアントで接続し、DNS、WebRTC、IPv4・IPv6、分割トンネルを順番に確認すれば、原因をかなり整理できます。設定を変更したあとは、必ず同じ条件で再テストし、ログポリシーやアプリの配布元も含めて、自分の利用目的に合う構成を選びましょう。