V2RayのDNSリーク検出と対策｜v2rayNのリモートDNS・FakeDNS設定ガイド

DNSリークとは？Web通信と名前解決の経路を分けて確認

DNSはドメイン名をIPアドレスに変換します。Web通信がプロキシ経由でも、ドメイン名の問い合わせまでプロキシ経由とは限りません。本来プロキシで処理したいドメイン名をアプリがローカルネットワークのDNSサーバーに問い合わせると、利用中のネットワークに検索内容が知られる可能性があります。対処すべきなのは、この経路の食い違いです。

v2rayNはデスクトップ用クライアントです。DNSの動作は、使用中のコア、インバウンド方式、生成された設定によって異なります。VMessやVLESSなどのプロトコル名だけでは、DNSリークの有無は判断できません。プロトコルを変えても、ブラウザー独自の名前解決やルーティング規則の順序は通常改善しません。

この流れはトラブルシューティングの考え方であり、すべてのリクエストが必ず同じ順序で処理されるわけではありません。アプリが端末上で先に名前解決する場合も、IPルールとの照合のためにコアが先に名前解決する場合もあります。確認するのは「誰が問い合わせたか」と「どのアウトバウンド経由で送信されたか」の2点です。

• リモートDNS：プロキシ経由で名前解決するドメインの問い合わせに使用します。サーバーが遠隔地にあるだけでは、問い合わせが自動的にプロキシ経由になるわけではありません。
• 直接接続DNS：直接接続を許可したドメインの名前解決に使用し、実際のローカル接続経路に合わせます。
• ブラウザーのセキュアDNS：ブラウザー独自の暗号化された名前解決経路です。システムのDNS設定を迂回する場合がありますが、プロキシを経由するかどうかは接続経路によります。
• プロキシノードの名前解決：プロキシサーバーへの接続前に必要になることがあります。まだ確立していない同じプロキシ接続に依存させないでください。

DNSリークを検査する：基準値を記録してプロキシ接続時と比較

DNSLeakTestなどの検査ページを開き、標準テストまたは拡張テストを実行して、DNSリゾルバーのアドレス、運営ネットワーク、所在地を記録します。検査ページに表示されるのは通常、最終的な再帰リゾルバーの出口であり、PCが直接接続しているDNSサーバーとは限りません。所在地データベースにも誤差があるため、「国が違う」という理由だけで判断しないでください。

1. 基準値を記録：プロキシとTUNをオフにし、ブラウザーを再起動して、個人情報を入力しないDNS検査ページにアクセスします。このときのパブリックIPとDNSリゾルバーの運営ネットワークを記録してください。
2. 通常のプロキシを有効化：接続できることを確認済みのノードを起動し、v2rayNのトレイメニューで「システムプロキシ」→「システムプロキシを自動設定」を選択します。表示名はバージョンによって異なる場合があるため、実際の画面に従ってください。
3. 同じテストを再実行：Webアクセス時のパブリックIPが変わったことを確認してから、DNS検査を実行します。できる限りブラウザー、ノード、検査ページは変更しないでください。
4. ブラウザー設定を切り分け：現在の「セキュアDNS」の設定を記録し、一時的にオフにして再検査します。ノードとルーティングを同時に変更すると、どの操作が結果に影響したか判断できません。
5. ほかのアプリも確認：ブラウザーで問題がなければ、対象のアプリでも確認します。システムプロキシは端末上のすべての通信を制御するものではありません。ブラウザーで問題がなくても、ほかのアプリも正常とは限りません。

ポートとコマンドで確認：端末上の名前解決とプロキシ経由を切り分ける

まず「設定」→「パラメーター設定」で、現在のローカル待ち受けポートとインバウンドの種類を確認します。以下ではSOCKSインバウンドの例として10808を使用します。すべてのバージョンの既定値を示すものではありません。該当ポートがSOCKSに対応していることを確認してから、対応するコマンドを実行してください。

WindowsではPowerShellで以下のコマンドを実行できます。最初のコマンドはローカルポートへのTCP接続を確認するだけです。後の2つで、ドメイン名がどこで名前解決されるかを比較します。環境によってcurlが別のコマンドのエイリアスになっている場合があるため、curl.exeを使用してください。

Test-NetConnection 127.0.0.1 -Port 10808

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

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

• --socks5：curlが端末上で接続先のドメイン名を名前解決し、接続先IPをSOCKSプロキシに渡します。
• --socks5-hostname：ドメイン名をSOCKSプロキシに渡し、その後のプロキシ経路で名前解決します。これだけでは、最終的にどのDNSサーバーが使われたかは証明できません。
• 後者だけが成功する場合は、まず端末上の名前解決が妨げられていないか確認します。両方とも失敗する場合は、ノード、待ち受けポート、アウトバウンド接続を先に確認してください。
• nslookup example.comは通常、システムに設定されたDNSサーバーに問い合わせます。システムHTTPプロキシを有効にしても、自動的にv2rayN経由にはなりません。この出力だけを根拠に、ブラウザーの検査結果を否定しないでください。

v2rayNのリモートDNSと直接接続DNS：アドレスとアウトバウンドをセットで設定

変更前にクライアント設定をバックアップし、現在のノード、ルーティングモード、DNS設定を記録します。「設定」→「DNS設定」を開き、使用中のコアに対応する項目を確認してください。バージョンによってDNS項目がパラメーター設定にある場合は、実際の画面にあるDNSの項目から操作します。コアごとに設定構造は異なります。1つのJSONをすべてのコアに貼り付けないでください。

