FakeDNSとは？仮想IPの仕組み・使いどころとv2rayNでの設定

FakeDNSの仕組み：ドメインを保持してから接続先を決める

仮想IPの対応付け：通常のDNSは、ドメインに対して接続可能な実IPアドレスを返します。一方、FakeDNSは指定されたアドレスプールからIPを割り当て、「ドメインと仮想IP」の対応関係をローカルに記録します。このIPはWebサイトの実際の接続先ではなく、後続の接続からドメインを特定するための索引です。アプリは返されたIPに通常どおり接続し、プロキシの処理経路が対応関係を参照して元のドメインを特定します。

接続が成立する条件：DNSリクエストと後続の接続が、連携した処理経路を通って初めて仮想IPが機能します。DNSが仮想IPを返しても、TUNがそのアドレスプール宛ての通信を取り込まなければ、アプリは通常のネットワークに接続しようとしてタイムアウトすることがあります。反対に、アプリが独自の暗号化DNSで実IPを取得した場合、FakeDNSにその問い合わせのドメイン情報が記録されることはありません。

接続先での名前解決：ドメインを復元できても、接続全体で実DNSが不要になるわけではありません。その後に名前解決するか、どこで行うかは、アウトバウンドの種類、ドメイン処理ポリシー、サーバー側の動作によって異なります。直接接続では通常、接続可能なIPアドレスが必要です。ドメインを転送できるプロキシアウトバウンドなら、名前解決をリモート側に任せられます。FakeDNSが解決するのはローカルでの識別と振り分けであり、インターネット全体の名前解決を置き換える機能ではありません。

アドレスプールとポート：仮想IPが表示されてもDNSエラーとは限らない

アドレスの見分け方：XrayのFakeDNSでは、198.18.0.0/15のアドレスプールを使う設定がよく見られます。この範囲はネットワークのベンチマーク用に予約されており、通常の公開Webサイトのアドレスではありません。以下はアドレスとプロトコルに関する情報で、速度測定の結果でも、すべての環境で同じ設定にすべきという意味でもありません。

アドレス範囲：198.18.0.0/15は198.18.0.0から198.19.255.255までです。ブロック全体のアドレス数と、カーネルが実際に保持できる対応付けの数は同じとは限りません。実際の容量はプールの設定や実装上の制限にも左右されます。社内の検証ネットワークですでにこの範囲を使っている場合は、先にルートの競合を解消してください。「予約済みアドレス」だからといって「この端末では未使用」とは限りません。

• 正常な状態：ドメインの問い合わせにプール内のIPが返り、アプリからアクセスでき、接続ログでドメインと想定どおりのアウトバウンドを確認できる。
• 異常な状態：問い合わせにプール内のIPが返るものの、接続が取り込み処理を通らない。またはログに仮想IPしか表示されず、接続がタイムアウトし続ける。
• 確認範囲：UDP 53番ポートを待ち受けたり転送したりするだけでは、すべてのDNS問い合わせを処理できるとは限りません。従来型DNSではTCPが使われることもあり、アプリが暗号化DNSを使う場合もあります。

v2rayNで有効にするタイミング：システムプロキシとTUNを区別する

システムプロキシの場合：通常、システムプロキシ設定に従うアプリは、接続先のドメインをローカルのHTTPプロキシまたはSOCKSプロキシに渡します。ただし、ローカルで名前解決するかどうかは、アプリとプロトコルの使い方によって異なります。ログにドメインが表示され、ルーティングも想定どおりなら、FakeDNSを有効にする必要はあまりありません。FakeDNSはVMessやVLESSのノード接続に必須ではなく、サブスクリプションの無効化やTLSパラメーターの誤りも修正できません。

カーネルの制約：v2rayNはデスクトップクライアントです。画面で選択したノードのカーネルと、TUNで実際に通信を処理するコンポーネントが異なる場合があります。ノードがXrayで接続されるからといって、XrayのFakeDNS設定項目をすべてのTUN設定にそのまま貼り付けないでください。現在の設定と起動ログを確認し、DNS、TUN、ルーティングをそれぞれどのコンポーネントが処理しているかを把握したうえで、使用中のカーネルに対応した設定を行います。

Androidでの注意点：v2rayNGはXrayカーネル、v2flyNGはv2flyカーネルを使用します。両者の画面項目、設定の生成方法、対応フィールドは、デスクトップ版の画面から推測できません。名前が似ていても、使用中のバージョンで利用できるDNS設定と通信の取り込み設定を個別に確認してください。プラットフォーム間で設定を移行する際は、振り分けの方針を維持しつつ、確認していない低レベル設定をそのままコピーしないでください。

設定の手順：アドレスプール、DNS応答、ドメイン復元をそろえる

最小構成の例：以下はXrayのトップレベル設定におけるfakednsアドレスプールのみを示したもので、単独で動作する完全な設定ではありません。poolSizeの65535は、この例で指定したマッピング容量です。アドレスブロックの総数ではなく、すべての端末に推奨される値でもありません。v2rayNが自動生成するファイルは再起動時に上書きされる場合があります。編集前に、カスタム設定の適用箇所と保存方法を確認してください。

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

