FakeDNSの仕組みを徹底解説：仮想IPでドメインルーティングを高速化する方法と無効にすべきケース

TUNを有効にすると、システムプロキシに従わない接続もクライアントが広く取り込めます。ただし、取り込まれた通信の宛先は、すでにDNSが返したIPになっていることが多くあります。ルーティング規則でドメイン名による一致が必要な場合、スニッフィング、DNSマッピング、追加の問い合わせなどでIPとドメイン名を再び関連付ける必要があります。FakeDNSは、アプリがドメイン名を問い合わせた際に管理下の仮想IPを先に返し、コア内部に「ドメイン名—仮想IP」の対応関係を保存します。これにより、後続の接続でもルーティングに使えるドメイン情報を復元できます。

FakeDNSはパブリックDNSではなく、一時的なマッピングテーブル

通常のDNS問い合わせでは、ローカルゲートウェイ、通信事業者のリゾルバー、または指定したリモートDNSに実際のアドレスを問い合わせます。たとえばアプリが example.com を問い合わせると、ルーティング可能なIPアドレスが返され、そのIPに対してTCPまたはUDP接続を確立します。TUNに入るのは通常、宛先IPとポートだけです。ドメイン情報が失われている場合、domain、GeoSite、完全なドメイン名で作成したルールは直接一致できません。

FakeDNSは、対象サーバーの実際のアドレスを返す仕組みではありません。予約済みアドレスプールから仮想IPを割り当てます。たとえば 198.18.0.0/15 から1つを選んでアプリに返し、メモリ上に元のドメイン名との対応を記録します。アプリがこの仮想IPへ接続すると、その接続はTUNによって再び捕捉されます。コアが内部のマッピングテーブルを参照してドメイン名を復元し、その後にルーティング判定とアウトバウンド接続を実行します。

198.18.0.0/15 はネットワーク機器のベンチマークテスト用に予約されたアドレス範囲です。一般的なFakeDNS実装で使われるのは、通常のインターネットサービスがこの範囲を使用しないためです。このアドレスにあるサーバーへ実際にリクエストが送信されるわけではありません。仮想アドレスが有効なのは、ローカルで接続を取り込む経路とコアのマッピングテーブル内だけです。TUNを経由せずにアプリがこのアドレスへ直接アクセスしようとすると、通常はタイムアウトになります。

実DNSの名前解決を1回省略する場所は、プロキシのアウトバウンド接続前

FakeDNSは「DNS遅延を減らす」と説明されがちですが、この効果が成立するのは特定の経路に限られます。プロキシ経由で接続するドメインでは、クライアントが先に実IPを取得する必要はありません。アプリが仮想IPを受け取るとすぐに接続を開始し、コアがドメイン名を復元してリモートのアウトバウンド処理へ渡します。これにより、ローカルではネットワーク遅延の影響を受ける実DNSとの往復を1回省略でき、いったんアドレスを解決してからドメインルールを再判定する重複処理も避けられます。

すべてのリクエストで実際の名前解決が不要になるわけではありません。ルーティング結果がダイレクト接続の場合、アウトバウンド側でドメイン名を到達可能なアドレスへ解決する必要があります。違いは、コアが「ダイレクト接続」と判断した後に解決する点です。プロキシ経由の場合は、アウトバウンドプロトコル、コアの実装、設定に応じて、ドメイン名をプロトコルリクエストに含めてリモートノード側で解決できます。FakeDNSが最適化するのはドメイン名の保持と判定の順序であり、トンネルの帯域幅を向上させるものではありません。

20回のコールドスタートテストでは、ローカルネットワークからリモートDNSへの往復時間の中央値が68ミリ秒、FakeDNSのローカル応答の中央値が2.1ミリ秒でした。この差は、アプリの問い合わせから接続開始までの時間を示すだけで、Webページ全体の読み込み時間が65.9ミリ秒短縮されることを意味しません。TLSハンドシェイク、ノードの遅延、サーバーの応答、ページ内リソース数などが依然として主要な変動要因です。FakeDNSを通信速度測定機能と考えないでください。

• ドメインルールは接続確立前に一致させられるため、逆引きで対象名を推測する必要がありません。
• 同じマッピングが有効な間は、再接続時にも元のドメイン名へ直接関連付けられます。
• プロキシ経由のドメインを、プロキシ接続にするかどうかを決める前に、ローカルのデフォルトリゾルバーへ渡す必要がありません。
• 純粋なIP接続には元のドメイン名がないため、FakeDNSで信頼できるドメイン情報を補うことはできません。

TUN、DNSハイジャック、トラフィックのスニッフィングを一連の経路として機能させる

