V2RayのDNSリーク確認と対策｜v2rayN・v2rayNGの設定方法

1. DNSリークと判断する条件

DNSはドメイン名をIPアドレスに変換します。Webサイトへの接続がプロキシ経由でも、その前の名前解決までプロキシを経由するとは限りません。ブラウザー、OS、クライアントのコアがそれぞれDNSクエリを送信する可能性があります。ここでいうリークとは、本来プロキシ経由にする予定のDNSクエリが、実際にはローカルネットワークなど想定外の経路へ送られることです。国内向けドメインをルールどおり直接接続し、ローカルDNSを使う設定なら、それはルーティング方針の結果です。「ローカルのリゾルバーが表示された」だけで失敗と判断しないでください。

V2RayとXrayはコア、v2rayNはデスクトップ向けGUIクライアント、v2rayNGはXrayコアを使うAndroidクライアント、v2flyNGはV2Flyコアを使うクライアントです。画面上のDNS設定は、選択したコアの実行設定に反映されます。VMessやVLESSはプロキシプロトコルであり、システム上のすべてのアプリの名前解決経路を単独で決めるものではありません。

2. 基準値を取る：同じネットワークで3パターンを比較

まず現在のノード、ルーティングモード、ブラウザーのセキュアDNS、システムDNS、クライアントの動作モードを記録します。原因を特定できなくなるため、複数の項目を同時に変更しないでください。同じ端末、ブラウザー、ネットワークを使い、「クライアント切断」「システムプロキシのみ」「TUNまたはVPNで通信を取り込む」の結果をそれぞれ記録します。利用できないモードは省略し、比較のために別のネットワークソフトを重ねて使わないでください。

1. 直接接続の基準値を記録します。クライアントを切断し、DNS確認ページでテストを実行して、リゾルバー名、アドレス、時刻を記録します。確認ページではキャッシュの影響を抑えるためランダムなサブドメインを使うことがありますが、対象は現在のブラウザーのクエリに限られます。
2. プロキシ接続時の結果を記録します。ノードに接続し、同じ確認ページで古い結果を更新するだけでなく、テストを最初から実行します。Webサイトの出口IPも記録し、接続先の出口が変わったのか、DNSの経路が変わったのかを区別します。
3. ブラウザーの設定による影響を切り分けます。ブラウザー内蔵のセキュアDNSを一時的に無効にして、もう一度テストします。普段この機能を使う場合は、設定を戻してからHTTPS接続も想定したアウトバウンドを経由するか確認してください。
4. ほかのアプリも確認します。ブラウザーでテストを通過したら、実際に使うソフトでも確認します。システムプロキシは、コマンドラインツール、独自のリゾルバーを使うプログラム、UDPを直接送信するアプリを必ずしも対象にしません。

3. v2rayN：通信の取り込みを確認してからDNSを設定

以下では一般的な日本語UIを想定しています。バージョンや選択したコアによって項目の場所や名称は異なります。操作前にv2rayNのバージョンとコアの種類を記録し、現在の設定をバックアップしてください。デスクトップ版の「システムプロキシを設定」は、システムプロキシに従うアプリが対象です。TUNはより広い範囲の通信を取り込めますが、除外設定やDNSの取り込みルールも確認が必要です。2つのモードを混同しないでください。

1. ローカルの接続先を確認

   「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートを確認します。実際のポートが10808なら、アプリ側も対応するプロトコルとポートを指定してください。SOCKSの接続先をHTTP用として指定することはできません。混合待ち受けに対応している場合は、画面の説明に従ってください。

2. プロキシモードを確認

   メイン画面下部の「システムプロキシ」で「システムプロキシを自動設定」を選び、OS側のプロキシアドレスとポートが一致しているか確認します。システムプロキシに従わないアプリも対象にする場合は、メイン画面の「TUNを有効にする」を検討し、案内に従って必要な権限を許可します。

