V2RayのDNSリーク検出と防止設定：検出方法・原因分析・修正手順

プロキシ接続が正常でも、すべてのアプリ通信がV2RayまたはXrayのコアを経由しているとは限りません。通常、ドメイン名は接続前にIPアドレスへ変換されます。この処理をシステムネットワークのデフォルトDNSが担っていると、問い合わせ記録がローカルネットワークから独立して送信される可能性があります。DNSリークの確認で重要なのは、ノードを何度も切り替えることではなく、「誰が問い合わせを開始し、どの入口を通り、最終的にどのリゾルバーが応答したか」を確認することです。本記事の検証環境はv2rayN 7.14.x、v2rayNG 1.10.xです。マイナーバージョンによりメニュー名が多少異なる場合がありますが、確認の順序は変わりません。

DNSリークとは：まず名前解決の経路を分解する

ドメインへアクセスするとき、アプリ自身が名前解決する場合もあれば、ドメインをシステムリゾルバーへ渡す場合、完全なドメイン名をHTTPまたはSOCKSプロキシへ渡す場合もあります。どの経路を通るかによって、DNS問い合わせがプロキシコアへ入るかどうかが決まります。システムプロキシでは、システムのプロキシ設定に従うアプリの通信だけが引き継がれます。バックグラウンドプログラム、一部のコマンドラインツール、UDP問い合わせを独自に送信するアプリは、ネットワークインターフェースに設定されたDNSへ直接アクセスする可能性があります。

DNSリークは、検出ページに複数のリゾルバーが表示されることと同義ではありません。パブリックDNSサービスではAnycastノードが使われることが多く、1回の問い合わせでも複数の出口拠点が表示される場合があります。ブラウザーで暗号化DNSを有効にしている場合も、OSの設定を経由せず、ブラウザー指定のDNSサービスと直接通信することがあります。確認すべきなのは、現在利用している固定回線またはモバイル回線の事業者リゾルバーが結果に現れていないか、プロキシ接続前後でリゾルバーの集合が完全に同じではないか、UDPまたはTCPの53番ポートを使う平文通信がローカルインターフェースから出ていないか、という点です。

V2RayとXrayの設定にあるdnsオブジェクトは、コア内部の名前解決を担います。ただし、OSが生成するすべてのDNSリクエストを自動的に引き継ぐわけではありません。ドメイン名がすでにコアへ渡っているか、またはシステムDNS通信がTUNや透過的な入口などによって捕捉された場合に限り、内蔵DNS設定が機能します。これが「DNSを設定したのに検出結果が変わらない」最も一般的な原因です。

検出の基準を作る：1回のテストだけで判断しない

検出前に、ブラウザーで独立して動作する可能性のあるセキュアDNSを無効にし、他のネットワークプロキシツールも一時停止します。現在のネットワーク接続は維持し、システムDNSアドレス、v2rayNまたはv2rayNGの動作モード、選択中のノード、ルーティングモードを記録してください。これにより、ブラウザー独自の名前解決とクライアントが引き継いだ後の結果を区別できます。

1. 直接接続の結果を記録

   クライアントを完全に終了してからDNS検出ページを開き、標準テストと拡張テストをそれぞれ実行します。リゾルバー数、所属ネットワーク、国または地域を記録してください。拡張テストは連続2回の実行を推奨します。

2. システムプロキシを有効化

   v2rayN 7.14.xで「システムプロキシ」→「システムプロキシを自動設定」を選択します。デフォルトのローカルSOCKSポート10808とHTTPポート10809はそのままにし、新しいブラウザーウィンドウでテストを繰り返します。

3. TUNモードへ切り替え

   「設定」→「パラメータ設定」→「TUNモード設定」を開き、DNSハイジャックの範囲を確認してからTUNを有効にします。ノードへ再接続し、10秒待ってから同じテストを実行します。

4. 3組のデータを比較

   直接接続、システムプロキシ、TUNの3組の結果を比較します。システムプロキシではローカルリゾルバーが表示され続け、TUNでは表示されなくなる場合、問題は通常ノード本体ではなく、システムDNSの捕捉範囲にあります。

5. 切断後に再検証

   クライアントを終了して検出ページを更新し、システムネットワークが基準時の結果へ戻ることを確認します。終了後も異常なDNS設定が残る場合は、ネットワークアダプターに手動アドレスが残っていないか確認し、ネットワークの切断と再接続を1回行います。

1回の拡張テストでは20～50件の問い合わせが発生することがあり、パブリックDNSサービスはそれらを複数のノードへ割り当てます。より確実に確認するには、約15秒間隔で3回連続してテストし、繰り返し現れるリゾルバーを安定した結果として扱います。1回だけ異なるアドレスが現れた場合は、キャッシュ、ネットワーク切り替え、DNSサービスの負荷分散を先に確認し、すぐに設定全体を変更しないでください。