表中のアドレスは設定の関係を説明する例であり、必ず使用すべきサービスの一覧ではありません。リモートDNSにDoHを選んでも、HTTPS暗号化で保護されるのは通信内容です。DoHの問い合わせが直接接続される場合、ローカルネットワークにはDNSサービスへの接続が見えます。DNS通信もローカル回線の外に出したい場合は、ルーティングも確認してください。

1. 対象範囲を決める：原因の切り分け中は、クライアントのグローバルプロキシモードを一時的に使用すると、ルーティングによる変数を減らせます。テストが終わったら通常のルーティングに戻し、一時的な設定を最終設定と混同しないでください。
2. リモートDNSを設定：使用中のコアが対応する形式でDNSアドレスを入力します。通常のDoHと、一部のコアにあるローカル直接接続の名前解決モードは別物です。HTTPSと表示されるだけでプロキシ経由と判断しないでください。
3. ルールの順序を確認：「海外IPは直接接続」やリゾルバーのアドレスに適用される直接接続ルールがある場合、先に一致していないか確認します。通常、ルールは上から順に評価されます。先に一致した直接接続ルールを、後続のプロキシルールで上書きすることはできません。
4. ノードの初期名前解決を設定：ノードにドメイン名を使用している場合は、独立した到達可能な名前解決経路を用意します。ノード自身を使わないとノードのドメイン名を解決できない設定は避けてください。
5. 保存してコアを再起動：ログに設定エラーがないことを確認し、同じテストをもう一度行います。通常のルーティングに戻すと問題が再発する場合は、ドメインルールとリゾルバーのアウトバウンドルールを重点的に確認してください。

FakeDNSとTUN：IPで受信した通信からドメイン名を特定

FakeDNSはドメイン名に実際のサーバーアドレスを直接返すのではなく、合成IPアドレスを割り当て、ドメイン名と合成アドレスの対応を保存します。後続の接続がこのアドレスに届くと、コアがドメイン名を復元して処理を続けられます。解決するのはドメイン名の伝達に関する問題であり、独立した暗号化DNSサービスではありません。また、プロキシのアウトバウンドルールの代わりにもなりません。

Xrayでよく使われるFakeDNSのIPv4アドレス範囲は198.18.0.0/15ですが、実際の生成設定を確認してください。この範囲はベンチマーク用であり、実際のWebサイトのパブリックIPではありません。問い合わせと後続の接続の両方が、FakeDNSに対応する同じ経路で処理されて初めて、マッピングが有効になります。

1. まず基本のプロキシを確認：FakeDNSを有効にせず、先ほどのリモートDNSテストを完了させます。ノードに接続できない状態で、複数の高度な設定を同時に有効にしないでください。
2. 実装の対応状況を確認：現在のTUN実装とコアが、該当するFakeDNSまたはfake-ipモードに対応しているか確認します。名前が似ていても設定を共用できるとは限りません。通常のSOCKS環境では、検査のために無理に有効にする必要はありません。
3. DNSの取り込みを有効化：使用中のクライアントが提供するTUNとDNS取り込みの項目を設定します。仮想ネットワークアダプターを有効にしただけでは、すべてのDNS問い合わせがコアに渡るとは限りません。
4. ドメイン名の復元を確認：生成された設定がFakeDNSマッピングの識別に対応しているか確認し、必要に応じてFakeDNSのスニッフィング関連設定も確認します。通常のスニッフィングでHTTPやTLSの識別を有効にしただけでは、設定が完了したことにはなりません。
5. キャッシュを消して再テスト：テスト対象のアプリを再起動し、必要に応じて以下のキャッシュ削除コマンドを実行します。ブラウザー独自のキャッシュがある場合は、ブラウザーも再起動してください。

ipconfig /flushdns

ブラウザー内蔵のDoH、アプリ独自のDNS、IPv6は見落としやすいポイントです。UDP 53を取り込むだけでは、すべてのHTTPSによる名前解決を処理できません。IPv6ルーティングが取り込み対象でなければ、アプリが別のネットワーク経路で通信する可能性もあります。IPv6は実際の対応状況に応じて設定してください。切り分けのため一時的に対象ネットワークアダプターのIPv6を無効にして結果を比較する方法もありますが、一般的な解決策として無効化を続けないでください。

DNS設定後にWebサイトを開けない場合：ログから失敗箇所を特定

まずログの接続先アドレス、使用されたアウトバウンド、失敗時刻を確認し、次にエラーのキーワードを調べます。以下はよくあるエラーの例で、毎回まったく同じ文面が表示されるとは限りません。一時的にログの詳細度を上げると原因の特定に役立ちます。ログを共有する前に、サブスクリプションURL、ノードの認証情報、個人のアクセス先ドメインを伏せてください。

変更後に一部のWebサイトだけ開けない場合は、まずルーティングルールとIPv6を確認します。すべてのWebサイトがすぐに開けなくなった場合は、DNSアドレスの形式、ノードの初期名前解決、TUNルーティングを優先して確認してください。クライアントで設定を正常に読み込めない場合は、ルールを追加し続けず、まず今回の変更を元に戻します。

• 元に戻す手順：DNS設定のバックアップを復元し、新たに追加したFakeDNSまたはTUN設定を無効にして、コアを再起動した後にキャッシュを消します。
• 状況を記録：通常のプロキシとTUNのどちらで失敗したか、どのDNSリゾルバーを使ったかを記録します。
• 変更を1つに絞る：各テストではDNSアドレス、アウトバウンドルール、ブラウザーのセキュアDNSのいずれか1つだけを変更します。

よくある質問：検査結果とDNSリーク対策の確認方法