3. DNSルールを確認

   「設定」→「DNS設定」を開きます。使用中のコアやバージョンでこの項目がパラメーター設定にある場合は、該当するDNSページを使ってください。プロキシ対象ドメインに使うリモートリゾルバーを確認し、そのリゾルバーへの接続がプロキシのアウトバウンドを通ることも確認します。サーバーアドレスを入力しただけで完了としないでください。

4. ルーティング対象を確認

   ルーティング設定で、直接接続するドメイン、プロキシ経由のドメイン、デフォルトのアウトバウンドを確認します。切り分けの間だけグローバルプロキシにすると調査範囲を絞れますが、DNSの取り込みの代わりにはならず、システム上のすべてのアプリを捕捉できた証明にもなりません。

5. 再起動して再テスト

   保存後にコアを再起動し、起動ログに設定エラーがないことを確認してから、同じテストを繰り返します。サブスクリプションの更新後に結果が変わる場合は、DNSやルーティングがサブスクリプションまたはカスタム設定によって再生成されていないか確認してください。ルールを次々と追加しないようにします。

macOSやLinuxでは、システムプロキシの適用範囲はデスクトップ環境やアプリの実装によって異なります。Windowsと同じ設定画面があるとは限りません。どのプラットフォームでも、アプリの通信がクライアントに取り込まれているか、コアがどのDNSを使っているか、DNSクエリが最終的にどのアウトバウンドを選んだかを確認します。

4. v2rayNG：VPNの対象範囲とリモートDNSを確認

Androidで接続後にVPNアイコンが表示されても、VPNサービスが起動したことを示すだけで、すべてのアプリが対象になっているとは限りません。アプリごとのプロキシ設定、LANのバイパス、別のVPNサービス、システムのプライベートDNSによっても結果が変わります。v2rayNGの項目名はバージョンによって異なります。以下では設定画面によくある「リモートDNS」「ローカルDNSを有効にする」を手がかりにしてください。見つからない項目を、別のスイッチで無理に代用しないでください。

1. アプリの対象範囲を確認

   サイドメニューから「設定」→「アプリごとのプロキシ」を開き、選択したアプリをプロキシ経由にするのか、選択したアプリを除外するのかを確認します。テストに使うブラウザーがプロキシ対象に含まれている必要があります。切り分け時はアプリごとの制限を一時的に解除しても構いませんが、元のリストを記録しておいてください。

2. DNSの接続先を設定

   「設定」でDNS関連の項目を開き、「リモートDNS」を確認します。「ローカルDNSを有効にする」がある場合は、説明を読んでから有効にしてください。ここでいう「ローカル」は通常、クライアント内部でDNSを処理する意味であり、通信事業者のDNSにクエリを渡すことではありません。

3. Android側の設定を確認

   Androidの「設定」→「ネットワークとインターネット」→「プライベートDNS」を開き、現在の状態を記録します。メーカーによって項目の場所は異なるため、システム設定で「プライベートDNS」を検索しても構いません。比較テスト中は一時的に無効にし、テスト後に元へ戻して再確認してください。

4. 再接続してログを確認

   設定を保存したら一度切断して再接続し、サイドメニューの「ログ」でクエリのタイムアウトやアウトバウンドの失敗を確認します。Wi-Fiとモバイルデータ通信の両方でテストし、選択したDNSサービスに片方のネットワークからしか接続できない状態ではないか確認してください。

ブラウザーのセキュアDNSとシステムのプライベートDNSを同時に使っている場合は、まず一度に1つだけ有効にして確認します。DoHはHTTPS、DoTは一般にTCP 853を使います。どちらもDNS通信を暗号化しますが、プロキシを経由するかどうかは通信の取り込み範囲とルーティングによって決まります。ネットワークを切り替えたあと、以前アクセスしたサイトだけ開ける場合は、キャッシュが名前解決の問題を隠している可能性があります。設定が安定したとは限りません。

