DNSリークの検出方法：V2RayでDNS漏れを防ぐ設定手順

まずDNS検査の結果が本当にリークか確認する

DNSはドメイン名をIPアドレスに変換します。ブラウザーでWebサイトを開くと、通常はまずリゾルバーに問い合わせ、その結果に対応するサーバーへ接続します。プロキシ接続が正常でも、この問い合わせまでプロキシを通るとは限りません。Webトラフィックはノード経由でも、DNSリクエストだけがルーター、通信事業者のリゾルバー、またはシステムに設定されたサーバーへ送られることがあります。

リークの判断は、検査ページに表示されたDNSアドレスの数だけで決められません。パブリックDNSはグローバルな振り分けを使うため、表示される出口都市がノードの都市と異なることがあります。リゾルバー名も、パブリックサービス事業者やその上流ネットワークの場合があります。本当に確認すべきなのは、接続前に表示されたローカル通信事業者のリゾルバーが接続後も現れるか、そしてDNSリクエストが想定したプロキシや暗号化経路を迂回していないかです。

1. クライアントを完全に終了し、現在のパブリック出口地域、DNS提供元の数、リゾルバーの地域を記録します。
2. クライアントを起動し、場所が明確なノードを選択して、システムプロキシまたはTUNを有効にしてから検査ページを更新します。
3. ブラウザーやシステムのDNSキャッシュが古い結果を返すのを避けるため、新しいドメインで再テストします。
4. 2回の結果を比較します。IPだけでなく、通信事業者名、ネットワークの所属、地域が依然としてローカルのアクセス網を指しているかも確認します。

DNSがV2Ray接続を迂回する理由

システムプロキシが主に処理するのは、HTTPまたはSOCKSプロキシに対応したアプリの接続であり、OSが送信するすべてのDNSパケットを自動的に引き受けるわけではありません。アプリによっては、まずシステムの名前解決APIでIPを取得してから接続をプロキシへ渡します。この場合、ドメイン問い合わせはすでに物理NICから送信されています。一方、SOCKSのリモート名前解決に対応するアプリは、ドメインを直接プロキシ側で処理させるため、両者の結果は異なります。

ブラウザー独自のセキュアDNS、ルーターから通知されたDNS、企業ネットワークのポリシー、仮想NICの設定も、それぞれ別の解決経路を作ることがあります。切り分けでは、「誰が問い合わせを開始したか」「誰に問い合わせを渡したか」「どのアウトバウンドからパケットを送ったか」を分けて確認する必要があります。DNSアドレスを1つ変更するだけで、問い合わせが通るアウトバウンドが変わらなければ、経路の問題は通常解決しません。

よくある4つの迂回経路

• システムプロキシがWeb接続だけを処理：システムDNSは引き続き、ルーターの53番ポートへUDP問い合わせを送信します。
• ブラウザーが独自に名前解決：ブラウザーに設定したセキュアDNSがクライアントの内蔵DNSルールに従わず、他のアプリとは異なる検査結果になります。
• TUNの引き受け範囲が不完全：物理NICの優先順位、除外ルート、アプリのバイパス設定により、一部の53番ポート通信が仮想NICに入らないことがあります。
• ノードのドメイン名を先に解決する必要がある：クライアントはノードへ接続する前にサーバーのIPを取得する必要があります。この初期解決は通常、トンネル確立前に行われるため、信頼できる直接接続用リゾルバーを別途設定します。

v2rayNで内蔵DNSと分流を設定する

ここではv2rayN 7.12.5、Xray-core 25.6.8のテスト画面を例にします。メニュー名は小バージョンによって変わる場合がありますが、手順は同じです。まずリゾルバーを決め、国内ドメインとリモートドメインを対応するルールへ振り分け、最後に生成された設定とコアのログを確認します。システムプロキシだけを使う場合、v2rayNのローカルSOCKS入口は通常 127.0.0.1:10808 です。アプリがプロキシに対応しているか、システムプロキシに引き渡される場合にのみ、この入口を通ります。

1. 「設定」→「DNS設定」を開き、変更に失敗しても戻せるよう、現在の内容を先にバックアップします。
2. リモートリゾルバーには、暗号化問い合わせに対応したアドレス（例：https://1.1.1.1/dns-query）を設定し、そのリゾルバーへの接続がルールに従ってプロキシのアウトバウンドへ入ることを確認します。
3. 中国国内のドメイン用に独立したリゾルバー（例：223.5.5.5）を残し、geosite:cn と geoip:cn で対象範囲を限定します。
4. 「設定」→「パラメーター設定」を開き、コアの種類がXrayであることを確認します。また、ルーティングモードによってすべてのDNS接続が直接接続へ強制されていないか確認します。
5. 保存後にコアを再起動し、ログで名前解決のタイムアウト、ノードのドメイン名を解決できないエラー、DNSアウトバウンドの拒否がないか確認します。

カスタム設定を使う場合は、以下の構造を内蔵DNSの分流を理解する参考にしてください。すべてのサブスクリプションにそのまま適用できる汎用ファイルではありません。グラフィカルインターフェースがユーザー設定とサブスクリプション生成項目を統合する場合もあるため、入力欄だけでなく最終的に生成された設定を重点的に確認します。

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

queryStrategy は、どの種類のアドレスを優先して問い合わせるかを決めます。IPv4だけが必要なら UseIPv4 を使うと、デュアルスタック環境での不確定要素を減らせます。ネットワーク、ノード、接続先サイトがIPv6を安定して利用できると確認してから、IPv6を含む方式を選択してください。これはDNS接続が直接接続かプロキシかを自動で決めるものではなく、アウトバウンドは引き続きルーティングルールで制御されます。

v2rayNGでリモートDNSを設定する

