V2RayのDNSリークを検出する方法｜リモートDNS・FakeDNS・TUNの設定手順

1. DNSリークとは：名前解決の出口と通信の出口が一致しない状態

DNSはドメイン名をIPアドレスに変換します。プロキシ接続が確立していても、その前のDNS問い合わせまでプロキシ経由とは限りません。たとえば、アプリが先に家庭用ルーターへ接続先のIPアドレスを問い合わせ、その後でローカルのプロキシポートに接続する場合、Webページの通信はプロキシ経由でも、ローカルのリゾルバーにはアクセスしたドメインが知られる可能性があります。リークの判断基準は、ローカルのリゾルバーが使われたかどうかではなく、問い合わせがあらかじめ決めた振り分けルールに反していないかどうかです。

中国本土のWebサイトをルールに従って直接接続する場合、直接接続用DNSを使うのは一般的に問題ありません。一方、プロキシ経由でアクセスすべきドメインの問い合わせがローカルネットワークのリゾルバーに送られるなら、この記事で防ぐ対象となる迂回です。VMessやVLESSはプロキシ通信を担いますが、システム内のすべてのDNS問い合わせを自動的に引き受けるわけではありません。サブスクリプションに含まれるのはノード設定であり、端末側のDNSルール一式とは限りません。

2. DNSリークの検出方法：基準を記録し、物理ネットワークアダプターを確認

ブラウザーの検査ページに表示されるのは、観測された再帰リゾルバーの出口であり、クライアントが直接接続したサーバーとは限りません。パブリックDNSでは出口の地域が異なる場合があり、表示都市も古い位置情報データに基づいていることがあります。そのため、「リゾルバーの都市とノードの都市が違う」ことだけを根拠にしないでください。問い合わせがどのネットワークアダプターを通ったか、現在のルールに合っているかも併せて確認します。

1. 基準となる状態を記録します。TUNとシステムプロキシを無効にし、システムDNSアドレス、ブラウザーのセキュアDNSの状態、検査ページに表示されたリゾルバーを記録します。テスト中は機密性の高いサイトにアクセスしないでください。
2. 条件を固定します。同じノードと同じルーティング設定を有効にし、同じページでテストします。ノードの切り替えとブラウザーDNSの変更を同時に行うと、どの設定が結果に影響したのか特定できません。
3. キャッシュを消去します。Windowsではターミナルで ipconfig /flushdns を実行し、ブラウザーを終了して再起動します。コア内蔵のDNSキャッシュは、通常コアの再起動も必要です。
4. システムの問い合わせを確認します。次のコマンドを実行し、既定のリゾルバーと問い合わせ結果を記録します。この結果で確認できるのはシステムの名前解決経路であり、ブラウザーも同じ経路を使うとは限りません。
5. 物理ネットワークアダプターを確認します。パケットキャプチャツールで、通信中の有線または無線ネットワークアダプターを選び、対象の問い合わせがローカルのリゾルバーへ直接送信されていないか確認します。仮想ネットワークアダプター上にDNSパケットが見えても、それだけでは端末の外へ出たことを意味しません。

ipconfig /all
ipconfig /flushdns
nslookup example.com

# パケットキャプチャ用フィルター：従来型DNSと一般的なDoT接続を確認
udp.port == 53 || tcp.port == 53 || tcp.port == 853

example.com は問い合わせ方法を示すためのサンプルドメインであり、リーク検査サービスではありません。実際の再テストでは、ルール上プロキシ経由になることが明確なドメインを選んでください。ブラウザー内蔵のDoHはHTTPSを使うため、ポート53のフィルターだけでは特定できません。セキュアDNSの設定、接続先アドレス、クライアントのルーティングログを照合して判断してください。

3. v2rayNのリモートDNSと直接接続用DNS：リゾルバーだけでなく出口も設定

v2rayNで「設定」→「パラメーター設定」を開き、現在のコアと待ち受け設定を確認します。次に「設定」→「DNS設定」を開いて、使用するコアのDNS設定を確認してください。バージョンによってメニューの場所や項目名が異なる場合があるため、実際の画面と生成された設定を基準にします。特に、通常のプロキシで使うコアとTUNで使うコアを区別してください。一方のコア用DNS JSONを、もう一方の設定欄に貼り付けないようにします。

