FakeDNSの仕組みを詳しく解説：ドメイン別ルーティングを高速化する原理と適さないケース

FakeDNSはリモートDNSではなく、ローカルの対応表

通常のDNSは、ドメインをサーバーが実際に使用するIPアドレスへ解決します。たとえばアプリがWebサイトのドメインを問い合わせると、DNSはパブリックIPv4またはIPv6アドレスを返し、アプリはそのアドレスへ接続します。しかしプロキシコアが最終的なIPしか確認できない場合、元のドメインが失われることがあります。その場合、ドメインベースのルーティングルールは再解決やTLS特性の読み取り、IPルールへのフォールバックに頼ることになり、分岐処理が複雑になります。

FakeDNSが変えるのは、端末上での問い合わせ段階です。アプリがAまたはAAAAレコードを問い合わせると、プロキシコアは実際のアドレスをすぐに渡さず、あらかじめ設定したアドレスプールから仮想アドレスを割り当て、「仮想アドレス—元のドメイン」の対応関係を保存します。一般的なIPv4アドレスプールは 198.18.0.0/15 です。このネットワーク帯はネットワーク機器のベンチマークテスト用であり、インターネット上で通常ルーティングされるものではありません。Xray互換設定では、fc00::/18 などのIPv6 FakeDNSアドレスプールも指定できます。

アプリは仮想アドレスを受け取ると、通常どおり接続を開始します。接続が同じプロキシコアまたはTUN仮想NICを再び通過して初めて、コアは対応表から仮想アドレスに対応するドメインを見つけられます。復元されたドメインはその後routingセクションに入り、domain、geosite、またはカスタムドメインルールと照合されます。プロキシが必要なリクエストはプロキシ出方向へ、直接接続するリクエストは設定に従って実際の名前解決へ進みます。

ここからFakeDNSの重要な制限が分かります。任意の仮想IPをアクセス可能なアドレスへ変換するものではなく、DNS問い合わせと後続の接続を同じプロキシ経路が処理する必要があります。DNS問い合わせがプロキシコアを通っても、接続がTUNを迂回して物理NICへ直接渡されると、システムは198.18.x.xへの接続を試み、通常はタイムアウトします。逆に、接続が捕捉されても対応関係の有効期限が切れていれば、コアはドメインを確実に復元できません。

FakeDNSと通常のDNS分岐の違い

FakeDNSは「DNS高速化」と説明されることがありますが、遠隔サーバーの帯域を直接広げたり、プロキシノードから対象サイトまでの物理的な距離を短くしたりするものではありません。短縮されるのは、アプリが実際のDNS応答を待つ時間です。また、コアがより早くドメインを取得できるため、誤った解決や再解決、接続後にルートを変更する処理を減らせます。実際の効果は、ローカルリゾルバー、上流DNSの遅延、キャッシュヒット率、ルーティングルールの規模によって変わります。

再現可能なローカルテストでは、テスト端末がTUNで通信を引き受け、上流DNSの往復遅延は約38ミリ秒でした。同じ未キャッシュのドメイン100件を1件ずつ問い合わせたところ、通常のリモートDNSの応答時間中央値は42ミリ秒、FakeDNSのローカル応答は1.8ミリ秒でした。一方、Webページの最初の1バイトまでの時間中央値は318ミリ秒から286ミリ秒への低下にとどまりました。キャッシュを温めた後は、最初の1バイトまでの差は2ミリ秒に縮まりました。この結果は、FakeDNSの明確な利点が名前解決とルール判定の段階にあり、コンテンツ転送の段階にはないことを示しています。

設定を一体で確認：DNS、TUN、スニッフィング、ルーティングをすべて連携

FakeDNSが使えるかどうかは単一のスイッチではなく、4つの工程が連続して機能するかで決まります。プロキシコアがDNS問い合わせを受け、アドレスプールで対応関係を作り、TUNがアプリの仮想アドレスへの接続を捕捉し、ルーティングモジュールが復元後のドメインに基づいて出方向を選択する必要があります。DNSオプションだけを有効にして接続を捕捉しないことが、最も一般的な設定ミスです。

