上級テクニック 読了目安 12分

FakeDNSによる仮想DNSマッピングの仕組み：有効にすべき場面・避けるべき場面

FakeDNSが実アドレスの代わりに予約済みアドレス帯を使う仕組みを解説。DNSの往復を1回減らす理由と、TUNモードで有効・無効にすべき具体例を紹介します。

FakeDNSが解決するのは「より正確な名前解決」ではなく、ドメイン情報の喪失です

アプリがドメインへアクセスすると、通常はまずDNSに実アドレスを問い合わせ、その後に返されたIPへ接続します。プロキシコアに入る接続に宛先IPしか残っていない場合、ドメイン情報がすでに失われている可能性があります。この状態では、geositeや完全修飾ドメイン名、ドメインサフィックスで記述したルーティングルールを直接適用できず、宛先IPやプロトコルのスニッフィング結果など、別の情報に頼ることになります。

FakeDNSは、DNSの段階で一時的な仮想アドレスを返し、コア内部に「ドメイン名—仮想アドレス」の対応関係を保存します。アプリがその後に仮想アドレスへ接続すると、コアは元のドメイン名を逆引きし、ドメインルールに従って直接接続、プロキシ、遮断を選択できます。本質的には短期間だけ有効なマッピングテーブルであり、パブリックDNSサービスではありません。仮想アドレスをインターネットへ公開することもありません。

Xrayでよく使われるFakeDNSのアドレスプールには、198.18.0.0/15のような専用の予約済みIPv4ネットワークが使われます。このアドレス帯が実際の接続先サイトのアドレスになることはありません。ローカルまたは管理下のネットワークスタック内で、インデックスとして機能するだけです。アドレスプールの範囲や容量、処理方法はコアの設定とクライアントのバージョンによって異なるため、特定のデフォルト値がすべての環境で固定されていると考えてはいけません。

1つのリクエストが仮想アドレスへマッピングされる流れ

v2rayNのTUNモードで、ブラウザがdocs.example.netへアクセスする場合を考えます。FakeDNSを有効にし、DNSトラフィックもTUNが引き受けていると、全体の流れはおおむね次の6段階に分かれます。

  1. アプリがシステムへdocs.example.netのDNSクエリを送信します。
  2. TUNネットワークスタックがクエリを捕捉し、コア設定のDNS処理チェーンへ渡します。
  3. FakeDNSがアドレスプールから仮想IPを割り当て、そのIPに対応する元のドメイン名を記録します。
  4. アプリが仮想IPを受け取り、通常のアドレスへ接続する場合と同じようにTCPまたはUDP通信を開始します。
  5. TUNがこの接続を再び捕捉します。コアはマッピングテーブルを参照し、docs.example.netを復元します。
  6. ルーティングモジュールがドメインルールに従ってアウトバウンドを選択し、実際に必要な名前解決は該当するアウトバウンド経路で引き続き行われます。
アプリがドメインを問い合わせる
    ↓
TUNがDNSを捕捉
    ↓
FakeDNSが仮想IPを返し、マッピングを保存
    ↓
アプリが仮想IPへ接続
    ↓
コアが元のドメイン名を復元
    ↓
ドメインルールにマッチ → 直接接続またはプロキシのアウトバウンドを選択

ここでいう「DNSの往復を1回減らす」とは、アプリが接続を確立する前に、パブリックDNSの上流サーバーから実IPが返るのを待たなくてよいという意味です。FakeDNSはローカルですぐにマッピング結果を返せます。ただし、アクセス全体で名前解決が完全になくなるわけではありません。プロキシのアウトバウンドがドメイン名をリモート側で解決することもあれば、直接接続のアウトバウンドが設定されたDNSを呼び出すこともあります。省略されるのは前段階の実アドレス問い合わせ1回であり、すべての経路における名前解決ではありません。

マッピングには有効期間があります。キャッシュの期限切れ、コアの再起動、設定の再読み込み、アドレスプールのエントリ回収などが起きると、古い仮想アドレスは対応関係を失う可能性があります。そのため、FakeDNSの返却値を長期的な業務データとして保存したり、別の端末へコピーして使ったりするのは適切ではありません。

FakeDNS、スニッフィング、実DNSの役割分担