リモートDNSはプロキシ経由でアクセスするドメインに、直接接続用DNSは直接接続するドメインに使います。リモートリゾルバーを設定するのは第一歩にすぎません。リゾルバーへの接続が直接接続のままなら、暗号化された問い合わせを使っても「名前解決もプロキシの出口経由にする」という目的は達成できません。DoHが保護するのはリゾルバーまでの通信であり、プロキシの出口を自動で選ぶわけではありません。

• まずブートストラップ名前解決を設定します。ノードサーバーにドメイン名を使っている場合、プロキシ接続の確立前に利用可能なIPアドレスが必要です。ノードのドメイン名には到達可能なブートストラップ経路を個別に用意し、「プロキシに接続するにはノードの名前解決が必要で、名前解決にはプロキシ接続が必要」という循環を避けてください。
• 直接接続用の名前解決範囲を限定します。直接接続することが明確なドメインだけを直接接続用リゾルバーに割り当て、すべての問い合わせが失敗したときの無制限なフォールバック先にはしないでください。
• ルールの順序を確認します。リゾルバーの出口ルールは、先に一致する可能性のある広範な直接接続ルールより前に配置します。通常、ルーティングは上から順に照合され、最初に一致したルールで経路が決まります。

XrayのDNS設定例：直接接続するドメインを個別に判定し、それ以外はリモートDNSで問い合わせ

以下はXray設定形式の例です。geosite:cn の分類を利用するには、geosite.dat が必要です。ルールデータがない場合は、データファイルを修復するか、明示的に指定した独自のドメインリストを使ってください。アドレス例は役割を示すためのもので、現在のネットワークから到達できるか確認が必要です。disableFallbackIfMatch は、一致したドメイングループの問い合わせが失敗した後に別のリゾルバーへ切り替わるのを制限しますが、ブラウザーやアプリが独自に送信する問い合わせまでは制御できません。

{
  "dns": {
    "queryStrategy": "UseIP",
    "disableFallbackIfMatch": true,
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query"
      }
    ]
  }
}

以下のルールは既存の routing.rules に追加してください。ルーティング全体を置き換えてはいけません。ここでは設定内に proxy と direct という名前のアウトバウンドがあるものとします。クライアントが生成したタグ名が異なる場合は、実際のタグ名を使ってください。この例はリゾルバーのIPアドレスを基準に出口を選ぶため、同じIPアドレス宛ての他の接続にも影響します。実際の設定では既存ルールとの兼ね合いを確認してください。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["1.1.1.1/32"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["223.5.5.5/32"],
        "outboundTag": "direct"
      }
    ]
  }
}

4. TUNモードでDNSリークを防ぐ：通信を取り込んだ後はDNSとIPv6も確認

TUNはシステムの通信を仮想ネットワークアダプターに取り込み、システムプロキシを参照しないアプリにも対応できます。ただし、「すべての通信を必ずプロキシへ送る」スイッチではありません。最終的に直接接続するかプロキシ経由にするかは、引き続きルーティングルールで決まります。DNSを捕捉して制御された名前解決経路に送るかどうかも、TUNの設定によります。まず現在の設定を保存し、v2rayNのメイン画面で「TUNを有効にする」をオンにします。システムの指示に従って権限を付与し、起動ログを確認してください。

1. 仮想ネットワークアダプターの作成を確認します。コアが起動しない場合は、DNSを変更して起動障害を隠そうとせず、権限、ドライバー、設定のエラーを先に解消してください。
2. DNSの取り込みを確認します。TUN設定に適切なDNSの捕捉またはリダイレクトルールが含まれているか確認し、システムへの問い合わせとパケットキャプチャで検証します。ネットワークアダプターのDNSアドレスを変更するだけでは、アプリに固定されたリゾルバーを制御できません。
3. ルーティングの除外設定を確認します。必要に応じてLAN通信を直接接続にできますが、除外範囲によってプロキシ経由にすべきDNS問い合わせまで迂回していないか確認してください。リモートリゾルバーのアドレスも、広範な直接接続ルールに先に一致しないようにします。
4. IPv6も併せて確認します。IPv4がTUNに取り込まれていても、IPv6も同様とは限りません。IPv6のデフォルトルートとDNSサーバーを確認してください。IPv6が不要な場合は、影響範囲を把握したうえで比較のため一時的に無効化できますが、一般的な解決策として常に無効にするのは避けてください。
5. 再接続後とスリープ復帰後も確認します。Wi-Fiネットワークを切り替えた後やスリープから復帰した後に、もう一度問い合わせを実行します。ネットワークアダプターのDNS、システムルート、仮想ネットワークアダプターの状態が変化している可能性があります。

