DNSリークの確認方法とv2rayN・v2rayNGの漏えい対策設定

1. DNSリークは問い合わせ経路の問題。国名だけでは判断できない

DNSはドメイン名をIPアドレスに変換します。アプリが先にシステムDNSで名前を解決し、そのIPアドレスをプロキシに渡す場合もあれば、ドメイン名をローカルプロキシに渡し、コアやリモート側で解決する場合もあります。どちらの経路でもウェブサイトは開けますが、前者では問い合わせが先にローカルネットワークのDNSリゾルバーへ届くことがあります。ここで対処するDNSリークとは、設定したルールではプロキシ経由にするはずのドメインが、意図せずローカル回線から名前解決される状態です。

中国国内向けのドメインを設定どおりローカルDNSで解決することは、それだけでリークとはいえません。VLESSやVMessはプロキシプロトコル、REALITYは接続の安全性に関わる仕組みです。いずれもOSがDNS問い合わせをどう送信するかを自動で決めるものではありません。サブスクリプションにノード情報が含まれていても、DNSの制御やルーティング設定まで整っているとは限りません。

2. オンラインDNS検査：3つの条件を比較して判断する

オンライン検査では、ブラウザーからランダムなサブドメインへの問い合わせを複数回発生させ、どの再帰DNSリゾルバーが問い合わせたかを確認します。表示されるのはリゾルバー側の出口であり、端末が接続している上流DNSのアドレスとは限りません。プロキシノードと同じ都市にあるとも限りません。パブリックDNSはエニーキャストや中継クラスターを利用するため、地図や国名だけではリークかどうか判断できません。

1. 直接接続時を記録

   プロキシを停止し、ブラウザーで dnsleaktest.com にアクセスします。標準テストと拡張テストを実行し、ネットワークの種類、日時、リゾルバーのIPアドレスと運営組織を記録して、ローカルネットワークの比較基準にします。

2. プロキシ経由でテスト

   クライアントを起動し、同じブラウザーがプロキシの対象になっていることを確認してから、テストを再実行します。同じノードとネットワークを使い、DNS、ルーティング、ブラウザー設定を同時に変更しないでください。

3. ブラウザーの影響を切り分ける

   ブラウザーの設定で「セキュアDNS」を検索し、一時的に無効にして再テストします。テスト後に有効へ戻すかどうかは、ブラウザーの暗号化DNSを個別に管理するかによります。

4. 切断時も再テスト

   短時間ネットワークが中断しても問題ない環境でプロキシノードを切断し、新しいドメインを使ってテストします。接続に失敗したら通信も止めたい場合、切断後も新しいドメインを名前解決してアクセスできるなら、システムからの直接接続、VPNの迂回、アプリのフォールバックを確認してください。

3. v2rayN（Windows）：システムプロキシとTUNを分けて確認

以下ではv2rayN 7.xの設定画面を例に説明します。マイナーバージョンによって項目名や分類が変わる場合があるため、まず現在のコアを確認し、生成された設定も確認してください。特にTUNモードでは、実際に使われるコンポーネントやDNS設定が通常のシステムプロキシモードと異なることがあります。XrayのDNS項目を変更しても、現在のTUN経路には反映されない場合があります。

1. 動作モードを確認

   「設定」→「パラメーター設定」を開き、コア関連の項目を確認します。メイン画面に戻り、「システムプロキシ」と「TUNを有効にする」の実際の状態も確認してください。タスクトレイでシステムプロキシが有効でも、すべてのプログラムがトンネルに入るわけではありません。

2. DNSの上流を確認

   「設定」→「DNS設定」を開き、現在のコアに対応する設定を確認します。リモート上流のテストには https://1.1.1.1/dns-query を使えます。そのアドレスを指定するだけでなく、接続がプロキシ経由でルーティングされていることも確認してください。

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

   「設定」→「パラメーター設定」でローカルの待ち受けポートを確認し、ブラウザーやアプリのプロキシアドレスと照合します。たとえば実際の待ち受け先が 127.0.0.1:10808 の場合、アプリ側でも対応するプロキシの種類とポートを指定します。例のポート番号を実際の設定確認の代わりにしないでください。

