V2Ray FakeDNSとは？仮想IPの割り当て・スニッフィングとの連携・活用場面

FakeDNSの仕組み：仮想IPでドメイン情報を保持

通常のDNSは、ドメインを接続可能な実IPアドレスに変換します。一方FakeDNSは、処理対象のAまたはAAAAクエリに仮想IPを割り当て、「ドメインと仮想IP」の対応をローカルに保存します。アプリは通常の名前解決結果を受け取ったように見え、そのアドレスへ接続します。プロキシコアが接続を受け取ると、対応表から元のドメインを復元し、ルーティングとアウトバウンド処理に渡します。

ここでいう「復元」は、ローカルの対応表を参照する処理であり、パブリックDNSにPTR逆引きを問い合わせることではありません。たとえばアプリが example.com を問い合わせてプール内のアドレスを受け取った場合、コアはアプリがそのアドレスへ接続したとき、同じ対応表から example.com を特定できます。割り当てられるアドレスは実行時の状態によって異なるため、特定の仮想IPを固定値としてルールに書き込まないでください。

仮想IPは、この端末内で通信を捕捉するための目印であり、Webサーバーの実アドレスではありません。別の端末からそのままアクセスすることはできず、通常のゲートウェイ経由でインターネットへ送っても宛先から応答は得られません。最終的にDIRECTアウトバウンドを選ぶ場合も、先にドメインを正しく復元し、その後で適切な名前解決と接続処理を行う必要があります。

アドレスプールとポート：3つの数値を区別する

198.18.0.0/15 は 198.18.0.0 から 198.19.255.255 までを含む、ベンチマーク用に予約されたアドレス帯です。一般的なプライベートLAN用アドレス帯ではありません。通常のインターネット上の宛先として使われない点を利用して仮想IPプールにできますが、企業ネットワーク、検証環境、ほかのトンネルでも使われる場合があります。利用前にルートの競合がないか確認してください。

poolSize は対応表の容量を表し、DNSキャッシュの保持時間や同時接続数の上限ではありません。ここでの 4096 は設定例にすぎず、すべての端末に適した推奨値ではありません。容量不足や、アプリが古いアドレスを保持したまま対応情報が削除されることにより、復元に失敗する場合があります。ブラウザーのキャッシュだけを消し、コア側の対応表やシステムDNSキャッシュの寿命を見落とさないようにしてください。

• アドレスプール：仮想宛先として識別するアドレス範囲を決めます。既存の業務用アドレスと重複させないでください。
• 対応表の容量：保持できる対応情報の数を決めます。数値だけで速度を判断せず、実際の動作を確認してください。
• DNSの待ち受け口：従来型DNSではUDP/TCP 53番ポートが一般的ですが、コア内蔵のDNS機能が自動的にローカルの53番ポートで待ち受けるとは限りません。

FakeDNS・sniffing・TUN：それぞれの役割

TUNは仮想ネットワークインターフェースへルーティングされたIP通信を受け取りますが、すべての接続でドメインが分かるとは限りません。通常のsniffingは、HTTP HostやTLSハンドシェイクなど、対応するプロトコル情報からドメインを特定します。FakeDNSは、先に作成された対応情報を使ってドメインを復元します。どちらもドメイン情報を補えますが、情報源が異なり、同じものではありません。

アプリがIPアドレスを直接使う場合、捕捉されない暗号化DNSを使う場合、または有効化前に取得した実アドレスを再利用する場合、FakeDNSは対応情報を作成できません。このとき接続がIPルールで処理されても、機能が動作していないとは限りません。逆に、DNS問い合わせだけがFakeDNSに届き、宛先への接続がTUNや透過型インバウンドを迂回すると、アプリは仮想IPへの接続に失敗します。

Xray設定例：仮想IPの割り当てとインバウンドでの復元を両方設定

以下はXray形式の設定項目の関係を示す例であり、完全な実行用設定ではありません。V2Rayは広く使われている呼称ですが、実際の設定項目と動作は利用中のコアに従ってください。v2rayNはクライアント、v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。画面上の名称が似ているだけで、異なるコア向けのJSONを流用しないでください。

最初はトップレベルの設定例です。IPv4プールを定義し、内蔵DNSでFakeDNSを使うよう指定します。必要な関係だけを示した最小例であり、ノードサーバーのドメイン解決、LAN内ドメインの例外、IPv6、DNS通信の受け入れ口は含みません。クライアントが生成した完全な設定をこの内容で置き換えないでください。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 4096
    }
  ],
  "dns": {
    "servers": [
      "fakedns"
    ]
  }
}

2つ目は、仮想宛先への接続を受け取るインバウンドオブジェクトに属する設定で、対応表からドメインを復元します。必要な設定関係が分かるよう、ここでは fakedns のみを記載しています。HTTPやTLSなどのスニッフィング種別を加える場合は、使用するコアが対応しているか確認してください。このオブジェクトを単独のトップレベル設定として扱ったり、宛先接続を受け取れないインバウンドに誤って追加したりしないでください。

{
  "sniffing": {
    "enabled": true,
    "destOverride": [
      "fakedns"
    ]
  }
}

• ノードサーバーにドメイン名を使う場合は、実アドレスを取得できる名前解決経路が必要です。仮想IPをノード接続の最終的な宛先として使うことはできません。
• ドメインを復元して初めて、ルーティングの geosite: ルールを適用する根拠が得られます。geoip: はIPアドレスを対象とするため、仮想IPをWebサイトの所在地判定に使うことはできません。
• IPv4プールだけを設定しても、AAAA問い合わせやIPv6接続まで対応したことにはなりません。デュアルスタック環境では別途検証してください。

