ノードには接続できるものの、ドメイン名の問い合わせがプロキシ経由かどうか分からない方に向けた解説です。ブラウザー、OS、コアそれぞれのDNSを切り分け、比較テストで問い合わせの出口を確認したうえで、リモートDNS、ローカルDNSの振り分け、TUN使用時のFakeIPを設定します。検査ページに表示されるアドレスを一つにすることではなく、プロキシ経由にしたいドメインの問い合わせが想定どおりの経路を通ることが重要です。
DNSリークと判断する際の注意点
DNSはドメイン名をIPアドレスに変換する仕組みです。Web接続がプロキシ経由でも、名前解決の問い合わせまでプロキシ経由とは限りません。アプリが先にルーターへ問い合わせ、取得したアドレスをプロキシに渡すこともあります。本来プロキシ経由で名前解決したいドメインがローカルで問い合わせられている場合は、経路のずれとして確認が必要です。
v2rayNはクライアントの操作画面であり、実際の転送や名前解決の挙動は使用中のコアと設定によって異なります。ブラウザーの「セキュアDNS」、WindowsのネットワークアダプターのDNS、コア内蔵DNSはそれぞれ別の問い合わせ先です。いずれか一か所にパブリックDNSを設定しても、ほかの経路まで同じように動作するとは限りません。
| 問い合わせ元 | 一般的な経路 | 確認するポイント |
|---|---|---|
| Windowsのシステム名前解決 | ネットワークアダプターに設定されたDNS。ルーターを経由する場合もある | システムプロキシでは通常、通常のUDP DNS通信は制御されない |
| ブラウザーのセキュアDNS | ブラウザー独自のDoHサービス | クライアントのDNSルールを迂回していないか、接続自体がプロキシ経由か |
| コア内蔵の名前解決 | 設定で指定したローカルまたはリモートのリゾルバー | リゾルバーの選択と問い合わせの出口の両方が適切か |
| TUNによるDNSの制御 | 捕捉されたDNS問い合わせがコアに届く | DNSのリダイレクト、ルーティング範囲、例外ルールが機能しているか |
従来のDNSは通常、UDPまたはTCPの53番ポートを使用します。DoHは通常HTTPSの443番ポート、DoTは通常853番ポートを使用します。暗号化が解決するのは通信内容の秘匿性であり、プロキシが制御するのは通信の出口です。両者は互いに代用できません。
確認方法：比較テストを行い、リゾルバーを確認する
リゾルバーのアドレスとネットワークを表示できるDNS検査ページを用意します。テストでは毎回同じページとブラウザーを使い、変更する設定は一つずつにします。検査ページに表示されるのは、通常、再帰リゾルバーがテスト用ドメインへアクセスした際の出口です。パソコンのグローバルIPアドレスやノードの出口とは限りません。
-
基準値を記録する
一時的な直接接続が可能なテスト環境では、まずプロキシをオフにし、検査ページに表示されるリゾルバーのアドレスとネットワーク事業者を記録します。直接接続が難しい場合は省略できますが、その後の判断はルーティングログを優先し、表示された地域だけで結論を出さないでください。
-
ブラウザーの設定を切り分ける
ブラウザーの設定で「セキュアDNS」を検索し、カスタムのセキュアDNSを一時的にオフにして、元の設定を記録します。ブラウザー内蔵のDoHがクライアントのテストに与える影響を抑えられます。テスト後は必要に応じて設定を元に戻してください。
-
システムプロキシをテストする
v2rayNのトレイメニュー「システムプロキシ」から「システムプロキシを自動設定」を選びます。ノードとルーティングルールは変更せず、検査を再実行してください。リゾルバーに変化があったかを記録し、「Webページが開ける」ことだけでDNSが制御されていると判断しないでください。
-
TUNと比較する
ほかの通信制御ソフトを終了してから、メイン画面で「TUNを有効にする」をオンにします。システムの指示に従って権限を設定し、コアが正常に動作していることを確認してください。キャッシュを消去して再検査し、システムプロキシとTUNの結果を比較します。
-
ログを確認する
クライアントのログで、テストした時間帯のDNSとルーティングの記録を確認します。必要に応じて一時的にログレベルを上げ、どのリゾルバーと出口が使われたかを確認してください。終了後はログレベルを戻し、アクセスしたドメインが長期間記録されないようにします。
Windows PowerShellでは、次の2つのコマンドでシステムの名前解決経路を確認できます。1つ目はWindowsのDNSキャッシュを消去し、2つ目は通常のDNS問い合わせを実行します。どちらもv2rayNのHTTPプロキシやSOCKSプロキシを自動的に使用するわけではありません。ブラウザーやコアに個別のキャッシュが残る場合もあるため、それぞれ再起動するかキャッシュを消去してください。
ipconfig /flushdns
nslookup example.com結論：リゾルバーの所在地だけでは判断できない
検査結果に現地のネットワーク事業者が表示された場合は、まずそのドメインの問い合わせが意図的な直接接続かどうかを確認し、出口のログも照合してください。パブリックDNSサービスは分散配置されているため、近隣地域が表示されても、それだけでDNSリークとは断定できません。
v2rayNのリモートDNS：アドレスと出口をセットで設定
デスクトップ版の画面やコアによって、DNS設定フォームは異なります。まず「設定」→「DNS設定」を開き、使用中のコアと対応する設定画面を確認してください。該当する項目が見つからない場合は、インストールしたパッケージの画面と設定メニューを確認します。別のコア用の設定をそのまま貼り付けないでください。
リモートDNSの目的は、プロキシ経由にしたいドメインを想定したDNSサービスで名前解決することです。たとえばhttps://1.1.1.1/dns-queryは具体的なDoHアドレスであり、サブスクリプションURLやノードのアドレスではありません。このアドレスを設定した後、サービスへの接続がプロキシ経由になることも確認してください。
-
元の設定を保存する
「設定」→「DNS設定」にある元の値、使用中のコア、ルーティング設定を記録します。元に戻せる設定のコピーを保管し、テスト前に既存のDNSルールを削除しないでください。
-
リモート名前解決を設定する
使用中のコアに対応するリモートDNS欄に、対応しているDNSサービスのアドレスを入力します。上記のDoHアドレスを使う場合は、フォームがIPアドレスだけでなく完全なHTTPS URLを受け付けることを確認してください。
-
問い合わせの出口を確認する
DNS問い合わせの出口設定や関連するルーティングルールを確認し、リモートDNSへの接続がプロキシ経由になるようにします。Xray設定の
https+local://にはローカルから直接接続する意味があります。「プロキシを強制する」書き方として使用しないでください。 -
再起動して再テストする
設定を保存してコアを再起動し、キャッシュを消去してから検査します。かえってWebページが開けなくなった場合は、まずDNSのタイムアウトとノードのドメイン解決ログを確認してください。ノード、DNS、ルーティングモードを同時に変更しないでください。
コアのDNSを正しく設定しても、アプリがドメイン名をプロキシに渡しているか確認が必要です。アプリによっては、先にシステムで名前解決し、取得したIPアドレスを送信先として渡します。この場合、コアのDNS設定が名前解決に使われないことがあります。こうしたアプリも制御するには、リモートDNSアドレスを何度も変更するのではなく、TUNとDNSの制御範囲を確認してください。
ローカルDNSの振り分け：直接接続とプロキシの範囲を明確にする
ローカルDNSの使用自体が誤設定というわけではありません。LAN内の機器、内部ドメイン、直接接続すると決めたサイトでは、アクセス可能なアドレスを得るためにローカルDNSが必要な場合があります。重要なのは対象範囲を限定し、プロキシ経由にするドメインをローカルDNSに渡さず、同時にすべての問い合わせをリモートサービスへ送ることも避けることです。
| ドメインの用途 | 名前解決の方針 | 確認方法 |
|---|---|---|
| LAN内の機器と内部ドメイン | 利用中のネットワークのDNSを使い、LANへの直接接続を維持する | 内部名が正しいプライベートIPアドレスを返すか確認する |
| 直接接続すると決めたサイト | ドメインルールに従ってローカルDNSを使う | 名前解決と接続の両方が直接接続ルールに従うことを確認する |
| プロキシ経由にすると決めたサイト | リモートDNSを使い、問い合わせ時の接続もプロキシ経由にする | リゾルバーの選択とプロキシ出口のログを両方確認する |
| ノードサーバーのドメイン名 | そのノードへの接続に依存しない初期解決を使う | コアの再起動後、初回接続が完了することを確認する |
たとえば223.5.5.5は、特定のネットワーク環境でローカルDNSの候補として使えます。ただし、企業内のドメインは解決できず、どのネットワークにも適した標準設定ではありません。内部名は、まず利用中のネットワークが提供するリゾルバーに問い合わせてください。内部ドメインを扱う際は、ネットワークの利用規則にも従ってください。
- まずルールの優先順位を確認：具体的なドメインのルールは、広範囲に適用されるデフォルトルールより先に置きます。そうしないと、詳細ルールが適用されない場合があります。
- 次にフォールバックを確認：リモートDNSの失敗時にローカルDNSへ自動的に切り替わる場合、その動作が意図どおりか確認してください。優先リゾルバーだけを確認しても不十分です。
- 最後にアドレスファミリーを確認：AレコードとAAAAレコードの両方を確認します。IPv4だけをテストしても、IPv6の通信が同じプロキシ経路を通るとは判断できません。
結論：検査結果を整えるのではなく、ドメインの用途で振り分ける
必要なローカル名前解決は維持し、プロキシ対象ドメインの問い合わせ経路だけを適切に制限します。すべての問い合わせをプロキシ経由にする必要がある場合は、該当するローカルDNSへのフォールバックを明示的に無効にし、ノードの初期名前解決とLANへのアクセスが引き続き正常か確認してください。
FakeIPとTUN：スイッチ名より制御範囲が重要
FakeIPでは、まずアプリに合成アドレスを返し、コアがドメイン名とアドレスの対応を保存します。その後の接続はドメイン名に基づいて処理されます。アプリが先に実IPを取得してドメイン名の情報を失う問題を減らせますが、単独で機能する「DNSリーク防止スイッチ」ではありません。DNS問い合わせが制御されない場合や、後続の接続がコアに戻らない場合は、期待した結果にならないことがあります。
Xrayでは、関連する仕組みは通常FakeDNSと呼ばれます。ほかのコアではFakeIPの設定構造が異なります。v2rayNのTUN機能で使うコアも、通常のプロキシ接続で使うコアと同じとは限りません。現在の設定と実行ログを確認してください。Xrayのfakednsフィールドを、ほかのコアのDNS設定にコピーしないでください。
- DNSが制御されているか確認：TUNを有効にした後も、通常のDNS問い合わせがコアに届いていることを確認します。アプリ独自の暗号化DNS接続を、UDP 53の問い合わせとして単純にリダイレクトできるとは限りません。
- 合成アドレスのルーティングを確認：実装によっては
198.18.0.0/15のアドレス範囲を使います。このネットワークはベンチマーク用途であり、実際のインターネット上の接続先ではありません。使用する範囲は設定で確認してください。 - 内部ドメインの例外を設定：LAN内の機器検出や内部サービスなど、実アドレスが必要なものには適切な名前解決の例外を設定し、合成アドレスによるアクセス障害を防ぎます。
- 切り替え後にキャッシュを消去：FakeIPを無効にしたりコアを変更したりしても、アプリに合成アドレスが残っていることがあります。関連アプリを再起動してキャッシュを消去し、必要であればコアも再起動して対応関係を作り直してください。
よくあるエラーと確認項目
ログの表記はコアによって異なります。以下はよく見られるエラー例です。原因を調べる際は前後のログも確認し、エラーの対象がDNSサーバー、ノードサーバー、接続先サイトのどれかを区別してください。エラーが1件あっただけでは、DNSリークの証拠になりません。
エラー：lookup example.com: i/o timeout
原因：ドメイン名の名前解決がタイムアウトしています。リゾルバーに接続できない、または問い合わせの出口が誤っている可能性があります。
対処：まず使用中のリゾルバーのアドレスと問い合わせ経路を確認し、該当する接続がファイアウォールやルーティングで遮断されていないか調べます。証明書の検証を安易に無効にしないでください。
エラー：no such host
原因：現在の名前解決経路で有効なドメイン名の結果を取得できていません。ドメイン名の入力ミス、ネガティブキャッシュ、誤った振り分けルールなどが考えられます。
対処：ドメイン名が有効か確認してキャッシュを消去し、ローカルDNSとリモートDNSの結果を比較します。内部ドメインの場合は、パブリックDNSへ誤って送信されていないかを優先して確認してください。
エラー：network is unreachable
原因：現在のネットワークスタックから接続先アドレスへの有効な経路がありません。IPv6、TUNのルーティング、合成アドレスへの接続などが関係している可能性があります。
対処：エラーに表示された接続先アドレスを確認し、ネットワークアダプターとルーティング範囲を調べます。FakeIPのアドレス範囲に該当する場合は、古いマッピングを消去し、TUNが正常に動作していることを確認してください。
設定後は、次の4項目で動作を確認してください。ブラウザーによる検査で確認できるのは、現在のブラウザーが発生させるテスト通信だけです。ほかのアプリの確認には別途テストが必要です。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。Androidへ移行する場合は、それぞれのDNSと通信制御設定を改めて確認してください。デスクトップのシステムプロキシで得た結果をそのまま当てはめないでください。
- プロキシ対象のドメイン：リゾルバーの選択が想定どおりで、問い合わせと接続の出口を説明でき、意図しないローカルDNSへのフォールバックがないこと。
- 直接接続するドメイン：意図したローカル名前解決を維持し、LAN内の機器や必要な内部サービスに引き続きアクセスできること。
- 再起動後：クライアントを終了して再起動した後もノードのドメイン名が初回から解決でき、前回のキャッシュに依存せず設定が機能すること。
- 通常の利用環境に戻す：ブラウザーのセキュアDNSを予定していた設定に戻して再テストし、IPv4、IPv6、実際に使うアプリも確認すること。