Androidで重要なのは、VPNモードが仮想ネットワークインターフェースを通じて、より多くの通信を引き受ける点です。以下はv2rayNG 1.10.31、Xrayコアを例にしています。「設定」→「VPN設定」を開き、「リモートDNS」「ローカルDNS」とローカルDNSの有効状態を確認します。画面の翻訳は異なる場合があるため、項目の用途を基準に判断してください。

1. 「設定」→「VPN設定」→「リモートDNS」で、プロキシ経由にするドメインの解決に使うリゾルバー（例：https://1.1.1.1/dns-query）を入力します。
2. 「ローカルDNS」には、直接アクセスできるリゾルバー（例：223.5.5.5）を残します。中国国内向けルールや、ノード接続前に必要な初期解決に使用します。
3. 「設定」→「ルーティング設定」を開き、中国国内ドメインのルールがフォールバックルールより前にあることを確認します。先にグローバルプロキシルールへ一致するのを防ぐためです。
4. VPNを切断してから再接続します。メイン画面へ戻るだけでは不十分です。古い仮想インターフェースやDNSキャッシュが残ることがあります。
5. ブラウザーと、別の通信を必要とするアプリでそれぞれテストします。ブラウザーだけ結果が異なる場合は、ブラウザー独自のセキュアDNS設定も確認します。

v2rayNGはXrayコアを使用し、VMessとVLESSのノードはいずれも内蔵DNSやルーティング分流と組み合わせられます。プロトコル名だけでDNSリークを自動的に防げるわけではありません。結果を決めるのは、VPNの引き受け範囲、DNS設定、アウトバウンドルールです。v2flyNGでv2flyコアを使う場合も切り分けの考え方は同じですが、対応する設定項目は実際に生成された設定を基準にしてください。Xray専用の拡張項目をそのまま流用してはいけません。

TUNモードでさらに確認すべき箇所

TUNモードは、システムプロキシを自発的にサポートしないアプリの通信も仮想NICで引き受けるため、DNSを一括処理するのに適しています。ただし、スイッチを入れるだけで終わりではありません。仮想NICのルート優先順位、DNSハイジャックルール、LANのバイパス範囲、IPv6経路を互いに整合させる必要があります。特に物理NICでIPv6 DNSがまだ利用できる場合、IPv4のテストは正常に見えても、一部の問い合わせが別経路から送信される可能性があります。

TUN確認チェックリスト

• クライアントが十分な権限で仮想NICを作成していること、ログにルート書き込み失敗がないことを確認します。
• UDPとTCPの53番ポートがどちらも処理されているか確認します。一般的なUDP問い合わせだけを検証してはいけません。
• LANアドレスのバイパスルールがプライベートネットワークだけを対象にしていることを確認します。パブリックDNSアドレスを誤って直接接続のセグメントに含めないでください。
• IPv6を一時的に使わない場合は、クライアントのDNS問い合わせ方式とシステムのネットワーク層で設定を一致させ、片方だけを無効にしないようにします。
• FakeDNSを有効にする場合は、ドメインスニッフィングとルーティングルールによって、マッピングアドレスを元のドメイン名へ戻せることを確認します。

FakeDNSはまず予約アドレスを返し、コアが「仮想IPと元のドメイン名」の対応関係を保存します。宛先IPだけを持つ接続を引き受け、ドメイン分流を引き続き有効にできる点が利点です。ただし、実際にリモート解決が完了したことを意味するわけではありません。最終的な接続前には、コアがルールに従って実アドレスを取得する必要があります。マッピングプールの競合、アプリの長すぎるキャッシュ、スニッフィングの無効化などで接続に失敗することがあります。

コアのログからDNSエラーを特定する

検査ページで分かるのは結果だけで、原因の特定にはコアのログが適しています。まずログレベルを一時的に情報または警告へ変更し、再接続して、これまで開いたことのないドメインへアクセスします。エラーがノードアドレスの解決時、リモートリゾルバーへの接続時、または宛先アドレス取得後のアウトバウンド段階のどこで発生したかを重点的に確認します。

ログにDNSエラーがないのに検査でローカルリゾルバーが表示される場合、問題はコアの外側で発生している可能性が高いです。アプリがシステム解決を使っている、ブラウザーが独立した接続を確立している、またはDNSパケットがTUNに入っていないことが考えられます。この場合はVMessやVLESSのノードを何度も交換するのではなく、システムプロキシとTUNの2モードを比較します。

修復後に最終確認する方法

最終確認では少なくとも「初回問い合わせ」「再問い合わせ」「切断からの復旧」の3状態を確認します。初回問い合わせでは実際の解決経路を、再問い合わせではキャッシュの安定性を、切断からの復旧では再接続後に仮想NICやルーティングルールが再読み込みされない問題を確認できます。

1. クライアントを終了し、出口地域、DNSネットワークの所属、リゾルバー数を含む基準結果を記録します。
2. システムとブラウザーのDNSキャッシュを消去し、クライアントを起動して、これまでテストしたことのないドメインへアクセスします。
3. 検査を3回連続で実行し、各回の間隔を少なくとも10秒空けます。ローカル通信事業者のリゾルバーが再び表示されるか記録します。
4. 15秒間切断してから再接続し、さらに3回検査します。再接続後も設定が有効なままか確認します。
5. Wi-Fiとモバイルネットワークを一度切り替えて接続を再確立し、初期DNSとTUNルートがネットワークの変化に対応できるか確認します。

目標は、検査ページに常に1つのアドレスだけを表示させることではなく、解決経路を説明可能かつ再現可能にすることです。中国国内のドメインはルールに従って直接接続用DNSを使い、リモートドメインは指定したリゾルバーとアウトバウンドで処理し、ノードのドメイン名には独立した初期解決経路を用意する。この3点がそろって、DNS分流は完成します。