V2Ray FakeDNSとは？仕組み・設定方法・活用シーン

FakeDNSとは？仮想IPを返し、あとからドメイン名を復元

通常のDNSは「このドメイン名に対応する実際のIPアドレス」を返します。一方、FakeDNSが返すのは「問い合わせたドメイン名を表す仮想IPアドレス」です。たとえば、アプリが example.com を問い合わせると、FakeDNSはアドレスプールからIPアドレスを割り当て、ドメイン名との対応を保存します。その後、アプリがこのIPアドレスに接続すると、プロキシの入口でドメイン名が復元され、ドメイン名に基づいて直結かプロキシ経由かが選択されます。

重要なのは「仮想」という点ではなく、処理が一連の流れとして完結することです。DNS応答で作成した対応表を、後続の接続を処理するコンポーネントから参照できなければなりません。DNS問い合わせを受けたプロセスと接続を処理するプロセスが別で、対応表を共有していない場合、後者にはインターネットへの接続に使えない宛先IPしか見えません。どちらもプロキシと呼ばれていても、対応表が自動で共有されるとは限りません。

通常のDNSとFakeDNSの違い

通常のDNSでもドメイン名によるルーティングは可能です。アプリがHTTPプロキシを使う場合や、ドメイン名をSOCKSプロキシに渡す場合、プロキシはすでにドメイン名を把握していることがあり、FakeDNSを追加しても効果がない場合があります。FakeDNSが特に役立つのは、TUNや透過プロキシがIPアドレス宛ての接続を捕捉し、ルーティングルールでは元のドメイン名が必要になるケースです。

FakeDNSは暗号化DNSと同じものではありません。DoHやDoTはDNS問い合わせの通信方式を扱い、FakeDNSはドメイン情報を後続の接続に引き継ぐ方法を扱います。問い合わせをFakeDNSに送っても、直結先の接続には実際のIPアドレスの名前解決が必要になる場合があり、プロキシサーバーのドメイン名も通常どおり解決できなければなりません。すべてのDNS問い合わせがなくなる、またはすべての通信がプロキシを通ると考えないでください。

アドレスプールとポート：混同しやすい3つの数値

198.18.0.0/15 は 198.18.0.0 から 198.19.255.255 までをカバーし、131072個のアドレスを含みます。ただし、対応表に常にこれだけの件数が保存されるという意味ではありません。例の poolSize は対応表の容量設定です。アドレス範囲、対応表の容量、DNSキャッシュの有効期間を同じものとして扱わないでください。

ポート番号も区別が必要です。システムがDNSサービスに問い合わせる際、一般的な宛先はUDPまたはTCPの 53 番ポートです。プロキシソフトウェア内部のDNS受信ポートは別に設定できます。HTTPやSOCKSのローカル待ち受けポートはDNS用ではありません。システムDNSの宛先をHTTPプロキシの待ち受けアドレスにしても、FakeDNSが自動的に有効になるわけではありません。

• アドレスプールの範囲は、既存のVPN、社内ネットワーク、検証用ネットワークで使用中のアドレス帯と重ならないようにしてください。
• アドレスプールを変更したら、TUNのルートや透過転送ルールが新しい範囲をカバーしているかも確認してください。
• 対応表の容量を増やしてもWebページの表示が速くなるわけではありません。まずDNS問い合わせと接続が同じ経路を通ることを確認してください。

有効化する前に確認：DNSを受けるのはどのコンポーネントか、接続を処理するのはどのコンポーネントか

v2rayNはクライアントの画面で、Xrayは呼び出される可能性のあるプロキシコアです。画面上のTUN機能は別のコンポーネントが担う場合もあります。ノードがVLESSやVMessだからといって、TUNのDNSも必ずXrayが処理すると判断することはできません。プロトコルが定めるのはノードへの接続方式であり、PC上のDNSをどのように処理するかではありません。

1. v2rayNの「設定」→「パラメータ設定」で現在のコアに関する設定を確認し、起動ログで実際に起動しているプロセスを確認してください。バージョンによって項目名や分類が変わる場合があるため、現在の画面とログを基準にしてください。
2. 「設定」→「DNS設定」がある場合は、どのコアの設定を変更するのかを先に確認してください。同じ名前のDNS項目を全体に適用されるスイッチと考えないでください。
3. 変更前に、システムプロキシ、TUN、DNSの各状態を記録し、一度に変更するのは1項目にしてください。元に戻せるよう、現在の設定を控えておきましょう。
4. v2rayNGやv2flyNGを使う場合も、実際に使用するコアと設定の対応状況を先に確認してください。デスクトップ版のメニュー手順をAndroid版にそのまま当てはめないでください。

Xrayの設定例：対応表の作成と宛先の復元が必要

以下は、これらの項目に対応するXrayコア向けの設定例であり、単独で動作する完全なノード設定ではありません。使用前に、利用中のコアのバージョンに対応した設定ドキュメントを確認してください。クライアントが自動生成するファイルは、設定の保存やノード切り替え時に上書きされる場合があります。繰り返し一時ファイルを編集せず、クライアントが提供するカスタム設定の方法を使ってください。

パート1：アドレスプールを定義してFakeDNSを選択

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