4. 古いキャッシュを消去

   Windowsのターミナルで ipconfig /flushdns を実行し、ブラウザーを終了してから再起動し、新しいドメインでテストします。このコマンドを実行しても、既存の接続やブラウザー独自のキャッシュはすべて消えるわけではありません。

Windowsで複数のネットワークアダプターを使っている場合は、Wi-Fi、有線LAN、仮想アダプターも確認してください。グループポリシーに対応したシステムでは、「コンピューターの構成」→「管理用テンプレート」→「ネットワーク」→「DNSクライアント」を開き、「スマートな複数ホーム名解決を無効にする」を「有効」に設定できます。これは並行する問い合わせを減らす補助策であり、TUNによる通信の取り込みに代わるものでも、システムDNSのすべてのフォールバックを止める設定でもありません。変更後も実際の挙動をテストしてください。

4. v2rayNG（Android）：まずVPNに通信を取り込み、次にプライベートDNSを確認

以下ではv2rayNG 1.9.xで一般的な設定項目を例に説明します。v2rayNGはXrayコアを使用しますが、システムVPNによる通信の取り込み、AndroidのプライベートDNS、ブラウザーのセキュアDNSはそれぞれ別のレイヤーです。v2flyNGはV2Flyコアを使用するため、ここで説明する設定項目や設定フィールドをすべてそのまま適用することはできません。

1. 対象アプリを確認

   サイドメニューから「設定」→「アプリごとのプロキシ」を開き、テストするブラウザーが除外されていないことを確認します。切り分け中はアプリごとのプロキシを一時的に無効にすると、対象範囲が分かりやすくなります。許可リストを使う場合は、ブラウザーがリストに含まれている必要があります。

2. ローカルDNSを確認

   サイドメニューから「設定」を開き、「ローカルDNSを有効にする」をオンにして、「リモートDNS」と「国内DNS」の項目を確認します。バージョンによってはDNS設定のグループにまとめられている場合があります。リモート上流と国内向け上流は個別に確認してください。項目名だけで最終的な通信経路を判断することはできません。

3. プライベートDNSをテスト

   Android標準の設定では、通常「設定」→「ネットワークとインターネット」→「プライベートDNS」から確認できます。まず現在の値を記録し、一時的に「オフ」にして、コアのDNS経路を基準としてテストします。メーカー独自のシステムでは「プライベートDNS」など別の表記の場合もあるため、設定画面で検索してください。

4. VPNを再接続

   設定を保存したら接続を停止して再起動し、システムにVPN接続中と表示されることを確認します。Wi-Fiとモバイルネットワークを切り替えて、それぞれテストしてください。一方のネットワークだけで問題が起きる場合は、そのネットワークのIPv6、DNSの到達性、VPNの再接続状況を重点的に確認します。

5. 切断時の保護をテスト

   接続が失敗したときに通信も止めたい場合は、Androidの「設定」→「ネットワークとインターネット」→「VPN」→「v2rayNG」で「常時接続VPN」と「VPNを使用しない接続をブロック」を確認します。これらの項目が表示されるかどうかは、端末やアプリの状態によって異なります。有効にした後は、アプリごとのルールが意図どおりに動作するか検証してください。

5. FakeDNS：事前の名前解決を抑える。リモートDNSの代わりではない

FakeDNSは合成アドレスを返し、後続の接続でそのアドレスを元のドメイン名に対応づけます。これにより、コアはドメイン名を保持し、ルーティングルールとの照合やプロキシ転送に利用できます。FakeDNSは暗号化DNSサービスではなく、実際のDNS問い合わせをすべて自動でプロキシ経由にするものでもありません。実IPアドレスが必要な直接接続の通信には、適切なDNS上流を別途用意する必要があります。

v2rayNGの「設定」で「Fake DNSを有効にする」を探します。有効にする前に「ローカルDNSを有効にする」が機能していることを確認し、保存後にVPNを再起動してください。デスクトップでは、現在のTUNコンポーネントがサポートするFakeIP／FakeDNSの方式に合わせて設定します。XrayのFakeDNSオブジェクトを、別形式の設定にそのままコピーしないでください。