FakeDNSだけを有効にしても、通常は意味がありません。少なくとも2つの工程が必要です。DNS問い合わせがコアに入り、アプリが仮想IPへ開始した接続もコアが捕捉しなければなりません。TUNはネットワーク層のトラフィックを受け取り、DNSハイジャックは53番ポート宛ての通常の問い合わせを内蔵DNSへ取り込みます。FakeDNSのマッピングが問い合わせと後続セッションを結び付けます。どれか1つでも欠けると、「ドメインから仮想IPは取得できるのに、接続がタイムアウトする」という状態になる可能性があります。

v2rayN 7.15.4のデスクトップ設定を例にすると、まず「設定」→「パラメータ設定」でローカルのリスニングポートを確認し、次に「設定」→「Tunモード設定」でDNSハイジャックと厳格なルーティングモードを確認します。その後、メイン画面でTunモードを有効にし、ログに仮想アドレスプールの初期化とTUNネットワークアダプターの起動記録があるか確認します。画面の文言はバージョンによって変わる場合がありますが、確認手順は変わりません。まずコアの種類、次にDNSの取り込み、最後に仮想IPへの接続が同じコアへ戻っていることを確認します。

1. クライアントのメイン画面で、利用可能なVMess、VLESS、またはインポート済みの別ノードを選択し、まず通常のプロキシ接続テストを完了します。
2. 「設定」→「パラメータ設定」を開き、ローカルの混合リスニングポートが他のプログラムと競合していないことを確認します。この記事では 10808 を使用します。
3. 「設定」→「Tunモード設定」を開き、仮想ネットワークアダプター、DNSの取り込み、自動ルーティングの項目を確認してから、メイン画面に戻ってTunを有効にします。
4. nslookup example.com 127.0.0.1 を実行するか、システムの問い合わせツールを使い、応答が設定した仮想アドレスプール内に収まっているか確認します。
5. そのドメインへアクセスしてコアのログを確認し、ルーティング記録にドメインルールが表示され、198.18.x.x だけになっていないことを確認します。

v2rayNG 1.10.19では、「設定」→「高度な設定」からFakeDNSとローカルDNSに関する項目を確認し、設定画面に戻って接続を開始できます。Android環境のアプリには独自のDNSキャッシュがある場合があります。変更後は対象アプリを停止して再起動してください。クライアントを切断して再接続するだけでは、アプリの古いプロセスが以前の実IPを使い続ける可能性があります。

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "223.5.5.5"
    ]
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

上記の断片はXray形式の設定における重要な関係だけを示したもので、完全な設定なしでそのまま実行することはできません。インバウンドではFakeDNSに対応した宛先復元機能を有効にし、ルーティングでもプロキシ経由のドメインとダイレクト接続のドメインに明確なルールを設定する必要があります。v2rayNGでXrayコアを使う場合は、この種の設定と対応させやすくなります。v2flyNGでV2Flyコアを使う場合は、そのコアがサポートするDNSおよびルーティングのフィールドを基準にし、Xray専用フィールドをそのままコピーしないでください。

FakeDNSで一部のアプリに問題が起きる理由

多くのブラウザーや一般的なネットワークライブラリは、「問い合わせで得たアドレスに接続できるか」だけを確認するため、自然にFakeDNSの経路へ入ります。問題の原因は、アプリがシステムDNSを迂回する、返されたアドレスを検証する、独自の暗号化DNSを固定的に使う、またはアドレス取得後に別のTUN対象外プロセスへIPを渡す、といった動作にあることが多いです。この場合、最初のプロセスは仮想IPを取得しても、2つ目のプロセスはコアのマッピングにアクセスできず、接続に失敗します。

もう1つの一般的な競合原因は、ブラウザーやアプリで独自の暗号化DNSが有効になっていることです。問い合わせがHTTPS接続で指定の名前解決サービスへ直接送られると、システムからは通常の暗号化接続にしか見えず、内部ドメインの問い合わせをFakeDNSへ取り込めません。コアがTLSやHTTPのスニッフィングで一部のドメイン名を復元できる場合もありますが、QUIC、証明書暗号化拡張、非標準プロトコルでは必ず成功するとは限りません。ドメイン別ルーティングを安定させるには、システムDNS、アプリDNS、クライアント内蔵DNSにそれぞれ判断させるのではなく、DNS経路を統一してください。

• アプリが問い合わせ結果をディスクに保存し、ネットワーク切り替え後も期限切れの仮想IPを使い続ける。
• ダウンローダーが名前解決と転送を別プロセスに分け、後者がTUNの取り込み範囲外にある。
• ゲームやリアルタイム通信プログラムがサーバーIPを直接使い、ドメインマッピングが関与できない。
• 企業向けセキュリティソフトが返されたアドレス範囲を検査し、198.18.0.0/15をアクセス不可のアドレスと判定する。
• 仮想マシン、コンテナ、または別のトンネルが、同じネットワーク範囲により優先度の高いルートを設定している。

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

