VPNを接続したのに、すべての通信が自動的に安全になるとは限りません。VPNは端末からVPNサーバーまでの通信経路を保護しますが、DNS名前解決、ブラウザーのWebRTC、IPv6、分割ルーティング、ブラウザー独自の暗号化DNS設定が別の経路を使うと、接続先を推測できる情報が外部へ露出することがあります。そこで重要になるのが、VPNの接続状態だけでなく、実際にどのDNSサーバーと出口アドレスが使われているかを確認することです。

本記事では、DNSリークが起こる仕組み、WebRTCによる情報露出との違い、無料のチェックサイトを使った確認手順、Windows・macOS・Android・iOS・Linuxや互換クライアントで見直すべき設定を整理します。チェック結果が期待と違っても、すぐにVPN全体が壊れていると判断する必要はありません。VPNの方式、クライアントのモード、ブラウザーの設定、OSのネットワーク構成を分けて調べると、原因を絞り込みやすくなります。

DNS
名前解決の経路を確認
WebRTC
ブラウザーの候補アドレスを確認
IPv6
別経路の有無を確認

DNSリークとは何か

DNSは、ドメイン名をIPアドレスへ変換する仕組みです。ブラウザーでサイトを開くとき、端末はまずDNSリゾルバーへ問い合わせ、そのドメインに対応する接続先を受け取ります。VPNが正常に動作していれば、通常はVPNクライアントが指定したDNS、またはVPNトンネル側のDNSを使うことが期待されます。

DNSリークは、VPN接続中にもかかわらず、DNS問い合わせの一部または全部が元のインターネット回線、家庭用ルーター、通信事業者のDNSへ送られる状態です。Webページの本文がVPN経由であっても、名前解決だけが別経路になることがあります。そのため、外部のDNS運用者から問い合わせ先のドメインを観測される可能性があります。DNS問い合わせは、必ずしもページの内容やアカウント情報を直接示すものではありませんが、利用先の傾向を推測する材料になり得ます。

「VPN」アイコンが表示されていることだけでは、DNSの経路までは判断できません。システムVPNが作成されていても、クライアントのルーティングモードが一部アプリだけを対象にしていたり、ブラウザーが独自のDNS over HTTPSを使っていたりすると、想定した結果にならない場合があります。DNSリークを確認するときは、IPアドレスの確認とDNSサーバーの確認を別々に行いましょう。

DNSリークが起こる主な原因

原因の一つは、VPNクライアントがDNSをトンネルへ強制していないことです。システムのDNS設定をそのまま利用するクライアントや、プロキシモードではブラウザーの通信だけを処理してDNSをOSに任せる構成では、VPN接続後も元のDNSが残ることがあります。TUNや仮想ネットワークインターフェースを使うモードは、より広い通信を処理できますが、DNSルールが正しく設定されているとは限りません。

次に、分割ルーティングの設定があります。ローカルサービスを直接接続にするルールは便利ですが、DNSも直接経路へ送る設定になっていると、対象ドメインの問い合わせだけがVPN外へ出る場合があります。逆に、国内向けと海外向けでDNSを分ける設定では、どのドメインをどのリゾルバーへ送るかを明確に理解しておく必要があります。

IPv6も見落とされやすい要素です。VPNクライアントがIPv4のトンネルだけを作り、端末やルーターがIPv6を有効にしたままだと、IPv6通信が別経路へ流れる可能性があります。チェックサイトにIPv6アドレスが表示され、VPN側がIPv6を処理していない場合は、クライアントのIPv6対応、システム設定、ネットワーク側の提供状況を確認してください。

また、ブラウザーのDNS over HTTPSは、OSやVPNクライアントのDNS設定とは別に動作します。これは通信事業者などからDNS内容を見られにくくするための機能ですが、VPNのDNSポリシーを迂回することがあります。プライバシー保護の観点だけで常に有効にするのではなく、VPNクライアントが想定しているDNS処理と整合するかを確認することが大切です。

WebRTCリークとIPアドレス露出の違い

WebRTCは、ブラウザーで音声通話、ビデオ会議、画面共有などを実現する技術です。接続相手と通信経路を確立するため、ブラウザーはICE候補と呼ばれる接続候補を取得します。この過程で、VPNの出口アドレスとは別に、端末が利用しているアドレスやローカルネットワークに関する情報が表示されることがあります。

