FakeDNSの仕組みを解説：偽アドレスへのマッピングで名前解決の遅延を短縮

FakeDNSの経路：まず偽IPを返し、その後に元のドメイン名を復元

通常のDNSでは、まずドメイン名をDNSサーバーへ送り、実際のAまたはAAAAレコードを取得してから、アプリが返されたアドレスへ接続します。この処理には少なくとも1回のDNS往復が含まれます。システムDNSの応答が遅い、DNSリクエストが適切でない経路へ送られる、ローカルキャッシュにヒットしないといった場合、接続確立が名前解決で待たされます。

FakeDNSが変えるのは、ローカルでの名前解決経路です。アプリがドメイン名を問い合わせると、カーネルはすぐにパブリックDNSから実アドレスを取得せず、あらかじめ設定したアドレスプールから偽IPを割り当て、ドメイン名と偽IPの対応関係を記録します。アプリが偽IPへ接続すると、TUNのインバウンドがその通信を捕捉し、コアがマッピングテーブルから元のドメイン名を復元します。その後、ドメインルールに従ってプロキシ、ダイレクト接続、ブロックのいずれかを選択します。

よく使われるIPv4アドレスプールは 198.18.0.0/15 です。この範囲はネットワーク機器のベンチマーク用で、インターネット上でルーティングされるアドレスではないため、ローカルのマッピング用マーカーとして適しています。偽IPは対象サーバーのアドレスではなく、最終的な宛先としてプロキシノードへ直接送信されることもありません。役割としてはローカルインデックスに近く、実際のプロキシリクエストは復元後のドメイン名を宛先にします。

上記の遅延データは、同じ端末でキャッシュなしの問い合わせを100回連続実行した例です。ローカルFakeDNSの応答時間の中央値は約1.2ミリ秒、リモートDNSの往復時間の中央値は約43ミリ秒でした。ただし、最初のDNS応答が速くなることを示すだけで、Webページ全体の読み込み時間が必ず41.8ミリ秒短縮されるわけではありません。TLSハンドシェイク、ノードとの往復、パケットロス、サーバーの応答時間が、その後の速度を左右します。

マッピングテーブル、スニッフィング、アウトバウンドの連携

FakeDNSが機能するには、3つの条件が同時に成立する必要があります。DNS問い合わせをコアが受け取ること、偽アドレスへの接続を対応するインバウンドが捕捉すること、アウトバウンドへ送る前にマッピング記録からドメイン名を復元できることです。アドレスプールだけを有効にしてTUNの通信をコアへ取り込まない場合、アプリが 198.18.x.x を取得した後に接続できなくなります。

コアは偽IP宛ての接続を受け取ると、宛先がFakeDNSのアドレスプールに含まれるか確認します。マッピングテーブルに、たとえば 198.18.0.27 が example.net に対応する記録があれば、宛先をドメイン名へ戻せます。その後、ルーターは設定順にドメインルール、IPルール、ポートルール、インバウンドタグを確認し、最終的にプロキシまたはダイレクト接続のアウトバウンドを選択します。

ここでは「プロトコルスニッフィング」と「FakeDNSによる復元」を混同しないことが重要です。HTTP、TLS、QUICのスニッフィングは通信内容からドメイン名を識別しようとします。一方、FakeDNSの復元は、先に作成したマッピングを直接参照します。両者は併用できますが、マッピングの復元はすべての接続で識別可能なホスト名が露出することを前提としないため、ペイロードからドメイン名を取り出しにくい接続でも安定します。

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

この設定は、アドレスプールとDNSサーバーの概念的な関係だけを示したもので、インバウンド、ルーティング、アウトバウンドから切り離して単独で使用することはできません。クライアントが設定を生成する際は、TUNインバウンドで宛先の復元が有効になっていること、またローカルネットワークで同じアドレス範囲が実験機器や企業のテスト環境に使われていないことも確認してください。

FakeDNSが遅延とルーティングに与える実際の影響

FakeDNSの最も直接的なメリットは、「アプリが実DNSの応答を待つ」状態を「アプリがローカルの偽アドレスをすぐ取得する」状態に変えることです。リモートDNSへの往復時間が長い、最初のパケットがタイムアウトしやすい、複数のアプリが同時にキャッシュなし問い合わせを行うといった場合、この差が目立ちます。システムキャッシュにヒットしているドメイン名では、完全な名前解決の遅延を再度負担しないため、効果は小さくなります。

