V2RayのDNS設定ガイド：国内外ドメインのDNS振り分けとDNS汚染対策

1. DNSの振り分けとプロキシの振り分けは別の設定

DNSの振り分けは「ドメインをIPアドレスに変換するサーバー」を決め、ルーティングの振り分けは「どの出口から接続するか」を決めます。海外ドメインの名前解決先をリモートDNSにしても、そのDNSサーバーへの通信がプロキシ経由になるとは限りません。反対に、Webサイトへの通信がプロキシ経由でも、ブラウザーが事前にシステムDNSで名前解決している可能性があります。両方の経路を確認してください。

この流れは、アプリがドメインをコアに渡し、ルーティングポリシー上、名前解決が必要になる場合を示しています。ドメインルールでプロキシ経由のアウトバウンドがすでに決まっていれば、ルーティング段階でDNS問い合わせが発生しないことがあります。また、宛先ドメインの名前解決をプロキシサーバー側に任せる場合もあります。アプリがIPアドレスだけを渡した場合、コアが元のドメインを確実に特定することは通常できません。

• DNS汚染：誤った、または改変された名前解決結果が返されること。IPアドレスが変わっただけでは汚染の証拠になりません。CDNは地域に応じて異なるアドレスを返すことがあります。
• DNSリーク：想定外の経路でDNS問い合わせが行われること。日本国内のドメインを予定どおり国内DNSで直接解決することを、単純にリークと判断すべきではありません。
• 名前解決の遠回り：日本国内のサービスに対し、遠方のCDNアドレスがリモートDNSから返されること。接続不能ではなく、画像の読み込みが遅い、動画がバッファリングするといった症状が出る場合があります。

2. 3つの設定箇所にあるdomainStrategyを区別する

V2RayのDNS設定を調べると、同じ名前のフィールドがよく見つかります。設定場所によって役割は異なります。ルーティングのdomainStrategy、directアウトバウンドの同名フィールド、DNSのqueryStrategyを混同しないでください。

最初の調整ではIPIfNonMatchから始めるとよいでしょう。まず明示的なドメインルールで出口を決め、一致しない場合にIP地理ルールで補います。「すべてのドメインを先に名前解決する」設定ではなく、システム上のすべてのアプリのDNSを制御するものでもありません。

3. ドメインごとに国内DNSとリモートDoHを使い分ける

dns.serversのサーバーオブジェクトでは、domainsを使って優先的に処理するドメイン群を指定できます。ここでのドメイン照合はDNSサーバーの選択だけを行い、Webサイトへの通信に使うルーティングルールは作成しません。この記事では、日本国内向けのUDP DNSとリモートDoHの2経路について、選択条件と通信方式を説明します。

geosite:cnとgeosite:geolocation-!cnはルールデータ内の分類ラベルであり、完全に相補的な集合ではありません。新しいドメインなどがどちらにも含まれない場合があるため、上記のリモートDNSは未分類ドメインのフォールバック先も兼ねます。重複やデータ不足がある場合は、現在のデータファイルとログを確認してください。ドメインの末尾だけでルールの一致を判断することはできません。

• skipFallback: trueは「このサーバーに一切問い合わせない」という意味ではありません。明示的に一致したドメインには引き続き使われます。主にフォールバック候補の選択に影響します。
• https://とhttps+local://ではリクエスト経路が異なります。後者はローカルモードで動作するため、この記事のコアルーティングに関する前提をそのまま当てはめることはできません。
• DoHのアドレスにドメイン名を使う場合は、DNSサーバー自身のドメインを最初に名前解決する必要があります。この記事では、その依存を減らすためIPアドレスを直接指定します。
• DoHはDNSサーバーまでの問い合わせ通信を暗号化しますが、DNSサーバーが常に適切な結果を返すとは限らず、ルーティングの確認に代わるものでもありません。

4. DNSとルーティングを統合し、DNSサーバーへの出口を固定する

以下はコアJSON設定に統合する例です。既存設定にproxyという名前のプロキシアウトバウンドと、directという名前の直接接続アウトバウンドがあることを前提としています。実際のタグ名が異なる場合は、該当箇所をすべて置き換えてください。既存のinbounds、ノード認証、トランスポート、TLS設定も保持します。この断片を完全な設定としてそのまま起動しないでください。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      }
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["1.1.1.1"],
        "port": "443",
        "network": "tcp",
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["223.5.5.5"],
        "port": "53",
        "network": "udp",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:geolocation-!cn"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

ルーティングルールは上から順に照合され、最初に一致したルールが適用されます。DNSサーバー専用のルールを通常の地理ルールより前に置くと、DNS通信の経路を予測しやすくなります。これらのルールは宛先IPとポートで照合するため、同じIPアドレス・ポートに向かう他の接続にも適用されます。

