DNSリークの検出と修正：v2rayN・v2rayNGのDNS漏れ対策と設定手順

プロキシノードが接続済みでも、すべてのドメイン問い合わせがプロキシ経由になるとは限りません。ブラウザーやシステムサービス、一般的なアプリは、通常サイトへアクセスする前にDNSへドメイン名を問い合わせます。この処理を現在のネットワークの既定DNSが行い、その後にWeb通信だけがVMess、VLESSなどのプロキシ経由で送信されると、いわゆるDNSリークが発生します。トラブルシューティングでは、「ドメインを誰が解決したか」と「Webデータがどこから送信されたか」を別々の経路として確認し、出口アドレスだけで判断しないことが重要です。

DNSリークの経路と判断基準

通常のアクセスは、ドメイン問い合わせ、アドレスの返却、ルート照合、プロキシ経由の送信という4段階に分けられます。システムプロキシが主に制御するのは、プロキシ設定に対応したアプリの通信であり、システムがUDP 53番ポートへ送る問い合わせまで自動的に制御するとは限りません。TUNモードは仮想ネットワークアダプターの層でより広範な接続を捕捉できますが、明確なDNSルールも必要です。設定が不十分だと、問い合わせが誤って直接接続へ送られたり、ローカルDNSとリモートDNSの間でループしたりします。

確認すべきなのは、設定どおりのDNSリゾルバーが使われているかどうかです。たとえば、クライアントでリモートDNSを明示的に指定し、プロキシ経由で検査ページを開いているのに、現在の固定回線やモバイル回線が提供するDNSが繰り返し表示されるなら、追加の確認が必要です。一方、検査結果に複数の都市が表示されても、必ずしもリークとは限りません。パブリックDNSはエニーキャストのノードを使うことがあり、検査サイトが同じサービスを別のデータセンターとして識別する場合もあります。

• システムプロキシの場合：ブラウザーのWeb通信はローカルHTTPまたはSOCKSポートを経由しても、ほかのアプリによるUDP 53番ポートの問い合わせは直接接続されることがあります。
• TUNの場合：仮想ネットワークアダプター、DNSハイジャック、ルール、リモートDNSをまとめて確認する必要があり、スイッチを1つ有効にするだけでは不十分です。
• ブラウザーの暗号化DNSの場合：ブラウザー独自の名前解決設定がクライアント側の構成を迂回し、検査結果とシステム設定が一致しないことがあります。
• キャッシュがある場合：システム、ブラウザー、クライアントはいずれも古い応答を保存することがあります。設定変更直後に1回だけ再読み込みしても、正しい結論は得られません。

オンライン検査：まず基準値を取り、プロキシ接続後と比較する

検査前に、ネットワーク経路を変更するほかのプロキシソフトを終了し、検査対象のクライアントを1つだけ残します。用意する結果は、プロキシ未接続時の基準値と、ノード接続後の比較結果です。標準テストと拡張テストをそれぞれ実行することをおすすめします。拡張テストでは通常、複数のランダムなサブドメインに連続して問い合わせるため、直接接続されているDNSが見つかりやすくなります。

1. v2rayNまたはv2rayNGの接続を切り、現在の出口アドレス、DNSサービス名、国または地域、検出されたサーバー数を記録します。
2. DNSキャッシュを消去してからブラウザーを終了し、再度起動します。古い問い合わせ結果がそのまま使われるのを防ぐためです。
3. 安定したノードに接続し、通常のWebページを開けることを確認してから、1回目の標準検査を実行します。
4. 拡張検査を実行し、すべての問い合わせが完了するまで待ちます。ページを開いた直後に表示された最初の記録だけで判断しないでください。
5. 30秒ほど間隔を空けてもう一度検査し、2回の結果が安定しているか比較します。古い記録が1件だけ表示された場合は、再度キャッシュを消去して検査してください。

再現可能な検証記録には、時刻、クライアントのバージョン、動作モード、結果数を含めます。例：v2rayN 7.15.4のシステムプロキシモードでは、未接続時にローカルDNSが2件検出され、接続後も同じ2件が表示された。TUNに切り替えてコアを再起動したところ、2回の拡張検査はいずれもリモートDNSサービス1組のみを表示した。このような比較は、スクリーンショット1枚の結果よりも有用です。

