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

DNSサーバーの選択・DNSリクエストの出方向・Web通信の出方向を区別する

「DNSの振り分け」には、ドメインをどのDNSサーバーに問い合わせるかと、DNSリクエストをどの出方向へ送るかという、少なくとも2つの別々の判断があります。Webサイトへの接続にも、さらに別の判断が必要です。海外のDNSアドレスを設定しても、問い合わせがプロキシ経由になるとは限りません。Web通信をプロキシ経由に設定しても、ブラウザーが事前に行ったローカルでの名前解決が自動的にコア経由になるわけではありません。

V2Ray/Xrayのdnsオブジェクトで内蔵DNSを設定し、routingで接続の出方向を決めます。geosite:cnはドメインルールの集合、geoip:cnはIPアドレスルールの集合で、互いに置き換えることはできません。アプリからドメイン名がコアに渡されない場合、IPアドレスだけの接続はドメインルールに直接照合できません。通信のスニッフィングでドメイン情報を復元できることもありますが、あらゆるプロトコルに使える対策とは考えないでください。

国内DNSとリモートDoH：それぞれの役割を決める

ここでは、国内ドメインに223.5.5.5、その他の問い合わせにhttps://1.1.1.1/dns-queryを使います。どちらも変更可能なパブリックDNSの例であり、すべてのネットワークに最適な固定値ではありません。前者は通常UDP 53、後者はHTTPS 443を使用します。暗号化で保護されるのはクライアントからDNSサーバーまでの問い合わせ通信であり、DNSサーバーには処理対象のドメイン名が見えます。

UseIPv4は、初回の切り分けをIPv4に限定し、IPv6のルーティング問題が同時に発生するのを避けるための設定です。IPv6を恒久的に無効化する一般的な推奨設定ではありません。ネットワークとノードの両方がIPv6に対応している場合は、基本設定で問題がないことを確認してからUseIPに変更し、AレコードとAAAAレコードをそれぞれ確認してください。DNS問い合わせの種類に関する設定は、システム側のIPv6ルーティング設定の代わりにはなりません。

dns.serversの設定例：ドメイン照合とフォールバックの動作

以下はコア設定の一部であり、単独でインポートできる完全なノード設定ではありません。v2rayNGで使用するXrayコアを想定した例です。v2rayNでも、まず現在選択しているコアを確認してください。変更前に設定をバックアップします。クライアントが設定を生成する場合は、該当するDNS設定またはカスタム設定の画面で変更してください。次回起動時に上書きされる一時的な実行ファイルは編集しないでください。

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

• domainsは、指定したドメインで優先して使うDNSサーバーを設定します。「そのDNSサーバーが指定ドメインしか認識できない」というアクセス制御ルールではありません。
• skipFallback: trueは、そのサーバーを一般的なフォールバックの対象にしない設定です。「このサーバーに失敗した場合、ほかのサーバーを試さない」という意味ではありません。
• domainsによる制限がないDoHサーバーは、デフォルトの名前解決を担います。この設定では、国内DNSでの名前解決に失敗した場合もDoHサーバーへフォールバックする可能性があります。そのため、これはフォールバックを伴う振り分け設定であり、厳密に分離する設定ではありません。
• tagは、内蔵DNSが送信する問い合わせをルーティングで識別するためのものです。ローカルの53番ポートで待ち受けるDNSサーバーではありません。

一致したドメインの名前解決を指定サーバーだけに限定するには、XrayのdisableFallbackIfMatchを検討できます。有効にする前に、使用中のコアがこの項目に対応していることを確認してください。また、指定したDNSサーバーに障害があると名前解決に失敗する点にも注意が必要です。フォールバック、キャッシュ、IPv6の設定を一度に大きく変更すると、失敗の原因を絞り込みにくくなります。

routingの設定例：リモートDNSを確実にプロキシ経由にする

以下の例では、proxyというタグの使用可能なプロキシ出方向と、directというタグの直結出方向が、既存の設定に含まれていることを前提とします。各タグは実際のoutbounds[].tagと完全に一致させてください。この例には最後の全一致ルールがないため、どのルールにも一致しない接続には先頭の出方向が使われます。したがって、先頭の出方向がproxyであることも条件です。既存の設定で別のデフォルト動作を使っている場合は、元の構成に合わせて調整し、そのまま上書きしないでください。

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

最初の2つのルールは内蔵DNSの問い合わせだけを識別します。同じIPアドレスへユーザーが直接接続した場合まで、DNSリクエストとして扱うのを防ぐためです。後の2つのルールはWebサイトへの接続を処理します。IPIfNonMatchは、ドメイン名を使った接続が既存ルールに一致しない場合に、IPアドレスを解決してIPルールとの照合を試みる設定です。使用するDNSサーバーを決めるものではなく、DNSリクエストを自動的にプロキシへ送る設定でもありません。

