V2RayのDNSリークを確認・対策する方法｜dns設定の手順

DNSリークの判断基準：地域ではなく名前解決経路を確認

DNSリークとは、本来想定したプロキシ経路で処理されるはずのドメイン問い合わせが、意図しないリゾルバーに送られることです。たとえば、Web接続はプロキシ経由でも、アプリが先にルーターへ問い合わせ、ルーターからローカルのプロバイダーへ転送される場合があります。Webの出口IPが変わっても、名前解決経路まで変わったとは限りません。

ブラウザーのセキュアDNS、OSのDNS、V2Ray内蔵のdnsは同時に存在できます。各設定が有効になるのは、リクエストが対応する処理経路に入った場合だけです。システムプロキシが処理するのは通常、プロキシ設定に従うアプリの接続であり、すべてのUDP問い合わせを捕捉するわけではありません。JSONにdns.serversを追加しても、ネットワークアダプターのDNSが自動的に切り替わることはありません。

• ブラウザーが独自に名前解決：セキュアDNSを有効にすると、ブラウザーがシステムのリゾルバーを使わず、指定したDoHサービスへ直接問い合わせることがあります。
• OSが先に名前解決：アプリが先にIPアドレスを取得し、その後に接続をプロキシへ渡します。この場合、コアに届くのはIPアドレスだけで、すでに送信された問い合わせを取り消せないことがあります。
• 必要に応じてコアが名前解決：ルーティングでのIPマッチ、一部の出力接続、DNSインバウンド転送によって内蔵リゾルバーが使われる場合がありますが、他のプロセスまでカバーするとは限りません。

検査手順：直接接続とプロキシ接続を比較

テスト中はブラウザー、ネットワーク、検査サービスを固定します。各回のWeb出口IP、リゾルバーIP、ブラウザーのセキュアDNS設定、クライアントのルーティングモードを記録してください。以下は手順の説明であり、当サイトでの実測結果ではありません。1回のテストで表示されたリゾルバー数を、一般的な合格基準とみなさないでください。

1. 基準値を記録

   プロキシ接続を一時的に終了し、ブラウザーでDNSリーク検査を1回実行します。リゾルバーのアドレスと運営元を記録してください。共有オフィスのネットワークや会社支給端末では、ネットワーク設定を変更してよいか事前に確認しましょう。

2. ブラウザーを固定

   ブラウザーの「設定」で「セキュア DNS」を検索し、現在の状態を記録します。切り分けのため一時的に無効にし、検査後は元に戻してください。このとき、システムDNSは同時に変更しないでください。

3. プロキシを有効化

   v2rayNを起動し、タスクトレイの「システムプロキシ」から「システムプロキシを自動設定」を選びます。接続中のサーバーとルーティングモードを確認したら、検査ページを開き直してテストを再実行してください。

4. キャッシュを消去

   Windowsのターミナルでipconfig /flushdnsを実行し、ブラウザーを完全に終了してから起動し直します。このコマンドで消去されるのはシステムのキャッシュだけです。ブラウザー独自のキャッシュを消去する代わりにはなりません。

5. 項目ごとに再テスト

   各回で変更するのは1項目だけにします。まずブラウザーの名前解決、次にコアのDNS、最後にDNSの捕捉方法を確認します。最低2回は繰り返してください。結果が安定しない場合は時刻とログを保存し、古いキャッシュを新しい設定の反映と誤認しないようにします。

コマンドラインもリクエストの入口を調べる手掛かりになります。以下では例としてSOCKSポート10808を使用します。実際のポートはクライアントで確認してください。--socks5-hostnameを指定すると、接続先のドメイン名をSOCKSプロキシに渡します。このアプリ接続でのドメイン名の受け渡しは確認できますが、システム全体に迂回DNSがないことの証明にはなりません。

curl.exe --proxy socks5h://127.0.0.1:10808 https://example.com/ --head
ipconfig /flushdns
Resolve-DnsName example.com -Type A