ドメイン名のスニッフィングとFakeDNSは同時に使われることがありますが、ドメイン名を取得するタイミングは異なります。スニッフィングは接続がすでにコアへ入った後、HTTPリクエストのHostやTLSハンドシェイクのサーバー名など、プロトコルデータから宛先名を抽出します。一方FakeDNSはそれより早く介入し、アプリがDNSを問い合わせた時点で確実なマッピングを作成します。

スニッフィングは、通信内に識別可能なフィールドが存在することを前提とします。プロトコルの挙動が変わった場合、暗号化ハンドシェイクの形式が変化した場合、アプリがIPへ直接接続した場合、または最初のパケットに利用可能なドメイン名が含まれない場合、結果が空になることがあります。FakeDNSは業務データからドメイン名を推測する必要がありません。DNSクエリと後続の接続が同じ管理下のネットワークスタックを通れば、マッピングテーブルから名前を復元できます。

実DNSは、最終的に接続可能な宛先アドレスを見つける役割を担います。FakeDNSは「アプリが先に解決し、その後に実IPへ接続する」という順序を、「アプリが仮想IPを取得し、コアがドメイン名を復元し、アウトバウンド段階で解決する」流れへ変更します。これにより、名前解決の場所をルーティング結果に合わせられます。プロキシ対象のドメインはプロキシ経路で、直接接続対象のドメインはローカルで選択したDNSで処理できるため、名前解決の場所と実際のアウトバウンド位置がずれる問題を減らせます。

仕組み ドメイン名を取得する段階 主な用途 主な制約
FakeDNS DNSクエリの段階 ドメイン名と後続接続の対応を保持 クエリと接続が同じ処理チェーンを通る必要がある
プロトコルスニッフィング 接続がコアへ入った後 識別可能なプロトコルフィールドからドメイン名を復元 すべての通信から名前を抽出できるわけではない
実DNS 接続前またはアウトバウンド段階 最終的な宛先アドレスを取得 結果は問い合わせ場所とキャッシュの影響を受ける

TUNモードで有効にしやすい場面

ドメイン名に基づく細かなルーティング

ルールが主にgeosite、ドメインサフィックス、完全修飾ドメイン名に依存する場合、FakeDNSは特に効果を発揮します。アプリが実IPしかネットワークスタックへ渡せない場合でも、コアは仮想アドレスのマッピングからドメイン名を復元できます。「指定サイトはプロキシ、よく使うローカルドメインは直接接続、その他はデフォルトルール」という構成では、ドメイン情報が安定するほどマッチ結果を説明しやすくなります。

名前解決の場所をアウトバウンドに合わせたい

同じドメインでも、ネットワーク上の場所によって異なるアドレスが返されることがあります。先にローカルDNSで解決し、実IPをプロキシ経路へ渡すと、名前解決の場所と接続場所が分離する可能性があります。FakeDNSなら、アプリはまず仮想アドレスを受け取り、コアがアウトバウンドを決めた後で実際の名前解決を処理できます。ドメイン名の解決をプロキシ側に任せたい接続では、この順序が通常より適しています。

個別のプロキシ設定に対応しないプログラムを取り込む

TUNモードは、HTTPまたはSOCKSプロキシの設定項目を持たないプログラムの通信も引き受けられます。このときFakeDNSとTUNを組み合わせることで、プログラムの通常のシステムDNSクエリと後続接続を同じ処理経路へ入れられます。プログラムがシステムネットワークスタックに従い、通信が実際に捕捉されていれば、ドメインルールはより十分な条件でマッチできます。

プロトコルスニッフィングへの依存を減らす

スニッフィングは補助情報として利用できますが、ドメイン名の復元を単独で担わせる必要はありません。接続確立が速いアプリ、最初のパケットの特徴が安定しないアプリ、UDP通信を使うアプリでは、事前に作られたFakeDNSマッピングの方が直接的です。ただし、FakeDNSによってすべてのUDPプロトコルが自動的に互換になるわけではありません。FakeDNSが担当するのは宛先のマッピングだけであり、現在のアウトバウンド経路でそのプロトコルを転送できるかどうかは、ノード、コア、ルーティング設定に左右されます。

FakeDNSを無効化または迂回すべき場面

LAN名や分流DNSが実際の結果に依存する