DoHとFakeDNS：暗号化された問い合わせと仮想アドレスは別の仕組み

DoHはDNSメッセージをHTTPS接続で送信し、主に問い合わせの通信経路を保護します。一方、FakeDNSはアプリに仮想IPアドレスを返し、ドメイン名と仮想アドレスの対応を保持することで、その後の接続をドメイン名に基づいて処理できるようにします。FakeDNSは仮想アドレス上に実際のWebサイトを構築するものではなく、「リモートで実際の名前解決が完了した」という意味でもありません。

たとえばFakeDNSのIPv4アドレスプールに198.18.0.0/15を使う場合、システムはこのアドレスプール宛ての接続をコアに戻し、コアが対応するドメイン名を復元できる必要があります。接続がVPNやTUNの経路を通らない場合、仮想IPアドレスには実際のインターネット上のアドレスのようにアクセスできません。有効化後に一部のアプリだけが失敗する場合は、すぐにノードを変更せず、アプリごとのプロキシ設定、通信の捕捉範囲、対応関係の処理を確認してください。

• 通常のDNS振り分けがまだ確認できていない場合は、FakeDNSを有効にせず、実際のアドレスを切り分けの基準にします。
• アプリが接続先のIPアドレスしか渡さず、ドメインルールが機能しにくい場合は、現在のインバウンドやスニッフィング設定と組み合わせてFakeDNSを検討します。
• FakeDNSを無効にしても仮想アドレスが使われる場合は、該当アプリとシステムのキャッシュを消去して接続を作り直し、古い対応関係が使われないようにします。

v2rayNとv2rayNGで項目ごとに確認する

クライアントの画面設定とコア設定は別のレイヤーです。同じ「リモートDNS」の入力欄でも、クライアントのバージョンによって生成される設定構造が異なる場合があります。実際に読み込まれたコア設定を基準にしてください。v2rayNでは「設定」→「パラメータ設定」からログ関連の項目を確認し、メイン画面のログ欄で起動結果を確認できます。DNS設定画面の名称はバージョンによって変わるため、通常の1行入力欄を完全なJSONエディターと混同しないでください。

1. 現在の設定を記録します。ノード、現在のルーティングモード、DNSアドレス、システムプロキシまたはVPNの状態を保存します。v2rayNGでは「設定」からDNS関連の項目を確認し、変更後にサービスを停止して再起動します。ログに設定の解析エラーがないことも確認してください。
2. 起動時のエラーを確認します。未対応の項目、出方向タグの不一致、geositeデータの読み込み失敗などを先に解決してください。コアが正常に起動していない状態では、Webページのテスト結果を正しく判断できません。
3. アプリからドメイン名が渡されているか確認します。デスクトップでは、リモート名前解決に対応したSOCKSリクエストを使ってテストできます。以下のコマンドは、ローカルのSOCKSポートが10808であることを前提としています。実際の設定が異なる場合は、使用中のポートに変更してください。
4. ルーティングの一致を確認します。一時的にログの詳細度を上げ、国内外のドメインにそれぞれアクセスして、DNSリクエストとWeb接続の出方向を確認します。検証後は通常のログレベルに戻し、不要なアクセス情報を長時間記録しないようにしてください。
5. キャッシュの影響を切り分けます。コアを再起動し、既存の接続を閉じてから再試行します。Windowsではipconfig /flushdnsを実行してシステムキャッシュを消去できます。ただし、ブラウザーやアプリ独自のキャッシュは別途消去が必要な場合があります。

curl --proxy socks5h://127.0.0.1:10808 --head --max-time 15 https://www.example.com/

socks5hでは、curlがドメイン名をSOCKSプロキシに渡します。socks5に変更すると、通常はローカルで名前解決されるため、2つのテスト経路は異なります。このコマンドで確認できるのはドメイン名がプロキシ経由になることだけで、すべてのDNSが想定どおり振り分けられている証明にはなりません。よくある誤解として、nslookup www.example.com 223.5.5.5だけを実行する方法があります。このコマンドは指定したDNSサーバーに直接問い合わせるため、サーバーへの到達性は確認できますが、内蔵DNSのルールが有効になっているかは確認できません。

よくあるトラブル：名前解決のタイムアウト、IPアドレスの異常、設定が反映されない

最終的には、設定の意図を説明できる状態にしておきましょう。どのドメインに国内DNSを使うか、デフォルトの問い合わせ先、DNS接続の出方向、どのルールにも一致しないWebサイトの扱いを明確にします。一度に変更する項目を1つに絞り、起動ログと接続結果で確認すると、パブリックDNSをいくつも追加するより原因を特定しやすくなります。