FakeDNSの仕組み：仮想IPによるドメイン紐付けとTUNモードでの活用

FakeDNSとは：アドレスにドメイン情報を紐付ける仕組み

通常のDNS問い合わせでは、ドメインを接続先サービスの実IPに変換し、アプリはそのアドレスへ接続します。一方、FakeDNSはあらかじめ用意したアドレスプールから仮想IPを割り当て、「ドメインと仮想IP」の対応関係をローカルに保存してから、仮想IPをアプリに返します。このアドレスは引換券のようなもので、マッピング情報を持つ処理コンポーネントだけが、元のドメインを特定できます。

たとえば、アプリが example.com を問い合わせると、FakeDNSはプール内の 198.18.0.10 を返すことがあります。アプリがこのアドレスの443番ポートに接続すると、接続を受け取ったコンポーネントがマッピングを参照して example.com を復元し、ルーティングと出力処理に渡します。これは処理の流れを示す例であり、このドメインが常にこのアドレスに対応するわけではありません。また、インターネットから直接アクセスできるサービスを示すものでもありません。

重要なのは「偽のアドレスを生成する」ことではなく、アドレスを返すコンポーネントと、その後の接続を受け取るコンポーネントが、マッピング情報を共有または連携できることです。DNSが仮想アドレスを返すだけで、接続先が通常のゲートウェイなら、接続は通常失敗します。FakeDNSは通信を暗号化するものではありません。VMessやVLESSなどのプロキシプロトコルとは役割が異なります。

仮想IPプール：アドレス数とマッピング件数は別

V2Ray/XrayのFakeDNS設定でよく使われるIPv4アドレスプールは 198.18.0.0/15 です。この範囲はネットワーク機器のベンチマーク用で、通常のインターネット上の接続先アドレスではありません。以下の3つの数値は、アドレス範囲、マッピング容量の例、一般的なDNSのポート番号を示すもので、性能測定の結果ではありません。

ipPool は割り当て可能なアドレス範囲、poolSize はマッピングプールの容量を指定します。両者は別の設定です。ドメイン数が多い場合や長時間稼働させた場合、またマッピングが削除された場合は、古いアドレスと現在のマッピングが対応しなくなることがあります。具体的な再利用方法は実装によって異なります。アプリ側に古いDNS結果が残ることもあるため、コアを再起動すると、以前キャッシュした仮想アドレスを正しく認識できない場合があります。

TUNモードでFakeDNSがよく使われる理由

TUNはネットワーク層でIPパケットを受け取るため、見えるのは多くの場合、アプリが最初に入力したドメインではなく接続先アドレスです。実IPは複数のドメインで共有されることがあり、IPだけから元のドメインを安定して特定するのは困難です。FakeDNSならマッピングにドメイン情報を保持できるため、後続の接続をドメインに基づいてルーティングしやすくなります。

ただし、TUNとFakeDNSは必ずセットで使うものではありません。TUNは実DNSを使って動作させることもでき、FakeDNSも透過的な接続処理に対応した別の経路で利用できます。TLSやHTTPのスニッフィングでドメイン情報を得られる場合もありますが、すべてのプロトコルや暗号化された通信に対応するわけではなく、マッピングの代わりにはなりません。

• 向いているケース：システムプロキシを参照しないアプリも接続を取り込み、ドメインルールで振り分けたい場合。
• 事前に確認：アプリのDNS問い合わせが設定したDNS処理経路に入り、仮想アドレスへの接続も同じ経路で取り込まれること。
• 無理に有効化しない：ブラウザーが明示的なプロキシ経由でドメインを渡し、システムプロキシで要件を満たせるなら、まずは現在の設定を維持してください。
• 解決できないケース：アプリが固定された実IPに直接接続し、ドメインの問い合わせが発生しない場合、FakeDNSでドメインを復元することはできません。

設定の読み方：DNSの割り当てと接続時の復元を連携させる

以下の2つのカードは、Xray形式の設定にある関連項目を見分けるためのものです。実行可能な設定一式ではなく、クライアントの任意の入力欄にそのまま貼り付けないでください。クライアントが生成した設定によって手動変更が上書きされる場合があります。また、TUNが別のDNS実装を使う場合は、項目名や動作が異なることがあります。