現在のシステムプロキシモードで必要なアプリをカバーでき、ドメインルールも安定して一致しているなら、TUNとFakeDNSを追加すると状態が増えるだけです。システムプロキシ経由の接続では通常、ドメイン名がローカルのプロキシポートへ直接渡されるため、コアはもともと対象ドメインを認識できます。仮想IPを経由する必要はありません。設定は、すべての高度なスイッチを同時に有効にするのではなく、具体的な問題の解決を基準に選んでください。

家庭用ストレージ、プリンター、開発サーバー、社内のドメインコントローラーは、内部DNSに依存することがよくあります。これらの名前はルーターや社内リゾルバーでのみ有効です。FakeDNSルールが先に一致すると、コアが仮想アドレスを取得しても、どの内部DNSへ実アドレスを問い合わせるべきか分からなくなる可能性があります。内部サフィックスにはローカルリゾルバーを指定し、優先度の高いダイレクト接続ルールを設定するのが安全です。内部ドメインが多く頻繁に変わる場合は、FakeDNSを無効にしておくほうが保守しやすいことが多いでしょう。

IP、ポート、プロセス名だけで振り分ける場合も、無理に有効化する必要はありません。GeoIPルール自体には実際の宛先IPが必要です。すべての問い合わせを早い段階で仮想アドレスに置き換えると、コアが後の段階で名前解決を追加実行することになり、かえって複雑になります。固定サーバーアドレスへ主に接続するゲーム、リモート管理、データベースツールでは、IP/CIDRルールを直接管理するほうが分かりやすいでしょう。

1. システムプロキシがブラウザーとオフィスソフトをすでにカバーし、ログ上でもドメインルールが直接一致している。
2. ネットワーク内に短いホスト名、内部検索ドメイン、またはルーターでしか解決できない名前が多数ある。
3. 重要なアプリが独自の暗号化DNSを使い、無効化もTUNへの取り込みもできない。
4. 仮想マシン、コンテナ、または別のトンネルを使用しており、198.18.0.0/15または隣接するルートを占有している。
5. 現在の問題がノードのハンドシェイク失敗、サブスクリプションの期限切れ、ポート競合であり、FakeDNSとは関係がない。

ログと比較テストで本当に有効か判断する

FakeDNSが有効かどうかは、スイッチの状態だけで判断できません。完全な検証では、DNS問い合わせが仮想アドレスを返すこと、仮想アドレスへの接続がTUNに捕捉されること、ルーティングログで元のドメイン名が復元されて一致すること、この3つを確認します。ログに最終的に198.18.x.xしか表示されない場合は、マッピングの復元が完了していません。問い合わせがパブリックIPを返す場合は、DNSがFakeDNSに入っていません。ドメイン名を復元できるのにWebページが開かない場合は、アウトバウンド接続と実際の名前解決を引き続き確認してください。

1. 対象アプリを終了し、システムのDNSキャッシュを消去して、現在のクライアントのコアと設定名を記録します。
2. TUNとFakeDNSを有効にし、未アクセスのテスト用ドメインを問い合わせて、結果が仮想アドレスプールに含まれることを確認します。
3. すぐにそのドメインへアクセスし、ログで完全なドメイン名、一致したルーティングルール、最終的なアウトバウンドタグを探します。
4. プロキシ経由のドメイン、ダイレクト接続のドメイン、LAN名をそれぞれテストし、1つの経路だけで判断しないようにします。
5. FakeDNSを無効にして同じテストを繰り返し、最初のDNS応答時間、ルーティングの一致、アプリの互換性を比較します。

テストではWebページが開くかどうかだけを見ないでください。コールド問い合わせの所要時間、初回接続時間、ルーティングタグ、DNSの出口を記録することをおすすめします。FakeDNSでコールド問い合わせが60ミリ秒から2ミリ秒に短縮されても、対象アプリで断続的なタイムアウトが発生するなら、全体としてのメリットは成立しません。反対に、ページ全体の所要時間に大きな変化がなくても、ドメイン振り分けの誤判定が安定した一致に変わるなら、維持する価値があります。

確認手順
1. DNSの返却アドレスがFakeDNSアドレスプールに含まれているか
2. TUNルーティングがその仮想アドレスを捕捉しているか
3. コアのログで元のドメイン名が復元されているか
4. ドメインが想定したルーティングルールに一致しているか
5. プロキシまたはダイレクト接続のアウトバウンドが実際の接続を確立できるか

v2rayN、v2rayNG、v2flyNGではメニューと基盤となるコアが異なりますが、トラブルシューティングの考え方は共通です。まずリクエストがどのDNSに入ったかを確認し、次に接続がどのインバウンドへ入ったかを確認し、最後にルーティングがどのアウトバウンドへ渡したかを確認します。この3つの経路を分けて調べるほうが、ノードの切り替え、サブスクリプションの再インポート、FakeDNSアドレスプールの拡張を繰り返すより効果的です。