v2rayNのDNSリークを検出する方法：3つの確認手順と漏洩対策

まずDNSリークの判定基準を確認する

DNSはドメイン名をIPアドレスに変換します。アプリがキャッシュされていないドメインへアクセスすると、通常は先に名前解決を行い、そのアドレスへ接続します。プロキシが正常に接続していても、DNS問い合わせまでプロキシ経由になるとは限りません。システムプロキシが主に扱うのはHTTPまたはSOCKS対応アプリの通信であり、Windows DNS Clientが送信するUDP 53の問い合わせは、現在のネットワークアダプターに設定されたDNSサーバーへそのまま送られる場合があります。

検査ページに表示されたサーバー数だけで漏洩を判断してはいけません。まずプロキシ未使用時のDNS事業者、都市、サーバー数を記録し、v2rayNを有効にして同じテストを繰り返します。プロキシ有効後も同じ事業者・同じ地域のDNSサーバーが継続して表示され、さらにログで問い合わせがXrayに入っていないことを確認できた場合に、漏洩として対処する十分な根拠になります。

ブラウザーに内蔵された安全なDNS機能も検査結果を変えることがあります。ブラウザーは指定したDoHサービスへHTTPSで直接問い合わせを送れるため、検査ページに表示されるDNSサーバーは、システムDNSともv2rayN経由とも限りません。確認中はブラウザーの「設定」→「プライバシーとセキュリティ」→「セキュリティ」→「安全なDNSを使用する」を開き、現在の設定を記録してください。条件をそろえるため一時的に無効にし、検査後に元へ戻す方法もあります。

方法1：ブラウザーの検査サイトで2回比較する

ほかのプロキシツールを終了し、v2rayNだけを残します。v2rayNのメイン画面を開き、下部で対象サーバーが選択されていることを確認し、システムプロキシを「システムプロキシを自動設定」に切り替えます。ブラウザー検査は出口とDNSの場所が大きく食い違う状況をすばやく見つけるのに便利ですが、どのプロセスが問い合わせを送ったかを単独で証明するものではありません。

1. 古いキャッシュを削除する

   すべてのブラウザーウィンドウを閉じ、管理者権限のターミナルで ipconfig /flushdns を実行します。「DNSリゾルバーキャッシュを正常にフラッシュしました」と表示されたら、ブラウザーを再度開きます。

2. ダイレクト接続の基準を記録する

   v2rayNのシステムプロキシを「システムプロキシを解除」に切り替え、dnsleaktest.comへアクセスしてStandard testを実行します。サーバー名、国または地域、検出数を記録してください。

3. システムプロキシを有効にする

   v2rayNに戻り、「システムプロキシを自動設定」を選択します。遅延テストが正常であることを確認してから、ブラウザーの新しいプライベートウィンドウを開き、以前の接続やDNSキャッシュが結果に影響しないようにします。

4. 検査を2回繰り返す

   Standard testを連続2回実行し、各回の間隔を約30秒空けます。プロキシの出口が変わったのに、DNSにはダイレクト接続時と同じ事業者名が表示される場合は、コマンドラインで確認を続けます。

検査ページには複数のパブリックDNSノードが同時に表示されることがあります。パブリックDNSはAnycastを採用している場合が多く、同じサービスでも異なる都市へ振り分けられます。そのため、「DNSの都市とプロキシ出口の都市が違う」だけでは漏洩とはいえません。重要なのは事業者がローカルの固定回線やモバイル回線に属しているか、そしてプロキシを無効にしたときのサーバーがそのまま残っているかです。

異常が特定のブラウザーだけで発生し、ほかのブラウザーでは正常なら、まずそのブラウザーの安全なDNS、拡張機能、バックグラウンド接続を確認します。この段階でv2rayNの全体設定をすぐ変更すると、ブラウザー独自の名前解決をコアの問題と誤認するおそれがあります。

方法2：nslookupでシステムDNSとプロキシDNSを見分ける

nslookup は標準ではシステムに設定されたDNSサーバーへ直接問い合わせます。通常のHTTPシステムプロキシを有効にしただけで、自動的にプロキシ経由へ切り替わることはありません。そのため「システムプロキシを自動設定」だけを有効にした状態で、ルーターのアドレスや通信事業者のDNSが表示されても不思議ではありません。これは、システムレベルのUDP 53が通常のプロキシに引き取られていないことを示しています。

Windowsターミナルを開き、まずDNSサーバーを指定しない問い合わせを実行します。出力上部のServerとAddressは現在のシステムリゾルバーです。よくあるアドレスには家庭用ルーターの 192.168.1.1、LANゲートウェイ、ネットワークアダプターから配布されたDNSなどがあります。続いてDNSサーバーを指定して再度問い合わせ、本来の経路が利用できるか確認します。

ipconfig /flushdns
nslookup example.com
nslookup example.com 1.1.1.1
nslookup -type=AAAA example.com