v2rayNでは、まず「設定」→「パラメーター設定」で現在の基本設定を確認し、次に利用中のバージョンでDNSとTUNの設定画面を確認します。オプションの場所や名称はバージョンによって変わります。同じ名前のチェックボックスを探すのではなく、DNSを待ち受けるのはどのコンポーネントか、仮想アドレスを生成するのはどれか、接続を受け取るのはどれかを確認してください。

v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。ただし、デスクトップ版の設定とAndroidアプリの設定を、項目の位置だけを頼りにそのまま移し替えることはできません。クライアントで選べる設定項目、同梱コアのバージョン、実行ログを基準にしてください。サブスクリプションで提供されるのは通常ノード情報であり、端末全体のDNS通信まで設定済みとは限りません。

省略されるDNS解決はどの段階か

FakeDNSによって省けるのは、アプリが接続する前にローカルで接続先の実IPを待つためのDNS問い合わせです。アクセス全体でDNSが不要になるわけではありません。プロキシの出力先にドメインを渡す場合、リモート側で名前解決が必要になることがあります。直接接続ルールに一致した場合、ローカルの出力側で接続用の実IPが必要になるのが一般的です。

ドメインルールとIPルールも分けて考えましょう。ドメインを復元できれば、ドメインルールで直接照合できます。一方、IPの地理情報による分類には実アドレスが必要な場合があり、実際に名前解決が行われるかはルーティング設定によります。198.18.0.10 を接続先サーバーの所在地を示す情報として扱わないでください。また、FakeDNSを有効にしても、すべてのDNS通信がプロキシ経由になるとは限りません。

互換性の問題：キャッシュ、迂回経路、特殊なネットワークを確認

よくある不具合は「すべてのサイトが遅くなる」ことではなく、有効化後に一部のアプリだけ動かない、コアの再起動後に既存接続がおかしくなる、社内ネットワークに突然つながらなくなる、といったものです。原因を切り分ける際は一度に変更する条件を1つにし、元に戻せる設定を基準として残してください。ノード、DNS、ルーティングを同時に変更すると、原因を特定できなくなります。

もう1つのよくある誤解は、ping で仮想IPを測定し、パケットロス率からノードの品質を判断することです。このアドレスはマッピングを示すもので、実サーバーではありません。また、ICMPの処理はTCPやUDPと異なる場合があります。対象アプリの実際の接続をテストし、DNSの所要時間、接続時間、ダウンロード速度をそれぞれ記録してください。

有効化と切り戻し：同じリクエストで比較する

FakeDNSを使うかどうかは、設定項目を増やすことではなく、現在の接続経路をより完全に処理できるかで判断します。まずクライアントのバージョン、現在のノード、TUNの状態、DNS処理コンポーネント、アドレスプールを記録し、以下の手順で再現可能な比較を行ってください。

1. 基準となる状態を記録：FakeDNSを無効にし、ノードとネットワークは同じまま、プロキシ接続先、直接接続先、LAN内のサービスにそれぞれアクセスして、成否を記録します。
2. マッピング経路だけを有効化：DNSの割り当てと受信側の復元をセットで有効にし、同時にノードを変更したりルーティング全体を書き換えたりしないでください。
3. 接続を作り直す：テストするアプリを終了してから再起動します。必要に応じてシステムのDNSキャッシュを消去し、古い実アドレスと新しい仮想アドレスを混在させないようにします。
4. 3つの項目を確認：問い合わせ結果がプール内のアドレスか、接続時に元のドメインが復元されるか、最終的な出力先が想定した振り分けと一致するかを確認します。IPv6が有効な場合は、AAAA問い合わせとIPv6接続も個別に確認してください。
5. 切り戻しを確認：FakeDNSを無効にし、元のDNS設定に戻してから、影響を受けたアプリを再起動します。切り戻しても問題が続く場合は、すべてをDNSのせいにせず、TUNルート、システムプロキシ、ノードの接続性を引き続き確認してください。