Webサイトの接続先は切り替わっているのに、DNS検査では利用中の回線事業者が表示される場合は、ブラウザー・OS・コアのどこで名前解決されているかを切り分けましょう。この記事ではWindows版v2rayNを例に、比較テスト、リモートDNSの通信経路、TUNの取り込み確認、ログの調査方法を解説します。ノードを導入して接続できているものの、ドメイン名の問い合わせが想定どおりにルーティングされているか確認したい方に適しています。
DNSリークと判断する基準
DNSはドメイン名をIPアドレスに変換する仕組みです。プロキシ接続に成功しても、すべてのアプリのDNS問い合わせが同じ経路を通るとは限りません。ブラウザーが独自の暗号化DNSを使う場合や、OSがルーターに問い合わせる場合、ノードへの接続やルーティング判定のためにプロキシコアが個別に名前解決する場合があります。それぞれの経路を確認する必要があります。
この記事でいうDNSリークとは、本来プロキシ経由にするはずのドメイン問い合わせが、誤ってローカルネットワークのDNSサーバーに送られることです。国内ドメインは直接接続し、それ以外はプロキシ経由にする設定なら、国内ドメインにローカルDNSを使うのは想定どおりの場合があります。検査結果にローカルの地域が表示されたというだけで、設定全体が機能していないとは判断できません。
v2rayNはクライアントの操作画面であり、実際の名前解決の動作は選択したコア、生成された設定、アプリ側の設定によって異なります。VMessやVLESSなどの接続プロトコルが、システムDNSを自動的に処理するわけではありません。検査ページに表示されるのは通常、テスト用ドメインの権威DNSサーバーへ問い合わせた再帰DNSサーバーの出口です。プロキシノードのアドレスとは限らず、DNSサーバーの所在国だけでは問い合わせが暗号化されているかどうかも判断できません。
まず接続先を確認し、次にDNSを検査
同じPC、同じネットワーク、同じブラウザーを使って検査します。ブラウザーでDNSLeakTestやBrowserLeaksを検索し、DNS検査ページを開いてください。検査サービスにはテスト用の問い合わせが送信されるため、機密性が必要な環境では事前にプライバシーに関する説明を確認しましょう。サブスクリプションURL、ノードの認証情報、クライアント設定全体は送信しないでください。
- プロキシを使わない状態を記録します。v2rayNのシステムプロキシとTUNを無効にし、ブラウザーに手動プロキシが設定されていないことを確認します。パブリックIP、検出されたDNSサーバー名、ブラウザーのセキュアDNSの状態を記録してください。
- システムプロキシだけを有効にします。利用可能なノードを選び、トレイメニューから「システムプロキシ」→「システムプロキシを自動設定」を選択します。Webサイトの接続先が想定どおり変わったことを確認してから、DNS検査を最初から実行してください。
- 変更する条件は一度に1つだけにします。ノードとルーティングモードはそのままにして、DNS設定またはブラウザーのセキュアDNSを変更し、再検査します。ノードの変更、ネットワークの切り替え、TUNの有効化を同時に行うと、原因を特定できません。
- TUNの有無を比較します。システムプロキシの状態を確認して記録した後、TUNを有効にし、同じ項目を検査します。切り替え後はブラウザーを再起動し、以前の接続が接続プールに残らないようにしてください。
| 結果 | 考えられる原因 | 次の手順 |
|---|---|---|
| Webサイトの接続先が変わらない | ブラウザーがプロキシを使っていない、または対象がルールによって直接接続されている | DNSを変更する前に、システムプロキシとルーティングルールの適用状況を確認する |
| 接続先は変わったが、DNSサーバーは利用中の回線事業者のまま | ローカル経由の問い合わせがあるか、あらかじめ設定された直接接続ルールに一致している可能性がある | 検査対象ドメインのルーティングとブラウザーのDNS設定を確認する |
| 複数のパブリックDNSサーバーが表示される | ブラウザー、コア、上流DNSサービスで異なる名前解決経路が使われている可能性がある | ログとパケットキャプチャを照合し、発生元を一つずつ特定する |
| DNSサーバーとノードのアドレスが異なる | ノードが独自の再帰DNSサービスまたはパブリックDNSを使っている | これだけでDNSリークと判断しない |
結論：アドレスの数ではなく、想定した経路かどうかで判断する
まず「どのドメインをプロキシ経由で名前解決するか」を明確にし、その対象の実際の問い合わせ経路を確認しましょう。DNSサーバーが複数検出されても、それだけでは証拠になりません。対象ドメインが誤ってローカルDNSへ送られていることが、修正すべき具体的な問題です。
システムプロキシとブラウザーDNS：迂回経路を確認
システムプロキシの設定が適用されるのは、主にその設定に従うアプリです。すべてのネットワーク接続を引き受けるわけではありません。独自に名前解決してから接続するプログラムや、システムプロキシをまったく使わないプログラムもあります。ブラウザーのセキュアDNS、つまりHTTPSを使ったDNS問い合わせも、別途、通信経路を確認する必要があります。有効にしただけでプロキシ経由になるわけではありません。
- 待ち受けアドレスとポートを確認します。v2rayNのメイン画面で現在のローカル待ち受け情報を確認します。設定に「設定」→「パラメーター設定」→「基本設定」がある場合は、ローカル待ち受けポートを確認してください。画面の項目名はバージョンによって異なる場合があるため、例のポート番号をそのまま使わないでください。
- ブラウザーの名前解決方法を固定します。ブラウザーの設定で「セキュアDNS」を検索し、プロバイダーと有効・無効の状態を記録します。原因を調べる間は一時的に無効にして、OSまたはプロキシが提供する名前解決経路に戻し、その後、有効にした場合の動作を個別に検査できます。
- 手動のSOCKS設定を確認します。アプリに「プロキシ経由でドメイン名を解決する」設定がある場合は、有効にしてください。アプリがローカルで名前解決してからIPアドレスをSOCKSプロキシに渡していると、Webサイトに接続できても、ドメイン名はローカルで問い合わせ済みの可能性があります。
- WebRTCとDNSを区別します。WebRTCによるアドレスの露出は、DNSとは別の検査項目です。同じ検査ページにほかのアドレスが表示されても、すべてをDNSの問題とみなさないでください。
WindowsのネットワークアダプターのDNSを、一般的な対策として127.0.0.1に変更しないでください。そのアドレスの53番ポートでDNSサービスが実際に待ち受けている場合にのみ意味があります。v2rayNのローカルHTTPプロキシやSOCKSプロキシのポートは、システムDNSのポートではありません。互いに置き換えて使うことはできません。
v2rayNのDNS設定：サーバーと通信経路を確認
変更前に現在の設定をバックアップし、選択中のコアを記録してください。「設定」→「DNS設定」を開きます。画面によっては、関連項目がパラメーター設定内にあります。同じ名前の項目が見つからない場合は、実際の画面にあるDNS設定を操作してください。別のコア向けのJSONをそのまま貼り付けないでください。項目名、利用できるテンプレート、DNSのルーティング機能はコアによって異なります。
- 直接接続時とプロキシ接続時の名前解決を明確に分けます。ルーティングを使い分ける場合、直接接続用DNSは直接接続するドメインに、リモートDNSはプロキシ経由にするドメインに使います。すべての通信対象ドメインをプロキシ経由で名前解決したい場合は、検査時に対象ドメインを直接接続用DNSへ送るルールを残さないでください。
- 利用可能なリモートDNSを指定します。DNSサーバーには通常のDNS、またはコアが対応する暗号化方式を利用できます。パブリックDNSのアドレスを入力するだけでは、通信経路は変わりません。たとえばサーバーを
1.1.1.1に変更しても、問い合わせがローカルネットワークから直接送信されるなら、「プロキシ経由で問い合わせる」という目的は達成できていません。 - DNS問い合わせのルーティングを確認します。リモートDNSへの接続が想定したプロキシ経由になっていることを確認します。プライベートアドレス向け、地域別、その他の広いルールによって、先に直接接続されていないかも確認してください。DoHは通常443番ポートを使うため、53番ポートだけを対象にしたルールで対応できたと判断しないでください。
- 初回の名前解決に必要な経路を整えます。プロキシノードのアドレスがドメイン名の場合、プロキシの接続前にノードのアドレスを取得する必要があります。DoHサーバーのアドレスもドメイン名なら、その初回の名前解決も必要です。起動時に必要な名前解決の経路を明確にし、「プロキシ接続にはDNSが必要だが、DNSには未接続のプロキシが必要」という循環を避けてください。
- 設定を保存し、コアを再起動します。起動ログに異常がないことを確認してから、新しいドメイン名にアクセスしてテストします。保存後に設定を再読み込みしていない場合、確認した結果は以前の設定によるものかもしれません。
ルーティングとTUN：システムのDNS問い合わせを確認
TUNは仮想ネットワークアダプターを使い、ルーティング条件に合うIP通信を取り込みます。システムプロキシに従わないプログラムに適しています。ただし、TUNを有効にしても、すべてのDNS問い合わせが自動的にコアのDNSリゾルバーへ送られるわけではありません。使用中のコアでDNSの取り込みやハイジャックが有効か、対象範囲はどこまでか、除外ルートがあるかを確認してください。別のコアにある同名の項目を、そのまま流用しないでください。
- まずTUNが正常に起動したことを確認します。画面の案内に従って必要な権限を付与し、仮想ネットワークアダプターの作成失敗やルート追加失敗などのログがないか確認してください。スイッチが有効になっていても、アダプターが作成されていなければ、通信を取り込めている証拠にはなりません。
- 従来型DNSの取り込みを確認します。UDP/TCPの53番ポート宛ての問い合わせが、想定した名前解決の処理に渡されているか確認してください。UDPだけではTCPの問い合わせを取りこぼします。IPv4だけを対象にすると、IPv6経由の通信が漏れる可能性もあります。
- 暗号化DNSの個別の通信経路を確認します。ブラウザー内蔵のDoHはHTTPS通信であり、従来型DNSの53番ポートへの問い合わせではありません。DNSサーバーのドメイン名またはアドレスに基づいて、ルーティングを確認してください。
- ルールの順序を確認します。ルールは通常、コアが定める順序で評価されます。広範囲の直接接続ルールがリモートDNS用ルールより先に適用されることがあります。画面にルールが存在するかだけでなく、生成された設定とログを確認してください。
- IPv6と複数のネットワークアダプターを確認します。無線、有線、ほかのトンネルが同時に存在する場合があります。実際に使用中のインターフェースのDNSサーバーとルートを確認してください。IPv6の無効化を恒久的な一般対策とせず、まず該当する通信の取り込み経路を整えましょう。
FakeDNSは、DNSリーク対策として必ず有効にする設定ではありません。仮想アドレスを返し、ドメイン名との対応関係を保持して通信処理に利用します。そのため、名前解決の入口と後続の接続の両方が、対応するコアに取り込まれる必要があります。システムのキャッシュに仮想アドレスが残った状態で通信が処理経路から外れると、かえって接続できなくなることがあります。通常のリモートDNSで目的を満たせるなら、まずはシンプルな設定にしてください。
Windowsでの確認コマンドとエラーの対処
PowerShellで以下のコマンドを実行すると、ネットワークインターフェースのDNS設定やローカルキャッシュを確認し、システムキャッシュを消去できます。キャッシュを消去すると、ほかのアプリによる次回の名前解決にも影響しますが、ブラウザー独自のキャッシュがすべて消えるわけではなく、既存の接続も自動で終了しません。消去後はブラウザーを完全に終了し、検査ページを開き直してください。
Get-DnsClientServerAddress
Get-DnsClientCache
Clear-DnsClientCache
Resolve-DnsName example.comResolve-DnsNameとnslookupは、ブラウザーのプロキシ接続を検査するコマンドではありません。システムプロキシだけを有効にしている場合、これらの問い合わせがHTTPプロキシやSOCKSプロキシ経由になることは通常ありません。TUNモードで取り込まれるかどうかは、DNSの取り込み設定とルーティングによります。コマンドが成功しても、名前解決が完了したことしか確認できず、通信経路が要件を満たす証拠にはなりません。
エラー：i/o timeout
原因：制限時間内に応答がありません。DNSログに表示された場合は、上流サーバーに到達できないか、該当する通信経路が使えない可能性があります。
対処：まず同じログの宛先アドレスと通信経路を確認し、プロキシ接続とDNSサービスをそれぞれ検証します。タイムアウトが出るたびに、やみくもにタイムアウト時間を延ばさないでください。
エラー：no such host
原因：名前解決に失敗しています。ドメイン名の入力ミス、上流DNSからの不存在応答、起動時の名前解決経路の設定不備などが考えられます。
対処：エラーがノードのドメイン名、DNSサービスのドメイン名、アクセス先のどれに対応するかを確認し、そのドメインに使われるDNSサーバーを調べます。すべての失敗をノードの障害と決めつけないでください。
エラー：connection refused
原因：接続先のポートに拒否されています。DNSの接続先をローカルに設定しているのにDNSサービスが待ち受けていない場合や、ローカルプロキシのポートを間違えている場合によく発生します。
対処：画面に表示された実際の待ち受け情報を確認し、DNSの53番ポートとプロキシのポートを区別します。対応する待ち受けサービスがないループバックアドレスの設定は取り消してください。
より確かな証拠が必要な場合は、物理ネットワークアダプター上の従来型DNS通信をキャプチャし、UDP/TCPの53番ポートの宛先アドレスとテスト対象ドメインを確認します。仮想アダプター上の通信だけを見ると、最終的な送信先を見落としやすくなります。物理アダプター上に暗号化されたプロキシ通信が見えるのは正常です。また、53番ポートの通信が見えなくても、DoHサーバーへの直接接続は否定できません。ブラウザーの設定とコアのログも併せて確認してください。
よくある質問と修正後の再検査
リモートDNSを変更しても、検査結果に同じ回線事業者が表示されるのはなぜですか？
まずブラウザーが独自のセキュアDNSを使っていないか確認し、DNS設定が保存され、コアが再起動されていることを確認します。次に、検査対象ドメインが直接接続ルールに一致していないか調べてください。サーバーのアドレスを変えるだけで問い合わせの送信経路を変更しなければ、通常、経路は変わりません。
システムプロキシの検査に問題がなくても、ほかのプログラムからDNSが漏れることはありますか？
あります。検査ページで確認できるのは、現在のブラウザーが発生させた問い合わせだけです。システムプロキシに従わないプログラムは、個別にプロキシ設定とDNS設定を確認するか、TUNで取り込まれることを検証してください。ブラウザーで一度検査しただけで、すべてのアプリが問題ないとは判断できません。
検査ページに複数の国が表示されたら、設定に問題があるのでしょうか？
必ずしもそうとは限りません。パブリックDNSサービスが複数の出口を使っている場合や、IPアドレスの位置情報に誤差がある場合があります。まずブラウザー独自の名前解決経路を無効にして比較し、送信ログと物理ネットワークアダプター上の通信を確認してください。国名の表示だけを理由にDNSサーバーを削除しないでください。
TUNを有効にした後、すべてのWebサイトが開けなくなりました。まず何を確認すればよいですか？
まずTUNを無効にして元の接続を復旧し、仮想ネットワークアダプター、ルート設定の権限、起動時の名前解決が循環していないかを確認します。動作する設定に戻してから、一度に一項目ずつ変更してください。FakeDNS、全トラフィックのルーティング、新しいDNSテンプレートを同時に追加しないでください。
修正後は「システムプロキシの検査」「TUNの検査」「実際のアプリでの検査」を分けて結果を記録します。毎回、Webサイトの接続先、DNSサーバー、ブラウザーのセキュアDNSの状態、コアのエラーログを確認してください。国内向けの直接接続を残す場合は、想定どおり直接接続する問い合わせと、プロキシ経由にする問い合わせを分けて記録し、正常なルーティングをリークと誤認しないようにしましょう。
- プロキシ経由にするテスト対象ドメインが、ローカルの平文DNS問い合わせに誤って現れない。
- リモートDNSへの接続が想定した通信経路を通り、ログに継続的なタイムアウトや起動時の名前解決ループがない。
- クライアントとブラウザーの再起動後も同じ結果を再現でき、ネットワークを切り替えた後にも再検証している。
- ブラウザーのセキュアDNSを再び使う場合は、個別に有効化して通信経路を再検査する。