最後のコマンドはPowerShellで実行し、通常はシステムDNSを使います。HTTPシステムプロキシを設定していても、V2Rayに自動的に渡されるわけではありません。ブラウザーと結果が異なるのは、両者のリクエスト経路が異なることを示しています。この違いだけでコアの設定が無効だと判断することはできません。

ポートとプロトコル：ローカルプロキシ、DNS、DoHを区別

対応するポートでDNSサービスが実際に待ち受けている場合を除き、ネットワークアダプターのDNSを127.0.0.1に変更しないでください。SOCKSとDNSの待ち受けは別のプロトコルです。問い合わせを10808へ送っても、自動的にDNS応答が返るわけではありません。クライアントによっては複数プロトコルを扱うポートを使う場合もあるため、現在の生成設定を確認してください。

dns.serversの設定例：DNSトラフィックの経路を明示

以下はV2Ray/Xray形式の設定統合例です。リモートDoHとDNSトラフィックのタグ付けを示しています。使用中のコアがこれらのフィールドに対応し、既存のoutboundsにproxyという名前の利用可能なプロキシ出力があることが前提です。実際のタグ名が異なる場合は、使用中の値に置き換えてください。この断片を完全な設定として起動しないでください。

{
  "dns": {
    "tag": "dns-query",
    "servers": [
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIPv4"
  },
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["dns-query"],
        "outboundTag": "proxy"
      }
    ]
  }
}

• dns.tag：内蔵DNSが発行する問い合わせにルーティング用のタグを付けます。ここではinboundTagでdns-queryに一致させます。SOCKSインバウンドを新たに作成するものではありません。
• servers：例ではIP形式のDoHアドレスを使い、DNSサービス自体のドメイン名を解決するための事前処理を減らしています。サービスに到達できるかは、現在のネットワークとプロキシ経路で確認してください。
• queryStrategy：UseIPv4は内蔵DNSの問い合わせをIPv4に限定し、まずIPv6経路による違いを切り分けるための設定です。デュアルスタック環境では、設定を確認したうえでUseIPを検討してください。
• ルールの配置：このDNS専用ルールは、広い範囲に適用される直接接続ルールより前に置き、既存の他のルールは残してください。前のルールに一致すると、後続のDNSプロキシルールでは補えません。

DoHが暗号化するのは、クライアントからリゾルバーへの問い合わせ接続です。その通信がプロキシを経由するかどうかは、ルーティングにも左右されます。一部のコアには+localで終わる名前を使うローカル処理モードがありますが、通常のリモートモードとはルーティングの挙動が異なります。「高速化」のために本例の設定と安易に置き換えないでください。DNSを振り分ける場合は、ドメインを限定した上流ルールを追加し、フォールバック時に想定外のサービスが使われないか確認してください。

domainStrategy：ルーティング時と出力時の名前解決を個別に確認

domainStrategyは全体に適用されるDNSリーク防止スイッチではありません。同じキー名でも、配置されるオブジェクトによって制御する段階が異なります。トラブルシューティングではJSONの階層も含めて確認し、キー名だけを検索して一括置換しないでください。

AsIsが制御するのはルーティング段階だけで、接続先が以後一切名前解決されないという意味ではありません。最終的に直接接続出力へ進むリクエストには、接続先のアドレスが必要です。ドメイン名のままプロキシ側へ渡されたリクエストは、通常リモート側で処理されます。日本国内のサイトを直接接続する場合も、ローカルDNSへの問い合わせをすべて問題とみなすのではなく、先にそれらのサイトの名前解決方針を決めてください。

FakeDNS：アドレスのマッピングだけではトラフィックを捕捉できない

FakeDNSが返すのは、予約済みアドレスプール内のマッピング用アドレスであり、実際の接続先アドレスではありません。コアはドメイン名とマッピング用アドレスの対応を保存し、後続の接続が同じ処理経路に戻ったとき、その対応からドメイン名を復元します。DNSの捕捉と接続の再取得に対応した環境向けの機能であり、フィールドを1つコピーしただけで有効にできるものではありません。

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