WebRTCの結果にアドレスが表示されたからといって、必ずしもVPNの暗号化トンネルが破られたという意味ではありません。WebRTCの候補収集と通常のウェブ通信は異なる仕組みで動作します。ただし、ブラウザーやクライアントの構成によっては、利用者のネットワーク環境を推測できる情報が表示されるため、プライバシーを重視する場合は確認対象に含めるべきです。

ブラウザーの設定では、WebRTCのローカル候補を隠す機能、プライバシー拡張、サイトごとのカメラ・マイク権限を確認します。未知の拡張機能を無制限に追加するのではなく、提供元、更新状況、権限の範囲を確認してください。ビデオ会議やブラウザー通話を使う場合、WebRTCを全面的に無効にすると必要な機能まで動かなくなる可能性があります。用途に応じて、候補アドレスの公開範囲を抑える設定を選びましょう。

無料サイトでDNSリークを調べる手順

チェックを始める前に、他のVPNクライアント、システムプロキシ、ネットワークフィルターを一時的に停止し、普段使うネットワークへ接続します。ブラウザーのプライベートウィンドウを使うと、古いキャッシュや拡張機能の影響を減らせます。まずVPNを切った状態でIP、DNS、WebRTCの結果を確認し、その後VPNへ接続して同じ条件で再確認します。比較の前後でブラウザー、端末、接続先を変えないことが重要です。

  1. VPNを切断し、IPアドレス確認サイトを開いて現在の出口情報を記録します。
  2. DNSリークチェックサイトで標準テストを実行し、表示されたDNSサーバーの事業者や地域を確認します。
  3. WebRTCリークチェックサイトを開き、ローカル候補とパブリック候補の表示を確認します。
  4. VPNクライアントでサブスクリプションを更新し、近い入口または別の回線へ接続します。
  5. 同じチェックをもう一度実行し、出口IP、DNSリゾルバー、IPv6、WebRTC候補の変化を比較します。

VPN接続後も元の通信事業者のDNSが表示される場合は、DNSリークの可能性があります。ただし、チェックサイトが表示する運用者名や地域はデータベースに基づくため、実際の物理位置と完全に一致するとは限りません。単一サイトの結果だけで断定せず、別のDNSチェックサイト、クライアントのログ、OSのDNS設定を照合してください。

DNSサーバーがVPN事業者または設定したリゾルバーとして表示され、通常の出口IPもVPN側に変わっているなら、基本的な経路は想定に近いと考えられます。それでもWebRTCに元のアドレスが表示される場合は、DNSの問題ではなくブラウザーの候補収集を個別に見直します。結果のスクリーンショットを公開すると、IPやネットワーク情報が漏れることがあるため、問い合わせ時も不要な情報を隠してください。

確認の要点：切断時と接続時を同じ条件で比較し、IP、DNS、WebRTC、IPv6を別々の項目として記録すると、原因を誤認しにくくなります。

VPNクライアントとOSの設定を見直す

まずクライアント内のDNSモードを確認します。名称はクライアントによって異なりますが、リモートDNS、トンネルDNS、仮想DNS、Fake-IP、ルールベースDNSなどの項目が使われます。大切なのは名称ではなく、DNS問い合わせがどのインターフェースから送られ、どのルールで処理されるかです。設定を変更した後は、クライアントを再接続し、ブラウザーのDNSキャッシュも必要に応じて消去します。

Clash Vergeやsing-boxなどのルール型クライアントでは、DNS設定、proxyモード、TUNモード、ルールの順番を確認します。Shadowrocketでは、グローバル、ルール、ダイレクトなどのモードとDNS関連設定が結果に影響します。どのクライアントでも、サブスクリプションを追加できたことと、全アプリのDNSがトンネルを通ることは同じではありません。公式クライアントでも、分割ルーティングを有効にしている場合は除外アプリや除外ドメインを確認してください。

Windowsでは、使用中のネットワークアダプターに手動DNSが設定されていないか、追加の仮想アダプターが残っていないかを調べます。macOSでは、Wi-Fiや有線接続のDNSサーバー、ネットワーク拡張、他のフィルターアプリを確認します。AndroidとiOSでは、システムのプライベートDNS、構成プロファイル、他のVPN、アプリごとのVPN設定が競合していないかを見直します。Linuxでは、NetworkManager、systemd-resolved、resolv.conf、TUNインターフェースの関係を確認し、複数のサービスがDNSを同時に管理していない状態にします。

