V2RayのDNS振り分け設定｜中国国内・国外ドメインの名前解決とDNS汚染対策

まず仕組みを整理：DNSの振り分けと通信の振り分けは別

ドメインにアクセスするとき、DNSは接続先のIPアドレスを調べ、ルーティングはどのアウトバウンドから接続するかを決めます。これは別々の判断です。中国国内のドメインをローカルDNS、その他のドメインをリモートDNSで名前解決する設定は、問い合わせ先を指定するものにすぎません。ルーティングルールで接続が直接接続用アウトバウンドに送られていれば、リモートDNSを使ったからといって自動的にプロキシ経由にはなりません。

問い合わせがコアに届いているかも、先に確認しましょう。システムプロキシだけを有効にしている場合、ブラウザーはOS経由で名前解決することも、独自に暗号化DNSを使うこともあります。ターミナルのプログラムも、それぞれのプロキシ設定によって動作が異なります。V2RayやXrayの内蔵DNS設定で直接制御できるのは、コアに渡された名前解決リクエストだけです。アプリがローカルで名前解決してIPアドレスをプロキシに渡した場合、コアから元のドメインが見えないことがあります。

トラブルシューティングでは、次の順に確認します。アプリがドメインとIPアドレスのどちらを渡しているか、DNSでどのサーバーが選ばれたか、接続がどのルーティングルールに一致したか、の順です。「ノードに接続済み」だからといって、DNSも想定どおりに振り分けられているとは限りません。ノードの状態から分かるのは接続が確立したことだけで、ブラウザーの名前解決経路までは確認できません。

中国国内とその他のドメインでリゾルバーを使い分ける

内蔵DNSでよく使われる設定は、中国国内のドメインルールに一致する問い合わせをローカルで名前解決し、それ以外はリモートで名前解決する方法です。ドメインルールはコアで利用できるルールデータに基づきます。対象範囲はコアやルールデータのバージョンによって異なる場合があります。ルールに一致しないドメインはデフォルトのリゾルバーを使うため、細かなルールを増やす前に、デフォルトの問い合わせ先を確認しましょう。

ここでいう「国内・国外」はドメインルール上の分類であり、問い合わせのたびにサーバーの所在地を判定するものではありません。ドメインによっては複数の地域にサービス基盤があり、分類もルールデータの更新によって変わることがあります。業務用サイトや社内ドメインには、明示的なルールを優先して設定してください。ドメインの末尾だけを見て通信経路を決めないようにしましょう。

v2rayNの設定と構成形式を確認する

まずv2rayNの「設定」→「パラメーター設定」で、使用中のコアとプロキシモードを確認し、クライアントのDNS設定画面を開きます。バージョンによって設定画面のレイアウトが異なる場合があるため、実際の画面に表示される項目を確認してください。変更前に元の設定を保存しましょう。サブスクリプション、プリセット設定、自作テンプレートなどでコア設定が再生成される場合は、再起動後も変更が反映されているか確認してください。

以下は項目間の関係を確認するためのXray DNS設定例で、単独で動作する完全な設定ではありません。geosite:cnに一致したドメインは、localhostが示すシステムのローカルDNSに渡し、それ以外の問い合わせは後続のDoH設定に送ります。実際に使う前に、使用する項目をコアがサポートしていること、ルールデータを利用できることを確認し、例示のDoHアドレスを有効なエンドポイントに置き換えてください。

{
  "dns": {
    "servers": [
      {
        "address": "localhost",
        "domains": ["geosite:cn"]
      },
      "https://dns.example.net/dns-query"
    ],
    "queryStrategy": "UseIP"
  }
}

queryStrategyは問い合わせるアドレスファミリーの方針を指定するもので、直接接続かプロキシ接続かを選ぶ設定ではありません。サイトにIPv6レコードしかなく、現在のネットワークでIPv6を利用できない場合は、まずアドレスファミリーの選択を確認し、IPv6の問題をリモートDNSの障害と誤認しないようにしましょう。前述のdns.example.netは例示用ドメインで、対応するエンドポイントは実際の名前解決サービスを提供しません。

DoHとfakednsの役割

DoHはHTTPS経由でDNS問い合わせを送信します。アプリと指定したリゾルバー間で、通常の平文DNS経路によって問い合わせ内容を書き換えられる可能性を減らせますが、ルーティングルールの代わりにはならず、リゾルバーが返すアドレスすべてが現在のアウトバウンドに適しているとも限りません。リモートDoHへのリクエスト自体にも接続が必要です。エンドポイントにドメインを指定している場合、初回接続時にそのドメインの名前解決が発生することがあります。実際のアウトバウンド経路をログで確認してください。

