この記事の要点

Webページはプロキシ経由なのに、DNSテストでは利用中の回線事業者が表示される場合に役立つ内容です。まず同じテストページで直接接続とプロキシ接続を比較し、ブラウザーのセキュアDNS、WindowsのシステムDNS、コアのDNSという3つの経路を切り分けます。そのうえで、TUNによる通信の取り込み、リモートDNSの接続先、トラフィック検出を確認します。判断の基準は、テストページに表示された国名ではなく、クエリが実際に通過した経路です。

1. DNSリークの判断：クエリと接続を切り分ける

DNSはドメイン名をIPアドレスに変換します。Web接続がプロキシ経由でも、その前段のドメイン名の問い合わせまでプロキシを通るとは限りません。たとえば、アプリがルーターの192.168.1.1:53に問い合わせ、その結果のIPアドレスをローカルプロキシに渡す場合、ページは表示できますが、DNSクエリはすでにローカルネットワークへ送信されています。確認すべきなのは、このように経路が分かれている状態です。

アプリからドメイン名を要求名前解決の経路を選択DNSクエリを送信接続先アドレスを取得Web接続を確立

オンラインのDNSリークテストでは通常、ブラウザーからランダムなサブドメインにアクセスさせ、テスト事業者の権威DNSサーバーが、どのリゾルバーから再帰問い合わせを受けたかを確認します。ページに表示されるのは多くの場合、再帰リゾルバーまたはその出口であり、PCのネットワークアダプターから送信された全パケットを直接示すものではありません。リゾルバーの所在国がプロキシの出口と異なるだけでは、リークの証拠にはなりません。

2. オンラインテスト：再現可能な3つの条件を比較

ブラウザーでdnsleaktest.comを開き、まずStandard testを実行してから、Extended testでも確認します。テストページにはテストに関連するネットワーク情報が送信されます。入力欄にサブスクリプションURL、ノードの認証情報、社内ドメインを入力しないでください。以下は記録用のテンプレートであり、本記事で実施したテスト結果ではありません。

テスト条件記録する項目主な目的
TUNを無効にし、システムプロキシを解除パブリックIP、リゾルバーのIP、事業者名現在のネットワークで直接接続した場合の基準を記録
システムプロキシを有効にし、同じノードを使用パブリックIPの変化、基準時のリゾルバーが引き続き表示されるかブラウザーのプロキシ経路を確認
TUNを有効にし、同じノードを使用リゾルバーの一覧、コアのログ、ブラウザーのDNS状態通信の取り込み範囲とDNSの接続先を確認

  1. 基準を記録

    信頼できるネットワークで、まずメイン画面の「TUNを有効にする」をオフにし、「システムプロキシ」→「システムプロキシを解除」を選びます。テスト結果を記録してください。この状態でのアクセスは、現在のネットワークを直接経由します。

  2. 条件を固定

    利用可能なノードを1つ選び、同じブラウザー設定を使います。ブラウザーの「セキュアDNS」が有効かどうかも記録してください。比較中はノード、リゾルバー、ルーティングルールを同時に変更しないでください。

  3. キャッシュを消去

    管理者権限のPowerShellでClear-DnsClientCacheを実行します。ブラウザーを完全に終了してから開き直し、ブラウザーのキャッシュや接続の再利用による影響を抑えます。

  4. 条件ごとにテスト

    まずシステムプロキシ、次にTUNの順でテストします。それぞれの状態で2回実行し、時刻とリゾルバーのIPを記録してください。国名の表示だけをスクリーンショットに残したり、古いタブの結果を最新の結果として扱ったりしないでください。

結論：繰り返し表示されるローカルリゾルバーを特定する

プロキシ出口が変わったにもかかわらず、2回のテストでどちらも直接接続時の基準に記録した事業者のリゾルバーが表示される場合は、まずローカルの名前解決経路を確認します。パブリックリゾルバーの地域が異なるだけなら、すぐにノードを変更せず、サービスの提供元を確認してください。

3. システムプロキシとTUN：通信を取り込む範囲の違い

