プロキシクライアントに接続成功と表示されても、ノードとのハンドシェイクと一部の送信通信が利用できることを示すだけで、名前解決まで同じプロキシ経路に入ったとは限りません。ブラウザーがWebサイトへアクセスする前には、通常ドメイン名をIPアドレスへ解決します。この処理をローカルネットワーク、ルーター、または通信事業者のDNSに任せたままだと、アクセス内容はプロキシを経由していても、どのドメインを問い合わせたかという名前解決リクエストだけが別経路から送信される可能性があります。
DNS漏洩を調べる際は、検査ページにどの国や地域が表示されたかだけで判断できません。また、ローカルのリゾルバーをすべて異常とみなすのも適切ではありません。アプリの通信をどの方式で取り込んでいるか、システムDNS、ブラウザーのセキュアDNS、クライアントのリモートDNS、ルーティングルールを確認し、設定変更前後の結果を比較して経路が本当に一本化されたかを判断します。
この記事は、VMessやVLESSなどのノードには接続できるものの、DNS検査でローカルリゾルバーが表示される、Webページの名前解決が時々失敗する、または分流結果が不安定な方を対象としています。検査の基準作りから始め、v2rayNとv2rayNGを個別に設定し、ログ、システムコマンド、再検査で修正結果を確認します。
DNS漏洩は経路のどこで発生するのか
一般的なWebリクエストには少なくとも「アプリがドメイン名を問い合わせる」「DNSがアドレスを返す」「アプリが宛先へ接続する」「ルーティングルールが送信経路を選ぶ」という段階があります。システムプロキシが取り込めるのは、主にHTTPまたはSOCKSプロキシに対応したアプリの接続です。OSが生成するUDP 53番ポートの問い合わせまで自動的にプロキシへ入るとは限りません。XrayコアにリモートDNSを設定していても、アプリがシステムリゾルバーを直接呼び出していれば、コアはその問い合わせを認識できない場合があります。
TUNモードは仮想ネットワークアダプターを通じて、より広範囲のIP通信を取り込みます。システムプロキシ設定を参照しないプロセスやDNSパケットもルーティング対象にできます。Androidのv2rayNGは通常、システムのVPNインターフェースを利用して同様の取り込みを行います。ただし、取り込みは第一段階にすぎません。53、853、443番ポートの名前解決通信が、直通ルールによって先に許可されていないことも確認してください。
ブラウザーに内蔵されたセキュアDNSも別の変数です。ブラウザーはシステムDNSを迂回し、指定したDoHサービスへHTTPSリクエストを直接送る場合があります。この通信は検査ページ上で別のDNSサービスとして表示されます。漏洩するかどうかは、HTTPS接続が最終的に直通するかプロキシを経由するかで決まり、ページに見慣れたDNS名が表示されるかどうかでは決まりません。
再現可能なDNS検査の基準を作る
まず設定を急いで変更しないでください。修正前の状態を記録しておくと、実際の改善と検査ページのキャッシュを区別できます。同じブラウザー、同じネットワーク、同じノードで3回テストし、各回の間は検査タブを閉じて約30秒待つのがおすすめです。標準テストではリゾルバーを素早く確認し、拡張テストではより多くのランダムなドメイン問い合わせを発生させるため、ローカルDNSとリモートDNSが同時に存在するケースを見つけやすくなります。
-
現在のモードを記録する
クライアント名、コアの種類、ノードのプロトコル、通信の取り込みモードを記録します。例：v2rayN 7.x、Xrayコア、VLESSノード、システムプロキシモード。「プロキシ接続済み」とだけ書かないでください。
-
他のネットワーク接続を一時停止する
同時に動作している他のプロキシ、企業ネットワーク接続、独立したDNSツールを終了し、複数の仮想アダプターやローカル待受ポートが結果に影響しないようにします。
-
ブラウザーのDNSを確認する
ブラウザーのプライバシーまたはセキュリティ設定で、「セキュアDNSを使用する」のスイッチとプロバイダーを記録します。最初の基準測定では、この機能を一時的に無効にしてシステムとクライアントの経路を切り分けても構いません。
-
拡張検査を実行する
信頼できるDNS漏洩検査ページを開き、標準テストと拡張テストを実行します。リゾルバー名、アドレス数、地域、初回問い合わせの所要時間を記録してください。
-
切断後に比較する
クライアントを切断してネットワーク接続を更新し、もう一度テストします。接続前後でリゾルバーがまったく同じなのに、Webの出口アドレスだけが大きく変わる場合、DNSがプロキシ経路に追随していない可能性が高いです。
Windowsでは、システムコマンドを使って現在のネットワークアダプターが取得しているDNSアドレスを確認できます。これはシステムがどこへ問い合わせようとしているかを示すだけで、パケットが最終的にどの送信経路を通ったかを単独で証明するものではありません。ただし、ルーターのアドレス、古い仮想アダプター、手動設定されたリゾルバーの特定には役立ちます。
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName example.com
ipconfig /flushdns一覧に物理アダプター、仮想アダプター、切断済みの古いアダプターが同時に表示される場合は、まずデフォルトルートを持つ現在のアダプターを確認します。設定変更後にキャッシュを消去し、ランダムなドメイン名を再度解決してください。同じドメインを繰り返し問い合わせると、システム、ブラウザー、クライアントのキャッシュが直接使われ、新しい外部リクエストが発生しないことがあります。
エラー：DNS request timed out.
原因と対処：システムに設定されたDNSへ到達できないか、現在のネットワークで53番ポートが遮断されています。まず到達可能なリゾルバーへ戻し、その後TUNルートがDNSを取り込んでいるか確認します。
エラー：server failed
原因と対処：リゾルバーがSERVFAILを返しています。上流障害、ドメイン検証の失敗、転送経路の設定ミスなどが一般的な原因です。リモートDNSを変更し、キャッシュを消去して再検査してください。
v2rayNの修正手順：システムプロキシとTUNを分けて設定する
v2rayNでシステムプロキシを使用すると、ブラウザーのHTTP/HTTPSリクエストは通常ローカルプロキシポートへ入りますが、WindowsのDNSはネットワークアダプターに設定されたリゾルバーへ直接送信される場合があります。よくあるローカル待受ポートはSOCKS 10808とHTTP 10809ですが、実際の値は「設定」→「パラメーター設定」のローカルポートを確認してください。ポートが正常に待ち受けていても、UDP 53番ポートが取り込まれているとは限りません。
目的が、プロキシに対応したブラウザーだけを指定した名前解決経路で動かすことなら、ブラウザーのセキュアDNSも調整し、そのDoHリクエストがプロキシ経由で送信されることを確認します。より多くのデスクトップアプリ、コマンドラインツール、システムの名前解決リクエストまで対象にするなら、TUNを使用してDNSハイジャックとルーティングルールを確認してください。両者は対象範囲が異なるため、システムプロキシモードの検査結果をそのままTUNと同一視してはいけません。
-
コアの種類を確認する
「設定」→「パラメーター設定」→「Core タイプ」を開き、現在のコアがノードのプロトコルに対応しているか確認します。コアを変更した場合は、古いプロセスが設定を使い続けないようクライアントを一度再起動してください。
-
リモートDNSを設定する
「設定」→「DNS設定」を開き、リモートDNSに明確な名前解決サービスを入力します。まずは1.1.1.1または8.8.8.8で単一変数のテストを行い、安定したことを確認してからネットワーク環境に合わせて調整します。
-
TUNによる取り込みを有効にする
メイン画面でTUNモードを有効にし、仮想ネットワークアダプターの作成に必要なシステム権限を許可します。有効化後は仮想アダプターが存在し、デフォルトルートが他のネットワークツールに上書きされていないことを確認してください。
-
DNSの分流を確認する
ルーティングルールで、DNSサーバーのアドレス、UDP 53、TCP 853、使用するDoHドメインに対するルールを確認します。プロキシ経由にしたい問い合わせが、「LAN直通」や広すぎるIPルールに先に一致しないようにしてください。
-
キャッシュを消去して再起動する
ブラウザーを閉じ、
ipconfig /flushdnsを実行してからv2rayNコアを再起動し、検査ページを開きます。新しいランダムドメイン名で問い合わせを発生させ、古いキャッシュを読み込まないようにします。
XrayのDNSモジュールは、ルーティング判定のためにドメイン名を解決したり、問い合わせを指定した上流へ転送したりできますが、すべてのシステムリクエストを自動的に取り込むわけではありません。リクエストがコアに入って初めてDNS設定が適用されます。ログに宛先への接続記録だけがあり、対応するDNS問い合わせがない場合は、上流アドレスを何度も変更する前に取り込みモードを確認してください。
エラー：failed to lookup ip
原因と対処：コアが現在のDNS設定からノードまたは宛先のアドレスを取得できません。サーバーアドレスの綴り、リモートDNSへの到達性、DNSの送信ルールを確認し、コアを再起動してください。
エラー：no such host
原因と対処：ドメインが存在しないと返されたか、ローカルキャッシュに失敗結果が残っています。サブスクリプションにあるサーバードメインが完全か確認し、システムDNSキャッシュを消去して別のリモートリゾルバーで再検査します。
エラー：context deadline exceeded
原因と対処：上流DNSがタイムアウトまでに応答していません。DoH接続が直通ルールで遮断されているケースが一般的です。443番ポートの送信設定とドメインルールを確認し、必要なら一時的に通常のリモートDNSへ変更して切り分けます。
v2rayNGの修正手順：VPNによる取り込みとプライベートDNSを連携する
v2rayNGがシステムVPNインターフェースで通信を取り込む場合、DNSはデスクトップのシステムプロキシよりトンネルへ入りやすくなりますが、「プライベートDNS」、アプリごとのプロキシ、LANの迂回、ルーティングルールの影響を受けることがあります。v2rayNGでXrayコアを使用する場合、リモートDNS、ドメイン戦略、FakeDNSは別々の設定項目です。漏洩を調べるときは、まず通常のリモートDNSで安定した基準を作り、その後FakeDNSを有効にするか判断してください。
システムのプライベートDNSは通常DoT、つまりTCP 853を使用します。プライベートDNSにホスト名を指定したままだと、システムはそのサービスへの接続を試み続けます。この接続が現在のノードを経由するかどうかは、VPNの取り込み範囲と分流ルールによって決まります。変数を切り分けるため、最初の検証ではシステムの「設定」→「ネットワークとインターネット」→「プライベートDNS」を一時的に「自動」または「オフ」にし、v2rayNGの確認後に一つずつ元へ戻してください。
-
動作モードを確認する
v2rayNGにVPN接続中と表示され、ステータスバーにシステムVPNのマークがあることを確認します。設定を変更しただけで接続を開始していなければ、リモートDNSは他のアプリのリクエストを取り込みません。
-
リモートDNSを入力する
左上のメニューから「設定」→「リモートDNS」を開き、明確に到達可能なDNSアドレスを入力します。テスト中は挙動が不明な上流を複数指定せず、結果の原因を追えるようにしてください。
-
ローカルDNSを確認する
「設定」で「ローカルDNS」と「ローカルDNSを有効にする」を確認します。ローカルDNSは主にクライアント側の問い合わせ入口を処理し、リモートDNSはコアに入った後の上流経路を決めます。両者を同じ設定項目として扱わないでください。
-
アプリごとの迂回を無効にする
切り分け中はアプリごとのプロキシを一時的に無効にするか、ブラウザーと検査ツールがプロキシ対象リストに含まれていることを確認します。除外されたアプリは物理ネットワークを直接使用するため、検査結果がノードの出口と異なるのは自然です。
-
再接続して再検査する
接続を停止し、約10秒待ってから再起動します。ブラウザーを強制終了して開き直し、拡張検査を2回実行して、モバイルネットワークとWi-Fiでそれぞれ記録した結果と比較してください。
v2rayNGとv2flyNGではコアの実装が異なり、設定名や利用できる機能もバージョンによって変わる場合があります。v2rayNGのXray DNS設定を、そのままv2flyNGのv2flyコア設定として使用することはできません。サブスクリプションの移行で取り込まれるのはノード情報だけで、端末上のDNS、ルーティング、アプリごとの設定は自動的に複製されません。クライアントを変更したら、あらためて基準を作り直してください。
エラー：Unable to resolve host
原因と対処：アプリまたはコアがドメイン名の結果を取得できていません。まずVPNが接続済みであることを確認し、リモートDNS、システムのプライベートDNS、現在のネットワークが該当ポートを遮断していないか確認します。
エラー：network is unreachable
原因と対処：DNSの上流が利用できないインターフェースへルーティングされています。Wi-Fiの切り替え後に古いVPNルートが更新されていないケースが一般的です。v2rayNGを停止し、ネットワークを一度切り替えてから再接続してください。
再検査で修正完了と判断する基準
修正完了の条件は、検査ページにアドレスが1つだけ表示されることではありません。パブリックDNSはエニーキャストを使用することがあり、同じサービスでも問い合わせごとに複数の出口が返されます。また、検査ページによってはリゾルバーのフロントエンドと実際の再帰ノードを分けて表示します。より確実な基準は、クライアント接続後に家庭用ルーター、現在利用しているネットワーク事業者、または明らかに想定外のローカルリゾルバーが表示されず、クライアント、ブラウザー、端末を再起動しても結果が一貫することです。
分流も検証が必要です。中国本土のドメインはルールに従って直通し、それ以外のドメインはプロキシ経由にする場合、DNSもドメインごとに異なる上流を使うことがあります。これは設計どおりの結果であり、「リゾルバーを必ず1つにする」ことだけを目標にすべきではありません。重要なのは、各グループの問い合わせと対応する送信経路が一致していることです。ローカルDNSでネットワークの影響を受けたアドレスを先に取得し、その接続だけをプロキシへ渡す構成は避けてください。
出口アドレスが変わったのに、DNS結果が変わらないのはなぜ？
システムプロキシが取り込んだのはWeb接続だけで、システムDNSは物理アダプターから送信されています。v2rayNではTUNへの切り替えとDNSルートを確認し、変更後にキャッシュを消去して再検査してください。
検査ページに2つのリモートリゾルバーが表示されても問題ない？
正常な場合があります。両方が選択した上流またはその再帰ノードに属していることを確認し、3回繰り返しテストしてください。プロキシを切断しても一方が常に表示される場合は、ローカルネットワーク設定を確認します。
FakeDNSを有効にすれば必ず解決する？
一概には言えません。FakeDNSは偽のアドレスでドメインとの対応を保持する仕組みで、TUNやドメイン分流との併用に適していますが、取り込まれていない問い合わせを修正するものではありません。まずDNSパケットがコアに入っていることを確認してください。
ノードを変更した場合も再検査は必要？
必要です。ノードによって適用されるルート、出口地域、DNS上流が異なる場合があります。少なくとも標準テストを1回実行し、リゾルバーに異常な変化があれば拡張テストも行ってください。
Webページは正常なのにサブスクリプション更新に失敗する場合は？
サブスクリプション更新のプロセスが独立したネットワーク経路を使用している可能性があります。サブスクリプション設定でプロキシ経由の更新が許可されているか確認し、コアのログからドメイン解決タイムアウトや接続タイムアウトの記録を探してください。
最終確認チェックリスト
- クライアント再起動後もノードへ正常に接続でき、VMessまたはVLESSのハンドシェイクログに継続的な名前解決エラーがない。
- 標準テストと拡張テストのどちらでも、現在の家庭用ルーターや想定外の通信事業者のリゾルバーが表示されない。
- Windowsの物理アダプター、TUN仮想アダプター、古い仮想アダプターのデフォルトルートが互いに競合していない。
- AndroidのプライベートDNS、アプリごとのプロキシ、v2rayNGのリモートDNS設定が、現在の取り込み目的に合っている。
- ブラウザーのセキュアDNSの状態を記録し、元に戻した後、そのHTTPSリクエストが想定した送信経路を通ることを再確認する。
- ノード、Wi-Fi、モバイルネットワークを切り替えた後、それぞれ少なくとも1回再検査し、結果がローカルの名前解決経路に戻らない。
再検査が安定しない場合は、「アプリが取り込まれているか、DNSリクエストがコアに入っているか、上流へ到達できるか、ルートが一致しているか、キャッシュを消去したか」の順に確認します。TUN、DNS、ルーティング、ブラウザーの4種類の設定を同時に変更しないでください。毎回1つの変数だけを変えて結果を保存することで、経路に本当に影響している設定を特定できます。