Webサイトへの接続元IPが変わっていても、DNSクエリがローカルネットワーク経由で送信されることがあります。ブラウザー、システムの名前解決機能、プロキシコアの3つの経路を確認し、基準値の記録、リモートDNSの設定、TUNの適用範囲、正常な直接接続時の名前解決と意図しない漏えいの見分け方を解説します。ノードに接続できており、DNSの送信先を確認したいPC・Androidユーザー向けです。
1. DNSリークとは：プロキシ経由にするクエリを確認
DNSはドメイン名をIPアドレスに変換しますが、Webサイトへの接続とDNSクエリが同じ経路を通るとは限りません。ブラウザーがプロキシ経由でWebサイトにアクセスする際、ドメイン名をプロキシ側で解決する場合があります。一方、ほかのアプリは先にシステムのDNSを使ってIPアドレスを取得し、その後にプロキシへ接続することがあります。この場合、Webサイトへの接続元は遠隔地でも、ローカルネットワークからアクセス先のドメイン名を確認できる可能性があります。
ここでいう「リーク」は、設定したルーティング方針を基準に判断します。プロキシ経由で名前解決するはずのドメインが、実際にはローカルネットワークや想定外のDNSリゾルバーに送られている場合は、設定を見直す必要があります。LAN内の名前や直接接続するWebサイトをローカルDNSで解決する設定なら、ローカルのリゾルバーが検出されても、設定全体が機能していないとは限りません。
- システムプロキシ：システムのプロキシ設定に従うアプリにのみ適用され、UDP 53番ポートのクエリをすべて自動で捕捉するわけではありません。
- TUNモード：仮想ネットワークインターフェースで通信を取り込みます。DNSも捕捉されるかどうかは、DNSのリダイレクト、ルーティング、インターフェースの除外設定、IPv6の設定にも左右されます。
- ブラウザーのセキュアDNS：HTTPS経由で独自に名前解決し、システムDNSを迂回する場合があります。ただし、そのHTTPS接続がプロキシ経由かどうかは別途確認が必要です。
- ルーティングルール：アプリの通信とDNSクエリの送信先を決めます。両者は関係しますが、同じ設定ではありません。
2. DNSリークの確認：3つの状態を比較する
プロキシをオフにした状態で、インターネットへの接続元IP、DNSリゾルバーの運営元、利用中のネットワークを記録してから、プロキシをオンにして同じテストを行います。ランダムなテスト用ドメインを複数回照会できるDNSリークテストサイトを利用できます。テストサイトに表示されるのは通常、再帰リゾルバーの接続元であり、PCが直接接続しているDNSアドレスとは限りません。パブリックDNSのエニーキャストや位置情報データベースによって地域表示も変わるため、国旗だけで判断しないでください。
| テスト状態 | 記録する項目 | 主な目的 |
|---|---|---|
| プロキシをオフ | インターネットへの接続元、リゾルバーの運営元、ネットワークの種類 | 現在のネットワーク環境の基準値を記録 |
| システムプロキシのみオン | Web接続元、ブラウザーのセキュアDNSの状態、リゾルバーの変化 | ブラウザーが実際に使う名前解決経路を確認 |
| TUNをオン | リゾルバー一覧、IPv4・IPv6接続、コアのログ | システム通信とDNSが取り込まれる範囲を確認 |
各状態で最低2回ずつテストし、設定を変更したらキャッシュを消去してテストページを開き直してください。Windowsではターミナルで次のコマンドを実行できます。システムのDNSキャッシュだけを消去するもので、ブラウザー独自のキャッシュは消去されず、DNSサーバーの設定も変更されません。
ipconfig /flushdns
Get-DnsClientServerAddress2つ目のコマンドはPowerShell用です。各ネットワークアダプターのDNSアドレスを一覧表示でき、物理アダプターと仮想アダプターを見分けるのに役立ちます。ただし、これだけでリークの有無は判断できません。アダプターにルーターのアドレスが表示されていても、すべてのクエリがTUNを迂回しているとは限りません。また、nslookup example.comは通常のHTTPシステムプロキシを経由しません。このツールのクエリ経路を確認する参考にはなりますが、ブラウザーや端末全体のテストの代わりにはなりません。
判断のポイント：運営元を比べ、実際の送信先を確認する
プロキシのオン・オフで同じ地域のISPリゾルバーが検出された場合は、まず想定どおりの直接接続ルールによるものか確認します。プロキシ経由にする必要があるドメインについては、DNSログと物理ネットワークアダプターの通信を照合してください。すぐにノードを変更する必要はありません。
3. v2rayNのリモートDNSとドメインルールの設定
作業前に、v2rayNのバージョン、通信に使うコア、TUNで使うコアを記録します。DNS画面のレイアウトはバージョンによって異なります。以下は「設定」→「DNS設定」がある画面を前提としています。コアごとに設定欄が分かれている場合は、現在実際に使われている設定を編集してください。完全なカスタム設定を使っていると、GUIで生成した内容が上書きされる場合もあります。
-
現在の設定を記録
「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートや関連するコア設定を記録して、現在のDNS設定を保存します。ローカルの待ち受けポートが
10808なら、アプリには実際のポートを指定してください。ほかの解説にある10809をそのまま設定しないでください。 -
リゾルバーを使い分ける
「設定」→「DNS設定」を開き、プロキシ経由のドメインに使うリモートDNSと、直接接続するドメインに使うローカルDNSを区別します。DoH対応の入力欄には、
https://dns.google/dns-queryのような完全なエンドポイントを指定できます。IPアドレスのみ受け付ける欄にURLを入力しないでください。 -
送信経路を確認
DNS設定の送信先オプション、または生成された設定のルーティングルールを確認し、リモート名前解決のリクエストが想定どおりプロキシ経由で送信されるようにします。ローカルDNSは、直接接続するドメインや起動時に必要な名前解決に利用できます。項目名に「リモート」とあるだけで、クエリがプロキシ経由で送信されていると判断しないでください。
-
ドメインルールを確認
「設定」→「ルーティング設定」を開き、ドメインルールを確認します。Xrayのルーティングにある
AsIs、IPIfNonMatch、IPOnDemandは、ルーティングの照合時に名前解決を行うかどうかを制御するもので、DNSの暗号化設定ではありません。まずドメインルールが正しく適用されることを確認し、そのうえで名前解決後にIPルールとの照合が必要か判断してください。 -
設定を適用して再テスト
設定を保存し、サービスを再起動するかノードに再接続して、コアの起動ログに設定エラーがないか確認します。次にDNSキャッシュを消去し、同じテストを繰り返します。一度に変更する項目は1つにし、正常に動作していた元の設定も保存して、必要に応じて元に戻せるようにしてください。
4. TUNでDNSリークを防ぐ確認項目：DNS、IPv6、ブラウザー
システムプロキシに対応していないアプリの通信も取り込みたい場合は、v2rayNのメイン画面で「TUNを有効にする」を検討してください。初回起動時は管理者権限が必要な場合があります。TUNを有効にしても、すべてのDNS迂回が自動的に防がれるわけではありません。バージョンによってはTUN専用のコアを使うため、DNS設定も通常のプロキシモードとは別に管理されています。
- 仮想ネットワークアダプターの起動を確認：スイッチの表示だけで判断せず、ログでTUNインターフェースが正常に作成されたか確認します。ドライバーやルートの作成に失敗している場合は、まず起動の問題を解決してください。
- DNSの取り込みルールを確認：UDP/TCPの53番ポート宛てのクエリが捕捉されているか確認します。従来のDNSポートだけを取り込んでも、443番ポートを使うアプリ独自のDoHをすべて自動検出できるわけではありません。
- IPv6を確認：IPv6対応ネットワークでは、AAAAクエリとIPv6接続が同時に発生する場合があります。IPv6のルートが取り込まれているか確認してください。原因の切り分けとして一時的にIPv6を無効にする方法はありますが、すべてのネットワークに適した恒久対策ではありません。
- ブラウザーの条件をそろえる：ブラウザーの「設定」→「プライバシーとセキュリティ」でセキュアDNSの設定を記録します。項目の場所はブラウザーによって異なります。テスト中は名前解決方式を1つに固定し、完了後に普段の設定に戻して再テストしてください。
- ほかの仮想ネットワークアダプターを確認：別のVPN、仮想マシン、企業向けネットワークツールがDNSやルートの優先順位、インターフェースメトリックを変更していることがあります。切り分けの際は一度に複数の経路を変更せず、1つずつ無効にして確認してください。
詳しく調べる場合は、物理ネットワークアダプターから想定外の宛先へ53番ポートのクエリが送信されていないか観察できます。時間帯を絞り、Webサイトのクエリ、LAN内のクエリ、ノード起動時の名前解決を区別してください。平文の53番ポート通信が見つからなくても、すべてのDNSがプロキシ経由だとは限りません。アプリが暗号化DNSサービスへ直接接続している可能性もあります。
判断のポイント：リゾルバー一覧の一致ではなく、対象ドメインをテスト
必要な直接接続時の名前解決は残し、プロキシ経由にするドメインについてDNSとアプリの通信がルールどおりか確認します。端末全体をプロキシ経由にする必要がある場合に限り、直接接続の例外を1つずつ見直し、LAN内サービスが正常に使えるか再確認してください。
5. v2rayNG（Android）のDNS確認リスト
v2rayNGはXrayコアを使用し、AndroidのVPNインターフェースを通じて対象アプリの通信を取り込みます。v2flyNGはV2Flyコアを使用するため、DNSやルーティングの設定項目をすべて相互に流用できるわけではありません。以下はv2rayNG向けの確認項目です。設定名や配置はバージョンによって異なる場合があるため、現在の画面表示に従ってください。
- 接続モードを確認：v2rayNGの「設定」でVPNモードが有効か確認し、Androidのシステム上でも対応するVPN接続が表示されていることを確認します。ローカルプロキシモードのみの場合、ほかのアプリでは各自プロキシの設定が必要です。
- DNS設定を確認：「設定」で「リモートDNS」「中国本土DNS」「ローカルDNS」に関する項目を確認します。モードによっては、一部の設定が適用されません。まず現在の値を記録し、1つずつ変更してからサービスに再接続し、ログを確認してください。
- アプリごとのプロキシ設定を確認：「設定」→「アプリごとのプロキシ」を開き、テストするブラウザーがVPNの対象になっているか確認します。選択したアプリを除外する設定を有効にしている場合、一覧の意味は選択したアプリだけをプロキシ経由にする設定とは逆です。チェックの有無だけで判断しないでください。
- AndroidのプライベートDNSを確認：Androidのシステム設定で「プライベートDNS」を検索し、自動、オフ、プロバイダー指定のどれになっているか記録します。クライアント側のDNS処理との関係は、OSのバージョンや設定によって異なります。必ず上書きされると決めつけず、設定変更前後を比較してください。
- ネットワークごとにテスト：Wi-Fiとモバイルネットワークでそれぞれテストします。ネットワークを切り替えたらクライアントに再接続し、リゾルバーの変化を確認するとともに、IPv6やブラウザーのセキュアDNSにも注意してください。
特定のアプリだけで異なるリゾルバーが表示される場合は、まずアプリごとのプロキシ設定と独自DNSを確認します。すべてのアプリで問題が起きる場合は、VPN接続、システムのプライベートDNS、現在のネットワークを調べてください。問題のある層を絞り込めるため、サブスクリプションを何度も更新したり、プロトコルを変更したりする必要はありません。
6. DNS設定後に接続できない場合：エラーから原因を絞り込む
リモートDNSの設定を誤ると、ノードは選択できてもWebページを開けないことがあります。まず変更した設定を元に戻し、サービスが起動できることを確認してから、ログを見て名前解決の失敗、接続タイムアウト、設定エラーを切り分けます。以下のエラーメッセージは複数の処理経路で表示されるため、前後の接続先アドレス、送信先の表示、発生時刻とあわせて確認してください。
エラー：no such host
原因と対処：通常は、該当する名前を正常に解決できなかったことを示します。エラーに表示されたドメインがノード、DoHエンドポイント、Webサイトのどれなのか確認し、入力ミス、リゾルバーへの到達性、起動時の名前解決経路を調べてください。このエラーだけでノードの障害と判断しないでください。
エラー：context deadline exceeded
原因と対処：処理が制限時間内に完了しなかったことを示します。DNSリクエストや、その後の接続が原因の可能性があります。DNSの応答待ちが明記されている場合は、リゾルバーの実際の送信経路とネットワークへの到達性を確認してください。ノードへの接続中に発生した場合は、ノードまでの通信経路を引き続き調べます。
エラー：network is unreachable
原因と対処：選択されたアドレスへのネットワーク経路がありません。IPv6、TUNのルート、インターフェースの変更が原因の可能性があります。ログに記録された宛先のアドレス種別を確認し、接続を作り直してルートを確認してください。インターフェースの問題を隠すために、むやみにDNSを変更しないでください。
設定を修正したら、同じブラウザー、ネットワーク、プロキシモードで再テストし、変更前後の結果を記録します。DNSリークテストで確認するのは、名前解決経路が想定どおりかどうかです。検出ページにサーバーが1つだけ表示されることではありません。コアの変更、クライアントの更新、ルーティングルールの変更後も、基準値と比較して再確認してください。