FakeDNSの仕組みを徹底解説：仮想IPでドメイン振り分けを高速化

FakeDNSで解決できる問題

通常のDNSモードでは、アプリが先にドメインを実際のIPへ解決し、そのIPに接続します。プロキシコアが接続を受け取る時点では、203.0.113.20:443のように宛先がアドレスだけになっている場合があります。同じアドレスで複数のドメインを運用していたり、サーバーアドレスが頻繁に変わったりすると、IPだけでルーティングルールを作る方法では誤判定が起きやすくなります。

FakeDNSは、実際のインターネット上のアドレスを提供するものではありません。アプリからDNS問い合わせを受けると、あらかじめ設定したアドレスプールから仮想IPを割り当て、「ドメインと仮想IP」の一時的な対応表を保存します。アプリがこの仮想アドレスへ接続すると、TUNインバウンドが接続を捕捉し、プロキシコアが対応表から元のドメインを取得します。そのためルーティングモジュールは、domain、domainSuffix、またはルールセットに記録されたドメインを直接照合できます。

一般的なIPv4アドレスプールは198.18.0.0/15です。このアドレス帯はネットワーク機器のベンチマークテスト用で、インターネット上のルーティングには使用されないため、端末内の仮想宛先に適しています。/15には131072個のアドレスが含まれますが、Xrayの設定では通常、poolSize: 65535のように小さめのマッピングプールを指定し、実用性のない巨大な対応表の作成を避けます。

上記の1～3ミリ秒は、同じAndroid端末でキャッシュされていないドメインを連続検索した場合の端末内応答時間です。FakeDNSが仮想アドレスを返すまでの時間を示すもので、ウェブページ全体の読み込み速度を表すものではありません。実際の接続には、ノードとのハンドシェイク、リモートでの名前解決、TLS接続、データ転送が必要です。

ドメインリクエストが仮想IPマッピングを通過する流れ

完全な通信経路は6段階に分けられます。まずアプリがシステムDNSへAまたはAAAA問い合わせを送ります。次にTUNモードがDNSトラフィックをプロキシコアへ渡します。FakeDNSはアドレスプールから未使用のアドレスを取り出し、対応表へ登録します。アプリは仮想アドレスを受け取ってTCPまたはUDP接続を開始します。インバウンドは宛先アドレスからドメインを逆引きします。最後にルーティングモジュールがドメインに基づいて、直接接続、プロキシ、ブロックのいずれかを決定します。

1. 問い合わせをプロキシコアへ渡す：DNSリクエストはTUNまたは制御対象のローカルDNSで捕捉される必要があります。アプリが外部DNSへ直接接続すると、FakeDNSはその問い合わせを取得できません。
2. 一時的なマッピングを作成する：たとえばnews.exampleに198.18.0.12を割り当てます。この対応は端末内のメモリ上だけで有効です。
3. アプリが仮想アドレスへ接続する：アプリは198.18.0.12を通常の宛先アドレスとして扱い、FakeDNSの仕組みを理解する必要はありません。
4. インバウンドでドメインを復元する：コアは対応表からnews.exampleを取得し、そのドメインをスニッフィングとルーティングモジュールへ渡します。
5. ルーティングルールを適用する：ドメインルールは実際のDNS問い合わせが行われる前に接続先を決定できるため、「先に解決してから判定する」ことによる情報不足を減らせます。
6. アウトバウンドで名前解決を完了する：直接接続では通常、ローカルで実際のアドレスを解決します。ドメイン宛先に対応したプロキシアウトバウンドでは、ドメインをリモート側に渡して処理させることもできます。具体的な動作は、アウトバウンドのプロトコルとDNS設定によって異なります。

Xray設定の主要フィールド

Xrayの設定には通常、連携する3つの部分があります。トップレベルのfakednsでアドレスプールを定義し、dns.serversで問い合わせをFakeDNSへ渡し、インバウンドのsniffing.destOverrideでコアが仮想アドレスの対応表から宛先ドメインを復元できるようにします。どれか1つだけ追加しても、完全な通信経路にはなりません。

以下はフィールド間の関係を説明するための最小構成例です。クライアントが設定を生成する際は、ローカルDNS、ルールセット、複数のインバウンドが追加される場合があります。編集前に現在の設定をエクスポートし、使用中のクライアントが基盤となるJSONのカスタマイズに対応しているか確認してください。サブスクリプションの更新で、手動変更したノードパラメータが上書きされることがあります。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": [
      "fakedns",
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  },
  "inbounds": [
    {
      "tag": "tun-in",
      "protocol": "tun",
      "settings": {
        "stack": "system"
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "quic",
          "fakedns"
        ],
        "metadataOnly": false
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  }
}

destOverride内のfakednsは対応表の読み取りに使います。http、tls、quicは、それぞれのプロトコルメタデータからドメインを補完します。両者は競合しません。対応表は問い合わせ済みのドメインを直接示せます。一方、プロトコルスニッフィングはFakeDNSを経由していなくても、ハンドシェイクにホスト名が含まれる接続を処理できます。

v2rayNGでXrayコアを使用する場合は、TUNとローカルDNSをクライアントの画面から管理することをおすすめします。一般的な確認手順は、「設定」→「VPN設定」で通信の取り込みに関する項目を確認し、「設定」→「ルーティング設定」でルールの順序を確認することです。バージョンによってスイッチ名が変わる場合があるため、動作確認は画面上の状態だけでなく、エクスポートした実行設定とコアログを基準にしてください。

FakeDNSを有効にするのに適した場面