v2rayN：リモートDNS、DNS出力、TUNの設定

以下ではv2rayN 7.15.4の画面を例に説明します。7.xのマイナーバージョンによってメニュー名が多少異なる場合がありますが、目的は同じです。Xrayコアにリモートリゾルバーを指定し、DNS問い合わせを専用の出力へ振り分け、プロキシに対応していないアプリまで制御したい場合はTUNを有効にします。変更前に、「サーバー」→「選択したサーバーをエクスポート」または設定のバックアップ機能で、現在動作している設定を保存してください。

手順1：ローカルリスニングとシステムプロキシを確認

1. 「設定」→「パラメータ設定」を開き、ローカルの混合リスニングポートを確認します。一般的な初期値は10808ですが、変更済みの場合は画面に表示される値を使用してください。
2. ポートがほかのプログラムに使用されていないことを確認し、メイン画面に戻って「システムプロキシを自動構成」を選択します。
3. コアログを開き、インバウンドのリスニングが開始され、bindやaccess deniedなどのエラーが出ていないことを確認します。
4. まずシステムプロキシモードで1回検査します。ブラウザーは正常でもほかのアプリでリークが発生する場合は、TUN設定へ進みます。すべての項目を同時に変更しないでください。

手順2：リモートリゾルバーを指定

「設定」→「DNS設定」を開き、現在使用しているXrayのDNS設定を選択します。リモートDNSには暗号化問い合わせに対応したアドレスも、通常のIPリゾルバーも使用できます。重要なのは、後続のルーティングで問い合わせが想定どおりプロキシ出力を通るようにすることです。以下はフィールドの関係を理解するための例であり、実際に保存する際はクライアントが生成する構造に従ってください。

{
  "dns": {
    "hosts": {
      "dns.google": "8.8.8.8"
    },
    "servers": [
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "223.5.5.5"
    ],
    "queryStrategy": "UseIP"
  }
}

queryStrategyは、返すアドレス種別の優先度を制御します。IPv4のみが安定しているネットワークではUseIPv4を使用し、デュアルスタック環境ではUseIPのままにできます。到達できないIPv6設定を選ぶと、「リークが検出される」のではなく、名前解決が遅くなったり、ログにタイムアウトが出たり、一部のWebサイトが開けなくなったりすることが一般的です。

手順3：DNS出力とTUNを確認

• ルーティング設定で、DNS問い合わせが既定の直接接続ルールに入らないことを確認します。専用DNS出力を使う場合は、対応するインバウンドのタグまたはポートルールが、その出力を向くように設定します。
• 「設定」→「パラメータ設定」→「TUNモード」を開き、仮想ネットワークアダプターを有効にしてコアを再起動します。初回の有効化時には、システム権限の確認が必要になる場合があります。
• DNSハイジャックが53番ポートを対象としていることを確認し、ローカルネットワークに必要な名前解決の範囲は残します。社内ネットワークのドメインを、無条件にパブリックDNSへ送らないでください。
• ログでDNS問い合わせがリモートサーバーから返されているか確認します。完了後にキャッシュを消去し、拡張検査を2回実行してください。

v2rayNG：AndroidのVPN DNSとローカルDNS設定

v2rayNGはシステムのVPNインターフェースを通じて通信を制御します。DNSがトンネルに入るかどうかは、VPN DNS、ローカルDNS、リモートDNS、ルーティング設定によって決まります。以下ではv2rayNG 1.10.16を例に説明します。開始前にサブスクリプションを更新して使用可能なノードを選択し、コアの種類がXrayであることを確認してください。現在のルーティングモードも記録しておくと、ノードの障害をDNSの問題と誤認しにくくなります。

手順1：VPN DNSを入力

1. 右上のメニューから「設定」→「VPN DNS」を開き、使用するリゾルバーのアドレスを入力します。例：1.1.1.1。
2. 「設定」→「リモートDNS」を開き、プロキシ経由のドメイン問い合わせに使うサーバーを設定します。暗号化DNSアドレスを使用する場合は、そのドメイン自体を初期段階で名前解決できることを確認してください。
3. ネットワーク環境に合わせて「ドメイン戦略」を確認します。IPv4のみが安定している場合はIPv4を優先し、到達できないAAAAアドレスによる接続遅延を避けます。
4. メイン画面に戻り、いったん切断してから再接続します。VPNインターフェースとDNSパラメータが再作成されます。

