FakeDNSの仕組みを解説｜仮想IPの割り当て・使いどころ・注意点

FakeDNSの仕組み：仮想アドレスはマッピングの索引

通常のDNSは、ドメイン名を接続先サービスの実アドレスに変換します。一方、FakeDNSはローカルのアドレスプールからアドレスを選び、「ドメイン名と仮想IP」の対応を記録してから、仮想アドレスをアプリに返します。たとえば、アプリがexample.orgのAレコードを問い合わせると、198.18.0.1が返る場合があります。このアドレスは説明用の例で、実際の割り当て順序は実装や動作状況によって異なります。

その後、アプリはこの仮想IPに接続します。通信を捕捉するコンポーネントが宛先アドレスを読み取り、対応するドメイン名を引き当てて、ルーティングや送出処理に渡します。つまりFakeDNSで重要なのは「特殊なIPを返す」ことではなく、DNSクエリと後続の接続が、同じマッピングを共有または参照できる処理経路を通ることです。

198.18.0.0/15はベンチマークテスト用に予約されたアドレス範囲で、198.18.0.0から198.19.255.255までを含みます。一般のインターネット上のサービスアドレスではありません。FakeDNSではこの範囲がよく使われますが、実装によっては別のアドレスプールを使うこともあります。仮想アドレスが捕捉処理を通らず物理ネットワークへ送られると、通常は本来のWebサイトに到達できません。

TUNとドメイン別ルーティング：捕捉・復元・照合が必要

TUNはネットワーク層でIPパケットを受け取ります。接続を捕捉した直後に確認できる情報は、通常、宛先IP・ポート・通信プロトコルです。アプリがすでにドメイン名を名前解決していると、ドメイン名がパケットに含まれない場合があります。FakeDNSは「このアドレスが元はどのドメイン名だったか」をあらかじめマッピングに保存し、ドメインルールの手掛かりを提供します。

1. DNSを捕捉：アプリのクエリが想定したDNS処理経路に入る必要があります。従来のDNSではUDP 53番ポートがよく使われますが、TCP 53番ポートが使われることもあります。片方だけを処理しても、すべてのクエリを捕捉できたとは限りません。
2. 接続を捕捉：仮想アドレスプール宛てのTCPまたはUDP通信は、対応するTUN・ルーティング・コアの処理経路に入る必要があります。除外ルールによって途中で素通りさせないでください。
3. ドメイン名を復元：接続を受け取るコンポーネントがマッピングを参照できる必要があります。XrayではFakeDNSやインバウンドのスニッフィングに関する設定が関係します。DNSリストに名前を追加するだけでは、一連の処理は完結しません。
4. ルールを適用：ドメイン名を復元したうえで、ドメインルール・IPルール・フォールバックルールに従って送出先を決めます。VMessやVLESSなどのプロトコルは、その後のプロキシ通信を担うもので、このマッピングを作るものではありません。

ブラウザーがシステムのHTTPプロキシ経由でHTTPSサイトにアクセスする場合、CONNECTリクエストに接続先のホスト名を含められます。SOCKS5でもドメイン名形式のアドレスを使用できます。このような経路では、すでにドメイン名がプロキシに渡されている可能性があり、FakeDNSを追加する必要はないかもしれません。反対に、アプリがローカルで名前解決してIPアドレスだけを渡す場合は、ドメイン情報をどう取得するか別途確認が必要です。

設定の確認：アドレスプールと復元経路をそろえる

v2rayNはデスクトップクライアント、v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。クライアントの画面、選択したコア、TUN接続コンポーネントはそれぞれ異なる階層です。クライアント名だけで設定項目が使えるかどうかを判断しないでください。以下のキーと値はXrayの設定関係を説明するもので、3つのクライアントすべてに同名のスイッチがあることを示すものではありません。また、そのまま完全な設定として読み込めるものでもありません。

以下はXrayネイティブJSONの割り当て側の一部で、アドレスプールと内蔵DNSの関連だけを示しています。インバウンド、アウトバウンド、ルーティング、通信の捕捉設定は含まれないため、クライアントが生成する完全な設定ファイルの代わりにはなりません。クライアントが別のコンポーネントでTUNやDNSを処理する場合は、そのコンポーネントの設定形式に従い、項目を混在させないでください。

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

