v2rayN・v2rayNGでDNSを調べる際は、「どこが名前解決を行うか」と「DNS通信がどの経路から出ていくか」の両方を確認します。ノードには接続できるものの、検査結果に日本国内の通信事業者が表示される、またはドメインへのアクセスに問題がある方向けに、直接接続とプロキシ接続の比較から、デスクトップのシステムプロキシ、Android VPN、リモートDNS、ルーティングルールの確認まで順を追って解説します。最後にログと再テストで結果を検証します。
1. DNSリークの判断基準
DNSリークとは、DNSクエリが想定したネットワーク経路を通らない状態です。プロキシ経由でアクセスするドメインが日本国内の通信事業者によって名前解決されると、問い合わせ内容が国内の名前解決経路に漏れる可能性があります。ウェブサイトに表示される出口IPがプロキシサーバーのものでも、そのページへの接続がプロキシを通ったことしか分からず、DNSクエリまでプロキシ経由だったとは限りません。
v2rayNのシステムプロキシが影響するのは、システムプロキシ設定に従うアプリだけです。PC上のすべてのDNS通信を制御するものではありません。v2rayNGのVPNモードではより多くのアプリの通信を取り込めますが、アプリごとの除外設定、ブラウザーのセキュアDNS、AndroidのプライベートDNS、IPv6のルーティングによって実際の経路が変わることがあります。TUNやVPNを有効にしただけでは確認は終わりません。そこから検証を始めましょう。
| 検査結果 | 分かること | 次に確認すること |
|---|---|---|
| ウェブサイトのIPが変わった | ウェブ接続が別の出口を通った | DNSクエリの経路を個別に確認する |
| 日本国内の通信事業者のリゾルバーが表示された | 検査用ドメインが国内の名前解決経路で処理された可能性がある | ブラウザー、システムDNS、直接接続ルールを確認する |
| リゾルバーの国と接続ノードの国が異なる | パブリックDNSのエニーキャストや転送が関係している可能性がある | 国だけで判断せず、DNS事業者と実際の通信出口を確認する |
| プロキシと国内のリゾルバーが両方表示された | 複数の名前解決経路やフォールバックが存在する可能性がある | 再テストし、キャッシュ、アプリごとの設定、フォールバック設定を確認する |
結論：ドメインの用途に応じてリークを判断
ルール分岐の設定によっては、直接接続するドメインに国内のDNSを使う場合があります。優先して修正すべきなのは、プロキシ経由にするドメインが意図せず国内の名前解決経路に流れることです。国内のリゾルバーが表示されたというだけで、すべてを異常と判断する必要はありません。
2. 直接接続とプロキシ接続を比較する
DNS検査サイトでは通常、ランダムなサブドメインを生成し、権威DNSサーバー側から再帰問い合わせ元を確認します。表示されるのは、最終的に再帰問い合わせを行ったサービスであり、クライアントに設定したDNSアドレスとは限りません。パブリックDNSの転送やエニーキャストは位置情報にも影響するため、DNS事業者、検査モード、使用中のクライアント設定を併せて記録してください。
-
基準値を記録する
クライアントのプロキシ接続を無効にし、同じブラウザーでDNS検査サイトを開きます。たとえば、
dnsleaktest.comを直接入力してください。ウェブの出口IP、リゾルバー事業者、IPv4/IPv6の状態、ブラウザーのセキュアDNSが有効かどうかを記録します。 -
プロキシを有効にする
v2rayNまたはv2rayNGを起動し、接続中のノードとルーティング設定を確認します。同じネットワーク、ブラウザー、検査サイトを使って、再度フルテストを実行してください。2回のテストの間にWi-Fiとモバイルネットワークを切り替えないでください。
-
条件を切り分ける
ブラウザー独自のセキュアDNSを一時的に無効にして再テストし、その後セキュアDNSだけを元に戻して再テストします。毎回変更するのは1項目だけにし、「システムプロキシ」「TUN」「VPN」のどの接続方式かをそれぞれ記録して、異なる方式の結果を混同しないようにします。
-
繰り返し検証する
設定ごとに最低2回テストし、クライアントのログも確認します。DNS設定を変更したら、コアまたはVPN接続を再起動してください。通常のページ再読み込みでは古いキャッシュが使われることがあり、新しいランダムドメインを使ったテストの代わりにはなりません。
Windowsでは、次のコマンドで物理・仮想ネットワークアダプターのDNSアドレスを確認し、システムのDNSキャッシュを消去できます。システムキャッシュを消去してもブラウザー独自のキャッシュは消えず、アプリが選ぶリゾルバーも自動では変わりません。
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientServerAddress -AddressFamily IPv6
ipconfig /flushdns3. v2rayN：リモートDNSとダイレクトDNSを分けて設定する
v2rayNの設定では、3つの名前解決用途を区別する必要があります。プロキシ経由の宛先ドメイン、直接接続する宛先ドメイン、そしてプロキシサーバー自体のアドレスです。プロキシサーバーをドメイン名で指定している場合、接続を確立する前にサーバーのIPアドレスを解決する必要があります。この解決まで確立前のプロキシに通そうとすると、名前解決の依存関係が循環するおそれがあります。
v2rayNは、バージョンや画面形式、コアによってDNSの編集画面が異なります。以下では「設定」→「DNS設定」から開く画面を例に説明します。DNS設定テンプレートやJSONエディターが表示される場合は、まず元の設定をバックアップし、用途に応じて使用中のコアの設定を変更してください。別のコア用の項目をそのまま貼り付けないでください。
-
現在の設定をバックアップする
まずメイン画面で選択中のノード、ルーティング設定、システムプロキシの状態、TUNの状態を記録し、「設定」→「DNS設定」を開いて現在の内容を保存します。サブスクリプションに含まれるのはノード情報であり、PCのDNS通信に関するルールまですべて設定済みだとは限りません。
-
名前解決の用途を分ける
リモートDNSはプロキシ経由で名前解決するドメインに、ダイレクトDNSは国内または直接接続するドメインに使います。たとえば
https://1.1.1.1/dns-queryはDoHサービスのアドレスです。これは形式とサービスの例であり、接続がプロキシを経由するかどうかは実際のルーティングによって決まります。 -
DNS通信の出口を確認する
DNS設定とルーティングルールを確認し、リモートDNSへの接続がプロキシ経由、ダイレクトDNSへの接続が直接接続になるようにします。直接接続を意味する解析アドレス形式や特殊なDNSモードを使う前に、使用中のコアでの動作を確認してください。「リモートDNS」という表示だけで判断することはできません。
-
通信の取り込みを確認する
ブラウザーだけをプロキシ経由にする場合は、まずシステムプロキシでテストします。システムプロキシに従わないアプリがある場合に、TUNの利用を検討してください。TUNを有効にしたら、DNS通信の取り込み、ネットワークアダプターのルート、IPv6を確認します。互いに競合する複数の仮想ネットワークアダプター設定を併用しないでください。
-
再起動して再テストする
設定を保存してコアを再起動し、前の節と同じ方法で再検査します。ノードサーバーのアドレスを名前解決できない場合は、プロキシルールを追加し続けるのではなく、まず利用可能な初期名前解決経路を復元してください。
| 名前解決方式 | 一般的なポート | 確認する通信経路 |
|---|---|---|
| 従来型DNS | UDP 53、TCP 53 | 物理ネットワークアダプターから直接送信されていないか、TCPへのフォールバックがないか |
| DoT | TCP 853 | 暗号化されたDNS接続が想定どおりプロキシに入るか |
| DoH | 通常はHTTPSの443番ポート | DNSサービスのアドレス、初期名前解決、HTTPS通信の出口 |
DNSの暗号化とDNS通信のプロキシ経由は別の観点です。DoHはDNSサービスまでの問い合わせを暗号化できますが、DoH接続が国内のネットワークから直接出ていれば、「DNS通信をプロキシの出口から送る」という目的は達成できません。逆に、プロキシトンネル内で従来型DNSを使っていても、問い合わせが国内ネットワークから平文で送信されたとは限りません。
4. v2rayNG：ローカルDNS、VPN、対象アプリを確認する
v2rayNGはXrayコアを使用し、AndroidのVPNインターフェース経由でアプリの通信を取り込みます。「ローカルDNSを有効にする」の「ローカル」は通常、クライアント内でのDNS処理機能を指し、すべてのドメインを国内の通信事業者に送るという意味ではありません。実際の接続先はDNS設定、ルーティング、VPNが取り込む範囲によって決まります。
-
DNS設定を確認する
サイドメニューの「設定」を開き、「リモートDNS」「ダイレクトDNS」「ローカルDNSを有効にする」を探します。これらの項目は設定画面内の別々のグループにある場合があります。使用中のバージョンに項目がない場合は、まずクライアントとコアのバージョンを確認してください。存在しないスイッチを探す必要はありません。
-
対象アプリを確認する
「設定」→「アプリごとのプロキシ」で、ブラウザーやテスト対象のアプリが除外されていないか確認します。テスト中はアプリごとの制限を一時的に無効にし、VPNが通信を取り込めることを確認してから、除外設定を1つずつ戻してください。
-
プライベートDNSの影響を切り分ける
Androidでは通常、「設定」→「ネットワークとインターネット」→「プライベートDNS」から設定できます。メーカーによって名称が異なる場合があります。現在の設定値を記録し、指定されたプロバイダーのホスト名を一時的に無効にして比較テストを行います。企業管理端末や管理対象ネットワークでは、先に管理ポリシーを確認してください。
-
VPN接続を再確立する
v2rayNGを切断してVPNを再起動し、ブラウザーのセキュアDNS、IPv6、ネットワーク切り替え後の結果を確認します。設定を変更しても以前のVPNセッションを維持していると、変更が反映されないことがあります。
v2rayNGのIPv6も段階的に確認してください。DNSからAAAAレコードが返るのは、IPv6アドレスを取得できたことを示すだけです。続いて発生するIPv6接続がVPNに取り込まれているかを確認する必要があります。一時的にIPv6を無効にして比較できますが、最終的にはVPNの取り込みやルーティングを修正してください。異常をすべてAAAAレコードのせいにするのは適切ではありません。
5. DNSルーティングとTUN：ルールの競合を防ぐ
Xrayの内蔵DNS、ルーティングのドメイン戦略、スニッフィングはそれぞれ異なる役割を担います。内蔵DNSは名前解決を行い、ルーティングルールは通信の出口を選び、スニッフィングは接続からドメイン情報を補います。ルーティングのドメイン戦略を変更しても、システムDNSがすべて自動でプロキシに入るわけではありません。スニッフィングを有効にしても、ブラウザーが直接送るDoH接続は取り込まれません。
- 広範囲に適用される直接接続ルールを先に確認：DNSサービスのアドレスが先行する広範なIP直接接続ルールに該当すると、その後のプロキシルールは適用されないことがあります。実際に生成されたコア設定で、ルールの順序を確認してください。
- 初期名前解決経路を確保：プロキシサーバーとDoHサービスの両方をドメイン名で指定している場合、最初の名前解決をどの仕組みが行うかを明確にし、起動時の依存関係が循環しないようにします。
- 社内ドメインを確認：社内ドメインは企業DNSでしか解決できない場合があります。すべての問い合わせをパブリックDNSに送らず、対象ドメインと到達可能な経路を個別に設定してください。
- TUNによるDNSの取り込みを確認：リクエストが仮想ネットワークアダプターに入った後、どの仕組みが処理するか、また直接接続の出口がTUNに再度取り込まれる循環をどう避けるかを確認します。変更前に元の設定を復元できるよう保存してください。
- FakeDNSは慎重に有効化：FakeDNSはドメインとの対応関係を維持するために仮想アドレスを返すもので、独立した暗号化DNSサービスではありません。通信の取り込みが不完全だと、アプリが仮想アドレスを受け取っても正しく接続できないことがあります。
結論：まず接続方式を固定し、その後DNSルーティングを調整
まず1つの接続方式で1つのブラウザーを使い、安定した結果が得られる状態にします。その後、ルール分岐、アプリごとの設定、ブラウザーのセキュアDNSを戻してください。一度に1項目ずつ戻せば、どの経路がDNSの出口を変えたのか特定できます。
6. よくあるエラーと最終確認
DNSの問題が必ず「リーク」として現れるわけではありません。リモートDNSへの接続が誤って直接接続になる、DNSアドレスに到達できない、ノードのアドレスを初期解決できないなどの原因でも、ウェブページを開けなくなります。ログの文言はコアやOSによって異なります。以下は実際に表示される可能性のあるエラー例です。前後のログにある宛先アドレスや時刻と併せて判断してください。
lookup example.com: i/o timeout
原因：タイムアウトまでに名前解決が完了していません。DNSサービスに到達できない、または通信の出口が誤っている可能性があります。対処：まずDNSサービスのアドレスと出口ルールを確認し、同じサービスへの接続をテストしてください。ウェブサイトの接続先ノードを繰り返し切り替えるだけでは解決しません。
dial tcp: lookup example.com: no such host
原因：名前解決で有効な結果を取得できていません。ドメインの入力ミス、ドメインの不存在、名前解決ポリシーの問題などが考えられます。対処：実際のドメインを確認し、別の利用可能な名前解決経路と比較してください。これだけでプロキシの認証失敗と判断しないでください。
context deadline exceeded
原因：処理がタイムアウトしました。DNS固有のエラーではなく、DNSサービスや接続先サーバーへの接続でも発生する場合があります。対処：前後のログから失敗した段階を特定し、DNS、TLS接続、プロキシの出口を個別に確認してください。
DNSパケットのキャプチャはウェブ上の検査を補えますが、UDP 53だけをフィルターするとTCP 53、DoT、DoHを見落とします。物理ネットワークアダプターを調べる際は、DNSサービスの宛先アドレスと接続方向を確認してください。443番ポートの接続が見つかっても、接続先を確認せずにすべてのHTTPS通信をDNSと判断してはいけません。53番ポートの通信が見つからないことだけで、名前解決が想定どおり行われているとは証明できません。
- 用途に合ったリゾルバー：プロキシ経由のドメインが意図せず国内の名前解決経路を使わず、社内または直接接続するドメインは引き続き正常に解決できる。
- 出口と接続方式を個別に確認：システムプロキシ、TUN、Android VPNをそれぞれテストし、ある方式の結果を別の方式の検証に流用しない。
- キャッシュの影響を除外：新しく生成した検査用ドメインを使い、設定変更後に関連する接続を再起動して、最低2回再テストする。
- ネットワーク切り替え後も正常：AndroidでWi-Fiからモバイルネットワークに切り替えた後、またはデスクトップのスリープ復帰後に、VPN、仮想ネットワークアダプター、DNSの状態を再確認する。
- 復元用の記録を残す：リモートDNS、ダイレクトDNS、ルーティング設定、ブラウザーのセキュアDNSの最終値を記録し、問題が起きたら1項目ずつ元に戻す。
v2rayN・v2rayNGのDNS漏れ対策では、DNSクエリと宛先への接続がそれぞれ明確なルールに従う状態を目指します。ウェブページが開けること、出口IPが変わること、パブリックDNSに別の地域が表示されることだけでは、通信経路を確認できません。比較テストを行い設定を記録しておけば、ノードやネットワークを変更した後の変化にも気づきやすくなります。