V2RayのDNS設定｜国内外のDNS振り分けとDNS汚染対策

1. 内蔵DNSが接続処理に関わる場所

「DNSを設定したのに、ブラウザーがシステムのDNSサーバーに問い合わせるのはなぜ？」サーバーアドレスの入力ミスではなく、DNSリクエストがコアの内蔵DNSに届いていない可能性があります。V2RayやXrayの内蔵DNSは、コアが利用する名前解決モジュールです。dnsフィールドを追加しただけで、端末上のすべてのUDP 53リクエストを自動的に処理するわけではありません。

アプリがドメイン名をSOCKSプロキシに渡すと、コアはそのドメイン名をそのままリモートサーバーに渡し、リモート側で名前解決することがあります。一方、アプリが先にシステムDNSでIPアドレスを取得し、そのIPアドレスをプロキシに渡した場合、コアが受け取るのは元のドメイン名ではありません。どちらも「クライアントの内蔵DNSが有効になった」とは限りません。

• ルーティングでIPアドレスが必要な場合：routing.domainStrategyをIPIfNonMatchに設定すると、ドメインルールに一致しなかった場合に内蔵DNSで名前解決し、IPルールを照合できます。
• ダイレクト接続でIPアドレスが必要な場合：XrayのfreedomアウトバウンドでUseIPv4などの名前解決ポリシーを使うと、内蔵DNSから接続先アドレスを取得します。
• 端末から通常のDNSパケットを送信する場合：受信・転送・捕捉の経路を別途設定する必要があります。DNSサーバーを指定するだけでは実現できません。
• ブラウザーでセキュアDNSを有効にしている場合：ブラウザーが独自にHTTPSでDNSを問い合わせることがあります。リクエストがプロキシを経由しても、ここで設定した内蔵DNSサーバーが使われるとは限りません。

2. DNSサーバー、ポート、コアの処理範囲を確認

この記事では、中国国内のドメインを223.5.5.5に、それ以外のドメインをhttps://1.1.1.1/dns-queryに問い合わせ、後者のリクエストを既存のプロキシアウトバウンド経由で送信します。IPアドレス形式のDoH URLを使うと、DNSサーバーへの接続に先立ってそのホスト名を名前解決する依存関係を減らせます。TLS証明書の検証は必ず維持してください。

v2rayNはデスクトップクライアントであり、使用するコアが固定されているわけではありません。v2rayNGはXray、v2flyNGはV2Flyを使用します。同名のフィールドでも、サポート範囲や既定の動作は実際のコアによって異なるため、確認が必要です。特にDNSのフォールバック用フィールド、特殊なアドレスプレフィックス、アウトバウンドの名前解決ポリシーは、Xray用の設定をすべてのコアにそのまま適用しないでください。

1. 現在接続できている設定をバックアップし、クライアントのバージョンと起動ログに表示されるコアのバージョンを記録します。
2. 実行中の設定にプロキシアウトバウンドがあることを確認し、実際のtagを控えます。以下ではproxyを使用します。プロトコル名を変更するという意味ではありません。
3. geosite.datを読み込めることと、cnカテゴリが含まれていることを確認します。データファイルがない場合はルールの読み込みに失敗します。DNSサーバーのタイムアウトとは別の問題です。
4. 作業中は一度に一つの層だけを変更します。まずDNS、次にルーティングを設定し、最後にシステムやブラウザーが独自に名前解決していないか確認します。

3. ドメインごとにDNSサーバーを割り当て、失敗時のフォールバックを制御

以下はトップレベルのdnsフィールドの設定例です。中国国内向けのDNSサーバーには対象ドメインのリストを指定し、そのドメインだけを処理させます。DoHサーバーにはドメインリストを指定せず、その他のドメインの通常の問い合わせ先にします。ここでは最初の切り分けでIPv6の到達性を変数にしないためIPv4を使います。IPv6を恒久的に無効化する必要があるという意味ではありません。

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

• domainsはDNSサーバーの選択条件であり、トラフィック全体のルーティングルールではありません。ドメインを特定のDNSに問い合わせても、Web接続が自動的に同じアウトバウンドを使うわけではありません。
• skipFallback: trueを指定すると、このDNSサーバーはどのサーバーの対象にも一致しない問い合わせのフォールバック先になりません。中国国内向けDNSが、対象外のドメインの問い合わせまで受け取るのを防ぎます。
• disableFallback: trueは、対象ドメインに一致したDNSサーバーが失敗した後のフォールバックを無効にします。専用ドメインリストに一致しない問い合わせは、引き続き既定のDNSサーバーで処理されます。「すべての問い合わせで既定サーバーを使わない」という意味ではありません。
• queryStrategy: "UseIPv4"は、この名前解決で使うアドレスファミリーを制限します。システムレベルのIPv6ルーティング管理の代わりにはなりません。

この設定例では、フォールバック先にlocalhostやシステムDNSをあえて追加していません。そうすると、プロキシ経由のDoHに接続できないとき、回避したかったDNS経路に問い合わせが戻る可能性があります。起動ログに未対応フィールドが表示された場合は、コアのバージョンとドキュメントを確認してください。フォールバック制限を削除しただけで問題が解決したと判断しないでください。

4. DoHをプロキシ経由にし、ダイレクト接続で内蔵DNSを確実に使う