v2rayNのTUN機能ではsing-boxコアが使われる場合があり、そのDNSやFakeIPの設定構造はXrayのFakeDNSとは異なります。対応する設定画面、またはコアごとの設定形式を使ってください。v2rayNGはXray、v2flyNGはV2Flyを使用しますが、AndroidのVPNによる取り込み、アプリの除外、DNSの動作はクライアント設定にも左右されます。デスクトップ向けJSONをAndroidの設定画面にそのまま入力しないでください。

5. FakeDNSの設定方法：同じ経路内で仮想アドレスをドメイン名に復元

FakeDNSはWebサイトの実IPアドレスではなく、アドレスプール内の対応アドレスを返します。アプリがそのアドレスへ接続すると、コアが対応情報から元のドメイン名を復元し、ドメインルールを適用してプロキシ接続を行います。実IPアドレスを事前に取得する必要を減らせますが、暗号化DNSではなく、単独でリークを防げるわけでもありません。ノードのドメイン名に対するブートストラップ名前解決、直接接続先、制御されていないアプリのDNSは別途対処が必要です。

以下は、この機能に対応するXrayコアの設定例です。198.18.0.0/15 はこの種のマッピングによく使われるベンチマーク用アドレス範囲であり、Webサイトの実アドレスではありません。使用前に、LAN、他のVPN、既存のルートとの競合がないか確認してください。poolSize はマッピングプールの容量を表し、通信速度や同時接続数を表すものではありません。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

後続の接続を受ける入 inbound側にも、FakeDNSのドメイン名を復元する機能が必要です。たとえば、次のスニッフィング設定を該当するインバウンドに追加します。既存のインバウンドオブジェクトに統合し、単独のインバウンドとして追加しないでください。これは「マッピングの生成と復元」の例にすぎず、DNS通信の取り込み、ノードのブートストラップ名前解決、直接接続ドメインの例外ルールは含まれていません。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"],
    "metadataOnly": true
  }
}

• アドレスプールへの通信を取り込む必要があります。アプリがマッピングアドレスを受け取った後、その接続が物理ネットワークアダプターから直接送信されてはいけません。そうでないと、存在しないパブリックアドレスへの接続を試みます。
• マッピングと接続の対応を維持します。あるインスタンスでマッピングを生成し、そのマッピング情報を持たない別のインスタンスに接続を渡すことはできません。
• 直接接続する通信には実際の名前解決も必要です。ドメイン名を復元した後、直接接続のアウトバウンドで実IPアドレスを問い合わせる場合があります。この問い合わせも直接接続用DNSのルールに従わせてください。
• 再起動後はキャッシュを消去します。コアの再起動で古いマッピングが失われても、アプリには以前のアドレスがキャッシュされている場合があります。古いマッピングをノード障害と誤認しないよう、システムとアプリのキャッシュを消去してから再度問い合わせてください。

6. DNSエラーのよくある原因：どの段階で失敗したかを確認

以下はログに表示される可能性があるエラーの例です。ログの完全な前置きや表現はコアのバージョンによって異なります。エラー1件だけでは、おおよその原因しか分かりません。再テストでは一度に変更する設定を1つに絞り、ノード接続、リモートリゾルバーへの接続、接続先サイトのどこでエラーが発生したかを記録してください。

7. 再テストのQ&A：ブラウザーが正常でも端末全体が正常とは限らない

最終確認では、プロキシ経由のドメインが制御された名前解決経路を使い、リモートリゾルバーへの接続が想定したアウトバウンドを通り、直接接続ドメインがルールどおりに名前解決され、ノードアドレスのブートストラップが独立して行え、TUNとIPv6の取り込み範囲が明確であることを一連の流れとして確認します。基本設定を確認する場合は、サブスクリプションのインポートガイド、DNS設定ガイド、TUNモードの解説をご覧ください。