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

1. DNSリクエストがコアに届いているか確認する

まず、DNS名前解決とルーティングを分けて考えます。DNS名前解決はドメイン名をIPアドレスに変換する処理で、ルーティングは接続を直接接続にするかプロキシ経由にするかを決めます。dnsセクションを変更しただけでは、すべてのアプリのDNSリクエストが自動的にV2Rayへ届くわけではありません。プロキシルールを追加しただけでも、アプリが先に取得したIPアドレスが正しいとは限りません。

上記は、アプリがドメイン名をコアに渡す一般的な流れです。アプリ側ですでに名前解決し、IPアドレスだけを送る場合、コアが受け取る情報は異なります。ブラウザーのセキュアDNS、システムDNS、クライアント内蔵DNSが同時に使われることもあるため、DNSの入力欄ひとつだけでは実際の名前解決経路を判断できません。

• システムプロキシの場合：通常、プロキシ設定に従うアプリだけが対象です。HTTPプロキシのリクエストには接続先のドメイン名を含められますが、ほかのプログラムはシステムのDNSサーバーを直接使う可能性があります。
• SOCKSの場合：アプリからドメイン名をSOCKSプロキシに渡す必要があります。アプリ側で先に名前解決してIPアドレスを送ると、内蔵DNSのドメイン振り分けが適用されないことがあります。
• Android VPNの場合：v2rayNGはAndroidのVPNインターフェースを使って通信を処理しますが、DNSの動作はアプリの設定、アプリごとのルール、ブラウザーの挙動にも左右されます。
• カスタム設定の場合：内蔵DNSはコア内部の名前解決に使用できます。外部プログラムからDNSパケットを受け取るには、対応するインバウンドとDNSアウトバウンドも設計する必要があります。dns.serversだけでは設定できません。

2. servers、domains、expectIPsの役割

まずドメインを分類し、各グループに使用するDNSサーバーを指定します。serversはDNSサーバーのリストです。単純なアドレスのほか、条件を指定したオブジェクトも設定できます。国内・海外のドメインでDNSサーバーを使い分ける場合は、オブジェクト形式のほうが動作を確認しやすくなります。

geositeはドメインの分類データ、geoipはIPアドレスの分類データで、相互に置き換えることはできません。domainsにはdomain:example.comのように、ドメインとサブドメインを照合する記法も使えます。特定のサイトを調べる場合は、分類データ一式を入れ替えるより、対象ドメインのルールを1つ追加するほうが原因を特定しやすくなります。

3. 国内ドメインを優先し、ほかのドメインは暗号化して名前解決する

以下は動作を確認しやすい基本設定例です。国内向けの分類に一致するドメインは223.5.5.5へ優先的に問い合わせ、それ以外はhttps://1.1.1.1/dns-queryを使います。後者はDoHで、HTTPS経由でDNS問い合わせを送信します。例ではIPv4を使い、デュアルスタック環境での切り分け要因を減らしています。IPv6に問題があるという意味ではありません。

{
  "dns": {
    "tag": "dns-query",
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "skipFallback": false
      }
    ]
  }
}

ここでskipFallback: trueを指定するのは、国内向けDNSサーバーが一致しないドメインの通常のフォールバック問い合わせに使われないようにするためです。「国内向けDNSで名前解決に失敗したら、絶対に再試行しない」という意味ではありません。国内向けDNSからexpectIPsに合致する結果が返らない場合、フォールバックが無効化されていなければ、ほかの適用可能なサーバーも試されます。フォールバックと完全な隔離を混同しないでください。

• 設定を有効にする前に、コアがgeosite.datとgeoip.datを読み込めることを確認してください。分類データの読み込みエラーが発生した場合は、回線品質を調べる前にデータファイルのパスやクライアントのリソースを修正します。
• 通常のhttps://形式のDoHを使うと、後述するルールに従って問い合わせをコア経由でルーティングできます。コアによってはローカルから直接接続する形式もありますが、これに置き換えると接続経路が変わるため、出口が同じだとは限りません。
• リモートDNSサーバーにはIPアドレス形式のHTTPS URLを指定すると、DNSサーバー自身のドメイン名を事前に名前解決する必要性を減らせます。ただし、TLS証明書の検証は通常どおり行ってください。接続エラーを隠すために検証を無効にしないでください。
• これは内蔵DNSのサーバー選択設定であり、OSのDNS設定ではありません。すべてのアプリがローカルネットワークのDNSサーバーを使わなくなるわけではありません。

4. ルーティングルールでDNSの接続先を指定する

