VPNは安全？DNSリークの確認方法とプライバシー対策

VPNは通信経路を保護するための便利な仕組みですが、接続ボタンが有効になっただけで、すべての通信が自動的に安全になるわけではありません。特に見落とされやすいのがDNSリークとWebRTCリークです。VPNのトンネルを使っているつもりでも、ドメイン名の問い合わせやブラウザーのリアルタイム通信が通常のネットワークから外へ出ていると、接続先や実際のIPアドレスに関する情報が第三者へ伝わる可能性があります。

本記事では、VPNが担う範囲と担わない範囲を整理したうえで、DNS、公開IP、WebRTCの状態を自分で確認する手順を説明します。Windows、macOS、Android、iOS、Linuxの公式クライアントだけでなく、Clash Verge、sing-box、Shadowrocketなどの互換クライアントを使う場合にも応用できるよう、設定を確認するときの考え方を中心にまとめます。

VPNの安全性を判断する基本

VPNの安全性を考えるときは、暗号化、接続経路、ログ、端末上の設定を別々に確認します。暗号化は、端末からVPNノードまでの通信内容を途中で読まれにくくする働きです。しかし、接続先のWebサイトに自分で入力した情報を保護するものではなく、偽サイトへの入力や悪意のあるファイルの実行を防ぐ機能でもありません。VPNを有効にしているからといって、すべてのWebページを無条件に信頼してよいわけではありません。

プロトコルにも役割の違いがあります。WireGuardは比較的シンプルな構成で高速な再接続を行いやすく、Shadowsocksは暗号化されたプロキシ方式として利用されます。VMess、Trojan、Hysteria2などは、それぞれ異なる認証、伝送、接続維持の仕組みを持ちます。ただし、プロトコル名だけで安全性や速度を決めることはできません。クライアントの実装、サーバー側の設定、DNSの処理方法、ルール分岐が結果に影響します。

ログについても、「ログがない」という短い説明だけで判断せず、どの種類の情報を保存するのかを確認しましょう。接続時刻、利用量、障害調査用の情報、アクセス先の記録は意味が異なります。サービスのプライバシーポリシーや利用規約で、保存期間、第三者への提供、問い合わせ時の確認方法を確認しておくと、サービス選びの基準を作りやすくなります。

DNSリークが起きる仕組み

DNSは、入力したドメイン名を接続先のIPアドレスへ変換する仕組みです。通常のインターネット接続では、OSやルーターが指定したDNSリゾルバーへ問い合わせます。VPNを接続すると、VPNクライアントが用意したDNSやトンネル経由のDNSを使う構成が一般的ですが、OSの設定が残っていたり、クライアントがDNSを完全に引き継げなかったりすると、問い合わせだけが通常の回線から送信されることがあります。これがDNSリークです。

DNSリークでは、Webページの本文がそのまま見られるとは限りません。しかし、どのドメインを調べたかという情報が、利用しているネットワーク事業者やDNSサービス側に残る可能性があります。VPNの公開IPは海外ノードになっているのに、DNSテストでは自宅回線や通信事業者のDNSが表示される場合、経路が一部分だけ分離していると考えられます。

原因は一つではありません。VPN接続前に設定されたカスタムDNS、IPv六のDNS、ブラウザーのSecure DNS、OSの名前解決キャッシュ、分割トンネル、ルールモードのDIRECT指定などが関係します。Clash Vergeやsing-boxでは、プロキシ経由の通信とDIRECT通信を細かく分けられるため、意図した例外設定がDNS問い合わせにも影響することがあります。Shadowrocketでも、グローバル、ルール、プロキシの選択によって挙動が変わります。

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

テストを始める前に、普段使っているVPNクライアントを一度終了し、現在の公開IPとDNSサーバーを確認します。これは比較用の状態です。その後、公式クライアントまたは互換クライアントからVPNを接続し、同じブラウザーでIP確認ページとDNSリークテストを開きます。テストサイトは、VPNサービスの公式ページや信頼できるネットワーク診断サイトを選び、サブスクリプションURLを入力するよう求めるページは使わないでください。