• 比較のためにグローバルプロキシを使ったら、元のルーティングルールに戻し、プロキシ対象ドメインと直接接続するドメインを改めて確認してください。
• LANプリンターや社内ドメインはローカルDNSに依存する場合があります。対象ごとに明確なルールを設け、すべてのリゾルバーを一律にパブリックDNSへ置き換えないでください。
• v2flyNGは異なるコアとUIを使用するため、v2rayNGの実行設定をそのままコピーしないでください。移行時にDNS項目とルーティング機能を改めて確認します。

5. ログとパケットキャプチャで失敗箇所を特定

まず、失敗がクエリ、接続、待ち受けのどの段階で発生しているかを確認します。以下のメッセージはコアやネットワーク関連のエラーに表示されることがありますが、完全なログの形式はバージョンによって異なります。いずれも調査の手がかりであり、ログの1行だけでDNSリークと断定することはできません。

Windows：システムDNSの確認とキャッシュの削除

PowerShellで次のコマンドを実行し、ネットワークアダプターのDNS設定、システムの名前解決キャッシュの削除、コマンドラインからの名前解決をそれぞれ確認します。最後のコマンドは通常、システムに設定されたDNSサーバーを使用します。HTTPシステムプロキシを有効にしても自動的にクライアント経由にはならないため、ブラウザーの結果と異なっていても矛盾ではありません。

Get-DnsClientServerAddress
Clear-DnsClientCache
nslookup example.com

平文DNSとIPv6を確認

パケットキャプチャを利用できる場合は、物理ネットワークアダプターで以下のフィルター条件を指定します。関係のないアプリを終了してから、新しいドメインクエリを1回発生させてください。ポート53の通信が見えただけでは不十分です。クエリ名と時刻を照合し、テスト対象のアプリによる通信か確認します。ポート53の通信が見えなくても、暗号化DNSの利用やキャッシュヒットの可能性があるため、安全とは断定できません。

udp.port == 53 || tcp.port == 53
tcp.port == 853

6. DNSリーク対策の確認リストと元に戻す方法

確認では、画面にリゾルバーが1つだけ表示されることを目指すのではなく、決めた方針どおりに動作するかを検証します。すべての業務クエリをプロキシ経由にするなら、対象アプリごとにDNSの接続口とアウトバウンドを確認します。国内外で振り分けるなら、直接接続するドメインとプロキシ経由のドメインをそれぞれテストします。DNSクエリとWeb接続で異なる方針を使うことはできますが、意図した設定である必要があります。

• 設定が反映されている：再起動後にコアが正常に動作し、DNS設定の解析エラーや待ち受けエラーがログにない。
• 経路が意図どおり：テスト用ブラウザーが通信の取り込み対象に含まれ、リモートDNSへの接続が想定したプロキシのアウトバウンドを通る。
• キャッシュの影響を排除：システムのキャッシュを削除するか、確認ページで新たに生成されたクエリを使い、古い結果を現在の設定の結果と取り違えない。
• 複数のネットワークで確認：Wi-Fi、モバイル通信、デスクトップのネットワークを切り替えて再テストし、結果の違いを記録する。1回の結果をすべての環境に当てはめない。
• 起動直後も接続できる：端末の再起動後、初回の接続でもノードのアドレスを名前解決でき、前回の接続で残ったキャッシュに依存しない。
• 元に戻す手順が明確：元のDNS、ルーティング、プライベートDNSの設定を残しておく。問題が起きたら直近の変更から戻し、基本的な接続を確認する。

問題を共有するときは、クライアントのバージョン、コア、ルーティングモード、エラー発生時刻、機密情報を伏せたログを記載すれば十分です。サブスクリプションURL、ノードの認証情報、実行設定全体にはアクセス権につながる情報が含まれる場合があるため、公開しないでください。さらに調査する場合はトラブル診断を参照し、起動、待ち受け、接続、名前解決の順に確認してください。