DoHのURLを指定しただけでは、問い合わせがノード経由になるとは限りません。通常のhttps://形式のDoHリクエストはコアのルーティング対象にできます。以下では接続先のIPアドレスとポートを指定し、proxyに送信します。安易にhttps+local://へ変更しないでください。ローカルで名前解決する意味が異なるため、ここでのルーティング判定をそのまま適用できません。

以下のルールを既存のルーティング設定に統合してください。DNSサーバー向けのルールは、広範なダイレクト接続ルール、IP分類ルール、最終フォールバックより前に置きます。proxyは実際のプロキシアウトバウンドのタグに、directは既存のダイレクト接続アウトバウンドに合わせてください。この例では接続先IPによる中国国内向けの振り分けを行わないため、不要なドメインの追加名前解決を避ける目的でAsIsを選んでいます。

{
  "routing": {
    "domainStrategy": "AsIs",
    "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",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

このルールは最小限の構成例です。既存のLAN向けバイパスやノードアドレスへのダイレクト接続など、必要なルールを上書きしないでください。特にノードの接続先がドメイン名の場合、ノード接続に必要な名前解決を「接続済みのプロキシ」に依存させると、起動時にループするおそれがあります。クライアント既定のノード名前解決方式を維持し、使用するDNSサーバーを個別に確認してください。

ダイレクト接続アウトバウンドも確認します。以下は既存のfreedomアウトバウンドを統合または置き換えるための設定例です。同名のアウトバウンドを別途作成するものではありません。設定すると、中国国内のドメインをダイレクト接続する際に、内蔵DNSでIPv4アドレスを取得します。

{
  "tag": "direct",
  "protocol": "freedom",
  "settings": {
    "domainStrategy": "UseIPv4"
  }
}

5. v2rayNとv2rayNGに設定を反映する

GUIのDNS設定画面で、Xray JSON全体を受け付けるとは限りません。DNSサーバーアドレスだけを入力する画面もあれば、基本設定と詳細設定が分かれている画面もあります。貼り付ける前に、入力欄がアドレス・DNSオブジェクト・設定全体のどれを求めているか確認してください。クライアントが一時生成した実行用ファイルを直接編集すると、ノードの切り替えや再起動で上書きされることがあります。

1. デスクトップ版は設定箇所を確認：v2rayNで「設定」→「DNS設定」を開き、現在のコアに対応するDNS項目を確認します。次に「設定」→「ルーティング設定」でルールの順序を確認してください。バージョンによって設定タブが異なる場合は、画面に表示されている項目の説明に従います。
2. 複雑なルールはカスタム設定を使用：dns、routing、outboundsをまとめて制御する場合は、v2rayNの「サーバー」→「カスタム構成サーバーを追加」から、既存の設定に統合した完全な構成を読み込みます。既存ノードの認証・通信方式・TLSパラメーターはそのまま維持してください。
3. Android版は実行方式を確認：v2rayNGの「設定」でVPNモードとDNS関連の項目を確認します。カスタム設定全体を読み込んだ場合は、リストに保存されているだけでなく、その設定が実際に実行されていることを確認してください。
4. 異なる設定形式を混在させない：v2rayNGで読み込むカスタム設定はXrayの構造に準拠する必要があります。v2flyNGではV2Flyがサポートするフィールドを使用してください。サブスクリプションURL、個別ノードの共有リンク、完全なJSONはそれぞれ異なる入力形式です。
5. 保存したら接続を再起動：起動ログでJSONの解析エラー、未定義のタグ、データファイルの読み込みエラーがないか確認します。起動に失敗した場合は、複数の設定を続けて切り替えて原因を隠さず、まずバックアップに戻してください。

6. DNS振り分けとDNS汚染対策の効果を確認

検証では、どのDNSサーバーが問い合わせを受けたか、どのアウトバウンドを経由したか、アプリが最終的にどのアドレスへ接続したかの3点を確認します。nslookupで使用可能なIPアドレスが表示されても、コアの内蔵DNSが使われた証明にはなりません。通常はシステムDNSをテストするため、比較対象として利用できます。

テスト前に関連するキャッシュを消去します。Windowsでは以下のコマンドでシステムDNSキャッシュを消去し、続けてコアを再起動してプロセス内のキャッシュを消去できます。ブラウザーにも独自のキャッシュがある場合があります。同じキャッシュ済みドメインを何度も再読み込みし、新しい問い合わせがないことだけを理由に設定が無効だと判断しないでください。

ipconfig /flushdns
nslookup www.example.com

詳しく調べる場合は、トップレベルのlog.loglevelを短時間だけdebugに設定し、接続ログと合わせて確認します。DNS関連のログ内容はコアのバージョンによって異なるため、特定の文言だけを検索しないでください。テスト後はwarningまたは元のログレベルに戻します。アクセスしたドメイン名、サーバーアドレス、認証情報を含むログ全体を公開しないでください。

• DoHがタイムアウトする：まずプロキシノードが使えること、proxyタグとルールの順序が正しいことを確認し、その後DNSサービスのアドレスに到達できるか調べてください。
• 証明書エラーが発生する：端末の時刻とTLSの検証環境を確認してください。証明書検証を無効にしてDNSの問題を解決しようとしないでください。
• 中国国内のサイトは名前解決できるのに表示が遅い：適切でないCDNアドレスが返されていないか、Web通信もダイレクト接続のルールに一致しているか確認してください。
• テストページに海外のDNSリゾルバーが表示される：想定する経路に照らして判断してください。プロキシ経由のDoHでは海外の再帰DNSサーバーが表示されることがあります。サーバーの所在地だけではDNS漏えいとは判断できません。

7. よくある質問