V2RayのDNSリーク検査とv2rayNのDNS設定・対策

DNSリークと判断する際の注意点

ドメインにアクセスする際、通常はまずIPアドレスを取得してから接続します。DNSクエリとWeb接続は別々の経路を通ることがあり、Web通信がプロキシ経由でも、DNSクエリまでプロキシ経由とは限りません。ここでいうDNSリークとは、プロキシ経由にする想定の名前解決リクエストが、ローカルネットワークや想定外のDNSサービスに送られる状態です。

まず、ソフトウェアごとの役割を確認しましょう。v2rayNはサブスクリプション、ノード、ルーティング、コア設定を管理するデスクトップクライアントです。V2RayやXrayなどのコアが、実際のネットワーク処理を行います。VMessやVLESSのノードを使っても、Windows上のすべてのアプリのDNS経路が自動で決まるわけではありません。コアが名前解決を行うかどうかは、アプリから渡されるのがドメイン名か解決済みのアドレスか、またシステムプロキシやTUNがどこまで通信を処理するかによって変わります。

• Web通信の出口IP：Web接続がどこから外部に出たかを示すもので、DNSリゾルバーのアドレスとは異なります。
• 検出されたDNSサーバー：通常は再帰リゾルバーが外部への問い合わせに使うアドレスです。設定画面に入力したアドレスと同じとは限りません。
• 直接接続での名前解決：振り分け設定によって、ローカルドメインを直接接続DNSで解決する設計もあります。そのような設定を一律にリークと判断することはできません。
• DNSサービスの所在地：パブリックDNSのエニーキャストや振り分けの影響を受けるため、国や都市の表示はあくまで判断材料の一つです。

オンライン検査：基準値を記録して比較する

同じネットワーク、同じブラウザー、同じ検査サイトを使います。ブラウザーのアドレスバーに dnsleaktest.com と入力し、標準テストの後に拡張テストも実行します。検査ページは新たなドメインクエリを発生させ、権威DNS側から再帰リゾルバーを確認します。「何台のサーバーが検出されたか」だけでなく、事業者名とWeb通信の出口も記録してください。

1. 直接接続時の基準値を記録する。一時的な直接接続が許容され、機密性の高い通信を行わない環境で、TUNをオフにし、v2rayNで「システムプロキシを解除」を選択します。現在のネットワークで通常使われるDNSサービスを記録してください。直接接続できない場合は基準値の記録を省略し、通信を危険にさらしてまでテストしないでください。
2. プロキシ経由と比較する。利用可能なノードを選び、「システムプロキシを自動設定」を選択します。ルーティングルールはそのままにして、同じテストをもう一度実行してください。ブラウザーのプロキシ拡張機能がシステム設定と競合していないことも確認します。
3. 検査ドメインのルートを確認する。検査サイトや検査用ドメインが直接接続に設定されている場合、結果はプロキシ経由の名前解決を示しません。検査トラフィックをプロキシに送るルールを一時的に選び、再テストした後、元のルールに戻してください。
4. 再読み込みではなく再テストする。設定変更後にコアを再起動し、以前のテストタブを閉じて、新しいテストを開始します。変更前後の結果を記録し、キャッシュされた結果を新設定の効果と混同しないでください。

プロキシ接続中も、直接接続時と同じローカル通信事業者のリゾルバーが検出される場合は、さらに原因を調べる必要があります。同じパブリックDNSサービスに属する複数のアドレスが検出された場合は、負荷分散の可能性があります。一方、リゾルバーが1つしか検出されなくても、すべてのアプリの通信が適切に処理されている証明にはなりません。

v2rayNのリモートDNSと直接接続DNSの設定

現在の設定をバックアップし、使用中のコアを記録します。「設定」→「DNS設定」を開き、現在のコアに対応するDNS設定を確認してください。バージョンによっては、関連項目が「設定」→「パラメーター設定」のDNSタブにあります。項目名、テンプレート、対応するアドレス形式はコアによって異なります。設定項目が見つからない場合は、現在の画面とコアを確認してください。他のコア向けのJSONをそのまま貼り付けないでください。

ポート番号はサービスを区別するためのもので、相互に置き換えられません。127.0.0.1:10808 がプロキシの待ち受け先として稼働していても、そのままDNSサーバーとして使えるわけではありません。該当アドレスでDNSサービスが実際に待ち受けている場合に限り、システムのDNS設定に指定できます。

1. リモートDNSを設定する。対応する形式の入力欄には、https://dns.google/dns-query のようなDoHアドレスを指定できます。これは設定例であり、現在のネットワークから必ず接続できるとは限りません。また、リモートDNSの問い合わせが設定どおりプロキシ経由で送信されることも確認してください。暗号化したDNSをローカルネットワークから送るだけでは不十分です。
2. 直接接続DNSを設定する。直接接続するドメインには、ネットワーク管理者が指定するDNSなど、ローカルから到達できるリゾルバーを選びます。223.5.5.5 はパブリックIPv4 DNSの例ですが、現在のネットワークに適しているかはテストが必要です。内部ドメインを使う場合は、所属ネットワークの設定を優先してください。
3. 起動時の名前解決を確認する。DoHアドレスにはドメイン名が含まれるため、初回接続時にはその名前の解決が必要です。プロキシノードのアドレスがドメイン名の場合も、先に名前解決が必要になることがあります。現在のコアに用意されたブートストラップDNSやドメイン解決の設定を使い、まだ確立していないプロキシ接続にノードの名前解決を依存させないようにしてください。
4. 保存してコアを再起動する。ログに名前解決エラーが出ていないか確認し、同じオンラインテストを実行します。一度に変更する項目は一つにして、DNSサービスに接続できないのか、アウトバウンドルートが誤っているのかを切り分けてください。