fakednsは、これとは異なる仕組みです。コアがまずアプリに対応付け用の仮想アドレスを返し、アプリがそのアドレスに接続すると、元のドメインを復元して処理します。元のドメイン情報を維持する必要がある特定の透過プロキシ環境で利用できます。パブリックDNSサーバーではなく、すべての実DNS問い合わせを一括で暗号化する機能でもありません。有効にするかどうかは、TUN、インバウンドの取り込み、スニッフィングの設定とあわせて判断してください。

この2つのポート番号は、リクエストの種類を見分ける手がかりにすぎず、すべての問い合わせがコアを通ることを示すものではありません。たとえば、ブラウザー独自のDoHが有効な場合、そのリクエストは通常のHTTPS接続として扱われることがあります。ポート53の通信があるかどうかだけでは、ブラウザーが最終的にどのリゾルバーを使ったのか判断できません。

DNSの結果とルーティングルールを連携させる

ルーティングのドメインルールとIPルールは役割が異なります。ドメインルールはドメインに基づいてアウトバウンドを直接決められますが、IPルールには利用可能な宛先IPが必要です。XrayのdomainStrategyを例にすると、IPIfNonMatchはドメインルールに一致しない場合に名前解決を試み、続けてIPルールを照合します。IPOnDemandはルーティング判断でIPアドレスが必要になった時点で名前解決します。ルーティングのdomainStrategyとDNSのqueryStrategyを同じ設定として扱わないでください。

• ドメインルール：社内サービスや業務用ドメインなど、明確なルールを先に設定してから、汎用的な分類ルールを使います。ルールの順序と実際に一致したアウトバウンドを確認してください。
• IPルール：名前解決後のアドレスに基づいて判断する必要がある場合は、ルーティングで名前解決が実行されるか確認してください。すべてのドメインリクエストで事前にIPアドレスが検索されるとは限りません。
• アプリがIPアドレスを渡す場合：プロキシに届く前にアプリが名前解決していると、ドメインルールで直接照合できないことがあります。プロキシモードと、元のドメインが見えるかを確認してください。

実用的な検証方法として、アクセス結果を自分で確認できるドメインを2つ選びます。一方はローカルDNSルールに明示的に登録し、もう一方はデフォルトのリモートリゾルバーに任せます。Webページの読み込み速度だけを比べず、DNS問い合わせ、ルーティングの一致結果、最終的なアウトバウンドをそれぞれ記録してください。DNSの選択が正しいのに接続経路が違う場合は、ルーティングルールを調整します。ルートが正しいのに名前解決結果が異常な場合は、DNSルールの一致状況と上流リゾルバーを確認しましょう。

症状別に確認：クライアントからコアのログまで

テスト前にv2rayNの現在のローカルプロキシポートを記録し、システムプロキシが同じポートを参照していることを確認します。ポート番号はデバイスや設定によって異なるため、例示のポートを常用設定にしないでください。ブラウザーでテストする場合は、独自のDNS設定や拡張機能の動作も一時的に確認します。ターミナルでテストする場合は、コマンドが明示的にプロキシを使っているかを調べ、直接接続の結果でコアのDNSを検証しないようにしましょう。

1. まずリクエストの入口を確認。ブラウザーとターミナルでそれぞれテストし、該当時刻の接続記録をv2rayNのログで探します。記録がなければ、システムプロキシ、アプリのプロキシ設定、またはTUNによる取り込み状態を確認してください。
2. 次にドメインが保持されているか確認。ログに宛先IPしか表示されない場合は、アプリが事前に名前解決していないか確認します。ドメインが表示されている場合は、DNSルールとルーティングルールがそれぞれ一致しているか確認してください。
3. 最後に結果を比較。同じドメインを複数回テストするときは、時刻、使用したリゾルバー、返されたアドレスファミリー、アウトバウンドを記録します。前のネットワークのキャッシュ結果を使い回さないよう、ネットワークを変更したらテストし直してください。

「ブラウザーでは開けるのにターミナルでは開けない」場合、すぐにDoHを切り替えないでください。ターミナルのプログラムがシステムプロキシを参照していないか、独自のプロキシ環境変数だけを参照している可能性があります。「中国国内のサイトがリモート経由になる」場合は、まずドメインの分類とルーティングの一致を確認します。「一部のドメインだけ失敗する」場合は、DNSの応答、IPv4／IPv6の利用可否、そのドメインに個別ルールが必要かを確認してください。