FakeDNSとは？仕組み・設定方法・利用シーン

FakeDNSの仕組み：仮想IPでドメイン名を保持する

通常のDNSは、ドメイン名を実際のサーバーIPアドレスに変換します。一方、FakeDNSは問い合わせられたドメイン名に仮想IPを割り当て、ローカルで「ドメイン名と仮想IP」の対応を保持します。たとえば、アプリがexample.comを問い合わせると、アドレスプール内のIPが返されることがあります。そのIPにアプリが接続すると、プロキシのコアが対応情報から元のドメイン名を特定します。このIPはWebサイトの実サーバーのアドレスではないため、そのままインターネット上の接続先にはできません。

この流れには2つの前提があります。DNS問い合わせが対応情報を管理するコンポーネントで処理されること、そして後続の接続がその対応情報を参照できる処理経路に戻ることです。前者だけでは、アプリは仮想IPを取得しても接続できません。後者だけでは、問い合わせに実IPが返されるため、FakeDNSで利用できる対応情報がありません。

ドメイン名を復元できれば、プロキシはドメインルールに応じて直結かプロキシ経由かを選べます。直結には通常、接続可能な実IPが必要です。プロキシ経由でドメイン名をリモート側の名前解決に渡せるかどうかは、出力プロトコルと設定によって異なります。FakeDNSが変えるのはローカルでの名前解決と識別の手順であり、最終的な接続先の名前解決を代替するものではありません。また、VMessやVLESSのプロトコル設定にも影響しません。

FakeDNS・TUN・トラフィックのスニッフィング、それぞれの役割

TUNは通信の入口、FakeDNSはアドレスの対応付け、スニッフィングは宛先の識別を担います。3つは同じ機能の切り替え設定ではありません。TUNが受け取るのは通常IPパケットです。アプリが別の場所ですでに名前解決していると、パケットにドメイン名が残っていない場合があるため、別途ドメイン名を識別する仕組みが必要になります。

FakeDNSは主に自身の対応情報を使ってドメイン名を復元するため、アプリが読み取れるHTTPホストヘッダーやTLSホスト名を送る必要はありません。ただし、アプリ独自の暗号化DNS、IPアドレスを固定した接続、独自のDNSキャッシュは、この対応経路を通らない可能性があります。「スニッフィングを有効にすればすべての接続にドメインルールが適用される」と考えないでください。

設定前に確認：コアとDNSの取り込み範囲

v2rayNはデスクトップクライアントで、利用できる設定は使用中のコアや動作モードによって異なります。v2rayNGはAndroid向けでXrayコアを使用し、v2flyNGはAndroid向けでV2Flyコアを使用します。クライアント名だけを根拠に、設定項目が同じだと判断しないでください。特に、TUNの通信入口とノードのプロキシ処理を別々のコンポーネントが担う場合があります。XrayのFakeDNS設定を、別のコンポーネントの設定にそのまま流用することはできません。

IPv4とIPv6は別々に確認してください。IPv4の仮想IPプールだけを設定していても、アプリが実際のIPv6アドレスを取得できる場合、別経路で接続されることがあります。必ずしも障害ではありませんが、想定とは異なる振り分けになる可能性があります。テスト結果を揃えるためだけに、システムのIPv6を安易に無効化しないでください。まず、クライアントがIPv6の対応する通信も捕捉できるか確認しましょう。

Xrayの設定例：アドレスプール・DNS・入口での復元

以下は設定項目の関係を示すXray JSONの抜粋であり、TUNの完全な設定例ではありません。トップレベルのfakednsアドレスプール、DNSのfakednsサーバー、SOCKS入口でのドメイン名復元設定を示しています。反映する前に、使用中のXrayバージョンがこれらの項目に対応していることを確認してください。既存のdnsやinbounds設定と項目ごとに統合し、現在の入口や出力先を上書きしないようにします。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": [
      "fakedns"
    ]
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "fakedns"
        ]
      }
    }
  ]
}

• poolSize: 65535は対応付けプールの容量設定であり、ノード数や通信速度を示すものではありません。長時間運用では、対応情報の有効期間とアプリのキャッシュが適切に連動していることが重要です。
• 127.0.0.1:10808はこの例のSOCKS入口であり、DNSの待ち受けポートではありません。システムのDNSにこのアドレスとポートを設定しても、DNSサービスが自動的に利用可能になるわけではありません。
• ここではdns.serversにFakeDNSだけを示しています。実際の運用では、コアが対応するルールに従って実IPを取得するための名前解決も設定してください。実IPが必要な問い合わせまで、すべて仮想IPプールに割り当ててはいけません。
• destOverrideのfakednsは、対応情報から宛先ドメイン名を復元する設定です。これだけでTUNアダプターが作成されたり、システムDNSがコアに取り込まれたりするわけではありません。

