FakeDNSは、通信を透過的に取り込んだ際に「宛先IPしか分からず、元のドメイン名が失われる」問題への対策です。v2rayNやv2rayNGを利用中で、TUNやVPN経由のルーティングを調整したい方向けに、仮想IPの割り当て方法、通常のDNS解決が必要なリクエスト、ログやキャッシュ削除による確認方法を解説します。現在のドメイン別ルーティングに問題がなければ、設定項目を増やすためだけに有効化する必要はありません。
FakeDNSの仕組み：仮想IPでドメイン名を保持
FakeDNSはプロキシプロトコルでも、暗号化DNSでもありません。通常のDNSがドメイン名に実際の接続先アドレスを返すのに対し、FakeDNSは専用のアドレスプールから仮想IPを割り当て、「ドメイン名と仮想IP」の対応関係を記録します。その後、アプリがこのアドレスに接続すると、通信を取り込むコアが対応関係から元のドメイン名を復元し、ルーティングとアウトバウンド処理を行います。
この一連の処理では、XrayがDNSリクエストと後続の接続の両方を処理する必要があります。たとえば、アプリが example.com を問い合わせると、アドレスプール内の 198.18.0.1 が返されます。その後、このアドレス宛ての接続も、対応関係を保持するコアを経由しなければなりません。このアドレスは割り当て結果の例であり、ドメインの実際のアドレスでも、ノード設定に入力するサーバーアドレスでもありません。
TUNとドメイン別ルーティング：FakeDNSが解決する問題
v2rayNのシステムプロキシでは、アプリがHTTPプロキシまたはSOCKSプロキシを利用し、ドメイン名をプロキシ側に直接渡せる場合があります。一方、TUNが取り込むのはネットワーク層のパケットで、コアから見える宛先はすでに名前解決後のIPアドレスになっていることがあります。このような場合に、ドメインルールの照合に使える情報を保持するのがFakeDNSの役割です。
v2rayNGはAndroidのVPNインターフェースを通じて端末の通信を受け取りますが、VPNで通信を取り込むだけでFakeDNSが自動的に有効になるわけではありません。DNSがコアに届くか、コアが仮想IPを割り当てるか、接続時にドメイン名が復元されるかは、それぞれ別の条件です。TLSやHTTPのスニッフィングでドメイン名を取得できる場合もありますが、対応プロトコルやアプリの動作に左右されるため、すべての接続で確実に使える代替手段ではありません。
明示的なプロキシ経由
- 通信の入口
- HTTPまたはSOCKSインバウンド
- ドメイン名の取得元
- アプリから渡される宛先ドメイン名
- 確認ポイント
- アプリがプロキシを使い、名前解決をプロキシ側に任せているか
- 有効化の判断
- ドメイン名が正しく渡されているなら、通常FakeDNSを追加する必要はありません
SOCKSを使うアプリでも、ローカルで先に名前解決してIPアドレスだけを渡す場合があります。プロキシの種類だけで判断しないでください。
TUN・VPN経由
- 通信の入口
- 仮想ネットワークインターフェース
- ドメイン名の取得元
- FakeDNSの対応関係、または利用可能な別のメタデータ
- 確認ポイント
- DNSの取り込みと仮想IPのルーティング
- 有効化の判断
- ドメイン名に基づく安定した振り分けが必要な場合に検討
DNS問い合わせと後続の接続の両方が取り込まれて初めて、仮想IPの対応付けが機能します。
VLESSとVMessはプロキシ接続を担い、FakeDNSはローカルDNSと宛先情報を処理します。プロキシプロトコルを切り替えても、対応付けの経路が自動的に修復されるわけではありません。v2flyNGはV2Flyコアを使用するため、設定機能やフィールドの対応状況は実際のコアで確認してください。Xrayの設定例を3つのクライアントすべてに共通する設定として扱うことはできません。
アドレスプールと設定項目：まず3つの数値を確認
XrayのFakeDNS設定では、IPv4アドレスプールに 198.18.0.0/15 を使用できます。このネットワークはベンチマーク用の特殊用途アドレス空間であり、インターネット上のサービスにそのまま接続できる通常のアドレスではありません。ネットワークに含まれるアドレス数と poolSize は別の概念です。前者はプレフィックス長で決まり、後者は実装上の対応付けプールの容量を制御します。
{
"fakedns": [
{
"ipPool": "198.18.0.0/15",
"poolSize": 65535
}
]
}Xrayのこの設定例は、最上位のアドレスプール定義のみを示したもので、単独で動作する完全な設定ではありません。実際に組み込むには、内蔵DNSの fakedns サーバー項目や、接続を受けるインバウンドでのドメイン名復元設定も必要です。たとえば、sniffing.destOverride が fakedns に対応しているか確認してください。アドレスプールを貼り付けるだけでは、システムDNSの経路は自動的に切り替わりません。
- まず生成された設定を確認：v2rayNのTUN実装と通常のプロキシインバウンドでは、処理経路が異なる場合があります。Xrayの設定項目をあらゆる設定ファイルに貼り付けるのではなく、現在の実行コンポーネントが実際に受け付ける設定を確認してください。
- アドレスの競合を確認：社内VPN、検証用ネットワーク、静的ルートですでに
198.18.0.0/15を使用している場合は、アドレスプールとルートを再設計し、同じネットワークを異なる用途で取り合わないようにしてください。 - IPv6を別途確認：IPv4のアドレスプールを設定しただけでは、AAAA問い合わせも正しく処理されるとは限りません。使用中の実装におけるIPv6の扱いを確認し、デュアルスタック対応アプリが未検証の経路を使わないようにしてください。
活用シーン：有効化を検討したい通信
FakeDNSは、ドメインルールに依存し、アプリからドメイン名を直接取得しにくい通信を透過的に取り込む場面に適しています。事前の実DNS解決がドメイン判定に与える影響を抑えられますが、Webページの表示が必ず速くなるわけではありません。接続結果には、最終的なアウトバウンド、サーバーへの到達性、実際の宛先の名前解決も影響します。
| 利用シーン | 推奨設定 | 確認ポイント |
|---|---|---|
| TUN経由の通信をドメイン名で振り分ける | 有効化を検討する価値あり | ログでドメイン名が復元され、接続が想定したルールに一致する |
| ブラウザーが明示的なプロキシを使い、ドメイン名も渡している | 現在の設定を維持してもよい | アプリがドメイン名をプロキシに渡しているか |
| 社内ドメインやプライベートIPへのアクセス | まず実DNSを使う例外を設定 | 社内DNS、返されるアドレス、直接接続のルートが一致しているか |
| アプリが固定IPアドレスに直接接続する | FakeDNSでは元のドメイン名を補えない | IPアドレスのルール、またはアプリに適した別のルールを使う |
| アプリ内蔵の暗号化DNS | 問い合わせが内蔵DNSを迂回しているか、まず確認 | ポート53の通信を取り込むだけでは、アプリ内のDNS問い合わせをすべて捕捉できない |
社内ドメインにFakeDNSを使う場合は、特に慎重な確認が必要です。社内サービスでは、指定されたDNSを使ってプライベートIPを取得しなければならないことがあります。こうした問い合わせには実DNSを使い、該当する接続を直接接続に設定するほうが、従来のアクセス方法を維持しやすい場合があります。例外設定は現在のDNSとルーティングの実装に合わせて行ってください。直接接続のルールを追加しただけで、名前解決の経路も変わるとは限りません。
有効化前の確認：DNS、アウトバウンド、キャッシュをまとめてチェック
- 現在の状態を記録。クライアントのバージョン、実行中のコアのバージョン、DNS設定、TUNまたはVPNの状態を記録します。同じドメインにアクセスしてログを保存しておけば、変更後と比較できます。
- 名前解決の入口を確認。システムDNSが取り込まれているか確認してください。ブラウザーのセキュアDNSやアプリ内DoHは、その経路を迂回することがあります。テスト中はテスト用アプリに一時的にシステムDNSを使わせ、終了後に元の設定へ戻してください。
- 接続がコアに戻るか確認。現在のTUNまたはVPNが仮想アドレスプール宛ての通信を受け取るか確認してください。Androidのアプリ別プロキシでテスト対象アプリが除外されていると、アプリは仮想IPを取得できても、接続をコアに戻せない場合があります。
- 実DNSを使うアウトバウンドを確認。プロキシサーバーのアドレスがドメイン名の場合は、利用可能な起点の名前解決経路が必要です。まだ確立されていないプロキシ経由の名前解決に依存してはいけません。直接接続する宛先でも、実際のIPアドレスが必要になる場合があります。
- 変更する項目は1つだけ。まずノードとルーティングのプリセットを変えず、FakeDNS関連の設定だけを調整してください。コア、プロトコル、DNS、ルールを同時に切り替えると、失敗箇所を特定しにくくなります。
v2rayNとv2rayNGの画面項目はバージョンによって変わります。古いスクリーンショットの設定位置ではなく、実行中の設定とログを根拠に判断してください。現在のバージョンで必要な設定ができない場合は、検証済みのモードを維持するのが無難です。カスタム設定にはDNS、インバウンド、ルーティングの理解が必要で、項目を1つ追加するだけでは済みません。
動作確認と切り戻し：名前解決と接続を分けて確認
FakeDNSのテストは2段階に分けます。まずシステムの問い合わせ結果を確認し、次に同じドメインへの実際の接続を確認します。Windowsでは、コマンドプロンプトで以下のコマンドを実行できます。nslookupで確認できるのは、その時点で使われているDNS問い合わせ経路です。ブラウザー内蔵のDNSも同じ経路を通るとは限りません。
ipconfig /flushdns
nslookup example.com- 名前解決の確認：FakeDNSで処理されるはずの問い合わせなら、返されたアドレスが設定済みの仮想アドレスプール内にあるか確認します。実アドレスが返された場合は、失敗と判断する前に実DNSを使う例外に該当していないか確認してください。
- 接続の確認：テスト用アプリで同じドメインにアクセスし、ログに記録された宛先ドメイン名、ルーティングルール、アウトバウンドのタグを確認します。仮想IPを最終的なインターネット上のサービスアドレスとして、通常のネットワークに直接送ってはいけません。
- 比較確認：社内ドメインと、IPアドレスを直接使う接続もテストし、例外設定に影響がないことを確認します。条件をそろえて比較し、ノードの不安定さをFakeDNSの障害と取り違えないようにしてください。
- 切り戻し：まずDNSと通信の取り込み設定を元に戻し、クライアントの接続を再確立します。その後、システムキャッシュを更新し、テスト用アプリを完全に終了してから再起動してください。Androidアプリが古い結果を保持している場合は、アプリを強制停止してから起動します。
FakeDNSの対応付けは通常、実行中だけ保持される状態です。コアの再起動、対応付けの破棄、設定変更などがあると、アプリに古い仮想IPがキャッシュされたまま、新しいコアでは対応するドメイン名を復元できないことがあります。この場合、ノードを繰り返し切り替えても解決しないことが多いため、まずキャッシュを削除して接続をやり直してください。Windowsの ipconfig /flushdns が更新するのはシステムDNSキャッシュだけであり、各アプリのキャッシュ削除に代わるものではありません。
よくある質問：仮想IP、アプリとの競合、バッテリー消費
198.18で始まるアドレスが返されました。DNSが壊れていますか？
FakeDNSが有効で、アドレスプールに 198.18.0.0/15 を指定している場合、これは正常な結果の可能性があります。まず、問い合わせたドメインがFakeDNSの対象か確認し、接続ログからドメイン名を復元できるか確認してください。アドレスの見た目だけでは障害かどうか判断できません。また、Webサイトの固定IPアドレスとして保存しないでください。
FakeDNSを無効にしたのに、一部のアプリがタイムアウトするのはなぜですか？
アプリが古い仮想IPをキャッシュしている可能性があります。DNS設定を元に戻してクライアント接続を再確立し、Windowsでは ipconfig /flushdns を実行してから、アプリを完全に終了して再起動してください。Androidでは、影響を受けているアプリを強制停止してから再テストします。最初からアプリのデータを消去する必要はありません。
ゲームや業務アプリの一部だけが開けない場合、どう調べればよいですか？
まず、そのアプリが必要とするドメインに実DNSを使う例外を設定し、ほかの設定は変えずにテストしてください。アプリによってはアドレスの種類を確認したり、IPアドレスを固定で使ったり、独自に名前解決したりします。「ほかのWebページは見られる」というだけでは、互換性の問題がないとは言えません。実DNSに切り替えて動作が戻った場合は、そのアプリに必要なDNSとルーティングの条件を確認してください。
v2rayNGでFakeDNSを有効にすると、バッテリー消費が増えたり、必ず速くなったりしますか？
どちらも一概には言えません。FakeDNSは対応関係を管理し、宛先情報の復元にも関わります。実際のバッテリー消費は、ネットワークの再起動、アプリの再試行、VPNの継続稼働などにも左右されます。同じネットワーク、ノード、アプリの負荷で比較してください。ログに頻繁な再試行が記録される場合は、アドレスプールを広げるのではなく、まず通信経路の問題を解消します。
FakeDNSを有効にする基準は、ドメイン名を復元でき、正しくルーティングできることを検証できるかどうかです。v2rayN、v2rayNG、v2flyNGで現在の設定が安定しているなら、機能を増やすためだけに変更する必要はありません。導入する場合は、問い合わせの入口、仮想IPのルーティング、実DNSを使う例外、キャッシュの切り戻しを説明できる状態にしてから、日常利用へ広げてください。