• デフォルトの問い合わせでルーターのアドレスが表示される：システムDNSはLANゲートウェイに渡されており、通常のシステムプロキシはこの問い合わせを引き取っていません。
• 指定したサーバーへの問い合わせがタイムアウトする：ネットワークがUDP 53を制限しているか、ファイアウォールがターミナルからの問い合わせを遮断している可能性があります。これだけでプロキシノードの障害とは判断できません。
• Aレコードは正常だがAAAAがタイムアウトする：ローカルIPv6の利用可否とv2rayNの問い合わせ方針を確認し、IPv4 DNSだけを変更しないでください。
• 短時間で結果が変わらない：Windows、ブラウザー、Xrayのキャッシュが利用されている可能性があります。キャッシュを削除し、まだアクセスしていないドメインで再検査します。

TUNがシステムの問い合わせを引き取っているか確認するには、まずTUNを有効にし、その後デフォルトの nslookup を再実行します。このときServerフィールドだけを見てはいけません。元のネットワークアダプターのアドレスが表示される場合があるためです。v2rayNのログも同時に開き、UDP 53の問い合わせがTUNインバウンドへ入り、DNSルールに一致し、想定した出力へ渡されているか確認します。

方法3：v2rayNとXrayのログで経路を確認する

ログからは2つの重要な点を確認できます。問い合わせがコアへ入ったか、入った後にどの出力を通ったかです。v2rayNの「設定」→「パラメーター設定」→「基本設定」を開き、ログレベルを一時的に info に変更します。保存してコアを再起動した後、「ヘルプ」→「ログを表示」を開きます。小バージョンによっては「ログ」や「実行ログを表示」と表示されることがありますが、いずれも現在のXrayインスタンスのリアルタイム出力を確認してください。

1. コアを再起動する

   メイン画面で「サーバー」→「サービスを再起動」を実行し、変更したDNSとログレベルが現在生成される設定に反映されるようにします。

2. 新しい問い合わせを発生させる

   ipconfig /flushdns を実行し、まだ開いたことのないドメインへアクセスします。キャッシュによってログに問い合わせが記録されない状況を避けるためです。

3. ポートを検索する

   ログで :53、udp、dns、対象ドメインを検索し、問い合わせ元がTUNインバウンドまたはアプリプロキシのインバウンドになっているか確認します。

4. 出力先を照合する

   ログのoutboundまたはdetourが想定したプロキシタグを指していることを確認します。directに一致する場合はルーティング設定へ戻り、DNSサーバーのIPとポートに関するルールを確認してください。

システムプロキシモードでは、ブラウザーがSOCKSまたはHTTPインバウンドへドメイン名を渡す場合、Xrayがコア側で名前解決できます。一方、アプリがローカルで先に名前解決し、IPアドレスをプロキシへ渡す場合、ログに残るのは宛先IPだけで、プロキシリクエストから元のドメイン名を復元できません。TUNモードはより多くのシステム通信を対象にできますが、DNSリダイレクトとルーティングを正しく設定しないと、UDP 53が通常の通信として直接接続される可能性があります。

システムプロキシモードでリモートDNSとDNS出力を設定する

主にブラウザーや、プロキシに明確に対応したデスクトップアプリを使う場合は、システムプロキシモードを維持できます。v2rayNの「設定」→「DNS設定」を開き、Xrayに対応するDNS設定ページを選択します。中国本土向けと海外向けのドメインは分けて名前解決できますが、リモートDNSサーバーは到達性とルーティング方向の両方を満たす必要があります。アドレスを入力するだけで、通信経路を確認しないのは危険です。

リモートDNSにDoHを使う場合、通常はTCP 443でHTTPS接続を確立するため、UDP 53を直接使うよりプロキシのルーティングへ組み込みやすくなります。設定後は、リモートDNSのドメイン自体が最初にどのように名前解決されるかも確認してください。そのドメインのアドレス取得にローカルDNSが必須だと、ブートストラップ依存が発生します。安定して到達できるブートストラップリゾルバーを使うか、該当DNSサーバーのアドレスを明確なルールで出力させます。

• 問い合わせ方針：利用可能なIPv6がないネットワークでは、IPv4を優先する方針を選び、AAAA問い合わせによる初回接続の遅延を避けます。デュアルスタックが必要な場合はAとAAAAの両方を残し、それぞれ検証してください。
• ドメイン方針：geosite ルールに依存するルーティングでは、名前解決後のIPだけで早期に照合せず、できるだけドメイン情報を保持します。
• DNS出力：組み込みの dns-out は、照合されたDNS通信をコアのDNSモジュールへ渡すためのものです。任意のパブリックDNSアドレスを指す別名ではありません。
• ポートルール：従来型の問い合わせを処理する場合はUDP/TCP 53に一致させます。DoHはHTTPS通信なので、対象ドメイン、対象IP、443ポートに基づいてプロキシまたはダイレクトを決めます。

「設定」→「ルーティング設定」を開き、DNSサーバーのIPを強制的にdirectへ送る高優先度ルールがないか確認します。リモートDNSをプロキシ経由で利用する予定なら、このようなルールは設定同士の衝突を招きます。ルールは現在のコアと生成された設定の順序に従って照合されるため、変更後はサービスを再起動し、ログで最終的な出力タグを確認してください。