1. デフォルトのアウトバウンドを確認：どのルールにも一致しない通信には、通常outboundsの先頭にあるアウトバウンドが使われます。未分類の通信を既定でプロキシ経由にしたい場合は、ルールだけでなく、先頭のアウトバウンドが想定するプロキシかどうかも確認してください。
2. ルールデータを確認：起動時にgeosite分類やデータファイルが見つからないというエラーが出た場合は、ルールデータの取得元とパスを修正してください。エラーになったルールを削除して起動を続けても、設定が正しいことの証明にはなりません。
3. directの名前解決を確認：directアウトバウンドでも組み込みDNSを使う場合は、既存のfreedomアウトバウンドのsettingsに"domainStrategy": "UseIP"を設定し、現在のコアが対応していることを確認してください。
4. ノードの名前解決を確認：プロキシサーバーのアドレスがドメイン名の場合、まだ確立していないプロキシ接続だけに依存した名前解決経路にしてはいけません。起動ループを避けるため、そのドメインに利用可能な初期名前解決経路を用意してください。

5. クライアントに設定を反映し、JSON設定の上書きを防ぐ

v2rayNは、画面で設定したノード、DNS、ルーティングの情報から実行時設定を生成します。一時生成されたファイルを直接編集すると、ノードの切り替えや再起動後に変更が上書きされることがあります。まず、使用中のバージョンで利用できるDNS設定、ルーティング設定、またはカスタム設定の入口を使ってください。メニュー名はバージョンによって異なるため、特定バージョンの操作手順をすべてのバージョンに共通するものとみなさないでください。

1. 復元用の設定を保存：現在のノード、システムプロキシモード、ルーティングモードを記録し、設定をエクスポートするか関連項目をバックアップします。変更はDNSと必要なルーティングに絞り、プロトコルやトランスポートの設定を同時に変えないでください。
2. 有効な設定を確認：設定を保存してコアを再起動した後、クライアントの実行設定または設定プレビューを開き、dns.servers、ルールの順序、アウトバウンドのタグが反映されていることを確認してください。
3. アプリの接続経路を確認：デスクトップアプリはシステムプロキシに従うか、ローカルのHTTP/SOCKS入口に明示的に接続する必要があります。SOCKSをテストする場合は、クライアントに表示される実際のポートを使ってください。説明中のポートが自分の環境の既定値とは限りません。
4. Androidでの通信制御範囲を確認：v2rayNGとv2flyNGでは、VPNモード、アプリごとの設定、DNSオプションも確認してください。対象外にしたアプリは、従来のネットワーク経路を使い続けることがあります。
5. 他のDNS設定を切り分け：テスト中は、ブラウザーの「セキュアDNS」とAndroidの「プライベートDNS」の現在の状態を記録してください。必要に応じて一時的に無効にして比較し、テスト後は想定する設定に戻します。

ブラウザー内蔵の暗号化DNSは、コアのドメイン分類を迂回する場合があります。一方で、そのDNS接続自体はプロキシ経由になることもあります。「どのDNSサーバーが使われたか」と「接続がどの出口を通ったか」は別々に確認してください。DoHが使われているだけで、DNSの振り分け全体が正しく機能しているとは限りません。

6. ポート、ログ、比較テストで振り分けを検証する

以下の数値はプロトコルのポート番号とテスト回数であり、性能測定の結果ではありません。検証では、国内ルールに確実に一致するドメインと、リモートルールに確実に一致するドメインをそれぞれ1つ以上選んでください。使用中のデータセットで分類を確認し、未収録のドメインを使ってルールの不具合と判断しないようにします。

Windowsではipconfig /flushdnsを実行してシステムDNSキャッシュを消去できますが、ブラウザーやコアにも個別のキャッシュが残っている場合があります。nslookupを直接実行した場合、通常はシステムまたは指定したDNSサーバーへの問い合わせをテストします。システムプロキシを有効にしても、自動的にコアのDNSをテストするわけではありません。ローカルDNSリスナーが明示的に設定され、問い合わせが実際にそのリスナーへ届いている場合に限り、該当する経路の検証に使えます。

7. DNS振り分けでよくある問題と修正手順

最終的な設定では、次の3点を説明できる必要があります。どのドメインを国内DNSで処理するか、どの問い合わせをプロキシ経由でリモートDNSに送るか、分類に一致しない場合にどのようにフォールバックするかです。DNS経路をさらに厳密に制御するには、システムDNS、ブラウザー独自の名前解決、ネットワークの通信制御範囲も個別に設計してください。dns.serversの設定断片だけで端末全体を制御することはできません。