V2Ray FakeDNSの仕組みを解説｜仮想IPマッピングと利用シーン

FakeDNSと通常のDNS名前解決の違い

通常のDNSでは、AレコードとAAAAレコードの問い合わせによってIPv4アドレスとIPv6アドレスを取得します。アプリは通常、返されたアドレスに直接接続します。透過プロキシの入口では、元の接続に「宛先IPアドレス＋ポート番号」しか残らないことがありますが、ドメインルールにはアプリが最初に問い合わせた名前が必要です。FakeDNSはこの前半部分を変え、実サーバーのアドレスをすぐに返す代わりに、制御された経路内だけで意味を持つ仮想IPを割り当てます。

たとえば、アプリが www.example.com を問い合わせると、FakeDNSは 198.18.0.2 を割り当て、両者の対応関係を保存します。その後、アプリが 198.18.0.2:443 に接続すると、接続を取り込んだコアがマッピングを参照し、宛先を www.example.com:443 に復元できます。このアドレスは仕組みを説明するための例であり、直接アクセスできるテスト用ノードでも、特定のクライアントが最初に割り当てる固定アドレスでもありません。

仮想IPマッピングの全体像

重要なのは「DNSが何を返したか」だけではなく、返された結果と後続の接続を再び結び付けられるかどうかです。DNS応答を返すマッピングテーブルと、宛先接続を処理するコアは、対応する状態を共有するか、この仕組みに対応した統合コンポーネントで連携する必要があります。あるインスタンスが仮想アドレスを割り当てても、マッピングを持たない別のインスタンスに接続が渡れば、後者には直接アクセスできない特殊用途アドレスしか見えません。

1. 問い合わせを制御対象のDNSに送る：アプリのAまたはAAAA問い合わせが、設定済みの名前解決経路に入る必要があります。従来のDNSで使われるUDP 53番ポートだけを取り込んでも、アプリ内蔵の暗号化DNSまで制御できるとは限りません。
2. マッピングテーブルに登録する：FakeDNSがドメイン名に仮想アドレスを割り当てます。アドレスプールには容量の上限があり、実装によっては容量が逼迫すると古いマッピングを再利用します。割り当て順を安定した仕様として扱わないでください。
3. 仮想アドレス宛ての接続を取り込む：TUNや透過プロキシのルールで、復元に対応した入口へ接続を渡します。FakeDNS自体がTUNインターフェースを作成したり、システム全体のルートを自動設定したりするわけではありません。
4. マッピングを参照して宛先を復元する：コアが仮想IPからドメイン名を取得し、ドメインルールや後続の外向き接続に利用します。接続先そのものを書き換えるかどうかは、入口のスニッフィングなどの設定にも左右されます。
5. 実際のアクセスを完了する：プロキシ経由の場合、ドメイン名を宛先として扱えるプロトコルなら、その名前をリモート側に渡せます。直接接続の場合は通常、接続可能なアドレスを取得するために実DNSでの名前解決が必要です。

つまりFakeDNSは「DNSが不要になる」仕組みではありません。実際の名前解決を後回しにし、ドメイン名との関連付けを保持します。また、VMessやVLESSなどのプロキシプロトコルを置き換えるものでも、ノードの認証情報を書き換えるものでもありません。サーバーへの接続不能、誤った通信経路、TLS設定の不一致を解決することもできません。

設定項目：アドレスプール、DNS、入口での復元

「V2Ray FakeDNS」はこの種の仕組みを指す総称として使われることがありますが、V2RayとXrayでは設定できる機能や項目、クライアントとの連携方法を個別に確認する必要があります。以下は該当項目に対応したXray-coreのJSON設定例です。明示的に指定した値を示しており、すべてのバージョンでの初期値を示すものではありません。v2rayN、v2rayNG、v2flyNGでは画面や設定の生成方法が異なるため、別のコア向けの設定をそのまま流用しないでください。

以下はルートオブジェクト内のDNSとアドレスプールの設定例です。単独で動作する完全な設定ではありません。待受入口、外向き接続、システムルートは定義されておらず、IPv4プールのみを示しています。この例から、AAAA問い合わせも同じ方法で処理されるとは判断できません。実際の環境では、使用中のコアのドキュメントを確認し、IPv6の動作と実DNSへのフォールバック経路を設定してください。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": [
      "fakedns"
    ]
  }
}

仮想アドレス宛ての接続を受け付けるインバウンドにも、復元の設定が必要です。以下では、そのインバウンド内の sniffing 項目だけを示しています。他のインバウンド設定は自動で補われません。routeOnly は通常、スニッフィング結果をルーティングにのみ使い、宛先は書き換えないことを意味します。この例では、復元前の仮想宛先をそのまま外向き接続に渡さないよう、false を明示しています。

{
  "sniffing": {
    "enabled": true,
    "destOverride": [
      "fakedns"
    ],
    "routeOnly": false
  }
}

利用に適した場面と適さない場面

FakeDNSが特に役立つのは、TUNや透過プロキシを使い、ドメイン名に基づいて通信を振り分ける環境です。ネットワーク層で接続を受け取る透過プロキシの入口では、接続情報だけからドメイン名を取得できるとは限りません。マッピングテーブルを使えば、HTTP HostやTLSハンドシェイクの情報だけに頼らず、ドメインルールを適用できます。実際の名前解決をプロキシの出口側で行いたい場合にも利用できますが、実現できるかどうかは外向き接続、ルーティング、実DNSの組み合わせによります。