v2rayNの「システムプロキシ」→「システムプロキシを自動設定」は、Windowsのプロキシ設定に従うアプリに主に影響します。これはシステム全体のDNSを取り込むスイッチではありません。システムプロキシを無視するアプリもあれば、Windowsでドメイン名を解決してからプロキシのポートに接続するアプリもあります。SOCKSを使うアプリでは、プロキシアドレスが正しいかだけでなく、「プロキシ経由でドメイン名を解決する」設定も確認してください。

本記事では、v2rayN 7.xで一般的なデスクトップ画面を操作手順の目安にしています。以降のバージョンでは項目名が変わる場合があります。メイン画面の「TUNを有効にする」は、仮想ネットワークアダプターによる通信の取り込みを開始します。TUNの実装、DNSのリダイレクトルール、ルーティングの動作は、実際に起動しているコアによって異なります。ノードにXrayを使っていても、TUN層までXrayが提供しているとは限りません。起動ログを確認して判断してください。

4. リモートDNS：リゾルバーと接続先の両方を設定

v2rayNで「設定」→「DNS設定」を開き、編集中の設定が実際に使用するコアのものか確認します。Xrayとsing-boxのDNS設定は形式が異なるため、片方のコア向けJSON全体をもう片方の設定画面に貼り付けることはできません。カスタム設定ノードを使っている場合、一部のGUI設定が反映されないこともあります。実際に生成され、読み込まれた設定を基準に確認してください。

リモートDNSには、サービスが提供するDoHアドレスを指定できます。例：https://1.1.1.1/dns-query。DoHはクライアントからリゾルバーまでのクエリを暗号化しますが、接続がプロキシを通ることまでは保証しません。DNSサービスからプロキシ出口が見えるようにしたい場合は、URLがHTTPSであることだけでなく、そのHTTPS接続の接続先も確認してください。

設定項目具体的な確認内容見落としやすい点
リゾルバーのアドレスDoHのパス/dns-queryが最後まで正しく設定されているか確認サービスのトップページだけを指定し、DNS応答ではなくWebページが返される
クエリの接続先リモートDNSへの接続をプロキシ経由にするDoHは暗号化されていても、ローカル回線から直接接続される場合がある
起動時の名前解決ノードとリゾルバーのドメイン名を解決できる起動時の経路を確保するプロキシの接続にDNSが必要なのに、DNSがまだ確立していないプロキシに依存している
失敗時のフォールバックシステムDNSや事業者のDNSにフォールバックしていないか確認するリモートDNSに失敗すると、気づかないままローカルDNSに切り替わる

Xray内蔵DNSの通常のhttps://モードを使う場合は、ルーティング設定と照らし合わせ、DNS接続の出口を確認してください。https+local://はローカルモードであり、「必ずプロキシ経由にする」ための代替指定ではありません。IPアドレス形式のDoHエンドポイントを使う場合は、サービス証明書がそのアドレスを正しくカバーしていることを確認してください。接続エラーを解消するために証明書検証を無効にしないでください。

5. トラフィック検出：ドメイン名を復元する機能であり、DNSの取り込みとは別

「設定」→「パラメーター設定」で、「トラフィック検出」に関する項目を探します。バージョンによって「トラフィック検出を有効にする」など、項目名が異なる場合があります。HTTP HostやTLSハンドシェイクなど、確認可能な情報から接続先のドメイン名を復元し、ルーティング判定を補助します。ただし、アプリがローカルリゾルバーに送信済みのクエリを取り消す機能ではありません。

以下は設定の意味を確認するために、Xrayのインバウンドにある検出フィールドだけを示したものです。完全な設定ファイルではなく、sing-boxのDNS設定にそのまま貼り付けられる内容でもありません。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"],
    "routeOnly": true
  }
}

