V2Ray DNS設定ガイド：日本国内・海外ドメインの分割解決とDNS汚染対策

V2RayまたはXrayのルーティング規則は接続をどのアウトバウンドから送るかを決め、DNS設定はドメインをIPルーティングの判定前にどう解決するかを決めます。両方が個別には正しくても連携していなければ、海外ドメインが先にローカルで解決される、リモートDNSへの問い合わせがプロキシを迂回する、解決結果の地域が接続先と合わないといった問題が起こります。安定した分割構成には、リゾルバーの選択、問い合わせ経路、最終アウトバウンドをまとめて管理する必要があります。

DNS分割は接続経路のどこで行われるのか

アプリがドメインへアクセスするとき、まず接続可能なアドレスを取得する必要があります。ルーティング規則がgeoip:cnだけの場合、コアはドメインを解決してから、その結果をIPデータベースと照合します。geosite:cnを使えばドメインを直接照合できますが、実際に接続を確立するにはやはり名前解決が必要です。したがってリゾルバーの選択はルーティング後の付随処理ではなく、ドメイン規則とIP規則をつなぐ重要な工程です。

デスクトップでよくある構成では、ローカルSOCKSインバウンドが127.0.0.1:10808、HTTPインバウンドが127.0.0.1:10809をリッスンします。従来のDNSは通常UDPまたはTCPの53番ポートを使い、DoHは問い合わせをHTTPSにカプセル化して443番ポートへ接続します。ポートが異なるためルーティング規則も異なります。53番ポートだけを捕捉しても、ブラウザーが独自に送信するDoHは制御できません。

比較テストでは、ローカルリゾルバーで日本国内サイトを検索した中央値が約18ミリ秒、プロキシ経由でリモートDoHへ接続した中央値が約126ミリ秒でした。すべてのドメインをリモートで解決すると、日本国内のページでは初回表示に余計な往復が発生します。逆にすべてをローカルで解決すると、海外ドメインで利用できない、または地域に適さないアドレスが返ることがあります。DNSアドレスを一つに絞るより、ドメインの種類に応じてリゾルバーを選ぶ方が効果的です。

servers、hosts、問い合わせ戦略の役割

dns.serversはリゾルバーの一覧です。通常のアドレスだけでなく、照合条件付きのオブジェクトも指定できます。オブジェクト内のdomainsは、どのドメインをそのサーバーへ優先的に送るかを指定し、expectIPsは返されたアドレスが想定どおりかを検証します。サーバーの順序はデフォルト選択とフォールバックに影響するため、ローカルDNSとリモートDNSを配列に無秩序に並べてはいけません。

フィールド	役割	よくある設定	エラーの症状
servers	リゾルバーとドメインの照合範囲を定義	日本国内DNSにgeosite:cnを指定	すべてのドメインが同じリゾルバーに入る
hosts	コア内部で解決結果を固定または書き換える	リモートDoHサービスのアドレスを固定	起動時にDoHホスト名の解決を繰り返す
queryStrategy	IPv4、IPv6、または両方の問い合わせを制御	UseIPv4またはUseIP	現在のネットワークで到達できないアドレス族を返す
expectIPs	結果が属するIPセットを検証	日本国内の結果をgeoip:cnと照合	異常な結果がそのまま接続段階へ進む

hostsはシステムのhostsファイルではなく、コア内部の静的マッピングです。リゾルバー自身の起動時依存を解決したり、LAN内のサービス名を固定したりする用途に適しています。たとえばdomain:router.exampleを192.168.1.1へマッピングすると、その名前は上流DNSへ送信されません。頻繁に変わるWebサイトのアドレスを大量に登録するのは避けてください。アドレス変更時に接続できなくなります。

• UseIPv4：IPv4だけを問い合わせまたは使用します。現在のネットワークで安定したIPv6ルートがない環境に適しています。
• UseIPv6：IPv6だけを使用します。ローカルネットワーク、ノード、宛先までの経路すべてで利用可能なIPv6が必要です。
• UseIP：コアが環境に応じてIPv4とIPv6を処理できます。デュアルスタック環境に適していますが、システムの優先順位に注意してください。

日本国内はローカル、海外はリモートで解決する設定の基本形