1. 現在の設定を記録：DNS、ルーティング、TUNの設定を保存し、比較用に普段使うWebサイトとLAN内サービスを1つずつ選びます。
2. DNSの入口を確認：システムとアプリの問い合わせが想定した処理経路に入っているかを確認します。設定にアドレスプールを記述しただけでは、システムのすべての問い合わせが自動的にFakeDNSを使うようにはなりません。
3. DNS応答でFakeDNSを使う：対象となるXray設定では、該当するDNS問い合わせが内蔵のfakednsサービスを使うようにする必要があります。問い合わせルールは、直接接続とプロキシ接続の要件に合わせて設定してください。
4. ドメインの復元を確認：Xrayの対象インバウンドを使う場合は、スニッフィング設定のenabledとdestOverrideを確認します。fakedns項目は、マッピングからドメインを復元するための設定です。他の通信取り込みコンポーネントを使う場合は、それぞれに相当する機能を設定してください。
5. 項目ごとに検証：通常のWeb閲覧、LANへのアクセス、対象アプリをそれぞれ確認します。まず復元されたドメインとアウトバウンドを確認し、その後、日常利用の範囲を広げるか判断します。

IPv6との組み合わせ：IPv4プールを用意しただけでは、IPv6も同じように処理されるとは限りません。アプリがAAAAレコードを優先して問い合わせ、IPv6で接続する場合があります。この経路に対応するルートやDNSポリシーがなければ、アプリによって動作が異なることがあります。AレコードとAAAAレコードの問い合わせ、それぞれの接続経路を個別に確認し、IPv4で一度成功しただけですべて正常と判断しないでください。

利用場面と互換性の考慮：ドメインルールを優先し、実IPが必要な場合は個別に対応する

ルール運用上の利点：TUNが受け取るのは通常、接続先のIPアドレスです。IPだけでWebサイトの用途を安定して判別するのは困難です。1つのドメインが複数のIPを使うこともあれば、1つのIPが複数のドメインをホストすることもあります。FakeDNSは問い合わせ時のドメイン名を保持し、ドメインルールの判定に必要な情報を補います。ただし、対象範囲は実際のDNS問い合わせ経路に左右され、すべての接続からドメインを復元できるわけではありません。

互換性の問題：アプリによっては、名前解決で得たIPが想定されたアドレス範囲かを検査したり、DNSの結果を別のプロセスやデバイスに渡したりします。仮想IPは元のマッピング環境を離れると、通常は利用できません。そのため、適切な通信取り込み機能を持たない別のデバイスにFakeDNSの応答を共有したり、返されたアドレスをサーバーの実IPとして長期設定に記録したりしないでください。

トラブルシューティングと切り戻し：問い合わせ、マッピング、接続の順に確認する

調査の始め方：有効化後に「Webページは開くのに、特定のアプリが使えない」という問題が起きた場合は、発生時のローカルログを保存し、対象アプリが独自DNS、固定IP、別のネットワーク経路を使っていないか確認します。ノード、ルーティングルール、DNSを同時に変更すると、復旧しても原因を特定しにくくなります。

1. 仮想IPが返らない：テスト対象のドメインがFakeDNSの問い合わせルールに該当しているか確認します。除外ルールによる実IPの返却が想定どおりの場合もあれば、アプリ独自のDNSや古いキャッシュが原因の場合もあります。
2. 仮想IPは取得できるがタイムアウトする：TUNが動作しているか、アドレスプール宛てのルートが正しいインターフェースを通るか、他の仮想ネットワークアダプターや社内ルートと競合していないか確認します。
3. ログに仮想IPしか表示されない：該当するインバウンドのドメイン復元設定を確認します。また、再起動でマッピングが失われた一方、アプリには古いDNSキャッシュが残っていないか確認してください。
4. ドメインは正しいのに接続先が違う：ルールの適用順を確認し、プロセス、ポート、IPのルールが先に適用されていないか調べます。この場合、問題はDNSだけではありません。
5. ブラウザーとアプリで動作が異なる：暗号化DNS、アプリのプロキシ設定、キャッシュを個別に確認します。ブラウザーで一度成功したことを、他のプロセスの成功の根拠にしないでください。

Windowsのキャッシュ：実DNSに戻す前に、DNS応答と通信の取り込み設定を元に戻し、システムキャッシュを消去して対象アプリを再起動します。以下のコマンドで消去されるのはWindows DNSクライアントのキャッシュだけです。ブラウザー内蔵のキャッシュは消去されず、ノード設定も変更されません。長時間起動しているアプリは独自の接続プールを保持している場合があるため、完全に終了してから再度起動してください。

ipconfig /flushdns

切り戻し後の確認：新しい問い合わせで以前の仮想IPが返らないこと、LAN内サービスにアクセスできること、システムプロキシまたはTUNが予定どおりの状態であることを確認します。通信の取り込みを無効にした後もアプリが古い仮想IPへの接続を試みる場合は、そのアプリのキャッシュも消去してください。仮想IPを直接接続ルールに追加しても、索引が実サーバーのアドレスに変わることはありません。

よくある質問：FakeDNS、スニッフィング、プライバシーの違い

最終判断：システムプロキシでドメイン別ルーティングが正常なら、FakeDNSを常時有効にする必要はありません。TUNでドメイン情報が実際に失われており、DNSと接続経路の両方を管理できる場合に限り、有効化を検討してください。設定後は、ドメインの復元、ルートの適用、アプリとの互換性の3点で動作を確認します。