1. VPN接続前に、公開IP、表示地域、DNSサーバーの名称を控えます。スクリーンショットを保存する場合は、アカウント情報やサブスクリプションURLが写り込まないようにします。
2. VPNクライアントを公式の入手元から起動し、利用するノードを選択します。接続後、クライアントに保護状態やTUN状態が表示されているか確認します。
3. 同じブラウザーで公開IPを調べます。VPN接続前と同じIPが表示される場合は、クライアントが実際には接続していない、またはブラウザーの通信が対象外になっている可能性があります。
4. DNSリークテストを実行し、表示されたDNSサーバーの事業者や地域を確認します。VPNノードとは無関係な自宅回線のDNSが出ている場合は、DNSリークを疑います。
5. VPNを切断し、ブラウザーを再起動してから再度テストします。結果が更新されないときは、DNSキャッシュやブラウザーのSecure DNSが古い結果を保持している可能性があります。
6. 別のノード、別のネットワーク、別のブラウザーでも同じ確認を行います。一つのテスト結果だけで断定せず、環境を変えて再現するかを見ます。

VPN接続中にDNSリークが確認された場合は、まずクライアントのDNS設定を確認します。「リモートDNSを使用」「DNSをVPN経由にする」「DNS保護」などの項目があれば有効にします。ただし、設定名や対応状況はクライアントによって異なります。OS側で指定したDNSを優先する設定、ブラウザー独自のSecure DNS、ルールモードのDIRECT指定が残っていないかも確認してください。

変更後は、VPNを切断してから再接続し、ブラウザーも再起動します。必要に応じてOSのDNSキャッシュをクリアします。設定を変更しても結果が変わらないときは、IPv六を含む名前解決、TUNの実装、分割トンネルの対象外アプリを調べます。原因が分からないまま複数のVPNアプリを同時に有効にすると、仮想ネットワークアダプターとDNSルートが競合し、診断がさらに難しくなります。

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

WebRTCは、ブラウザーで音声通話、ビデオ通話、画面共有などを実現するための通信技術です。接続相手との経路を確立するため、ブラウザーがネットワークインターフェースや接続候補を扱うことがあります。その実装やブラウザーの設定によっては、VPNで隠したいローカルアドレスや実際の接続情報がページ側のスクリプトから推測される場合があります。

WebRTCの確認では、VPN接続前と接続後に同じWebRTCテストページを開きます。VPN接続後も、VPN接続前の公開IPや不要なローカルアドレスが表示される場合は、ブラウザーがVPNの想定外の経路を使っている可能性があります。ただし、表示される候補には、ローカルネットワークのプライベートアドレス、VPN側のアドレス、マスクされた値などが含まれることがあります。表示内容を意味が分からないまま危険と断定せず、テストページの説明とブラウザーの仕様を確認してください。

対策としては、まずブラウザーとVPNクライアントを最新版に更新し、不要なWebRTC権限や拡張機能を見直します。ブラウザーによっては、プライバシー設定でWebRTCが扱うネットワーク候補を制限できます。企業や学校のビデオ会議を利用する場合、WebRTCを完全に無効にすると通話機能が動かなくなることがあるため、必要なサイトだけを例外にする方法が現実的です。ブラウザー拡張機能を追加する場合も、権限、公開元、更新履歴を確認し、正体の分からない拡張機能は避けます。

• ✅ VPN接続前後で公開IPとWebRTCの表示を比較する。
• ✅ ブラウザーのSecure DNS、WebRTC、プロキシ設定を個別に確認する。
• ✅ ビデオ会議など必要な機能を試したうえで、制限の影響を判断する。
• ✅ ブラウザー拡張機能は権限と公開元を確認してから導入する。
• ❌ WebRTCテストのために、見知らぬページへアカウント情報やサブスクリプションURLを入力しない。

クライアント設定とルール分岐を見直す

公式クライアントでは、VPNモード、システムプロキシ、TUNモード、DNS保護、分割トンネルなどの項目を確認します。システムプロキシは、プロキシ設定に従うアプリの通信を切り替える方式です。一方、TUNモードは仮想ネットワークインターフェースを作り、より多くのアプリ通信を引き受ける方式です。どちらが適切かはOSとアプリによって異なり、TUNを有効にすればすべての通信が必ず同じ経路になるという意味ではありません。