FakeDNSは、TUNで端末全体の通信を取り込み、主にドメイン単位でルーティングルールを記述している環境に最適です。Androidアプリは、先に自分でドメインを解決し、実際のIPをネットワークスタックへ渡すことがよくあります。TUNから宛先IPしか見えない場合、ドメインルールの適用率はスニッフィング結果に左右されます。FakeDNSを追加すると、DNS問い合わせと後続の接続が対応表で結び付くため、ルーティングをより直接的に判断できます。

• 大量のドメイン振り分け：数千件のドメインサフィックスやルールセットを含む場合、接続確立前に対象ドメインを明確にする必要があります。
• 共有アドレスのサービス：複数のサイトが同じサービスアドレス群を共有している場合、IPだけではサービスのドメインを安定して区別できません。
• アドレスが頻繁に変わる場合：サーバーが動的な振り分けによって異なるアドレスを返す場合、固定IPルールはすぐに使えなくなります。
• リモート名前解決が必要な場合：プロキシアウトバウンドでドメインを保持し、ノード側のネットワークに最終的な名前解決を任せたい場合に適しています。
• UDPおよびQUICトラフィック：アプリがUDP 443を使用する場合、FakeDNSマッピングとQUICスニッフィングによって宛先情報を補完できます。

v2rayNのシステムプロキシモードだけを使う場合、ブラウザーは通常、宛先ドメインをローカルのSOCKSまたはHTTPインバウンドへ直接渡します。この場合、コアはすでにドメインを取得しているため、FakeDNSを有効にしても明確な効果がないことがあります。必要性は、インバウンドの種類とログに表示される宛先形式から判断してください。

LANに特殊なルーティングがある場合も注意が必要です。一部の研究環境、仮想化プラットフォーム、企業向け機器では、性能テストや内部シミュレーションに198.18.0.0/15を使うことがあります。システムのルーティングテーブルがこのアドレス帯を実際のインターフェースへ向けていると、FakeDNSのアドレスが既存ネットワークと重なり、接続がTUNに入らずLANへ送られることがあります。

FakeDNS、スニッフィング、TUNの連携方法

TUNの役割はIPパケットを捕捉すること、FakeDNSの役割はドメインと仮想アドレスの関係を保存すること、スニッフィングの役割はHTTP Host、TLS Server Name、QUICハンドシェイクからドメインを抽出することです。3者が解決する問題はそれぞれ異なります。順序どおりに接続して初めて、ドメインルールでより多くのアプリ通信をカバーできます。

まず最小限の動作経路を構築し、その後で高度な設定を1つずつ追加してください。アドレスプール、DNSサーバー、ルーティングルール、MTUを一度に変更すると、障害の原因を切り分けにくくなります。以下の手順は、v2rayNGのXrayコア設定だけでなく、サブスクリプションから生成された実行設定の確認にも適しています。

1. 「設定」→「VPN設定」でTUNまたはVPNによる通信の取り込みが有効になっていることを確認し、対象アプリがアプリ単位のルールで除外されていないか確認します。
2. 接続を開始したらコアログを確認し、TUNインバウンドが存在すること、アドレス競合や権限エラー、インターフェース作成エラーがないことを確認します。
3. 実行設定のfakednsアドレスプールを確認し、DNSサーバー一覧にFakeDNSの処理項目が含まれていることを確認します。
4. インバウンドのスニッフィングが有効で、destOverrideに少なくともfakednsが含まれていることを確認します。ウェブトラフィックを識別する必要がある場合は、http、tls、quicも残します。
5. 「設定」→「ルーティング設定」でルールの順序を確認します。ブロックルール、プライベートアドレスルール、直接接続ルールが前にあると、対象ドメインのルールより先に適用される場合があります。
6. まだアクセスしていないテストドメインで接続を開始し、ログに仮想アドレス、復元されたドメイン、最終的なアウトバウンドタグが順番に表示されるか確認します。

MTUの問題とFakeDNSは異なる層の問題です。ドメインが正しく復元されているのにページが少ししか読み込まれない、または大きなファイルの転送が止まる場合は、TUNのMTUを確認してください。Android端末では1500から1400または1380へ変更して比較テストし、毎回1つの値だけを変更します。すべてのドメインで接続を確立できない場合は、DNSの捕捉とアドレスプールのルーティングに戻って調べます。

MuxもFakeDNSの代わりにはなりません。Muxは1本の基盤接続で複数の論理接続を運ぶ仕組みで、主に接続の再利用に影響します。FakeDNSは宛先ドメインを保持します。Muxの有効・無効によって仮想アドレスマッピングの作成可否が変わることはありませんが、接続数やログの表示方法は変わる場合があります。

よくある障害と段階的な切り分け

FakeDNSの障害は通常、3種類に分かれます。アプリが仮想IPを受け取った後に接続できない、ドメインルールが適用されない、クライアントを終了してもしばらくアクセスできない、という症状です。1つ目はTUNが仮想アドレス帯を捕捉しているか、2つ目はマッピングとルール順序、3つ目はシステムDNSキャッシュに残った仮想アドレスを優先して確認します。

トラブルシューティングでは、ブラウザーの結果だけを見ないでください。コアログで少なくとも4点を確認します。DNS問い合わせがクライアントに入っているか、仮想アドレスが割り当てられたか、インバウンドがドメインを復元したか、ルーティングが最終的にどのアウトバウンドを選んだか、の4点です。どこかが欠けていれば、ノードやプロトコルを同時に入れ替えるのではなく、該当するモジュールに戻って修正します。

「名前解決が速い」ことと「接続が速い」ことも区別してください。FakeDNSのローカル応答は数ミリ秒で完了しますが、プロキシノードの遅延、TCPパケットロス、TLSハンドシェイク、サーバーの応答がページ速度を左右します。仮想マッピングとルーティングが正しい場合、速度の問題はノード遅延、パケットロス率、転送パラメータを引き続き確認してください。