明示的プロキシと透過プロキシは分けて考えてください。ドメイン名を宛先に指定できるSOCKSリクエストやHTTP CONNECTリクエストなら、ドメイン名を直接渡せるためFakeDNSが不要な場合があります。一方、アプリがローカルで名前解決してからIPアドレスをプロキシに渡すと、ドメイン名が失われることがあります。必要性は実際のリクエスト形式で判断し、「システムプロキシ」という表示だけで決めないでください。

よくある副作用：キャッシュ、社内ネットワーク、DNSの迂回

FakeDNSは有効期間のあるローカルマッピングテーブルを使いますが、アプリやシステムには古いDNS応答が残ることがあります。コアの再起動後にマッピングが消えているのに、アプリが古い仮想IPで接続しようとすると、「最初は使えるのに、モード切り替え後に接続できない」といった症状が起きます。この場合、外向き接続を選ぶ前に問題が起きているため、ノードを何度も切り替えても通常は解決しません。

• モード切り替え後に接続できない：FakeDNSを無効にしたりTUNを終了したりした後も、キャッシュ内の仮想アドレスが使われる場合があります。まず接続を取り込むモードを正しい状態に戻し、キャッシュを消去して関連アプリを再起動してください。
• LAN内サービスに接続できない：社内ドメインは、社内DNSから内部アドレスを返す必要がある場合があります。すべての問い合わせを一律に仮想プールへ送るのではなく、該当ドメインには実DNSを使う経路と直接接続のルールを明示してください。
• アプリが独自に名前解決する：アプリ内蔵のDoH、DoT、または独自の名前解決結果を使う場合、従来のDNSを取り込んでも問い合わせを検出できないことがあります。その場合、仮想マッピングがないのは想定どおりであり、アドレスプールの故障を意味しません。
• IPv4とIPv6の動作が異なる：A問い合わせは仮想プール、AAAA問い合わせは別の経路に進むと、同じアプリでも動作が不安定になることがあります。各レコード、IPv6ルート、対応するアドレスプールを個別に確認してください。
• 診断ツールの結果が変わる：名前解決ツールに198.18帯域のアドレスが表示されても、ドメイン名の実際の接続先がそこだという意味ではありません。仮想IPへの疎通テストだけでは、リモートのWebサイトが稼働しているか判断できません。

FakeDNSを使えば自動的に「DNS漏えいがなくなる」わけではありません。ローカルから直接接続すると実DNSによる名前解決が発生することがありますし、アプリが制御対象のDNSを迂回する場合もあります。名前解決経路を確認するには、問い合わせ先と接続に使われた外向き経路をそれぞれ調べてください。仮想アドレスが一度返されたことだけで判断しないようにしましょう。

仮想IPへの接続失敗を順番に調べる

まずドメイン名、アプリ、ノードをそれぞれ1つに絞り、切り替え前後の状態を記録してください。以下では www.example.com を問い合わせ例として使います。コマンドは現在の端末で使われる名前解決経路を確認するもので、問い合わせが必ずFakeDNSに届くとは限りません。また、Windows、macOS、Linuxの名前解決ツールとブラウザーでは、異なる経路が使われる場合があります。

nslookup -type=A www.example.com
nslookup -type=AAAA www.example.com

1. まず名前解決が仮想プールに入ったか確認：Aレコードの結果が設定したプール内のアドレスなら、その問い合わせには仮想アドレスが返されています。実IPアドレスが返る場合は、問い合わせが制御対象のDNSを迂回していないか、対象ドメインが実DNSを使う例外設定に一致していないかを確認してください。
2. 次に接続がコアに届いたか確認：アプリが接続を開始した際のアクセスログを確認します。名前解決で仮想アドレスが返されたのに、コアに対応する接続記録がない場合は、ノードのVMessやVLESSの設定を変える前にTUNルートと入口の取り込みを確認してください。
3. マッピングから復元できるか確認：ログに仮想IPしか表示されない場合は、接続を受け付けるインバウンドで対応する復元設定が有効か、コアの再起動、アドレスプールの変更、複数インスタンスへの切り替えが発生していないかを確認してください。ログの表示形式はバージョンによって異なるため、1行だけで失敗と断定しないでください。
4. 最後にルーティングと外向き接続を確認：ドメイン名を復元できても接続に失敗する場合は、そのドメインに適用される外向き接続を確認してください。直接接続には利用可能な実DNSの名前解決経路が必要です。プロキシ経由の場合は、ノードへの接続、サーバー側の名前解決、通信設定を確認してください。

Windowsでは以下のコマンドでシステムのDNSキャッシュを消去できますが、アプリ内のキャッシュをすべて削除できるわけではありません。実行する前に、接続を取り込むモードが正しく設定されていることを確認してください。そうしないと、アプリは再び利用できない結果を取得します。ブラウザーやバックグラウンドで常駐するプログラムの問題が続く場合は、関連プロセスを終了してから再度試してください。

ipconfig /flushdns