以下はXray 25.xの設定構造を前提にした例です。既存のアウトバウンドにdirectとproxyという2つのタグがあるものとします。日本国内ドメインは223.5.5.5へ、海外ドメインはリモートDoHへ送ります。リモートリゾルバーのアドレス自体はhostsで固定し、DoHホストを探すためにコアが起動時にローカルDNSへ問い合わせる循環依存を避けます。

{
  "dns": {
    "hosts": {
      "cloudflare-dns.com": [
        "1.1.1.1",
        "1.0.0.1"
      ],
      "domain:router.example": "192.168.1.1"
    },
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://cloudflare-dns.com/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "localhost"
    ],
    "queryStrategy": "UseIPv4",
    "disableFallbackIfMatch": true
  }
}

skipFallbackは、そのローカルサーバーを他のカテゴリの汎用フォールバックリゾルバーとして使わないことを示します。disableFallbackIfMatchは、ドメインが指定サーバーに一致した場合にグループをまたぐフォールバックを制限します。これにより、海外ドメインのリモート解決が失敗したとき、黙ってローカルDNSへ切り替わって一見不規則な汚染を起こすのではなく、エラーを明確に確認できます。

1. まず、現在のコアがgeosite:cn、geosite:geolocation-!cn、geoip:cnのデータを読み込めることを確認します。
2. サンプルのdnsブロックを既存設定に統合し、インバウンド、アウトバウンド、ポリシーグループを上書きしないでください。
3. directとproxyのタグが実際のアウトバウンドタグと完全に一致していることを確認します。タグは大文字と小文字を区別します。
4. まずUseIPv4で検証し、デュアルスタックネットワークが安定していることを確認してからUseIPを検討します。
5. コアの起動後にログを確認し、failed to load geositeやリゾルバー接続のタイムアウトがないことを確認します。

v2flyコアを使用している場合、一部のXray拡張フィールドを認識できないことがあります。v2flyNGでv2flyコアを使う場合は、そのコアが実際に対応しているDNSフィールドを基準にし、まずhosts、servers、基本的な問い合わせ戦略だけを残して、フォールバック制御を一つずつ追加してください。v2rayNGでXrayコアを使う場合は上記のXray構造を適用できますが、クライアントに内蔵されたコアのバージョンも確認してください。

domainStrategyとDNS規則の連携

routing.domainStrategyの代表的な値にはAsIs、IPIfNonMatch、IPOnDemandがあります。AsIsはドメイン形式を優先して保持し、IP規則のために自動解決しません。IPIfNonMatchはドメイン規則に一致しない場合だけ解決し、IP規則との照合を試みます。IPOnDemandは照合にIPが必要になった時点で、より早く解決を開始します。日本国内・海外の分割では、まず明確なgeosite規則を記述し、ドメイン規則で判定できない宛先をIPIfNonMatchで補完する構成が一般的です。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "1.1.1.1/32",
          "1.0.0.1/32"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": [
          "geosite:geolocation-!cn"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private",
          "geoip:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

規則は上から順に照合されます。この例では、まずリモートDoHの2つのアドレスをプロキシへ送り、その後に海外ドメイン、日本国内ドメイン、日本国内IPを処理します。geoip:privateの直接接続規則を先頭に置く方法も通常は問題ありませんが、その前に範囲の広すぎる0.0.0.0/0を置かないでください。後続の分割処理が実行されなくなります。

Freedomの直接接続アウトバウンドに個別の解決戦略を設定している場合は、dns.queryStrategyとの競合を避けてください。たとえばDNSがIPv4しか返さないのにFreedomがIPv6を強制すると、ドメイン規則は直接接続に一致しても、接続段階で利用可能なアドレスがなくなることがあります。調査時は設定内のすべてのdomainStrategyとqueryStrategyを検索し、トップレベルのDNSブロックだけを確認しないようにします。

DNS汚染とリークを防ぐ実践チェック項目