活用場面：透過接続では効果的、通常のシステムプロキシではシンプルに

HTTPプロキシや、リモートDNS解決に対応したSOCKSリクエストは、ドメイン名をそのままプロキシに渡せます。この場合、FakeDNSを追加しても新たな問題の解決につながらないことがあります。透明接続ではIPパケットだけを受け取り、ドメイン情報が失われやすいため、FakeDNSがよく使われます。有効化する前に不足しているのがドメイン情報なのか、ノード接続、アウトバウンドでの名前解決、ルーティング順なのかを確認してください。

FakeDNSはDNSの暗号化機能ではなく、すべてのDNS通信がプロキシを通ることを保証するものでもありません。アプリに返す名前解決結果を変えるだけです。その後の実アドレスの解決場所や通信方式は、アウトバウンドとDNSのポリシーで決まります。VMessやVLESSなどのノードプロトコルだけでFakeDNSの可否が決まるわけではなく、この設定のためにサブスクリプションを再インポートする必要もありません。

確認手順：名前解決結果から最終的なアウトバウンドまで追う

1. 基準となる状態を保存。まず通常のプロキシモードで同じノードから目的のサイトに接続できることを確認し、現在の設定をバックアップします。サブスクリプション、ルーティングルール、DNSを同時に変更しないでください。
2. 通信の入口を確認。選択したTUNまたは透過接続を有効にし、アプリのDNS問い合わせと後続の接続が想定した経路に入っているか確認します。Windowsでは「設定」→「ネットワークとインターネット」で現在のネットワークインターフェースを確認できます。ただし、物理ネットワークアダプターに表示されるDNSだけを根拠に、通信捕捉の成功と判断しないでください。
3. 古いキャッシュを削除。テストするアプリを終了します。Windowsではコマンドプロンプトで ipconfig /flushdns を実行してシステムキャッシュを消去し、アプリを起動し直します。ブラウザー独自のキャッシュや暗号化DNSの設定も別途確認してください。
4. 実際の問い合わせを確認。アプリから名前解決を発生させ、DNSログで返されたアドレスが設定したプールに含まれるか確認します。nslookup example.com は補助的に使えますが、ブラウザーとは異なる経路で問い合わせる場合があります。一度の結果だけで、すべてのアプリの動作を判断しないでください。
5. 復元とルーティングを確認。利用可能なログで、元の仮想宛先、復元後のドメイン、適用されたルール、アウトバウンドのタグを確認します。記録できる詳細さはコアやクライアントによって異なります。必要に応じて一時的にログレベルを上げ、テスト後に元へ戻してください。
6. 例外を確認。社内サイト、IPv6の宛先、DIRECTルールをそれぞれテストします。プロキシ経由のサイトが1つ開けただけでは、DNSポリシー全体が正しいとは言えません。

テスト結果から、DNSが何を返したか、接続がどこへ向かったか、どのルールが適用されたかを確認できるようにしてください。ping だけではWebサイトへのプロキシ接続を判断できません。仮想IPがICMPに応答する必要はなく、Webアクセスでは別の接続経路が使われるためです。また、仮想IPを取得するまでの速度をWebサイトの応答時間として扱わないでください。異なる指標です。

よくあるトラブル：仮想IPが残る、社内ネットワークに接続できない、ルーティングが効かない

コアの再起動後だけ問題が起きる場合は、対応情報とアプリのキャッシュが同期していない可能性があります。アプリに古い仮想IPが残っている一方、新しいプロセスにはその対応情報がありません。この場合は、ノードを何度も切り替えるより、アプリを再起動して名前解決し直すほうが効果的です。プール容量を増やしても繰り返し発生するなら、DNSを処理するコンポーネントが複数ないか確認してください。容量を際限なく増やしても、トラブルシューティングの代わりにはなりません。

元に戻す手順：DNSを復元し、キャッシュを消して通常のプロキシ接続を確認

現在のネットワーク環境に合わないと判断した場合は、保存しておいた設定に戻してください。仮想IPの割り当てと、それに依存する通信捕捉の設定を両方解除し、処理経路を中途半端に残さないことが重要です。クライアントの更新で設定生成方法が変わる場合もあるため、どのスイッチを有効にしたか推測せず、保存した設定を基準に戻してください。

• 元のDNSサーバー、ドメイン例外、クライアントの通信捕捉設定を復元します。
• 物理ネットワークインターフェースとシステムルートに、仮想IPプールの通信捕捉ルールが残っていないか確認します。
• アプリを終了してDNSキャッシュを消去し、通常のシステムプロキシ設定で同じ宛先をテストします。
• 問い合わせ、対応情報の復元、アウトバウンド接続のどの段階で失敗したか記録し、次回は該当箇所だけを調整します。

覚えておきたいポイントは、FakeDNSはドメイン情報を必要とするルーティング経路を補う機能だということです。すでにドメインを安定して渡せる環境では、設定を増やして複雑にする必要はありません。透過接続でドメイン情報が不足している場合に、アドレスプール、DNS問い合わせの入口、インバウンドでの復元、アウトバウンドでの名前解決を順に整えてください。設定項目の詳しい関係は設定リファレンスのDNS設定を、基本的な接続の問題は接続トラブルの対処方法を確認してください。