TUNモードでシステムレベルのDNS問い合わせを引き取る

ゲームランチャー、コマンドラインツール、一部のデスクトッププログラムはHTTPシステムプロキシに従いません。これらも対象にする場合は、v2rayNのメイン画面で「Tunモード」を有効にし、「設定」→「パラメーター設定」→「Tunモード設定」を開きます。v2rayN 7.13.3を例に、TUN実装、厳格ルーティング、MTU、DNS引き取り関連の項目を確認し、保存後にコアを完全再起動します。

1. 競合するネットワークアダプターを無効にする

   まず、仮想ネットワークアダプターを作成するほかのネットワークプログラムを終了し、デフォルトルート、インターフェースメトリック、DNS引き取りルールが互いに上書きしないようにします。

2. 厳格ルーティングを有効にする

   「設定」→「パラメーター設定」→「Tunモード設定」で厳格ルーティングを有効にします。管理対象の通信をTUNルーティングテーブルで処理し、元の物理ネットワークアダプターから問い合わせが迂回する可能性を減らします。

3. MTUを確認する

   まずはデフォルト値を使用します。ウェブページの一部が読み込めない場合は、1500から1400へ下げて再検査します。MTUはパケット転送に影響するため、DNSリーク対策で最初に変更する項目ではありません。

4. TUNを再構築する

   「Tunモード」を一度無効にしてから再度有効にし、ステータス欄に起動エラーがないことを確認します。Windowsのネットワークアダプター一覧に現在の仮想インターフェースが表示されることも確認してください。

5. UDP 53を検証する

   新しい nslookup 問い合わせを実行し、リアルタイムログでUDP 53がTUNインバウンドへ入り、DNS処理ルールに一致していることを確認します。

TUNを有効にした後、名前解決が完全にできなくなっても、すぐにノードを何度も変更しないでください。ファイアウォールがv2rayNとXrayのネットワークアクセスを許可しているか、仮想インターフェースに有効なルートが設定されているかを確認し、ログで問い合わせのタイムアウト、ルールによる拒否、TUN起動失敗のどれかを確認します。ノードIPには接続できるのにノードドメインを解決できない場合は、ブートストラップDNSを重点的に確認します。

TUNモードでブラウザーは正常なのに nslookup がタイムアウトする場合、DNSリダイレクトが一部のプロトコルしか対象にしていないか、問い合わせが厳格ルーティングに阻止されている可能性があります。UDP 53、TCP 53、DoH 443を個別にテストし、DNSルールが通常のダイレクトルールより前にあることを確認します。変更後はブラウザー検査を2回やり直し、TUNの状態表示だけに頼らないでください。

キャッシュ、IPv6、ルールの競合を結果から特定する

DNSを変更しても検査結果がすぐ変わらない場合、最も多い原因はキャッシュです。Windows DNS Client、ブラウザー、Xrayコア、上流リゾルバーにはそれぞれ独立したキャッシュがあります。まずブラウザーを閉じ、ipconfig /flushdns を実行し、v2rayNのコアを再起動してから、未アクセスのドメインでテストします。ページを更新するだけでは、新しいDNS問い合わせが発生しないことがあります。

IPv6も個別に確認する必要があります。システムがIPv4でプロキシへ接続しながら、物理ネットワークアダプターからAAAA問い合わせを送信し続けることがあります。また、IPv6アドレスを取得しても、現在のネットワークに完全なIPv6ルートがなくタイムアウトする場合があります。nslookup -type=AAAA とログを照合し、問い合わせが引き取られているか、返されたアドレスへ到達できるか確認してください。

• ブラウザーだけが異常：安全なDNSとブラウザーキャッシュを確認し、全体のルーティングは先に変更しません。
• nslookupにローカルDNSが表示され、ログに記録がない：通常のシステムプロキシはシステムの問い合わせを引き取っていません。全体を対象にする必要がある場合はTUNを確認します。
• ログに問い合わせがあるがdirectに一致する：DNSサーバーのドメイン、IP、ポートに対応するルーティングの優先順位を調整します。
• ログに問い合わせがありproxyを通るのに、検査結果が異常：検査ページがブラウザー独自のDoHを使用していないか確認し、別のブラウザーでも比較します。
• TUN有効後にすべてタイムアウトする：仮想ネットワークアダプター、ファイアウォール、厳格ルーティング、ブートストラップDNSを確認し、ノードの遅延だけを判断材料にしないでください。

最終確認には3項目が必要です。ブラウザー検査でダイレクト接続時の基準と同じ通信事業者のリゾルバーが繰り返し表示されないこと、新しい nslookup 問い合わせをTUN環境でログから追跡できること、XrayログでDNS通信が想定した出力に一致することです。3つの結果が一致したら、一時的に上げたログレベルを元に戻し、長期的なログ容量を抑えます。