• 有効にした後にウェブサイトで問題が起きたら、まずアプリを再起動し、古いDNSキャッシュを消去してから、設定を戻すか検討してください。
• アプリが合成アドレスを受け取った後にVPNを迂回すると、そのアドレスを通常どおり使えないことがあります。通信の取り込み範囲を見直してください。
• 実アドレスを独自に検証するアプリや、独自の名前解決を行うアプリでは、FakeDNSが適さない場合があります。アプリごとにテストしてください。

6. フォールバックの無効化とルーティング：2つの設定レイヤーを個別に確認

「システムDNSのフォールバックを無効にする」という共通の設定は、すべてのプラットフォームにあるわけではありません。クライアントコアの代替DNS、Windowsの複数アダプターからの問い合わせ、Androidでのネットワーク切り替え、ブラウザー独自のセキュアDNSをそれぞれ確認する必要があります。Xrayの disableFallback が制御するのは内蔵DNSの代替問い合わせだけであり、OSからの直接接続を防ぐものではありません。

以下はXray DNSとルーティングの部分的な設定例で、完全な設定ではありません。リモート上流とその接続経路の制約だけを示しています。既存の設定で、proxy というタグのプロキシアウトバウンドが定義済みであり、アプリからの問い合わせがコアのDNSに届く必要があります。クライアントが自動生成する設定は、対応する編集画面から変更して最終結果を確認してください。既存の設定を上書きしてそのまま実行しないでください。

{
  "dns": {
    "servers": [
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIPv4",
    "disableFallback": true
  },
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "1.1.1.1/32"
        ],
        "port": "443",
        "network": "tcp",
        "outboundTag": "proxy"
      }
    ]
  }
}

ここではIPアドレス形式のDoHを使い、上流DNSのドメイン名を解決するためのブートストラップ依存を減らしています。UseIPv4 が制限するのは、この内蔵DNS問い合わせで使うアドレスファミリーだけです。システムのIPv6を無効にするものではありません。また、この例にはドメインごとの振り分けも、アプリのDNSを取り込むルールも含まれていないため、これだけで全体のDNSリーク対策が完了したとはいえません。

• リモート上流のルールを先に照合：リモートDNSへの接続ルールは、直接接続のルールに一致する可能性のある項目より前に配置します。Xrayのルーティングは上から順に照合され、先に一致した時点で後続のルールは評価されません。
• デフォルトのアウトバウンドを確認：Xrayはルールに一致しない場合、最初のアウトバウンドを使います。プロキシをフォールバック先にする場合、気づかないうちに最初のアウトバウンドが直接接続になっていないか確認してください。
• ローカル向けの形式と混同しない：上流DNSを選ぶときは、ローカルアクセスの意味を持つ https+local:// などの形式に注意してください。通常のリモートDoHと同じようにルーティングで制御できる設定ではありません。
• 通常のDNSも通信を取り込む：適切なインバウンドとルーティングを設定すれば、UDP/TCP 53をDNSアウトバウンドで処理できます。53番ポートを遮断するだけでは、一部アプリの名前解決が失敗するうえ、853番ポートやHTTPS経由の問い合わせも対象にできません。
• ノードのドメイン名を解決できるようにする：プロキシサーバーがドメイン名で指定されている場合、プロキシ確立前に名前解決が必要になることがあります。この例外の処理方法を明確にし、DNSがプロキシに依存し、プロキシもDNSに依存する循環を避けてください。

7. 設定を検証：ブラウザーの結果、ログ、切断時の挙動を確認

変更後は、検査ページのスクリーンショットだけで済ませないでください。クライアントのバージョン、動作モード、ネットワークの種類、リモート上流、テスト対象のアプリを記録します。まず上流を1つに絞って全通信をプロキシ経由にし、その後、国内ドメインの振り分け、ブラウザーのセキュアDNS、アプリごとのルールを1項目ずつ戻します。項目を戻すたびに再テストすると、どのレイヤーで経路が変わったか特定できます。

物理ネットワークアダプターに53番ポートの通信が見られなくても、確認できた範囲で平文DNSがなかったことを示すだけです。ブラウザーのDoHが443番ポートで直接接続している可能性は残ります。暗号化された問い合わせは、接続先の上流DNS、通信経路、ログを組み合わせて判断してください。ログレベルを一時的に上げた場合は、確認後に通常のレベルへ戻します。ログを共有する前に、サブスクリプションのURL、ユーザー識別情報、アクセスしたドメインを削除してください。