クライアントが設定を自動生成する場合、一時生成されたファイルを直接編集すると、再起動やノードの切り替え後に変更が失われることがあります。使用中のバージョンが用意するカスタム設定の入口を使うか、対応範囲内でDNSと入口の設定を調整してください。ルール項目を確認する場合は、まず設定ガイドをご覧ください。異なるコア向けの設定例を1つの設定ファイルに混在させないでください。

確認手順：DNS応答からルーティング結果まで追う

一度に変更する設定は1種類に絞り、元に戻せる状態を保ったうえで、次の順にテストしてください。確認するのは、仮想IPが表示されることだけではなく、処理経路全体がつながっていることです。遅延テストを1回行うだけでは、ドメインベースの振り分けが正しいとは判断できません。

1. 変更前の状態を記録する。テスト用のドメイン名を1つ決め、現在のDNS応答、接続の成否、適用されたルールと出力先を記録します。テスト中にノード、サブスクリプション、ルールセットを同時に変更しないでください。
2. 古いキャッシュを消去する。WindowsではPowerShellでClear-DnsClientCacheを実行し、テストするアプリを再起動します。このシステムコマンドでは、ブラウザー内部のキャッシュやプロキシコア独自の対応情報は消去されません。
3. 応答アドレスを確認する。問い合わせが設定したIPv4仮想IPプールを経由している場合、応答は198.18.0.0/15の範囲になります。実IPが返る場合は、ルーティングを変更する前にDNSの通信先を調べてください。
4. 実際に接続する。クライアントのログで宛先が想定したドメイン名に復元されているか、適用されたルールや出力先が正しいかを確認します。ログの項目はコアによって異なり、すべてのログレベルで対応情報の詳細が表示されるとは限りません。
5. 直結とプロキシ経由を個別にテストする。どちらの宛先にも接続できる必要があります。直結だけ失敗する場合は、実IPの名前解決と直結の出力設定を重点的に確認してください。仮想IPへの接続がすべてタイムアウトする場合は、接続を同じ対応処理経路に戻せているかを先に調べます。
6. 無効にした後の動作を確認する。このモードを無効にした後、システムとアプリのキャッシュをもう一度消去し、新しい問い合わせで古い仮想IPが再利用されないことを確認します。そうしないと、無効化後の接続失敗をネットワーク障害と誤認しやすくなります。

利用に向くケースと、設定を見送るべきケース

FakeDNSは、通信を透過的に捕捉し、ドメインルールに依存し、DNSを一元管理できる環境に適しています。プロトコルスニッフィングへの依存を減らせる一方で、対応情報の状態やキャッシュの整合性を保つ必要があります。現在の問題に応じて、利用するか判断してください。

• 導入を検討できるケース：TUNで通信を捕捉した後、ログにIPしか表示されずドメインルールが適用されにくい一方、システムとアプリの名前解決経路を管理できる。
• 現状を維持できるケース：ブラウザーが明示的なプロキシ設定でドメイン名を渡しており、現在のドメインベースの振り分けが安定していて、透過的な捕捉が不要。
• 先に確認が必要なケース：社内ネットワークでスプリットDNSを使っている、内部ドメインがある、またはルートが仮想IPプールと競合する。社内向けとインターネット向けの問い合わせを先に分けてください。
• 慎重にテストすべきケース：アプリがDNSの結果を長期間ディスクに保存する、IPアドレスをプロセス間で受け渡す、またはプロキシ終了後も古い接続を使い続ける。
• 改善を期待すべきではないケース：ノードに接続できない、サーバーの認証設定が誤っている、通信経路が混雑している。こうした問題はドメイン名の対応付けでは解決できません。

LANプリンター、ネットワークストレージ、社内サービスのドメイン名には、通常、ローカルネットワークの要件に合った名前解決を維持する必要があります。すべての問い合わせを一律に仮想IPへ置き換えると、実IPが必要なデバイス検出、アクセス制御、診断手順に支障をきたすことがあります。まず一部だけで検証し、結果を見てから範囲を広げましょう。関連する設定を一度にすべて有効にするより、問題を特定しやすくなります。

FakeDNSのよくある問題と対処手順

設定は順番に進めるのがおすすめです。まず通常のプロキシと実IPの名前解決を正常に動作させ、次にTUNによる通信の捕捉を確認し、最後にFakeDNSを導入します。各段階でログを保存し、元に戻せる設定を保つことで、名前解決、ルーティング、出力先への接続のどこに問題があるかを切り分けられます。