キルスイッチ、常時接続VPN、VPN以外の接続を遮断する設定は、VPNが切断したときの漏れを抑えるのに役立ちます。ただし、OSやクライアントによって対象範囲が異なります。キルスイッチを有効にした後は、VPNを意図的に切断して通信が停止するかを確認し、必要なローカルサービスまで遮断される場合は例外ルールを調整します。設定変更を一度に複数行うと原因が分からなくなるため、DNS、IPv6、WebRTC、キルスイッチの順に個別検証する方法が安全です。

暗号化DNSとブラウザー設定の整合性

DoHやDoTはDNS問い合わせを暗号化して送る技術です。VPNと併用する場合、ブラウザーが選んだリゾルバーへ直接接続するのか、VPNトンネルを通してそのリゾルバーへ接続するのかを確認してください。ブラウザーのセキュアDNSを有効にした結果、クライアントが想定するドメインルールを通らなくなる構成もあります。逆に、VPNクライアントが安全なDNS処理を提供している場合、ブラウザー側の設定を重ねる必要がないこともあります。

設定を見直した後は、ブラウザーを完全に終了して再起動し、DNSチェックを再実行します。チェック結果が変わらない場合は、ブラウザーだけでなく、OSの名前解決キャッシュ、ルーター、クライアントコアのログも確認します。企業ネットワークや学校ネットワークでは管理ポリシーによって設定変更が制限される場合があるため、無断でポリシーを回避せず、管理者の指示に従ってください。

日常利用でプライバシーを守る確認リスト

DNSリーク対策は、一度チェックして終わりではありません。VPNクライアントの更新、サブスクリプションの変更、OSアップデート、ブラウザー設定のリセット、ネットワーク切り替えによって挙動が変わることがあります。特に自宅Wi-Fiから公衆Wi-Fi、モバイル回線、職場ネットワークへ移動した後は、VPNが再接続していてもDNSやIPv6の扱いが変わっていないか確認しましょう。

TnVPNではWindows、macOS、iOS、Android、Linuxに対応し、公式クライアントへサブスクリプションをインポートして利用できます。Clash Verge、sing-box、Shadowrocketなどの互換クライアントを使う場合は、クライアントごとのDNSモードとルーティング範囲を確認してください。90+か国、200+回線から選べる場合でも、回線を頻繁に変更すること自体がプライバシーを高めるわけではありません。用途に合う設定を固定し、変更後に検証することが大切です。

最終結論：VPNの安全性は接続ボタンだけで決まりません。DNSをトンネルへ通し、WebRTCとIPv6の挙動を確認し、キルスイッチと分割ルーティングを用途に合わせて設定して初めて、実際のプライバシー状態を把握できます。

よくある質問

VPN接続中に自宅のDNSが表示されたら、すぐ解約すべきですか？
まず、VPN接続前後の条件、ブラウザーのセキュアDNS、IPv6、分割ルーティングを確認してください。チェックサイトの判定データが古い可能性もあるため、複数の確認方法を照合します。クライアントのDNSモードをトンネル側へ変更しても改善しない場合は、公式サポートへ結果を伝えて対応範囲を確認しましょう。
WebRTCでローカルIPが見えるのは危険ですか？
ローカルIPは家庭内や社内ネットワークの構成を推測する材料になりますが、それだけでVPNトンネルが破られたことを意味しません。利用しないブラウザーのWebRTC候補公開を制限し、カメラやマイクのサイト権限も見直してください。Web会議を使う場合は、機能を壊さない範囲で設定します。
DoHを有効にすればDNSリークはなくなりますか？
DoHはDNS問い合わせを暗号化しますが、問い合わせ先がVPNトンネルの外側になる構成もあります。暗号化されていることと、VPNが想定する経路を通ることは別です。ブラウザー、OS、VPNクライアントのDNS設定が重複していないか確認してください。
チェックサイトで問題が出たとき、最初に何を確認すべきですか？
他のVPNやプロキシを停止し、クライアントの接続先、DNSモード、TUNまたはシステムVPNの状態を確認します。その後、IPv6、ブラウザーのDoH、WebRTC、分割ルーティングを一項目ずつ見直し、変更のたびに同じチェックを繰り返してください。
TnVPN

接続経路を確認して使う

90+か国、200+回線に対応し、Windows、macOS、iOS、Android、Linuxで利用できます。接続後はDNSと出口情報を自分で確認できます。

無料で始める