ルーティング：DNS解決と接続の経路を揃える

「設定」→「ルーティング設定」を開き、未選択のルールセットではなく、現在有効なルールを確認します。ルーティングでは、対象ドメインをどのリゾルバーで解決するか、解決後の接続をどのアウトバウンドから送るか、という2点を確認します。両者は関係しますが、同じ設定ではありません。

Xrayのドメインルールで、geosite はドメインの集合、geoip はIPアドレスの集合です。ドメインルールは名前に直接マッチしますが、IPアドレスによる判定では先にアドレスの取得が必要な場合があります。ドメイン解決の方針を変更する前に、現在のルールがいつ名前解決を行うかを把握し、IPルールへのマッチを目的とした不要なローカル問い合わせを避けてください。

• ルールの優先順位を確認する。適用範囲の広い直接接続ルールが先にあると、本来プロキシ経由にしたい検査ドメインにも適用される場合があります。
• アウトバウンドのタグを確認する。カスタム設定のDNS用と通信本体用のアウトバウンドには、実在するタグを指定する必要があります。サンプルの名前をそのまま使わないでください。
• 2種類の「全体」を区別する。ルーティングをすべてプロキシ経由にしても、コアに届いた通信の経路が変わるだけです。システムプロキシを使わないアプリまで自動で処理されるわけではありません。
• 内部DNSを維持する。組織ネットワークで使う内部ドメインは、パブリックDNSでは解決できないことがあります。すべてをリモートDNSにする前に、必要な例外を残してください。

基本を確認するには、ルーティング設定の説明とプロキシモードの説明を参照してください。サブスクリプションのグループを変更しても、DNSルーティングは自動で修正されません。サブスクリプション更新後は、現在のノードとルールの組み合わせが想定どおりか確認してください。

ブラウザー、TUN、IPv6の迂回経路を確認する

システムプロキシは、プロキシ設定を参照するアプリを主な対象とします。ブラウザーが独自のセキュアDNSを使う場合や、別のプログラムがシステムの名前解決を直接呼び出したり、独自にDNSリクエストを送信したりする場合があります。システムプロキシを有効にしても検査結果に問題があるからといって、すぐにノードの障害と判断しないでください。まず、リクエストがv2rayNの管理する経路に入っているか確認します。

1. ブラウザーのセキュアDNSを固定する。Edgeで「設定」→「プライバシー、検索、サービス」→「セキュリティ」を開き、「セキュアDNSを使用する」の関連設定を確認します。原因の切り分け中は、変数を減らすため独自のセキュアDNSを一時的にオフにできます。組織のポリシーで管理されている場合は回避せず、管理者にDNS経路を確認してください。
2. 必要に応じてTUNをテストする。システムプロキシを参照しないアプリも処理する場合は、v2rayNを管理者として実行し、画面の「Tunを有効にする」をオンにします。仮想ネットワークアダプター、デフォルトルート、DNSの処理設定を確認してください。TUNの動作は使用するコアによって異なるため、スイッチがオンになっているだけで、すべてのクエリが処理されているとは限りません。
3. IPv6を確認する。AAAAクエリがあるだけでDNSリークとは限りません。IPv6の通信とDNSリクエストが同じプロキシ方針に従っているか確認してください。IPv4だけを処理してIPv6経路をそのまま残すと、出口が一致しない場合があります。
4. 他のネットワーク設定の影響を除外する。別の仮想ネットワークアダプター、組織のトンネル、セキュリティソフトがルートやDNSの優先順位を変えていることがあります。現在の状態を記録してから一つずつテストし、複数のネットワーク設定を同時に変更しないでください。

システムプロキシモードだけで問題が起き、適切に設定したTUNモードでは期待どおりの場合、アプリがシステムプロキシを迂回していないか優先的に確認してください。両方のモードで問題がある場合は、DNSのアウトバウンド、ブートストラップDNS、ブラウザー独自の名前解決を調べます。通信が取り込まれる範囲については、TUN設定の説明も参照してください。

コマンドとログ：名前解決の失敗と経路の問題を切り分ける

PowerShellを開き、まず各ネットワークアダプターのDNS設定を確認してから、システムのキャッシュを消去します。以下のコマンドはWindowsの名前解決環境を確認するもので、v2rayNのHTTPプロキシやSOCKSプロキシを自動で経由するものではありません。コマンドが成功しても、そのシステムDNS経路が使えることを示すだけで、ブラウザーのDNSリーク検査の代わりにはなりません。

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

ipconfig /flushdns で消去されるのはWindows DNSクライアントのキャッシュだけです。ブラウザーやコアのキャッシュはすべて消去されません。テストの前後でブラウザーのテストページを開き直し、コアのDNS設定を変更した後はコアを再起動してください。ログにエラーがないことだけでは、DNSの迂回がない証拠にはなりません。

よくある質問と設定完了時のチェック

設定完了後は、元に戻せるように記録を残してください。現在のノード、コアの種類、システムプロキシまたはTUNの状態、リモートDNSと直接接続DNS、ルール名、2回分の検査結果を記録します。サブスクリプションURL、ノードの認証情報、機密ドメインを含む完全なログは公開しないでください。

• プロキシ対象ドメインのDNSサービスが想定どおりで、直接接続ドメインと内部ドメインにも正常にアクセスできることを確認します。
• v2rayNを再起動した後も設定が有効で、現在のブラウザーセッション中だけ正常なのではないことを確認します。
• Wi-Fi、有線LAN、テザリングを切り替えた後にも確認します。特に各ネットワークアダプターのDNSとIPv6の状態を確認してください。
• クライアントのアップグレード、コアの切り替え、ルーティングテンプレートの変更後には再テストし、以前の環境での結果をそのまま当てはめないでください。