手順2：ローカルDNSを有効にするか決める

「ローカルDNSを有効にする」は、すべての問い合わせを単純に端末内へ留める機能ではありません。設定に従ってアプリのリクエストを処理し、リモートまたは直接接続のリゾルバーを選択する機能です。有効にした後は、中国本土向けDNS、リモートDNS、ドメインルールを同時に確認してください。スイッチだけを有効にしてルーティングの競合を残すと、同じドメインが2つのリゾルバーへ順番に問い合わせられることがあります。

設定後はいったん10秒間切断してから、再度起動します。コアログを開き、DNS timeoutが継続していないか確認してください。Webページを開ける場合は、同じブラウザーで検査を2回連続して実行し、その後、別の一般アプリで新しいドメインへアクセスします。ブラウザー独自の暗号化DNSだけが有効になっていないことを確認するためです。

修正後の確認とよくある異常

確認中はノード、ルート、DNSを変更し続けないでください。1つの経路、1つのブラウザー、同じ検査手順に固定することで、どの設定が効果をもたらしたか判断できます。各結果は「モード、リゾルバー数、基準値のDNSが表示されたか、初回表示時間」の4項目で記録することをおすすめします。

1. システムのDNSキャッシュを消去します。デスクトップではネットワークに再接続するか、システムが提供する更新操作を実行します。AndroidではVPNを切断してネットワークを一度切り替え、その後再接続してください。
2. ブラウザーの全ウィンドウを閉じて再起動し、まず以前開いたことのないドメインへアクセスします。キャッシュが直接使われるのを防ぐためです。
3. 標準検査と拡張検査をそれぞれ2回、少なくとも30秒間隔で実行します。
4. コアログを確認し、名前解決の連続タイムアウト、問い合わせループ、誤った出力へのルーティングが記録されていないことを確認します。
5. 別のネットワーク環境に切り替えてテストを繰り返します。特定のネットワークだけでリークする場合は、そのネットワークのDNSハイジャックまたはIPv6経路を確認してください。

設定の考え方：分割ルーティング、LANドメイン、安定性

DNSリーク対策は、すべてのドメインを同じパブリックDNSへ強制的に送ることではありません。家庭内ストレージ、プリンター、社内サービスはLANのDNSに依存している場合があり、すべてをリモートサーバーへ送ると名前解決に失敗します。より安定した方法は、ドメインとネットワーク範囲で分けることです。LANドメインはローカルリゾルバーへ、プロキシ対象のドメインはリモートリゾルバーへ送り、問い合わせを対応するルールによって直接接続またはプロキシ出力へ振り分けます。

• LANドメイン用に明確なローカル名前解決ルールを残し、すべてのサフィックスを覆う広すぎるルールは使用しないでください。
• GeoSiteルールはドメイン集合の照合を、GeoIPルールは宛先アドレスの照合を担当します。どちらもDNS出力設定の代わりにはなりません。
• VMessとVLESSはノードへの接続方式を示すだけで、システムDNSを誰が処理するかを自動的に決めるものではありません。
• v2rayNでは、まずシステムプロキシで単一アプリの動作を確認し、その後TUNで制御範囲を広げる方法が適しています。
• v2rayNGでは、VPN DNS、リモートDNS、ドメイン戦略、ルーティングモードを1組の設定としてまとめて確認してください。

修正後、初回の名前解決が約200ミリ秒から数秒に延びた場合は、リモートDNSが迂回経路を通っていないか、暗号化DNSのアドレスを再度名前解決する必要がないか、ルーティングがループしていないかを確認します。安定した設定には、検査結果を再現できること、よく使うドメインを通常の速度で解決できること、ネットワーク切り替え後に正しいDNS経路を再構築できることの3点が必要です。検査ページに特定の地域を表示させることだけを重視し、タイムアウトや互換性を無視すると、リークの問題が接続障害に変わってしまいます。