FakeDNSとは？仕組み・TUNモード連携・使いどころ

FakeDNSの仕組み：一時的なIPアドレスでドメインを保持

FakeDNSが返すのはローカルで対応付けられたIPアドレスであり、Webサーバーの実際のIPアドレスではありません。通常のDNSはドメイン名を実際のIPアドレスに変換しますが、FakeDNSはあらかじめ用意されたアドレスプールからIPアドレスを割り当て、「ドメイン名と一時アドレス」の対応を記録します。アプリは通常どおりそのアドレスに接続し、プロキシが通信を取り込んだ後、対応情報からドメイン名を復元して、後続のルーティングやアウトバウンド処理に渡します。

Xrayでよく使われるIPv4アドレスプールの例は 198.18.0.0/15 で、範囲は 198.18.0.0 から 198.19.255.255 です。これはベンチマーク用に予約されたアドレス範囲であり、インターネット上のサーバーアドレスでも、一般的な家庭内LANのプライベートアドレス帯でもありません。正しく構成されたFakeDNSの経路で、アプリがこのようなアドレスを受け取るのは正常です。

この仕組みの要点は「IPアドレスからドメイン名を復元できる」ことです。アプリが偽アドレスに接続する際にプロキシを迂回したり、通信を取り込むコアに対応情報がなかったりすると、偽アドレスでは正常にアクセスできません。DNS設定にアドレスプールを指定するだけで、接続の取り込みや復元を設定していない場合、これまでアクセスできていたサイトも接続タイムアウトになることがあります。

FakeDNSとTUN：通信の取り込みとDNSの取り込みは別

TUNはネットワークパケットをプロキシに渡し、FakeDNSはその過程でドメイン情報を復元できるようにします。よく併用されますが、同じ機能ではありません。TUNを有効にしてアプリの接続が取り込まれていても、DNSクエリはルーターや企業のDNS、またはブラウザー独自の暗号化DNSに送られている場合があります。この場合、返るのは実際のIPアドレスで、FakeDNSの対応情報は作成されていません。

ドメイン名の復元と通信のスニッフィングは区別が必要です。HTTPのHostやTLSのサーバー名などは一部の接続の識別に役立ちますが、すべての接続からドメイン名を読み取れるわけではありません。FakeDNSは事前のDNSクエリで記録した対応情報からドメイン名を復元するため、アプリ層のデータだけに依存しません。ただし、アプリがIPアドレスを直接使う場合や、対象のDNS入口を通らない場合、元のドメイン名を自動で補うことはできません。

Xrayの設定：アドレスプールとインバウンドでの復元を別々に確認

XrayのFakeDNSでは、アドレスプールの設定と実際のDNS利用方法を組み合わせる必要があります。以下は説明用のトップレベル設定例で、そのまま動作するクライアント設定一式ではありません。IPv4の偽アドレスプールと内蔵DNSのサーバー選択のみを示しています。実際の設定にはインバウンド、ルーティング、アウトバウンドも必要で、アプリのクエリが確実にこのDNSモジュールへ届くようにしなければなりません。

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

poolSize は対応情報を格納するプールの容量を示すもので、DNSの待ち受けポートや通信速度の設定ではありません。例の 65535 は、サイトが同時接続を65535件処理できるという意味ではありません。FakeDNSのDNS設定だけですべての名前解決を担うこともできません。実際のIPアドレスが必要な直接接続先、プロキシサーバーのドメイン名、特殊な社内ドメインには、それぞれ実際の名前解決経路を用意してください。接続先の決定段階で、直接使えない偽アドレスが返る事態を防げます。

この仕組みに対応したXrayインバウンドでは、sniffing.destOverride の fakedns を使って対応情報を検索し、接続先を復元します。この項目をほかのコアの設定にそのまま貼り付けたり、TUNの通信を受け取らないインバウンドだけを変更したりしないでください。クライアントが設定を自動生成する場合、一時ファイルを手動で変更しても次回起動時に上書きされることがあります。クライアントが提供する設定画面や設定方法を優先してください。

使いどころ：ドメイン別ルーティングを優先し、LANの名前解決は例外として維持

FakeDNSは、「通信を透過的に取り込みながら、ドメイン名に応じてアウトバウンドを選びたい」場合に適しています。たとえば、システムのHTTPプロキシを使わないアプリでは、TUNを有効にしても接続先IPアドレスしか見えないことがあります。FakeDNSで対応情報を保持すれば、ルーティングでドメイン名を条件にできます。改善するのは接続先を識別する経路であり、サブスクリプションのノード品質が上がるわけでも、VMessが自動的にVLESSへ変換されるわけでもありません。

