アプリが先にドメインを名前解決し、その後IPアドレスだけで接続する場合、FakeDNSはドメインと仮想IPの対応を一時保存し、プロキシコアに届いた接続からドメインを復元できます。ここではDNS問い合わせ、マッピング、スニッフィング、ルーティングの順に仕組みを解説し、v2rayNでTUN・DNS・スニッフィングを確認する方法も紹介します。通常のシステムプロキシだけを使う場合も、FakeDNSが必要かどうかを判断できます。
FakeDNSが解決するドメイン情報の欠落
ドメイン別ルーティングには、ルーティング時に接続先のドメインを把握できることが前提となります。ブラウザーがHTTPプロキシ経由でリクエストを送る場合、通常はプロキシがドメインを直接取得できます。一方、TUNモードでは、アプリがシステムDNSでドメインを実IPに名前解決してから、そのIPに接続することがあります。TUNが捕捉するのは接続先IPであり、元のドメインは必ずしもコアまで届きません。その場合、ルーティングにドメインルールを設定していても、IPルールでしか判定できないことがあります。
FakeDNSは、接続先サイトの実IPを調べる仕組みではありません。DNS問い合わせに対して一時的な番号を割り当て、コアがアプリに仮想IPを返すと同時に、その仮想IPとドメインの対応を記録します。アプリは通常どおりそのアドレスに接続し、コアが接続を受け取った後、マッピングからドメインを復元します。その後の処理はルーティングとアウトバウンド設定で決まります。FakeDNSはプロキシプロトコルでも、新しいサーバーノードでもありません。
重要なのは、DNS問い合わせと接続の両方が同じ処理経路に入ることです。DNS問い合わせがFakeDNSに届き、その応答アドレスへの接続も、マッピングを参照できるコアに届く必要があります。問い合わせが外部のシステムDNSに流れたり、接続がTUNを迂回したりする場合、FakeDNSを有効にしただけではドメインを復元できません。アプリが最初から固定IPに接続する場合も、FakeDNSに保存できるドメインはありません。
仮想IPの割り当てとドメインの復元
よく使われるIPv4仮想アドレスプールの一つが198.18.0.0/15です。このアドレス帯はネットワーク機器の性能測定用であり、Webサイトへのアクセスに使う実際の宛先IPではありません。FakeDNSは設定されたアドレスプールからIPを選び、問い合わせ元のアプリに返すとともに、コア内部に対応関係を保存します。プールの範囲や割り当て可能な数、キャッシュの状態は設定やコアの実装によって異なります。特定の仮想IPが恒久的なドメイン識別子になるわけではありません。
ここでいう「スニッフィング」は、TLSハンドシェイクやHTTPリクエストからドメインを読み取ることだけを指すのではありません。FakeDNSに対応したコアは、先に作成された仮想IPのマッピングを参照して接続先をドメインに復元できます。HTTP HostやTLS SNIなど、一般的なスニッフィングもドメインを取得する別の手段です。アプリのプロトコルや暗号化の有無、ドメイン情報を含むかどうかは通常のスニッフィングに影響しますが、「FakeDNSの応答を受け取ってからマッピングを参照する」という基本的な要件は変わりません。
確認のポイント：接続がマッピングに一致するか
ログにDNSが仮想IPを返した記録があるだけでは、ルーティングに成功したとはいえません。続いて、同じコアが後続の接続を受け取っているか、ルーティングログの宛先をドメインに復元できているかを確認します。仮想IPのままなら、まずTUNの捕捉範囲とスニッフィング設定を確認してください。
コアの再起動やマッピングの消去、アプリに残った古いDNS応答の長期キャッシュにより、アプリが対応するドメインを特定できない仮想IPに接続し続けることがあります。「設定を切り替えた直後は開けないが、しばらくすると復旧する」場合は、まずアプリにDNSを再問い合わせさせてください。必要ならアプリを終了して起動し直します。サーバーアドレスをすぐ変更する必要はありません。
v2rayNのTUN利用時に確認する設定
まずv2rayNの「設定」→「パラメーター設定」で、使用中のコアとTUN関連の項目を確認し、次にDNSとトラフィックのスニッフィング設定をチェックします。バージョンによって項目のグループ名やスイッチの位置が異なることがあるため、現在の画面表示を基準にしてください。FakeDNS、DNSの制御、TUNの捕捉、スニッフィングは連携して動作します。どれか一つを有効にしただけで、処理経路全体が機能しているとは限りません。
DNS問い合わせの経路
- 確認する場所
- 「設定」→「パラメーター設定」
- 確認項目
- 使用中のコア、TUN、DNSの設定
- 想定される動作
- アプリの問い合わせが設定済みのDNSで処理される
- 異常の兆候
- 実際のパブリックIPが返される
まず問い合わせがコアに届いていることを確認し、次に応答アドレスが設定済みの仮想アドレスプールに含まれるか確認します。
接続とルーティングの経路
- 確認する場所
- v2rayNのコアログとルーティング設定
- 確認項目
- スニッフィング、ドメインルール、アウトバウンドの有効化
- 想定される動作
- 復元されたドメインに基づいて接続をルールに照合する
- 異常の兆候
- ログに仮想IPしか表示されない
ルーティング結果はルールの順序にも左右されます。FakeDNSはドメインを復元するものであり、使用するアウトバウンドを決めるものではありません。
検証には、ドメイン別ルーティングルールに明記されたテスト用ドメインを選び、関連機能を有効にする前のルーティング結果を記録してから、DNS応答、接続の捕捉、ルールへの一致を一つずつ確認します。「Webページが開くか」だけを判断基準にしないでください。同じページでも、直接接続とプロキシ経由のどちらでも開く場合があります。また、LAN内の機器名をパブリックドメイン向けルールのテストに使わないでください。通常、両者は異なる名前解決経路を使います。
サブスクリプションが提供するのはサーバーへの接続情報であり、ローカルのDNSやTUNの設定ではありません。VMessまたはVLESSのノードを変更しても、FakeDNSの問い合わせ経路はローカルで確認する必要があります。ノードに接続できても、ドメインが想定どおりにルーティングされているとは限りません。問題を切り分けるときは、ノードを固定し、ローカル設定を一度に一つだけ変更するとログを比較しやすくなります。
有効にする通信と、実IPでの名前解決を保つ通信
FakeDNSは、「アプリが先に名前解決し、TUNが後から接続を捕捉する」場面に特に有効です。アプリはIPアドレスだけで接続する一方、ルーティングルールでは元のドメインが必要なケースです。また、アプリが実際の名前解決結果を先に取得したために、コアへ届く前にドメイン情報が失われるのを防ぐ効果もあります。ただし、あらゆるDNSの問題を解決する万能策ではありません。上流の名前解決、ルーティングルール、アプリ独自のDNS動作は、それぞれ確認が必要です。
| 通信の種類 | 優先して確認すること | 利用の目安 |
|---|---|---|
| TUN経由のパブリックドメインへのアクセス | DNS問い合わせと接続がどちらもコアに届くか | ドメイン別ルーティングが必要なら、FakeDNSのマッピングをテストする |
| LAN内の機器と内部ドメイン | ローカルDNS、LAN内の直接接続ルール | LANアクセスへの影響を避けるため、実アドレスでの名前解決を優先する |
| 数値のIPアドレスへの直接接続 | IPルーティングルール | FakeDNSで復元できる元のドメインがない |
| アプリが独自に暗号化DNSを利用する | アプリの名前解決がローカルDNSの経路を迂回していないか | まず問い合わせの送信先を確認する。OSのDNS設定だけで判断しない |
LANプリンター、ルーターの管理画面、社内サービスには特に注意が必要です。これらは実際のLAN内アドレスを返すローカルDNSに依存している場合があります。問い合わせが仮想アドレスに置き換わり、その後の接続が想定どおりコアに届かなければ、アクセスできなくなります。まず該当するドメインや宛先ネットワークに明確なローカル名前解決と直接接続の経路を設定してから、パブリックドメインでFakeDNSをテストしてください。すべての問い合わせを一括して仮想アドレスプールに流すのは避けましょう。
まとめ：通信の入口を見て有効化を判断する
主に通常のシステムプロキシを使い、ドメインルールも正しく適用されているなら、「DNS機能を追加するため」だけに現在の名前解決経路を変更する必要はありません。TUN環境でドメイン情報が失われていると確認できた場合に限り、対象の通信でFakeDNSをテストし、ローカルリソースには別の処理経路を用意してください。
アプリ自身が暗号化DNSの問い合わせを送信する場合や、別のネットワークコンポーネントに処理を任せる場合もあります。このとき、v2rayNから通常のDNS問い合わせが見えないことがあります。後続の接続がTUNに捕捉されても、参照できる仮想IPのマッピングが存在するとは限りません。まず「アプリが実際にどこへ問い合わせを送っているか」から調べ、FakeDNSの割り当て失敗だと決めつけないでください。
有効化後にアクセスできない場合：症状別の確認手順
まず問題を3つに分類します。仮想IPが返らない、仮想IPは取得できるが接続できない、接続は成功するが想定したドメインルールに一致しない、の3つです。それぞれDNSの入口、接続の捕捉とマッピング、ルーティングの照合に関係します。1回のテストで得た問い合わせ結果と、同じ時間帯のコアログを保存しておけば、別々のリクエストの症状を混同せずに判断できます。
FakeDNSを有効にしたのに、Webサイトの実IPが返される
まず「設定」→「パラメーター設定」で現在のコアとTUN・DNSの設定を確認し、問い合わせを送るアプリがそのDNS経路を使っているか確かめます。問い合わせがFakeDNSに届いていない場合、スニッフィングルールを変更してもDNS応答は変わりません。
198.18のアドレスが返るのに、Webページが読み込み中のままになる
後続のTCPまたはUDP接続がTUNに捕捉されているか確認し、コアログで該当するリクエストを探します。接続がコアを迂回している場合、仮想IPには実際のWebサイトのアドレスのように直接アクセスできません。コアを再起動した直後なら、アプリにDNSを再問い合わせさせてください。
パブリックサイトにはアクセスできるが、LAN内の機器に接続できない
ローカルDNSとLAN内の直接接続設定を確認し、内部ドメインとLAN内アドレスには実際の名前解決結果を使います。設定を変更した後、機器のドメインを再度問い合わせ、返されたアドレスが仮想アドレスプールではなく実際のLAN内アドレスであることを確認してください。
ドメインは復元できているのに、アウトバウンドが誤っている
ルーティング設定でルールの内容と優先順位を確認し、そのドメインが先に別のルールに一致していないか調べます。FakeDNSが補うのは判定に必要なドメイン情報だけです。最終的なアウトバウンドはルーティング設定で決まります。
特定のアプリだけで問題が起きる場合は、ブラウザーとそのアプリを比べてください。DNSの問い合わせ先、TUNの経由、接続先のドメインが同じか確認します。ブラウザーで正常だからといって、すべてのアプリが同じ問い合わせを行うとは限りません。設定を切り替えた直後だけ問題が起きるなら、アプリに古い仮想IPがキャッシュされている可能性を優先して考え、再問い合わせ後の動作を確認してください。
最後にノードとプロトコル層を確認します。v2rayNのVMessまたはVLESSサーバーに接続できるかどうかと、FakeDNSのマッピングが機能するかどうかは別の問題です。ログでドメインルールへの一致とアウトバウンドの選択が確認できているのにタイムアウトする場合に限り、次にノードの接続を調べます。DNS、スニッフィング、ルーティング、アウトバウンドの順に切り分けるほうが、サブスクリプション、ルーティング、DNSを同時に変更するより原因を見つけやすくなります。