OS標準のネットワーク監視ツールで53番ポートも確認できます。テスト中は検出ページを1つだけ開き、宛先ポート53のUDPまたはTCP接続が物理ネットワークアダプターから出ていないかを確認します。TUNを有効にしても53番ポートへの直接通信が継続する場合、アプリが引き継ぎを回避しているか、DNSハイジャックルールが該当するプロトコルファミリーを対象にしていない可能性があります。

テスト状態	結果の例	優先して確認する点
直接接続	ローカルネットワークのリゾルバー3件、所要時間42～68 ms	基準データとして保存し、比較に使用
システムプロキシ	同じ3件のリゾルバーが引き続き表示される	ブラウザーまたはシステムDNSがコアに入っていない
TUNモード	設定したパブリックDNSサービスのみ表示、所要時間85～120 ms	DNSの捕捉とプロキシ経由の外向き通信が有効
TUNモード	パブリックリゾルバーとローカルリゾルバーが同時に表示される	迂回問い合わせ、または対象外のプロトコルファミリーが存在

v2rayNの修正：内蔵DNSとルーティングルールを組み合わせる

v2rayNのデスクトップ版は通常Xrayコアを使用します。修正前に、コアの種類と設定の取得元を確認してください。通常のサブスクリプションノードではクライアントが実行設定を生成し、カスタムJSONではユーザーが直接管理します。同じ項目を両方で変更すると、サブスクリプション更新やコア再起動の際に手動設定が再生成された設定で上書きされる可能性があります。

1. コアの種類を確認

   「設定」→「パラメータ設定」→「Coreタイプ」を開き、現在のノードがXrayを使用していることを確認します。保存してコアを再起動し、ログ上部で実際に読み込まれたコア名とバージョンを確認します。

2. ローカルポートを確認

   「設定」→「パラメータ設定」→「基本設定」で、SOCKSポート10808とHTTPポート10809が他のプログラムに使用されていないか確認します。ポート競合があると、ブラウザーが直接接続へフォールバックすることがあります。

3. ドメインポリシーを設定

   「設定」→「ルーティング設定」を開き、現在のルールセットのドメインポリシーを確認します。名前解決結果に基づいてIPルールを照合する場合はIPIfNonMatchを使用できます。ドメインルールだけで振り分ける場合は、すべてのドメインを無条件に先行解決しないでください。

4. DNSの捕捉を有効化

   「設定」→「パラメータ設定」→「TUNモード設定」を開き、DNSハイジャックを有効にしてUDP 53を対象に含めます。保存後、クライアントを終了して再起動し、仮想ネットワークアダプターとルーティングテーブルを完全に再構築します。

5. 実行ログを確認

   ノードへ接続した後にログを開き、これまで名前解決していなかったドメインへアクセスします。正常であれば、ドメインがルーティング判定へ進むログが表示されます。ローカル名前解決のタイムアウトや宛先アドレス検索失敗が連続して表示される状態は避けるべきです。

以下は内蔵DNSの主要フィールドを説明するための構成であり、クライアントが生成した完全な設定をそのまま上書きするものではありません。queryStrategyは返すアドレスの種類を制御し、serversは候補リゾルバーを指定します。現在のネットワークでIPv6ルートが不安定な場合は、まずUseIPv4で再現可能な基準を作り、経路が正常であることを確認してから実際の要件に応じてアドレス種別の方針を調整します。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "223.5.5.5"
    ]
  }
}

サーバーアドレスを追加するだけでは不十分です。コアが送信するDNSリクエストにも明確な外向き経路が必要です。そうしなければ、暗号化DNSへの接続もデフォルトルールに従って直接接続される可能性があります。中国本土と国外のドメインを分ける設定では、特定のDNSサービスのドメインまたはアドレスを想定した外向き経路に一致させ、最終的なDNSルールを先に捕捉する広範なルールより前に配置します。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "network": "udp",
        "port": 53,
        "outboundTag": "proxy"
      }
    ]
  }
}

v2rayNGとv2flyNG：モバイル回線でVPNの引き継ぎを確認

v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。両者ではDNSフィールドの対応範囲とデフォルト動作が完全には同じではないため、デスクトップ版のカスタム設定をそのままコピーして有効にしないでください。モバイル版では、まずVPN接続が実際に確立しているかを確認し、次にローカルDNS、リモートDNS、ドメインポリシー、アプリごとのプロキシ範囲を確認します。

1. ネットワークの種類を記録

   Wi-Fiとモバイル回線のそれぞれでテストし、ネットワークを切り替えた後は接続を停止して再起動します。切り替え前の検出タブは使い回さず、キャッシュされた結果が新しいテストへ混ざらないようにしてください。

2. VPN設定を確認

   v2rayNG 1.10.xで「設定」→「VPN設定」を開き、現在VPNモードを使用していることを確認します。また、検出に使っているブラウザーがアプリごとのプロキシ対象から外れていないか確認してください。