まず、既存のアウトバウンドタグを確認します。以下の設定例では、directというタグの直接接続用アウトバウンドと、proxyというタグの利用可能なプロキシアウトバウンドがすでにあるものとします。これらは例で使う名前であり、DNS設定によって自動作成されるものではありません。既存のタグ名が異なる場合は、実際の名前に置き換えてください。VMessやVLESSのノード設定は変更しません。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["dns-query"],
        "ip": ["223.5.5.5"],
        "port": "53",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["dns-query"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private", "geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

ルールは記載順に照合されます。1つ目のルールは、dns-queryタグが付いた223.5.5.5:53宛てのリクエストだけを直接接続にします。2つ目は、同じタグが付いたほかの問い合わせをプロキシに送ります。DNSを広く対象にするプロキシルールを先に置くと、国内向けDNSの問い合わせも先に一致し、「国内向けDNSを設定したのに遠回りする」ことがあります。

1. DNS専用ルールは広範囲のルールより前に置きます。既存設定に全ポート直接接続、グローバルプロキシ、インバウンド別の振り分けルールがある場合は、どのルールが先に一致するか確認してください。
2. IPIfNonMatchの動作を理解します。ドメイン名が該当ルールに一致しない場合、コアは内蔵DNSでIPアドレスを取得してから、IPルールを照合できます。すべてのドメインを先に名前解決する設定ではありません。
3. 既存のデフォルト接続先を維持します。この設定例には、最後に適用される全通信向けのフォールバックルールはありません。どのルールにも一致しない通信は、設定全体のデフォルトアウトバウンドに従います。統合時はアウトバウンドの順序も確認してください。
4. プロキシサーバーの事前名前解決を確認します。プロキシサーバーのアドレスがドメイン名の場合、その唯一の名前解決経路が、まだ確立されていないプロキシ接続に依存しないようにしてください。プロキシサーバーのドメイン名には、到達可能な別の事前名前解決経路を設定できます。

5. ログと比較テストでDNS振り分けを検証する

まず「どのDNSサーバーが名前解決し、どの経路を通るか」を検証してから、Webページにアクセスできるかを確認します。nslookupだけを実行した場合、通常はシステムで指定されたDNSサーバーがテストされるため、V2Rayの内蔵DNSがルールどおりに動作している証明にはなりません。DNSリークテストに表示されるのも、多くの場合は再帰DNSサーバーの接続元であり、端末のプロキシ出口ではありません。

1. 一時的にログレベルを上げます。既存のlogオブジェクトでloglevelをdebugに変更し、コアを再起動します。確認が終わったらwarningに戻してください。ドメイン名や接続の詳細が大量に記録される状態を長期間続けないようにします。
2. テスト経路を再起動します。コアを再起動すると、今回の確認に影響するコアのキャッシュをクリアできます。テスト対象のアプリも終了して再起動し、必要に応じてアプリ内のDNSキャッシュを消去してください。Webページを再読み込みするだけでは、新しい問い合わせが発生しないことがあります。
3. 国内向けルールに一致するドメインを1つテストします。ログに該当するDNS問い合わせが記録されていることを確認し、223.5.5.5:53宛てのリクエストがdirectを通るか調べます。キャッシュ済みのリクエストや、ドメインルールに直接一致した通信では、新しい名前解決ログが記録されないことがあります。
4. 国内向けグループに含めていないドメインを1つテストします。DoHサーバーが使われ、その接続がproxyを通るか確認します。ログの表示内容はコアによって異なるため、DNSサーバーのアドレス、対象ドメイン、アウトバウンドタグを照らし合わせて判断してください。
5. アプリ経由とローカル名前解決の経路を個別にテストします。デスクトップでは以下の2つのコマンドを比較できます。実行前に、ポートをクライアントに表示されている実際のSOCKS待ち受けポートに変更してください。

curl --socks5-hostname 127.0.0.1:10808 -I https://example.com
curl --socks5 127.0.0.1:10808 -I https://example.com

1つ目はSOCKSプロキシに接続先ドメインの処理を任せ、2つ目はcurlがローカルで名前解決してからIPアドレスを送信します。10808はコマンド例のポートで、実際の待ち受けポートと同じとは限りません。どちらも成功しても、コアが名前解決したとは限りません。プロキシアウトバウンドがドメイン名をリモートサーバーに渡す場合もあるため、最終的にはログも確認してください。

6. DNS振り分けのよくある問題と復旧方法

最後に、起動・名前解決・接続のすべてを確認できた設定のコピーを保存してください。変更は一度に1つに絞り、まずDNSサーバー、次にドメインのグループ分け、最後にフォールバックとIPアドレスの絞り込みを調整します。ほかの設定項目を確認する場合は、サイト内の設定項目ガイドを開き、実際のコアのバージョンに合わせて1つずつ確認してください。