ブラウザーのセキュアDNSも個別に確認が必要です。Chromeでは「設定」→「プライバシーとセキュリティ」→「セキュリティ」から「セキュアDNSを使用する」を確認できます。Edgeでは設定画面で「セキュアDNS」を検索してください。原因を切り分けるときは、まずオフにして比較テストを行い、最終的な方針に合わせて有効にするか決めます。最終確認では、長期的に使う予定の設定でテストしてください。テスト中だけオフにし、テスト後にオンにした状態で再確認しないのは避けましょう。

6. ログのエラーとコマンドで原因を特定

コアのログにエラーがあっても、それは特定の処理が失敗したことを示すだけで、DNSリークが発生した証拠ではありません。接続先、発生時刻、接続先タグとあわせて原因を確認してください。以下はよくあるエラーの例です。前後の文字列はコアのバージョンによって異なる場合があるため、ログ全体が例と完全に一致する必要はありません。

エラー：lookup example.com: no such host

原因と対処：名前解決の結果が「存在しない」か、現在の名前解決経路でドメインを解決できていません。まずドメイン名の入力ミスがないか確認し、既知の解決可能なドメインと比較したうえで、DNSルールが誤ったリゾルバーにクエリを送っていないか確認します。

エラー：context deadline exceeded

原因と対処：処理がタイムアウトしています。DNSリクエストとプロキシ接続のどちらでも発生する可能性があります。同じログに記録された接続先を確認してください。DoHエンドポイントの場合は、ルーティング、プロキシへの接続、起動時の名前解決への依存関係を調べます。

エラー：x509: certificate has expired or is not yet valid

原因と対処：システム時刻、またはサービス証明書の有効期間に問題があります。まずWindowsの日付と時刻を同期し、次にエンドポイントの証明書の状態を確認してください。TLS証明書の検証は無効にしないでください。

Windowsで現在使われているDNSアドレスを確認するには、PowerShellで以下のコマンドを実行できます。これらはネットワークアダプターの設定確認やシステムDNSの検証に使うもので、プロキシ経由のブラウザーを同じ条件でテストするものではありません。特に、リゾルバーを手動指定した問い合わせは、TUNに取り込まれていない場合、そのアドレスへ直接送信される可能性があります。

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientServerAddress -AddressFamily IPv6
Clear-DnsClientCache
Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type AAAA

ネットワークアダプターの一覧にルーターのDNSが残っていても、TUNがその宛先へのクエリを捕捉している可能性があるため、それだけでリークの証拠にはなりません。反対に、パブリックDNSが表示されていても、クエリがプロキシ経由である証拠にはなりません。さらに調べるには、物理ネットワークアダプター上でUDP/TCP 53番とTCP 853番への直接通信をパケットキャプチャで確認します。HTTPS上のDoHはポート443だけでは通常のWeb通信と区別できないため、宛先アドレスやコアのログもあわせて確認してください。

結論：リークを論じる前に、失敗している経路を直す

リモートDNSがタイムアウトする場合は、まず指定した接続先を経由して安定して動作するようにします。そのうえで、方針に合わないローカルDNSへのフォールバックを無効にしてください。原因を直さずにフォールバックだけを削除すると、「ときどきリークする」状態が「すべてのドメインを解決できない」状態に変わるだけで、ルーティングの問題は解決しません。

7. 最終確認：普段使う状態をまとめてテスト

変更を保存したら、クライアントの案内に従ってコアを再起動します。TUNのルートや仮想ネットワークアダプターを変更した場合は、TUNをいったん無効にしてから有効にしてください。最終確認では1つのWebページだけでなく、再起動後、ネットワーク切り替え後、IPv6の動作もテストします。1つのテストページで分かるのは、そのときのブラウザーの通信だけであり、すべてのバックグラウンドアプリの動作を保証するものではありません。

安定した動作には、アプリの通信が想定した入口に入り、ドメイン名の問い合わせが想定したリゾルバーを使い、名前解決の接続が想定した出口を通るという3点が必要です。TUN、DoH、トラフィック検出はそれぞれ異なる部分を処理します。パブリックDNSのアドレスを何度も変更するより、3点を個別に検証するほうが原因を特定しやすく、クライアントのアップデート後の再確認にも役立ちます。