3. DNS項目を確認

   「設定」→「VPN設定」→「DNS設定」を開き、ローカルDNSとリモートDNSを確認します。リモートDNSには現在のネットワークから到達できるアドレスを選び、変更後は接続を停止して再起動します。

4. ドメインポリシーを確認

   「設定」→「ルーティング設定」を開き、ドメインポリシーと定義済みルールを確認します。宛先IPに基づく判定が必要なルールでは、名前解決結果を該当ルールで利用できることを確認し、ドメインが誤った外向き経路で先に解決されないようにします。

5. 2種類のネットワークで再検証

   2種類のネットワークそれぞれで、15秒間隔の拡張テストを3回行います。モバイル回線でだけローカルリゾルバーが現れる場合は、ネットワーク切り替え後のVPN再構築とIPv6ルートを優先して確認します。

アプリごとのプロキシ設定は、モバイル版で見落とされやすいポイントです。検出に使うブラウザーがプロキシ対象に含まれていないと、ページ本体もDNS問い合わせもネットワークへ直接アクセスするため、結果は当然ローカルのままです。一方、ブラウザーがVPN対象でも、別のバックグラウンドアプリが除外されていれば、そのDNSリクエストはデフォルトネットワークを通り続ける可能性があります。この場合、システムレベルの監視には迂回通信が現れても、ブラウザーの検出ページにはバックグラウンドアプリの問い合わせが表示されないことがあります。

v2flyNGでv2flyコアを使用する場合は、そのコアが実際に受け付ける設定フィールドを基準にしてください。インポートしたサブスクリプションにノードのプロトコル、アドレス、ポートしか含まれていない場合、DNSとルーティングは通常クライアント側のローカル設定で決まり、単純なノードリンクから完全なポリシーが自動取得されるわけではありません。設定を移行する際は、VMessまたはVLESSのノードパラメータ、トランスポート設定、DNS、ルーティングルールを個別に確認し、ノード名だけを比較しないでください。

• Wi-Fiは正常、モバイル回線だけ異常：VPN接続を再構築し、IPv6の到達性とモバイル回線が提供するリゾルバーがまだ呼び出されていないかを確認します。
• すべてのネットワークでローカルリゾルバーが表示される：ブラウザーが除外されていないか、リモートDNSが機能しているか、クライアントがVPNモードになっているかを確認します。
• 検出結果は正常だが一部のドメインに失敗する：ドメインポリシー、DNSの振り分けルール、リゾルバーが対象ドメインへ返す結果を確認します。
• ノードのIPには接続できるがノードのドメインに失敗する：サーバーのドメイン用に独立した到達可能なブートストラップ名前解決を確保し、プロキシ確立前の循環依存を避けます。

修正後の受け入れ確認：名前解決・ルーティング・失敗時のフォールバックを同時に確認

修正後は検出ページを1回見るだけで終わらせないでください。完全な受け入れ確認では、コールドスタート、ネットワーク切り替え、ノード切り替え、クライアント終了の4状態を確認します。コールドスタートではブートストラップ名前解決を、ネットワーク切り替えではVPNとルーティングテーブルの再構築を、ノード切り替えでは各サーバーアドレスの名前解決経路を、クライアント終了ではシステム設定が復元されることを確認できます。

簡潔な受け入れ確認記録を1つ残すことをおすすめします。基準の例：「v2rayN 7.14.x、Xrayコア、TUNモード、リモートDNSはHTTPS接続、3回連続のテストでローカルネットワークのリゾルバーなし、物理ネットワークアダプターの監視中にUDP 53への継続的な直接通信なし」。具体的な状態を記録しておくと、「修正済み」とだけ書くより、クライアント更新やルール変更による差分を後から比較しやすくなります。

確認項目	合格条件	失敗時の確認ポイント
コールドスタート時の名前解決	10秒以内にノードのドメインを解決し、接続を確立できる	ブートストラップDNS、サーバードメイン、外向き通信の循環
連続テスト	3回の結果が安定し、ローカルネットワークのリゾルバーが表示されない	ブラウザーのセキュアDNS、システムキャッシュ、迂回アプリ
53番ポートの監視	物理ネットワークアダプターからDNSへの継続的な直接問い合わせがない	TUNの捕捉範囲、UDPとTCPのルール
ネットワーク切り替え	再接続後の名前解決結果が切り替え前と一致する	VPNの再構築、IPv6ルート、リモートDNSの到達性
終了後の復元	システムDNSが変更前の基準へ戻る	ネットワークアダプターの手動DNSと残存プロキシ設定

検出結果が安定しない場合は、「アプリの入口、システムによる引き継ぎ、コアのDNS、DNSの外向き通信、最終ルーティング」の5層に分けて範囲を絞ります。リモートDNS、ドメインポリシー、ルーティングルール、動作モードを同時に変更しないでください。毎回1項目だけ変更して同じテストを繰り返すことで、どの層が実際に効果を発揮したのか判断できます。

よくある質問