企業内ネットワーク、家庭内デバイス名、ルーター管理用ドメイン、地域別DNSは、プライベートアドレスを返すLAN内のリゾルバーに依存することがよくあります。これらのクエリをFakeDNSが先に置き換えると、アプリがサービス検出に必要な実レコードを取得できなくなる可能性があります。通常は、イントラネットのドメイン、プライベートアドレス帯、指定DNSサーバーを直接接続にし、FakeDNSのルールから除外します。除外関係を確認しにくい場合は、FakeDNSを無効にしてからLANアクセスを検証する方が安全です。

アプリがDNSの返却内容を読み取る、または検証する

一部の診断ツール、ネットワーク管理プログラム、DNS解決テストツール、業務クライアントは、アドレスを受け取って接続するだけでなく、DNS応答を表示、保存、比較、検証します。これらはA、AAAAなどのレコードに含まれる実データを必要とします。仮想アドレスはこうしたプログラムが観測するデータを変えてしまうため、関連する問い合わせには適していません。

接続が同じTUNマッピングチェーンを通らない

FakeDNSの前提は「問い合わせ時にマッピングを書き込み、接続時にマッピングを読み取る」ことです。DNSクエリは捕捉されても後続接続がTUNを迂回すると、アプリは仮想アドレスを通常のネットワークへ直接送ろうとします。逆に接続がTUNへ入っても、DNSクエリが別の端末や独立した暗号化解決経路で処理されると、コアがマッピングを取得できないことがあります。2つの経路が一致しない場合は、まず捕捉範囲を統一し、統一できなければFakeDNSを無効にしてください。

名前解決の結果を別の端末へ渡す必要がある

仮想アドレスは、それを生成したマッピングインスタンス内でのみ有効です。そのアドレスを設定ファイルへ書き込んだり、LAN上の別ホストへ送ったり、ポートスキャンに使ったり、コアの再起動後も再利用したりすると、失敗する可能性があります。ルーター配下の分散構成では、DNS応答と後続接続が常に同じインスタンスへ戻ることを特に確認してください。クライアントが別のゲートウェイへ切り替える可能性がある場合は、実アドレスを返す方が動作を一貫させやすくなります。

トラブル対応で元の名前解決経路を確認したい

問題が上流DNS、分流DNS、ドメイン汚染、キャッシュ、IPv4とIPv6の選択に集中している場合、FakeDNSは変換レイヤーを1つ追加します。このときは一時的に無効にし、どのサーバーへ問い合わせが送られ、どのレコードが返り、どのアドレスへ接続されたかを直接確認できます。実際の名前解決経路が正常だと確認してから、再びマッピングを有効にして差分を比較します。

v2rayNで有効化する前の確認手順

v2rayNでは、バージョンによってTUN、DNS、コア設定の入口が変わることがあり、項目名もコアの対応機能に応じて変化します。古い画面のスクリーンショットをそのまま再現するより、データの流れに沿って確認しましょう。以下の手順は、多くの構成に適用できます。

  1. TUNが実際に動作していることを確認する。 まず通常のアプリ通信がコアへ入っているかを確認し、捕捉が成功していない状態でDNSの要因を重ねないようにします。
  2. DNSクエリがTUNへ入っていることを確認する。 システムに残った独立DNSツール、ブラウザ独自の名前解決設定、その他のネットワークサービスによって、クエリがマッピングチェーンを迂回することがあります。
  3. プライベートネットワークの除外項目を確認する。 LANドメイン、ゲートウェイアドレス、プリンター、内部サービスは、実際の環境に応じて直接接続または除外を設定します。
  4. ルーティングルールを簡素化する。 初回テストでは、明確な直接接続、プロキシ、デフォルトルールだけを残し、複数のルールセットが同時に判断へ影響しないようにします。
  5. FakeDNSを有効にする。 設定を再読み込みした後に新たに問い合わせを行い、アプリのキャッシュに残った古いアドレスで結果を判断しないでください。
  6. ログでドメイン名とアウトバウンドを確認する。 コアが元のドメイン名を復元できているか、またそのドメインが最終的にどのルーティングルールへマッチしたかを重点的に確認します。

v2rayNでサブスクリプションのノードを使う場合、FakeDNSとノードプロトコルは同じ階層の機能ではありません。VMessやVLESSなどのノードパラメータはプロキシのアウトバウンドがサーバーへ接続する方法を決め、FakeDNSはローカルDNSとルーティング処理の段階に位置します。ノードに接続できるからといってFakeDNSの設定が正しいとは限りません。FakeDNSのマッピングが正常でも、サーバーアドレス、ポート、セキュリティ層、トランスポートパラメータの誤りは修正できません。