これはFakeDNSに対応したV2Ray/Xrayコアの概念的な設定例です。DNSインバウンド、転送、システムルーティングは含みません。マッピングを復元する必要がある既存のインバウンドには、コアの対応状況に応じて以下のスニッフィング設定も統合してください。実際のトラフィックが通らない空のインバウンドを作らないでください。

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

• DNS問い合わせをコアに渡す：JSONで"servers": ["fakedns"]を設定しただけでは、Windowsのネットワークアダプターが自動的にFakeDNSへ問い合わせるようにはなりません。
• マッピング先の接続を再取得する：198.18.0.0/15はインターネット上のWebサイトのアドレスではありません。システムから物理ゲートウェイへ直接送られると、Webサイトがタイムアウトすることがよくあります。
• ルーティングを統一する：このアドレスプールが既存のネットワーク設計と競合しておらず、現在の捕捉経路で処理されることを確認してください。直接接続の除外リストには追加しないでください。
• 切り替え後にキャッシュを消去：FakeDNSの無効化や再起動によってマッピングが失われると、古いキャッシュ内のアドレスが使えなくなる場合があります。再度問い合わせて接続を確立してください。

v2rayNでは複数のコアを管理できます。TUNモードのDNS捕捉も別の設定形式で実装されている場合があります。まず実際に動作しているコアを確認し、上記のV2Ray/Xray形式を使うか判断してください。他のコアのTUN DNS画面にこのJSONをそのまま貼り付けることはできません。

v2rayNの設定場所とよくあるエラー

デスクトップ版では、まず「設定」→「パラメーター設定」でローカルの待ち受けポートを確認します。次に「設定」→「DNS設定」を開き、使用中のコアに対応するDNS項目を確認してください。バージョンによってはDNS設定がパラメーター設定内にあり、項目もコアごとに異なります。保存後にサービスを再起動し、実行ログで実際のコアと設定の読み込み結果を確認してください。クライアントの更新、サブスクリプションの更新、設定の切り替え後も、生成された設定に変更内容が残っているか再確認しましょう。

システムプロキシの確認には、タスクトレイの「システムプロキシ」を使います。DNS捕捉を確認する場合は、メイン画面の「TUNモード」とその設定を確認してください。両者は別の設定です。TUNには管理者権限が必要な場合があり、既存の仮想ネットワークアダプターと競合することもあります。変更前に現在の状態を記録してください。比較のために複数の捕捉ソフトを同時に有効にしないでください。

Androidでも使用するコアを区別してください。v2rayNGはXray、v2flyNGはV2Flyを使用します。システムVPNによる捕捉、アプリの除外リスト、Androidの「プライベートDNS」は、いずれも名前解決経路に影響します。デスクトップのシステムプロキシで得た結論をそのまま当てはめないでください。同じノードでも結果が異なる場合は、ノードを疑う前にリクエスト経路とリゾルバーを比較しましょう。

• 修正完了の確認：検査を繰り返したとき、テスト対象のアプリに表示されるのが想定したリゾルバーだけであり、ログ上でもDNSトラフィックが想定した出力先を使っていること。
• 振り分け設定の確認：直接接続するドメインとプロキシ経由のドメインを個別に検証し、名前解決結果と各Webサイトへの接続の両方を確認します。
• システム全体での検証：より多くのアプリを対象にする場合は、UDP/TCP 53、ブラウザーの暗号化DNS、IPv6経路も別途確認してください。単一のWebページによる検査では、すべてのプロセスを確認できません。
• 元に戻す方法：変更前の設定を保存し、一度に変更する階層は1つにします。問題が起きたら該当項目を元に戻し、サービスを再起動してキャッシュを消去してください。複数の誤った設定を重ねないようにします。