2つ目のメリットは、ドメイン名の情報を保持できることです。通常の名前解決では、アプリは実IPにだけ接続するため、TUNに入る時点で残るのが宛先アドレスだけになる場合があります。同じIPで複数のドメインがホストされていると、IPルールだけで正確に区別するのは困難です。FakeDNSが接続時に元のドメイン名を復元すれば、domain、domainSuffix、geosite などのルールをアウトバウンド選択前の判定に利用できます。

確認項目	通常のリモートDNS	FakeDNS	確認方法
最初に返されるアドレス	実際のA/AAAAレコード	予約済み範囲の偽IP	アプリ側の名前解決結果を確認
ドメイン名の情報	名前解決後はIPだけになる場合がある	マッピングテーブルで復元	ルーティングのヒットログを確認
キャッシュなし問い合わせの遅延	DNSの往復時間に左右される	通常はローカル応答	連続テストして中央値を比較
最終的な接続先	実IPまたはリモートDNSの結果	復元後のドメイン名	プロキシのアウトバウンドログを確認

3つ目の影響は、名前解決の出口をそろえやすくなることです。プロキシ経由にすべきドメインを、システムが先にローカルネットワークのDNSで解決してしまうと、名前解決の経路と通信経路が分離する可能性があります。FakeDNSでは、まずローカルで偽アドレスを割り当て、実際の名前解決をプロキシ側のアウトバウンドまで遅らせられるため、ローカルDNSがプロキシ対象ドメインの解決結果に与える影響を抑えられます。

FakeDNSではトラブルシューティングの方法も変わります。198.18.x.x が表示されても、すぐに名前解決エラーと判断しないでください。まず、そのアドレスが設定したプールに含まれるか、マッピング記録が存在するか、接続がTUNに入っているかを確認します。アプリが偽アドレスを受け取った後、コアがドメイン名を復元できない場合に初めて、経路の途中で問題が途切れていると判断できます。

TUNモードとルーティング規則の組み合わせ

TUNモードは仮想ネットワークアダプターを通じて、システムプロキシを自動的には使わないプロセスの通信を取り込みます。そのため、FakeDNSと組み合わせる代表的な入口です。v2rayNでは、まず「設定」→「パラメータ設定」でローカルのリッスンポートを確認してから、TUNモードを有効にします。TUN関連の項目はバージョンによって位置が変わる場合があるため、最終的にはステータスバーの表示とコアの起動ログを基準にしてください。

Android版のv2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。端末全体の通信を取り込む機能を有効にしたら、クライアント設定のローカルDNS、ドメインポリシー、ルーティングモードが同じ設定方針に基づいているか確認してください。別のローカルネットワークツールにVPNインターフェースを同時に使用させると、DNS問い合わせが現在のコアを迂回する可能性があります。

1. まずTUNによる取り込みを確認します。アプリ自身のHTTPまたはSOCKSプロキシ設定を無効にし、クライアントを起動してテスト用ドメインへアクセスします。その接続がコアのログに表示されることを確認してください。
2. 次に偽アドレスを確認します。キャッシュされていないドメイン名を問い合わせ、設定したプール内の 198.18.x.x アドレスが返されるか確認してください。
3. ドメイン名の復元を確認します。ルーティングログで偽IPだけでなく、元のドメイン名を探します。偽IPしか記録されていない場合は、宛先の復元設定を確認してください。
4. ルールのヒットを検証します。プロキシ対象のドメインとダイレクト接続のドメインをそれぞれテストし、想定したアウトバウンドタグへ振り分けられることを確認してください。
5. 最後にフォールバックをテストします。FakeDNSを無効にして通常のDNSへ戻し、設定に失敗した場合でも明確に利用できる代替経路が残ることを確認してください。

ルールの順序は特に重要です。偽アドレスは一時的な宛先にすぎません。広範なIPルールが先に 198.18.0.0/15 にマッチしてそのまま通過させると、ドメイン名が復元される前に誤った出口へ送られる可能性があります。より安全なのは、TUNインバウンドでFakeDNSの復元を完了させてからドメインルールで振り分け、LANや内部サービスを明示的に除外する方法です。

有効に向く場面と避けたい場面

