V2RayのDNSリーク確認方法とv2rayNのDNS設定・対策ガイド

1. DNSリークは地域ではなく、名前解決の経路で判断する

DNSはドメイン名をIPアドレスに変換します。プロキシ利用時は、Web接続とDNSクエリが別々の経路を通る場合があります。ブラウザーはプロキシ経由でWebサイトに接続していても、OSはルーターや通信事業者にドメイン名を問い合わせていることがあります。こうしたクエリもプロキシ経由にする想定だったのに、意図せず直接送信されている状態が、ここで確認するDNSリークです。

v2rayNはデスクトップクライアントです。実際の名前解決の動作は、選択中のコア、生成された設定、アプリごとの設定、システムのネットワーク環境によって異なります。「リモートDNS」のアドレスを一つ変更しただけでは、すべてのアプリのクエリを制御できません。システムプロキシを有効にしても、UDP通信がすべて自動的に処理されるわけではありません。ブラウザー内蔵の暗号化DNSがシステムのリゾルバーを経由せず、別の経路になる場合もあります。

2. オンライン検査：プロキシ無効時の基準値を記録する

https://www.dnsleaktest.com/を開き、Standard testまたはExtended testを実行できます。検査ページは一時的なドメインへのリクエストをブラウザーに送信させ、その権威DNSへの問い合わせを行った再帰リゾルバーを表示します。通常、表示されるのはPCのネットワークアダプターに設定されたDNSアドレスではありません。また、PCからリゾルバーまでのネットワーク経路全体を示すものでもありません。

1. 基準値を記録する

   TUNを一時的に無効にし、v2rayNの「システムプロキシ」メニューから「システムプロキシを解除」を選択します。検査を一度実行し、日時、Webの出口IP、リゾルバーのIP、運営組織を記録してください。この状態ではテスト通信が現在のネットワークを直接利用します。その点を許容できる場合にのみ実行してください。

2. ブラウザーの条件をそろえる

   同じブラウザー設定と同じネットワークを使用します。ブラウザーの「設定」で「セキュアDNS」または「DNS over HTTPS」を検索し、現在の設定を記録してください。まずクライアントの経路を確認するため、ブラウザー独自の暗号化DNSを一時的に無効にし、検査後にこの機能を個別に確認します。

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

   接続できることを確認済みのノードを選び、「システムプロキシ」から「システムプロキシを自動設定」を選択します。まず、検査サイトのWeb出口が実際に変わったことを確認してください。変わらない場合は、システムプロキシ、ブラウザー拡張機能、バイパスルールを先に確認します。

4. 検査を繰り返す

   Standard testを実行してから、Extended testを実行します。それぞれ少なくとも2回繰り返し、基準値と比較してください。モードを切り替えたら検査ページを開き直し、前回の結果だけを見ないようにします。後で比較できるよう、画面のスクリーンショットも保存してください。

3. v2rayNのリモートDNSとローカルDNSの役割

変更前に、v2rayNのバージョン、使用中のコア、ルーティングモード、現在のDNS設定を記録し、既存の設定をバックアップしてください。一般的なバージョンでは「設定」→「DNS設定」から関連画面を開けます。画面の設定項目はコアごとに分かれていることが多く、バージョンによって項目名や配置が異なります。以下の「リモートDNS」「ローカルDNS」は機能上の役割を指します。現在の画面に表示される項目を確認し、あるコアの設定形式を別のコアにそのまま貼り付けないでください。

• リモートDNS：プロキシ経由にするドメインの名前解決に使用します。https://1.1.1.1/dns-queryのようなDoHアドレスを指定する場合は、設定欄がDoHに対応しており、このサービスへの接続が想定した出口へ正しくルーティングされる必要があります。
• ローカルDNSまたは直接接続用DNS：直接接続するドメインや、起動時の一部の名前解決に使用します。ネットワーク環境に合った信頼できるリゾルバーを指定してください。たとえば223.5.5.5は具体的なパブリックDNSのアドレスですが、適切かどうかは接続性やプライバシー要件によって異なります。
• ノードのドメイン名解決：ノードに接続するには、通常、事前にノードサーバーのIPアドレスを知る必要があります。接続前のクエリまで、まだ確立していないノード経由にしようとすると、起動時に依存関係の循環が発生する可能性があります。直接接続の名前解決をすべて強制的に削除するのではなく、コアが対応する独立した名前解決の設定を使用してください。
• DNSの出力ルール：クエリ接続を直接接続とプロキシ経由のどちらで送信するかを決めます。暗号化DNSは通信内容を保護しますが、DoH接続自体が直接接続されると、リゾルバーにはローカルのグローバルIPアドレスが見えます。「暗号化」と「プロキシ経由」は別々の設定目標です。

一度に一項目だけ変更して保存する

まず「設定」→「DNS設定」で使用中のコアのページを選び、リモートリゾルバーと直接接続用リゾルバーの用途を確認します。入力は設定欄が対応している場合に限り、前述のアドレスを指定してください。次にルーティング設定を確認し、そのDNSサービスへの接続を強制的に直接接続するルールがないか調べます。保存後、サービスまたはコアを再起動し、ログに設定読み込みエラーがないことを確認してからオンライン検査を再実行します。カスタム設定のテキストしか表示されない場合は、対応するコアの形式を確認してください。名前が似ているからという理由で項目を追加しないでください。