トップレベルの fakedns で対応表のアドレスプールを定義し、dns.servers の "fakedns" で内部のFakeDNSサービスを選択します。この最小限の例は項目間の関係を示すだけで、ノードサーバーのドメイン名、LAN内のドメイン名、直結先に必要な実際の名前解決方法は含まれていません。実運用では用途に応じて通常のリゾルバーも設定し、すべての名前解決を仮想IPアドレスプールに任せないようにしてください。

パート2：接続を受ける入口でドメイン名を復元

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

2つ目の設定は、宛先への接続を実際に受けるinboundオブジェクトに追加します。新しいトップレベル項目として追加するものではありません。destOverride の "fakedns" は、FakeDNSの対応表から宛先のドメイン名を復元するために使います。DNS問い合わせを受ける入口だけに設定し、Webやアプリの接続を受ける入口への設定を忘れないでください。

• プロキシ接続前にプロキシ経由で名前解決しなければならない、という循環依存を避けるため、まずノードサーバーのアドレスを解決できるようにしてください。
• 仮想IP宛ての接続でドメイン名ルールだけを照合し、仮想IPのまま直結しないでください。出力経路に送る前に、宛先を正しく復元する必要があります。
• IPv6の問い合わせがある場合は、AAAAレコードとIPv6通信の扱いを別途設計してください。IPv4のアドレスプールを設定しただけでは、IPv6も受け入れられているとは限りません。

FakeDNSが有効か確認する方法：仮想IPが返るだけでは不十分

正しく動作しているか確認するには、DNS応答、接続の捕捉、最終的なアクセス結果をあわせて確認します。198.18.x.x が表示されても、分かるのはある問い合わせで仮想IPが返ったことだけです。ブラウザーの接続成功や、ドメイン名ルーティングに想定したルールが使われていることまでは確認できません。

1. 古い状態をクリアします。テスト用ブラウザーを終了し、設定を適用して関連するコアを再起動します。Windowsでは、ターミナルで次のコマンドを実行してシステムのDNSキャッシュを消去できます。アプリ独自のキャッシュは別途クリアが必要な場合があります。
2. テスト用ドメインを問い合わせます。nslookup example.com を実行し、応答アドレスと表示されたDNSサーバーを記録します。IPv4のFakeDNSを使う場合は、Aレコードが設定したアドレスプール内にあるか確認してください。
3. アプリの経路を確認します。ブラウザーを再起動し、同じドメイン名にアクセスします。ブラウザーのセキュアDNSはシステムの問い合わせ経路を迂回する場合があります。まず一時的に無効にして比較し、コマンドラインの結果がすべてのアプリに当てはまると考えないでください。
4. ルーティング結果を確認します。コアのアクセスログで、宛先ドメイン名と出力先のタグを確認します。ログの形式はバージョンによって異なるため、「接続成功」という表示だけでなく、想定したドメイン名が復元されているかを確認してください。
5. 直結とプロキシを確認します。既存のルールが適用される宛先をそれぞれ1つ選んでテストし、ドメイン名に一致した後、対応する出力先に進むことを確認します。仮想IPの割り当て地域を見て、直結かプロキシかを判断しないでください。

ipconfig /flushdns
nslookup example.com

nslookup が実際のIPアドレスを返す場合、問い合わせがFakeDNSに届いていない可能性も、そのドメイン名が設計上通常のリゾルバーを使っている可能性もあります。仮想IPが返ってもWebページを開けない場合は、まず仮想ネットワークのルートと対応表からの宛先復元を確認してください。すぐにサブスクリプションを変更したり、複数のノード設定を一括変更したりする必要はありません。

よくある問題：仮想IP、ブラウザーによる迂回、無効化後の接続障害

適した用途と元に戻す手順

透過プロキシでドメイン名を安定して取得する必要があり、DNSと接続を連携できるコンポーネントで処理でき、例外ルールも管理できる場合にFakeDNSが役立ちます。サブスクリプションのノードに付属する機能ではなく、サーバー側のノードが特定のプロトコルを使う必要もありません。設定の中心は、端末側での通信の捕捉とルーティングです。

• 適しているケース：TUN環境でドメイン名によるルーティングが必要で、アプリのプロキシリクエストだけではドメイン名を保持できない場合。または、透過プロキシでDNSの受け入れと宛先復元の経路がすでに明確な場合。
• 通常の名前解決を優先するケース：ブラウザーのシステムプロキシだけを使う場合、LAN内の名前解決に依存する場合、実際のIPアドレスを使った診断が必要な場合、または社内ネットワークのDNSポリシーで管理されている場合。
• 事前に互換性をテストするケース：ゲーム、リアルタイム通信、仮想マシン、複数のVPNを重ねて使う環境。仮想ネットワークとのアドレス範囲の競合に加え、UDPとIPv6にも同じ通信捕捉ルールが適用されるか確認してください。

元に戻すときは、まずDNS設定と通信の捕捉ルールを以前の状態に戻し、新しい問い合わせが正常に処理されることを確認します。次に、該当するTUNまたは透過プロキシを終了し、システムとアプリのキャッシュをクリアします。最後に、ドメイン名の解決と通常のアクセスをそれぞれ確認してください。アプリに古い仮想IPが返されたままアドレスプール設定だけを削除したり、仮想ネットワークのルートを残したままプロキシのプロセスだけを終了したりしないでください。