有効化に向く代表的な環境は、TUNによる取り込みが安定しており、リモートDNSへの往復時間が長く、ドメインベースの振り分けルールが多く、アプリ通信がIPだけの状態でコアに入ることが多い場合です。このときFakeDNSはキャッシュなし問い合わせの待ち時間を短縮するだけでなく、ルーターが元のドメイン名を再び利用できるようにするため、数十ミリ秒の短縮にとどまらない効果があります。

ブラウザーでローカルのHTTPまたはSOCKSポートへ明示的に接続するだけなら、通常はブラウザーがドメイン名をそのままプロキシへ渡します。コアがすでにドメイン名を受け取っているため、FakeDNSによる振り分け精度の向上は小さいでしょう。この構成では、まず 10808、10809 などのリッスンポートが競合していないことを確認し、システムプロキシが正しいポートを向いているか確認してください。

• 有効化を推奨：TUNで全通信を取り込み、コアのログに宛先IPしか表示されないことが多い場合。
• 有効化を推奨：リモートDNSのキャッシュなし問い合わせが長期間50ミリ秒を超え、アプリの初回起動時に明らかな待ち時間がある場合。
• 慎重に有効化：組織内の内部ドメインをLANのDNSで解決する必要があり、地域やネットワークによって異なる名前解決結果が存在する場合。
• 慎重に有効化：実ネットワークですでに 198.18.0.0/15 または独自の偽アドレスプールを使用している場合。
• 効果は限定的：アプリが明示的なプロキシ経由でドメイン名を送信しており、ローカルDNSが現在のボトルネックではない場合。

ログに沿って検証とトラブル対処を行う

FakeDNSの検証は、Webページを開けるかどうかだけで判断すべきではありません。DNS応答、TUNによる捕捉、ドメイン名の復元、ルールのヒット、プロキシのアウトバウンドという5段階を一通り確認する必要があります。どれか1つでも欠けると、「たまに使える」「一部のアプリだけ動かない」といった結果になる可能性があります。

これまでアクセスしていないドメイン名を2つ選ぶことをおすすめします。1つはプロキシ経由、もう1つはダイレクト接続になるものを選びます。クライアント内部のDNSキャッシュを消去してから、それぞれ問い合わせを行い、返されたアドレスと時間を記録します。その直後に接続を確立し、ログで元のドメイン名、インバウンドタグ、アウトバウンドタグを確認してください。テスト中にノードを頻繁に切り替えると、ノードの違いをDNSの違いと誤認しやすくなります。

1. 現在のクライアント設定を記録し、ローカルSOCKSポートが 10808、HTTPポートが 10809 であること、または実際に設定した値を確認します。
2. TUNを起動した後、コアのログを確認します。仮想ネットワークアダプターが正常に作成され、ルート追加の失敗やインターフェースの占有に関するメッセージがないことを確認してください。
3. テスト用ドメイン名を問い合わせ、応答アドレスが設定したFakeDNSプール内にあることを確認します。応答時間は通常、リモートDNSへの往復時間より短くなるはずです。
4. 接続を開始し、ログから元のドメイン名を検索します。最終的な宛先が常に 198.18.x.x になっていないことを確認してください。
5. プロキシ対象のドメインが proxy に、ダイレクト接続のドメインが direct にマッチすることを確認し、前方にある広範なルールで上書きされていないか確認します。
6. 20回連続でテストし、それぞれ中央値と失敗回数を記録します。1回だけ出た最速値を結論の根拠にしないでください。

テストに失敗した場合は、逆の順番で切り戻します。まずドメインベースの振り分けルールを一時的に無効にし、基本のプロキシアウトバウンドへ到達できることを確認します。次にFakeDNSを無効にして通常のDNSへ切り替え、名前解決を確認します。最後にTUNを無効にし、明示的なシステムプロキシでローカルのリッスンポートを検証します。一度に1つの変数だけを変更することで、問題がアドレスプール、DNS、TUN、ルーティング、ノード経路のどこにあるか特定できます。

FakeDNSの本質的な価値は、一見特殊な名前解決結果を作ることではなく、全通信を取り込む環境でもドメイン名の情報を安定して保持できることです。正しく設定すれば、偽アドレスはローカルに一時的に存在するだけで、ルーティングは復元後のドメイン名を使い、プロキシのアウトバウンドはVMess、VLESS、サブスクリプションのノード設定に従って接続を確立します。有効化するかどうかは、DNS遅延、TUNによる取り込み方式、内部ネットワークの構成、振り分けの要件を総合して判断してください。