同様に、Androidでv2rayNGがXrayコアを使う場合も、ローカルVPNによる捕捉、DNS設定、ノードプロトコルを区別する必要があります。v2flyNGはv2flyコアを使用するため、利用できる機能はコアとクライアントの現在の実装を基準にしてください。あるデスクトップ向けコアの設定項目を別のコアへそのまま移し、動作が完全に同じだと考えないでください。

よくある障害の切り分け方

有効化後、すべてのドメインにアクセスできない

まずDNSクエリがFakeDNSへ入っているかを確認し、次に仮想アドレスへの接続がTUNに捕捉されているかを確認します。システムルートが予約済みアドレス帯を通常のネットワークアダプターへ送っていると、マッピングがコア内部で完結しません。アドレスプールがローカルネットワーク、仮想マシンのネットワーク、他のトンネル設定と競合していないかも確認してください。

Webページは開けるが、LAN機器に接続できない

これは通常、ノードの障害ではなく、LAN名やプライベートアドレスが誤った処理範囲に含まれていることが原因です。LANドメインをローカルDNSへ渡すべきか、プライベートネットワークを直接接続にすべきか、ローカルサービス検出の通信を物理ネットワーク内に維持する必要があるかを確認します。まず明確なLAN範囲を除外し、デバイス名へのアクセスと直接IPアクセスの違いをテストしてください。

ログに仮想IPしか表示されず、元のドメイン名がない

これは接続段階でマッピングの読み取りに失敗したことを示します。問い合わせと接続が異なるコアインスタンスを通った、マッピングが期限切れになった、アプリが古いキャッシュを再利用した、通信の一部がTUNを迂回した、といった原因が考えられます。アプリを終了してシステムDNSキャッシュを消去し、コアを再読み込みしてから新しい問い合わせと接続を1回行う方が、同じページを何度も更新するより有効なログを得やすくなります。

ルールのマッチ結果が想定と逆になる

ルールの順序を確認してください。ルーティングは通常、設定された順番でマッチします。より広いIP、ポート、ドメインルールが前にあると、接続を先に取り込むことがあります。また、FakeDNSが復元したドメイン名、スニッフィングで得たドメイン名、最終的に解決されたIPを区別してください。トラブル対応では、まず主要な判定条件を1種類だけ残し、原因を特定してから複合ルールを戻します。

しばらく使うと、ときどき接続に失敗する

失敗がスリープ復帰、ネットワーク切り替え、コアの再読み込み、長時間接続の維持後に発生していないかを確認します。こうしたイベントによって、アプリがキャッシュした仮想アドレスと現在のマッピングテーブルが同期しなくなることがあります。アプリを終了して再起動し、DNSキャッシュを更新し、TUNを再構築すると、問題が古いマッピングに起因するかを確認できます。頻繁に発生する場合は、アドレスプールの容量や短期間のドメイン問い合わせが大量に発生していないかも調べてください。

最終判断はスイッチ名ではなく、通信経路で決める

FakeDNSに適した条件は明確です。DNSクエリと後続接続が同じTUN経路で捕捉され、ルーティングが安定してドメイン名を取得する必要があり、最終的な名前解決をアウトバウンド段階へ移せることです。この構成なら、アプリが接続する前の実DNS待ちを1回減らし、geosite、ドメインサフィックス、完全修飾ドメイン名のルールへより信頼性の高い情報を渡せます。

無効化または迂回すべき条件も明確です。プログラムが実際のDNSレコードを読み取る必要がある、LANが分流DNSに依存している、仮想アドレスを別の端末へ渡す、または問い合わせと接続が同じマッピングインスタンスへ入ることを保証できない場合です。FakeDNSは有効にするほどよい高速化機能ではなく、名前解決の順序を変えるルーティングツールです。

実際に設定する際は、まずTUN、実DNS、基本ルーティングを個別に動作させてからFakeDNSを追加します。一度に変更するのは1つの段階だけにし、「問い合わせ、マッピング、接続、ルーティング、アウトバウンド」の5段階をログで確認してください。問題が起きても、DNSの捕捉、マッピングの復元、ルールのマッチのどこに原因があるかを判断でき、すべてをノード品質の問題として扱わずに済みます。

v2rayN をダウンロード