v2rayNのDNS設定：中国国内外のドメインを分けて名前解決する汚染対策

まずシステムDNS、コアDNS、リモートDNSを区別する

v2rayNで「設定」→「パラメーター設定」を開き、現在有効なコアの種類、システムプロキシモード、TUNの状態を確認します。DNS振り分けは、どのサーバーを入力したかだけでなく、ドメインリクエストがXrayコアに入っているかどうかにも左右されます。通常のシステムプロキシはアプリのHTTPまたはSOCKS通信を主に処理するため、一部のアプリはOSのDNSを直接利用します。TUNモードではより多くの通信をカバーできますが、DNSハイジャックとルール設定も同時に確認が必要です。

システムDNSは、ネットワークアダプターまたはOSが現在使用しているリゾルバーです。コアDNSは生成された設定の最上位にある dns オブジェクトで、ドメインルールに応じてDNSサーバーを選択します。リモートDNSとは、プロキシのアウトバウンド経由で指定したリゾルバーへ問い合わせることであり、単にサーバーアドレスを国外のものへ変更することではありません。問い合わせパケットが直結経路から送信されているなら、リモートサーバーを指定しただけではリモートDNSにはなりません。

中国国内向けローカルDoHと国外向けリモートDNSを設定する

まず中国国内ドメイン用に低遅延のローカルDoHを用意し、それ以外のドメイン用にプロキシ経由で接続するリモートDoHを用意します。振り分けには、解決後のIPアドレスではなくドメインセットを使います。問い合わせ前にリゾルバーを決められるため、国外ドメインを先にローカルDNSへ漏らし、不正確な結果を取得する事態を避けられます。

1. 「設定」→「パラメーター設定」を開き、Xrayコアが有効であることを確認し、ローカルSOCKSの待受ポートを控えます。一般的なデフォルト値は 10808 ですが、実際の値は現在のパラメーター画面に従ってください。
2. v2rayNのDNS設定画面を開き、現在のコアに対応する設定欄を選びます。バージョンによって画面名は多少異なるため、変更後は編集欄だけでなく、生成された実行設定を確認してください。
3. 中国国内向けDoHサーバーを geosite:cn のようなドメインルールに関連付け、期待する返却アドレスを geoip:cn で制限します。
4. リモートDoHを後続の一致位置に置き、国外ドメインおよび未一致ドメインのリゾルバーにします。同時に、そのDoHドメインまたは接続先への通信がプロキシのアウトバウンドを経由することを確認します。
5. 設定を保存してコアを再起動します。まず明確に中国国内向けのドメインをテストし、次に国外ドメインをテストしてください。単一のサイトだけで判断しないことが重要です。

以下はXrayの dns オブジェクトの基本構造を示す例です。完全な設定をv2rayNの自動生成設定にそのまま上書きするものではありません。実際にはクライアントのカスタムDNS欄へ統合し、既存のログ、インバウンド、アウトバウンド、ルーティング設定を残してください。