• まず現在の設定をバックアップし、実際に生成された実行時設定を確認してください。画面で「TUNを有効」にしても、FakeDNSが有効になったとは限りません。
• クライアントの起動時に、未知の項目、設定の解析エラー、アドレスプールの競合がないことを確認します。設定が適用できない場合はすぐに元へ戻し、ノードのプロトコル設定を同時に変更しないでください。
• AレコードとAAAAレコードの処理方針をそれぞれ確認してください。上記のIPv4アドレスプールの例は、IPv6クエリにも対応する仮想マッピングが割り当てられることを意味しません。
• 復元したドメイン名を、直接接続とプロキシ経由の各アウトバウンドがどう処理するか確認してください。最終接続に実アドレスが必要な場合は、引き続き利用できる名前解決経路が必要です。クエリが仮想アドレスの割り当て側へ繰り返し戻らないようにしてください。

使いどころと注意点：すべてのアプリに仮想IPが適するわけではない

FakeDNSは、接続前にローカルで実アドレスを取得する必要性を一部減らし、IP接続に変わったリクエストのドメイン名をルールで判別しやすくします。ただし、リモートでの名前解決を自動的に高速化するものではなく、ノードの障害、TLSパラメーターの誤り、ルーティングルールの順序ミスも解決しません。効果はDNSの応答速度だけでなく、ドメイン名の判別とアプリの互換性で判断してください。

IPアドレスを直接指定するアプリは、事前にドメイン名を問い合わせないため、FakeDNSでドメイン名を補うことはできません。LANのマルチキャストによる名前検出も、通常のユニキャストDNSとは異なります。53番ポートのルールを調整するだけでは、プリンター、ファイル共有、内部サービスの検出問題を解決できない場合があります。

検証手順：DNS・マッピング・送出を分けて確認

検証には同じテスト用ドメインを使い、ノードとルーティングルールを固定して、一度に変更する設定は1つにします。仮想アドレスが表示されても、あるクエリで仮想応答が返ったことしか分かりません。Webサイトが開けても、すべてのアプリが同じ経路を通っているとは限りません。名前解決の結果、通信の捕捉ログ、ルールの適用状況をあわせて確認してください。

1. 基準を記録：FakeDNSを無効にして、テスト用ドメインにアクセスできるか、現在のDNS応答と送出ルールを記録します。元に戻せる設定を残し、サブスクリプション内のサーバーアドレスは変更しないでください。
2. クエリを確認：有効にした後、同じドメイン名を問い合わせ、Aレコードが実際に設定した仮想アドレスプール内にあるか確認します。実IPが返る場合は、アドレスプールをすぐに変更せず、キャッシュ、アプリ内蔵DNS、DNSルーティングを先に調べてください。
3. 復元を確認：新しい接続を開始し、ログで元のドメイン名と想定した送出先が関連付けられているか確認します。仮想IPへの直接接続しか記録されない場合は、まず復元経路とネットワークのルーティングを確認してください。
4. 互換性を確認：Webページ、内部サービス、ブラウザー以外のアプリをそれぞれテストします。UDPを使うアプリも個別に確認してください。WebページのTCP接続が成功しても、UDPの動作確認にはなりません。

Windowsでは、まずシステムが現在使っている名前解決結果を確認し、設定を切り替えた後にシステムDNSキャッシュを消去できます。以下の2つのコマンドは、それぞれ確認と消去に使います。性能テスト用ではなく、特定の結果を保証するものでもありません。

nslookup example.org
ipconfig /flushdns

システムのキャッシュを消去しても、ブラウザーやアプリ内のキャッシュは消えません。FakeDNSを無効にしたりマッピングコンポーネントを再起動したりした後も、アプリに古い仮想アドレスが残ることがあります。マッピングがすでに消えていると、古い接続は失敗します。設定を元に戻す場合は、関連アプリを終了し、システムキャッシュを消去してからアプリを再起動し、動作を確認してください。

よくある質問：有効化後の不具合を調べる

最終的な判断基準は、接続経路を説明でき、ドメインルールが適用され、日常使うアプリが安定して動作することです。FakeDNSはDNSと通信の捕捉を連携させる方法のひとつにすぎません。サブスクリプションの読み込み、ノードの選択、システムプロキシ、TUNは、それぞれ個別に確認する必要があります。