4. TUNモードでDNSハイジャックとIPv6を確認する

システムプロキシは、プロキシ設定に従うアプリを主な対象とします。TUNは仮想ネットワークインターフェースを通じて通信を取り込むため、システムプロキシに従わないアプリの確認に適しています。ただし、TUNを有効にするだけでDNSが完全に処理されるわけではありません。TUNのルーティング、DNSの取り込みルール、コアのログをあわせて確認してください。

1. 現在のTUN設定を開く。一般的なデスクトップ版では「設定」→「パラメーター設定」から「Tunモード設定」を探します。バージョンによっては独立したページにあります。自動ルート、厳格ルート、DNS関連項目の現在の値を記録し、使用中のバージョンに明示されている項目だけを変更してください。
2. 通常のDNSが取り込まれているか確認する。DNSハイジャックまたはDNS取り込みの項目がある場合、想定するUDP/TCPの53番ポートのクエリが対象になっていることを確認します。これは通常のDNSリクエストをコアの名前解決処理へ転送する機能であり、任意の暗号化接続をDNSに変えるものではありません。
3. 暗号化DNSは別途確認する。DoHは通常TCPの443番ポートを使用し、HTTP/3ではUDPの443番ポートを使う場合もあります。DoTは通常TCPの853番ポートを使用します。53番ポートだけをハイジャックしても、これらの接続は対象になりません。アプリの設定とルーティングで対応する必要があります。
4. IPv6の経路を確認する。システムにIPv6のDNS設定があるか、TUNにIPv6ルートが設定されているか、プロキシの出口が接続先へのアクセスに対応しているかを確認します。AAAAレコードの問い合わせと、問い合わせ通信自体がIPv6を使うことは別の問題です。AAAAレコードを無効にするだけでは解決したか判断できません。
5. ネットワークを切り替えて再検査する。設定を保存したら、まず現在のネットワークで再検査し、その後、有線や無線など実際に使う環境で再接続して検査します。ネットワークを切り替えるとシステムDNSやデフォルトルートが更新されることがあるため、以前の結果で新しい環境の状態を判断しないでください。

TUNの変更後にネットワーク全体が使えなくなった場合は、まずTUNを無効にして基準の状態へ戻し、権限、仮想インターフェース、ルートの競合を確認します。IPv6の無効化は一時的な比較テストには使えますが、システムのネットワーク動作を変えるため、一般的な解決策として扱わないでください。IPv6を維持する環境では、DNSの取り込みとルーティングを適切に設定します。

5. システムコマンドでキャッシュ・プロキシ・名前解決の失敗を切り分ける

以下ではWindows PowerShellを例にします。最初のコマンドはローカルのDNSキャッシュを消去し、システムの名前解決を実行します。確認できるのはシステムの名前解決経路であり、クライアントのリモートDNSを個別に検証するものではありません。ブラウザーやコアに別のキャッシュがある場合もあるため、必要に応じてブラウザーを完全に終了し、コアを再起動してください。

ipconfig /flushdns
Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type AAAA

続いて、SOCKSに対応したcurlを使い、「宛先ドメイン名をプロキシ側で処理する」接続をテストできます。以下では、v2rayNのSOCKSまたは混合リスナーの実際のポートが10808だと仮定しています。実行前に「設定」→「パラメーター設定」でローカルのリスナーポートを確認し、実際の値に合わせて変更してください。数値アドレスの127.0.0.1を使うことで、プロキシホスト名の追加の名前解決を避けてローカルプロキシに接続します。

curl.exe --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 -I https://example.com/

--socks5-hostnameは宛先のホスト名をSOCKSプロキシに渡します。一方、--socks5は通常、宛先をローカルで名前解決します。前者のコマンドが成功しても、明示したプロキシ経路が使えることを示すだけです。ブラウザーやバックグラウンドサービスにDNSリークがないことの証明にはなりません。

6. 再検査のチェックリスト：ルーティングを維持して想定経路を確認する

設定を変更したら、プロキシ無効、システムプロキシのみ、TUNの3つの状態を分けて記録します。各状態で同じブラウザー設定を使い、国や地域だけでなくリゾルバーの運営組織も記録してください。結果が想定と異なる場合は、直近で変更した設定に戻り、元に戻した状態で再検査します。

• ブラウザー：プロキシ経由にする検査リクエストが想定した出口を使い、DNSの結果も設定と一致していることを確認します。ブラウザーのセキュアDNSを再び有効にした場合は、別途もう一度検査してください。
• ターミナル：明示的なSOCKS接続が成功し、システムの名前解決テストでも妥当な結果が得られることを確認します。この2つは別の経路として記録してください。
• ルーティング：直接接続するドメインに引き続きアクセスでき、プロキシ経由にするドメインが、リモートDNSの失敗によって意図しない直接接続に切り替わらないことを確認します。
• ログ：DNSのタイムアウト、接続ループ、設定読み込み失敗が繰り返し発生していないことを確認します。原因の特定中は一時的にログの詳細度を上げ、調査後は通常のレベルに戻してください。
• 設定の記録：バージョン、コア、DNSアドレス、TUNの状態、検査日を保存します。外部に問い合わせる前に、サブスクリプションURL、ノードの認証情報、公開したくないグローバルIPアドレスを隠してください。

7. DNSリーク対策でよくある質問