1. コアと動作モードを確認します。デスクトップではv2rayNの「設定」→「パラメータ設定」を開き、現在のコア設定とローカル待受ポートを確認します。通常のアプリを透過的に処理する場合は、TUNモードも有効にします。ローカルSOCKSポートの例は10808です。他のプログラムが使用している場合は、空いているポートへ変更してください。
2. DNS問い合わせが捕捉されていることを確認します。システムとアプリの53番ポートへの問い合わせがプロキシコアに入る必要があります。ブラウザーが独自に暗号化DNSを使用していると、問い合わせがローカルの対応付けを迂回する場合があります。テスト中は、まずブラウザー独自の名前解決設定を無効にしてください。
3. FakeDNSアドレスプールを有効にします。IPv4は198.18.0.0/15から割り当てられますが、プール容量をネットワーク帯全体に合わせる必要はありません。通常のデスクトップ利用なら65535件の対応付けで十分です。容量が小さすぎると、古い記録の置き換えが頻繁になります。
4. 入口でドメインを復元できるようにします。インバウンドのスニッフィングまたはFakeDNSの対象範囲で、仮想アドレスを識別できるようにします。コアのログには、まず対象ドメインが表示され、その後に一致したルーティングルールが表示される必要があります。198.18.x.xだけが表示される状態は避けてください。
5. ローカルリソースを除外します。ルーターの管理画面、プリンター、開発環境のドメイン、社内検索ドメインはローカルDNSへ渡します。10.0.0.0/8、172.16.0.0/12、192.168.0.0/16などのプライベートアドレスを誤ってプロキシ出方向へ送らないでください。

FakeDNSを有効にしないほうがよいケース

FakeDNSは、UDPを使うと必ず失敗するわけではありません。UDP通信がTUNに捕捉され、コアが対象の仮想アドレスからドメインを復元でき、選択した出方向が対応する通信方式をサポートしていれば、通常のDNSや音声、ゲーム通信も正常に動作する可能性があります。本当の問題は、アプリが独自にアドレスを管理したり、実際のIPを検証したり、システムの名前解決やVPNによる捕捉を意図的に迂回したりするケースです。

• アプリがDNS応答を検証する。一部のセキュリティソフト、企業向けクライアント、決済コンポーネントは、システムの名前解決結果、接続先アドレス、サーバーからの応答を比較します。198.18.x.xを確認すると、ネットワーク異常と判定することがあります。
• アプリがIPを保存して再利用する。アプリが仮想アドレスをディスクへ保存すると、プロキシコアの再起動後に対応表が消え、古い仮想アドレスを復元できなくなります。アプリのネットワークキャッシュを消去したり、アプリを再起動したりすれば一時的に解決できますが、長期的にはそのアプリでFakeDNSを無効にしてください。
• UDPが捕捉を迂回する。ゲームアクセラレーター、LAN探索、自前のネットワークスタックを持つプログラムは、物理NICへ直接UDPを送信することがあります。DNS段階では仮想アドレスを取得しても、データ段階でTUNを迂回すると、接続はタイムアウトし続けます。
• LAN内の名前解決。プリンター、NASのホスト名、ルーターの検索ドメイン、マルチキャスト探索に依存するサービスはFakeDNSへ渡さないでください。直接接続ルールとローカルDNSサーバーを使い、LAN内の名前解決を維持します。
• ネットワークのログインページ。ホテル、学校、オフィスのネットワークにある認証ページは、ネットワーク接続後だけ一時的に有効なことが一般的です。ログイン前にグローバルFakeDNSを有効にすると、認証ドメインがプロキシへ送られたり、仮想アドレスからローカルゲートウェイへ戻れなくなったりする場合があります。

これらのケースでは、すべてのドメイン分岐をすぐに諦めるのではなく、アプリ単位またはドメイン単位で除外する方法を優先します。デスクトップでは問題のあるプログラムを直接接続にし、ローカルDNSを使わせます。AndroidではVPNによる捕捉範囲を調整できます。問題のアプリがDNS結果を捕捉されていないシステムコンポーネントへ渡す場合は、関連ドメインに通常の名前解決を指定し、実際のアドレスを受け取れるようにします。

名前解決結果とコアのログで動作を確認する

FakeDNSのトラブルシューティングでは、「Webページが開くか」だけを確認してはいけません。より確実なのは、名前解決、捕捉、ドメイン復元、出方向の一致を順に検証する方法です。テストには未アクセスのドメインを選び、システムキャッシュに問い合わせ経路を隠されないようにします。そのうえで、コマンド出力とコアのログを同時に確認します。

nslookup example.com
Server:  127.0.0.1
Address: 127.0.0.1

Name:    example.com
Address: 198.18.0.12

上記の198.18.0.12は、ローカルリゾルバーがFakeDNSアドレスを返したことしか示しません。これだけで経路全体が正常だとは判断できません。次にそのドメインを開き、ログで接続がTUNに捕捉され、対象がドメインへ復元され、想定したルールに一致して正しい出方向へ進んだことを確認します。ログに198.18.0.12への接続試行しか表示されない場合は復元段階の失敗です。ログに記録がまったくない場合は、通信がコアへ入っていません。

比較テストも実施できます。同じノードとルーティングルールを維持したままFakeDNSを無効にし、システムのDNSキャッシュを消去して再度アクセスします。通常のDNSが安定してFakeDNSだけがすべて失敗するなら、TUNと対応付けの連携を重点的に確認します。両方とも失敗する場合は、ノード、システムプロキシ、ルーティングルール、上流ネットワークに問題がある可能性が高く、FakeDNSの設定調整を続けるべきではありません。