LANプリンター、社内サービス、ローカル機器の検出に依存するアプリを、一律にFakeDNSへ通すのは避けてください。マルチキャストによる検出と通常のユニキャストDNSは別の仕組みです。まず既存の名前解決経路を維持し、通信を取り込む範囲を段階的に広げましょう。社内ドメインをパブリックDNSに問い合わせる設定にすると、FakeDNSを無効にしてもアクセスできないことがあります。

検証とトラブルシューティング：名前解決、接続先、アウトバウンドの順に確認

FakeDNSの検証は、Webページが表示されるかどうかだけで判断できません。既存の接続、キャッシュ、ブラウザー独自のDNSによってページが表示されている可能性があり、新しい設定が有効になった証拠にはならないためです。設定は一度に1項目だけ変更し、変更前後のDNS応答、接続先、アウトバウンドの表示を記録しましょう。以下の手順は特定のクライアントバージョンに依存せず、メニュー名もすべてのバージョンで共通とは限りません。

1. 実際に使われているコアを確認。v2rayNのコア選択画面や実行ログで、起動しているコアを確認し、クライアントとコアのバージョンを記録します。設定に「未知の項目」というエラーが出た場合は、サブスクリプションのノードを何度も切り替えるのではなく、その項目がどのコアに属するか確認してください。
2. DNSの入口を確認。通常のDNSはUDPまたはTCPの 53 番ポートを使うことが多いものの、内蔵DNSモジュールがシステム上でこのポートを待ち受けているとは限りません。クライアントのDNS取り込み設定とシステムのDNSアドレスを確認し、127.0.0.1:53 が使えると決めつけないでください。
3. 古いキャッシュを削除。テストするアプリを終了してシステムのDNSキャッシュを削除し、アプリを再起動します。ブラウザーには独自のDNSキャッシュやセキュアDNS設定がある場合もあるため、別途確認してください。
4. アドレスと復元結果を確認。DNSの応答が設定したアドレスプールの範囲内にあり、接続ログに復元後のドメイン名または対応する処理記録が表示されるか確認します。198.18.x.x が表示されたというだけでは、アウトバウンド接続が成功した証拠にはなりません。
5. 実際の名前解決とルーティングを確認。直接接続先やプロキシサーバーのドメイン名から実際のIPアドレスを取得できるか確認し、ドメインルールで選ばれたアウトバウンドを調べます。トラブルシューティングが終わったら通常のログレベルに戻し、接続情報を大量に長期間保存しないようにしましょう。

Windowsでは次のコマンドでシステムのDNSキャッシュを削除し、各ネットワークインターフェースに設定されたDNSサーバーを確認できます。2つ目のコマンドはPowerShellで実行してください。これらはDNSの入口を調べるためのもので、クライアントのルールを自動変更したり、アプリ内部のすべてのキャッシュを削除したりするものではありません。

ipconfig /flushdns

Get-DnsClientServerAddress -AddressFamily IPv4

テストツールが実際のIPアドレスを返した場合は、まずどのDNSサーバーに問い合わせているか確認してから、FakeDNSが動作していないか判断します。偽アドレスが返るのに接続がタイムアウトする場合は、アドレスプール宛ての通信が適切なインバウンドに届いているか、対応情報がまだ有効かを重点的に確認してください。コアを再起動すると、アプリが古い偽アドレスを使い続ける一方で、新しいコアには対応情報が残っていないことがあります。その場合は、ノードを何度も切り替えるより、アプリの再起動とキャッシュの削除が有効です。

• AAAAレコードが返る一方でIPv4の対応付けは正常：IPv6の取り込み設定とDNSポリシーを確認してください。IPv4で成功しただけで、すべての接続がプロキシを経由しているとは判断できません。
• 企業ネットワークで異常が発生：ネットワーク機器がすでに 198.18.0.0/15 を使用していないか確認し、アドレスプールと既存のルートが競合しないようにしてください。
• DNSリークが疑われる：従来のDNS、暗号化DNS、IPv6の経路を個別に確認してください。偽アドレスが返っても、すべてのクエリが外部へ送信されていない証拠にはなりません。

よくある質問：有効化、遅延、無効化後の復旧

最終的には接続経路全体を確認してください。アプリがどのアドレスを取得し、どのインバウンドが接続を取り込み、ドメイン名を復元できるか、ルールがどのアウトバウンドを選択したかを順に調べます。ルーティングやプロキシモードをさらに調整する場合は詳細ガイドを参照してください。クライアントを初めて設定する場合は、まず利用ガイドに沿って基本的な接続を確認し、その後FakeDNSを追加しましょう。