DNSリークとは通常、本来プロキシ経由で処理すべきドメイン問い合わせが、システム、ローカルルーター、またはアプリ内蔵のリゾルバーから直接送信されることを指します。コアにリモートDNSを設定するだけで、すべてのアプリの問い合わせを自動的に引き受けられるわけではありません。アプリがSOCKS、HTTPのシステムプロキシ、TUNのどれを経由するか、ブラウザーで独自のセキュアDNSが有効かどうかによって、最終経路は変わります。

• システムプロキシモード：通常はシステムプロキシに従うTCP通信だけをプロキシします。一部のアプリはシステムDNSへ直接アクセスし続けます。
• TUNモード：より多くのシステム通信を捕捉できますが、DNSの横取り、ルーティングの除外項目、LANアクセス規則も確認が必要です。
• アプリ内蔵のDoH：宛先ポートは443で、コアのDNSモジュールを迂回する可能性があります。アプリ独自の名前解決を無効にするか、その接続を明示的にプロキシしてください。
• リモートDNSの起動時解決：ドメイン形式のDoHアドレスを使う場合は、hostsまたは信頼できるブートストラップアドレスで循環依存を解消します。
• IPv6のバイパス：システムにIPv6がある一方、プロキシと規則がIPv4しか対象にしていない場合、問い合わせや接続が管理外の経路から送信される可能性があります。

v2rayN 7.xでは、「設定」→「パラメーター設定」でローカル待受ポート、システムプロキシ、ログレベルを確認し、メイン画面のコアログでルーティングタグを確認できます。カスタムJSONを使う場合は、「サーバー」→「カスタム設定サーバーを追加」からインポートし、現在動作している設定を1つ保管しておくと安全です。マイナーバージョンによってメニュー名は多少異なる場合がありますが、カスタム設定とパラメーター設定の入口が担う役割は変わりません。

問い合わせが正しい経路を通るか確認する4ステップ

1. システムとブラウザーのDNSキャッシュを消去してコアを再起動し、古い結果の影響を避けます。
2. 明確な日本国内ドメインへアクセスし、ログにローカルDNSへの問い合わせが表示され、directに一致することを確認します。
3. 明確な海外ドメインへアクセスし、リモートDoHへの接続がproxy経由で行われたことがログに表示されるか確認します。
4. 同じドメインを10回連続で問い合わせ、初回問い合わせとキャッシュヒットの所要時間を比較します。同時にlocalhostへフォールバックしていないことも確認してください。

テストでは、Webページを開けるかどうかだけを判断材料にしないでください。キャッシュ、予備アドレス、アプリ内部の再試行が誤った経路を隠すことがあります。より確実な基準は、日本国内ドメインがgeoip:cnに適合する結果を返すこと、海外ドメインのリモートDNS接続がプロキシアウトバウンドに一致すること、コアログで海外ドメインのフォールバックにローカルリゾルバーが関与していないことです。

よくある異常と段階的な修正方法

DNS分割の誤りは、「ノードは使えるのに一部サイトだけ開けない」「初回アクセスが非常に遅く、更新すると正常になる」「ノードを切り替えても古いアドレスへ接続する」といった形で現れます。こうした問題を最初からVMess、VLESS、トランスポート層プロトコルのせいにしてはいけません。プロキシのハンドシェイク前に、誤った宛先アドレスを取得している可能性があるためです。まず解決結果を確認し、その後にノードとトランスポート設定を調べる方が、短い手順で原因を絞れます。

サブスクリプションURLはクライアントへノード一覧を提供するだけで、通常はローカルのカスタムDNS戦略を自動的に置き換えません。v2rayN、v2rayNG、v2flyNGでサブスクリプションを更新した後は、現在有効な設定がカスタム規則を引き続き参照しているか再確認してください。ノード切り替えのたびにクライアントが設定を再生成する場合は、一時生成ファイルだけを編集せず、クライアントが対応するグローバルカスタムテンプレートへDNSとルーティングを記述するのが適しています。

最終的に使える設定は、ドメインの種類に応じてリゾルバーを選び、リモートDNS自体がプロキシ経由で接続され、解決結果と後続のルーティング規則が同じグループに属するという3条件を満たす必要があります。「問い合わせ元、解決結果、接続アウトバウンド」の3層でログを確認すれば、汚染、フォールバック、リークの多くを具体的なフィールドまで特定でき、ノードを何度も交換する必要はありません。