{
  "dns": {
    "queryStrategy": "UseIP",
    "disableCache": false,
    "hosts": {
      "dns.local.example": "223.5.5.5"
    },
    "servers": [
      {
        "address": "https://dns.alidns.com/dns-query",
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "https://1.1.1.1/dns-query"
    ]
  }
}

queryStrategy が UseIP の場合、コアは利用可能なネットワークに応じてAとAAAAの結果を問い合わせます。ローカルネットワークでIPv6が安定していないのにIPv6問い合わせを強制すると、名前解決は成功しても接続がタイムアウトすることがあります。IPv4のみを使う環境では、現在のコアが対応する方式を選べますが、問い合わせ方式とルーティングのアウトバウンドを同じ項目として扱わないでください。

リモートDNSの問い合わせを確実にプロキシ経由にする

リモートDoHも本質的にはHTTPS接続です。接続先アドレスがルーティングルールによって直結アウトバウンドへ送られると、問い合わせはローカルネットワークから発信されます。ルーティング設定でリモートリゾルバーのドメインをプロキシ経由に明示し、ローカルDoHまでプロキシへ送らないようにして、中国国内向け問い合わせの低遅延を保ちます。

• 「設定」→「ルーティング設定」でカスタムルールの順序を確認します。リモートDoHドメインのプロキシルールは、広範な直結ルールより前に置いてください。
• ローカルDoHドメインは geosite:cn または明示的なドメインで直結に設定でき、接続ポートは通常 443 です。
• 従来型DNSでUDP 53を使う場合は、TUNやファイアウォールによってパケットがコアを迂回していないか確認します。DoHはHTTPSを使うため、通常のTCP通信と同じルーティングルールを適用しやすい方式です。
• サブスクリプションノードのサーバーアドレスがドメイン名の場合は、初回接続に使える基本的な名前解決経路を残してください。そうしないと、「プロキシに接続しないとノードを解決できないが、ノードを解決しないとプロキシに接続できない」という循環が起きます。

切り分け時はv2rayNのログ画面を開き、コアのログレベルをDNSとルール一致を確認できる程度まで一時的に上げます。その後、システムキャッシュを消去してテストドメインへ順番にアクセスします。問い合わせ種別、DNSサーバー、ルーティングのアウトバウンドタグ、返却アドレス、タイムアウト原因を確認してください。テスト後はログレベルを下げ、日常の出力を減らせます。

hosts、fakeDNS、キャッシュの優先順位を整理する

hosts は通常のDNS問い合わせ前に指定ドメインを上書きします。固定された内部サービスのアドレス、障害中の名前解決の一時回避、あるドメインから別のドメインへのマッピングに適しています。頻繁に変わる大規模サイトのアドレス管理には向きません。固定IPによって最寄りの配信先選択を迂回したり、サーバーアドレス変更後に接続できなくなったりするためです。

fakeDNSは主にTUN環境で使われます。まずアプリに合成アドレスを返し、一般的なアドレスプールは 198.18.0.0/15 にあります。コアはその後、合成アドレスから元のドメインを特定してルーティングします。これによりドメイン情報を保持でき、アプリがシステム層で実アドレスを解決し、コアにはIPだけが渡る状況を減らせます。有効化の判断は、現在のTUN設定とコアの対応状況に従ってください。

キャッシュはTTLが切れるまで解決結果を保存し、重複問い合わせやページ初回表示時の待ち時間を減らします。DNSルールを変更しても古い結果が表示される場合、新設定が無効なのではなく、システム、アプリ、コアのいずれかのキャッシュに古い記録が残っている可能性があります。まずコアを再起動し、次にOSのDNSキャッシュを消去し、テスト対象のアプリを完全終了してから再起動してください。

hostsによる上書き

通常のサーバー問い合わせ前に指定したアドレスまたは別名を返します。少数の明確で管理しやすいドメインマッピングに適しています。

fakeDNS

アプリに合成アドレスを返し、コア内に元のドメインとの対応関係を保持します。主にTUN通信でドメインを識別するために使います。

DNSキャッシュ

TTLに従って既存の結果を再利用します。遅延を下げられますが、設定変更後もしばらく古い結果が表示されることがあります。

{
  "dns": {
    "hosts": {
      "internal.example": "192.168.10.20",
      "alias.example": "target.example"
    },
    "disableCache": false,
    "disableFallback": false
  }
}

hostsを設定した後は、名前解決と実際の接続を分けて確認します。解決結果が正しいのにウェブページを開けない場合、接続先サービスが正しいTLSドメイン、リバースプロキシの入口、特定ポートを要求している可能性があります。hostsが変えるのはアドレスの選択だけで、証明書検証、HTTP Host、サーバーの待受設定は書き換えません。

症状から名前解決失敗とルール未一致を切り分ける

問題をまず「問い合わせが送信されない」「誤った出口を通る」「期待と異なる結果が返る」「名前解決は正しいが接続に失敗する」の4種類に分けます。ウェブページを開けるかどうかだけでDNSを判断しないでください。TLSハンドシェイク、ルーティングルール、ノードの状態、接続先サービスも同じような症状を引き起こします。

コマンドラインのテストは補助的な証拠になりますが、nslookup はデフォルトでシステムDNSに問い合わせるため、必ずしもXrayコアを経由しません。OSが現在使っているリゾルバーの確認には適していますが、リモートDoH経路の証明だけに使うことはできません。コアのDNS振り分けを検証する際は、コマンド結果、v2rayNのコアログ、ネットワーク出口の状況を組み合わせて確認してください。

1. 変更前のDNS設定、ルーティングモード、コアの種類、待受ポートを記録する。
2. 一度に変更する変数は1つだけにする。たとえば、まずリゾルバーを調整し、その後にルーティングルールを調整する。
3. コアを再起動し、JSON解析エラー、ポート競合、DNS初期化失敗がないことを確認する。
4. 中国国内ドメインと国外ドメインを1つずつ使ってテストし、一致したサーバーとアウトバウンドタグを記録する。
5. 最後に通常のログレベルへ戻し、動作する設定のコピーを保存する。