Clash Vergeやsing-boxを使う場合は、ルールの順番が重要です。特定のドメイン、IP、プロセスをDIRECTにする規則が上位にあると、その通信はVPNを通りません。DNSのフェイクIP、リモートDNS、直列または並列の名前解決などの設定も、プロキシ通信と整合している必要があります。設定を変更する前に現在のプロファイルを保存し、変更後は対象アプリを完全に終了して再起動します。

Shadowrocketでは、グローバルモードで全体の挙動を確認した後、必要に応じてルールモードへ戻すと切り分けやすくなります。iOSのアプリ通信は、アプリごとのVPN設定やオンデマンド接続の状態にも影響されます。Androidでは、常時接続VPN、VPN以外の接続をブロックする設定、バッテリー最適化によるバックグラウンド停止を確認します。Windows、macOS、Linuxでは、複数の仮想アダプターや他のプロキシ設定が残っていないかを確認してください。

公衆Wi-Fiでのプライバシー対策

空港、ホテル、カフェ、学校などの公衆Wi-Fiでは、接続先の正当性を確認することが重要です。ネットワーク名が本物に似ていても、設置者が不明なアクセスポイントである可能性があります。接続直後に表示される認証ページで、必要以上の個人情報やサービスのアカウントパスワードを求められた場合は入力を止めます。VPNは偽アクセスポイントそのものを本物に変えるものではありません。

公衆Wi-Fiへ接続する前に、端末の共有機能、ファイル共有、近距離通信、不要な自動接続を見直します。VPNを接続した後も、公開IP、DNS、必要なアプリの経路を確認してから重要な操作を行います。銀行、業務システム、メールなどへログインするときは、アドレスバーのドメイン、証明書警告、二段階認証の通知を確認してください。VPN接続中に証明書エラーが出た場合、警告を無視して進むのではなく、ネットワークを切り替えて原因を調べます。

サブスクリプションURLは、クライアントへ設定を取り込むための認証情報として扱います。公衆Wi-Fi上でURLを第三者の変換サイトへ貼り付けたり、QRコードを公開画面に表示したりしないでください。公式クライアントや対応クライアントへ直接取り込み、不要になった端末や古い設定は削除します。異常が疑われる場合は、サービスの正式なパネルでURLの更新や無効化が可能かを確認します。

漏えいが疑われるときの切り分け

テストで問題が見つかったときは、すぐに複雑な設定を追加するより、構成を単純化して原因を絞り込みます。まず他のVPNアプリ、OSのプロキシ、ブラウザーの拡張機能を一時的に整理し、公式クライアントの標準設定で接続します。次に、公開IP、DNS、WebRTCを順に確認します。標準設定では問題がなく、ルールモードでだけリークするなら、プロファイルのDIRECT規則やDNS分岐が原因である可能性が高まります。

VPNを接続しても公開IPが変わらない場合は、接続失敗、ブラウザーの独自プロキシ、対象外アプリ、キャッシュを確認します。公開IPは変わるのにDNSだけ元の回線になる場合は、DNS保護、IPv六、Secure DNS、ルーター設定を見直します。DNSが改善してもWebRTCに実IPが表示される場合は、ブラウザーのWebRTC設定や拡張機能を確認します。症状ごとに一つの設定だけを変更し、そのたびに再テストすることが大切です。

• ✅ VPN接続前後の公開IP、DNS、WebRTCを同じ条件で比較する。
• ✅ 公式クライアントの標準設定で再現するか確認する。
• ✅ ルール、TUN、Secure DNS、IPv六を一つずつ切り分ける。
• ✅ 別のWi-Fiやモバイル回線で再テストし、ネットワーク固有の問題を除外する。
• ❌ 複数のVPNやプロキシを同時に起動して、結果だけを見て判断しない。

よくある質問

VPNのプライバシー対策は、接続状態の表示だけで完了するものではありません。公開IP、DNS、WebRTC、アプリごとの経路を確認し、クライアントの入手元とサブスクリプション情報も安全に管理する必要があります。公式クライアントを使う場合は、対応する設定手順を見ることができ、料金や返金条件を確認したい場合は料金を確認できます。テスト結果に不安があるときは、一度に多くの設定を変えず、標準設定から段階的に切り分けるのが最も確実です。