FakeDNSは、IP通信からドメイン名を復元する必要があるトラフィックの取り込みに向いています。すべての接続で有効にすべき高速化機能ではありません。DNSクエリ、仮想アドレスの割り当て、インバウンドのスニッフィング、ルーティングの関係を把握し、v2rayNが実際に使うコアも確認しましょう。この記事ではXrayの設定項目、Windowsでの確認手順、無効化後のキャッシュ削除方法を解説し、「名前解決できるのに接続がタイムアウトする」問題を防ぎます。
FakeDNSの仕組み:実IPを調べずに仮想アドレスを返す
通常のDNSは上位サーバーにドメイン名のAレコードまたはAAAAレコードを問い合わせ、実際のアドレスを取得してから接続します。一方、FakeDNSはローカルに「ドメイン名と仮想IP」の対応表を保持します。アプリからドメイン名の問い合わせがあると、指定したアドレスプールからアドレスを割り当てて返します。このアドレスはWebサーバーのものではなく、対応表なしでは接続先として使えません。
たとえば、アプリがexample.comを問い合わせると、ローカルからプール内の198.18.x.xのいずれかが返されます。アプリがそのアドレスに接続した後、通信は同じ対応表を参照できる処理経路に入る必要があります。そこで初めてXrayが元のドメイン名を復元し、ドメインルールに照合して、適切な出力先へリクエストを渡せます。通信が取り込み経路を迂回すると、そのWebサイトに割り当てられていない仮想アドレスへ接続しようとするだけです。
この仕組みから、FakeDNSがTUNと併用されることが多い理由がわかります。仮想ネットワークインターフェースで、アプリからこれらのアドレスに向かうIP通信を取り込めるためです。ただし、TUNは通信を取り込む入口にすぎません。DNSクエリも自動的にFakeDNSへ送られるわけではなく、異なるコア間で対応表が共有される保証もありません。DNSクエリと後続の接続が一連の経路としてつながっている必要があります。
アドレスプールとマッピング容量:3つの数値の見方
XrayのFakeDNS設定では、ipPoolとpoolSizeを指定できます。以下はIPv4の設定例で、数値は設定項目の意味を示すものです。すべてのクライアントで同じ値が初期設定になっているわけではありません。アドレスプールとマッピング容量は別の設定です。ネットワーク範囲が広いからといって、マッピングが回収されないとは限りません。
198.18.0.0/15は、ネットワークのベンチマークテスト用に予約されたアドレス範囲です。インターネット上のWebサイトのアドレスでも、一般家庭のLANで使うプライベートアドレス範囲でもありません。企業のテストネットワークや別のトンネルですでに使われていれば、ルートが競合する可能性があります。有効にする前にローカルのルーティングを確認しましょう。「予約済み」だから競合しないとは限りません。
{
"fakedns": [
{
"ipPool": "198.18.0.0/15",
"poolSize": 65535
}
],
"dns": {
"servers": [
"fakedns"
]
}
}
これはXray設定の一部であり、クライアント全体の設定ではありません。インバウンド、アウトバウンド、DNSの取り込み、ルーティングルールは含まれておらず、直接接続する宛先の実アドレスを解決する設定もありません。このまま接続に使えるファイルではありません。マッピングは実行中に保持される状態なので、コアを再起動した後も以前のアドレスが同じドメイン名に対応するとは限りません。
ポイント:容量の調整より先に、処理経路がつながっているか確認
DNSから仮想アドレスが返されてもWebページを開けない場合は、まず通信が同じ処理経路に戻っているか、ドメイン名を復元できているかを確認してください。poolSizeを大きくしても、DNSの迂回、インバウンドのスニッフィング不足、仮想ネットワーク範囲を誤って直接接続する問題は解決しません。
FakeDNS・通常のDNS・ドメイン名スニッフィングの違い
FakeDNSは暗号化DNSでも、HTTPやTLSのスニッフィングでもありません。FakeDNSは対応関係を作り、スニッフィングは通信内容からドメイン名を特定します。XrayのFakeDNSは対応表を使って名前を復元するため、すべての接続でアプリケーション層からホスト名を読み取れる必要はありません。それでも、アプリが実IPアドレスへ直接アクセスし、対応するドメイン名の問い合わせが発生していない場合、FakeDNSがドメイン名を推測することはできません。
| 方式 | 主な役割 | 利用上の制約 |
|---|---|---|
| 通常のDNS | 接続先の実際のAレコード・AAAAレコードを問い合わせる | 直接接続する宛先には、最終的に到達可能なアドレスが必要 |
| FakeDNS | 仮想アドレスを返し、ドメイン名との対応を保存する | 後続の接続は、対応表を使う処理経路を通る必要がある |
| HTTP・TLSスニッフィング | プロトコルの通信内容からホスト名を特定する | プロトコル、暗号化方式、ハンドシェイクの内容に左右される |
| DoH、DoT | DNSクエリの通信経路を保護する | 仮想アドレスのマッピングやルーティングによる振り分けは自動で行わない |
プロキシ経由にするドメインでは、FakeDNSを使うとクライアントが実IPアドレスの応答を待つ段階を省けます。プロキシの出力先がドメイン名をリモート側に渡す方式なら、その後の経路で名前解決できます。一方、直接接続するWebサイトには実アドレスが必要です。名前解決にかかる処理が別の場所に移るだけで、接続全体からなくなるわけではありません。Webページの読み込み速度は、ノードの遅延、パケットロス、サーバーの応答、リソース数にも左右されるため、一定の速度向上は保証できません。
- 向いている環境:アプリが主にIP接続を行い、TUNで安定して通信を取り込めていて、ドメインルールの照合に使える情報を増やしたい場合。
- 優先して有効にする必要はありません:ブラウザーがプロキシプロトコルでドメイン名を渡しており、現在のシステムプロキシも正常に動作し、ドメイン名が失われる問題がない場合。
- 慎重に検討してください:企業内ネットワーク、LAN機器の検出、実際の名前解決結果に依存するソフトウェア、別の仮想ネットワークインターフェースとの併用環境。
- 代替にはなりません:正しいサブスクリプション情報、利用可能なノード、正確なシステム時刻、サーバー側の対応。
v2rayNで有効にする前に、コアとDNSの経路を確認
v2rayNはクライアントの画面を提供し、Xrayは呼び出して使うコアです。画面に「TUN」と表示されていても、そのモードがXrayのfakedns項目を読み込むとは限りません。動作モードによって設定の生成経路が異なり、実際に使われる項目や通信の取り込み方法も変わる場合があります。起動ログに記録されたコア名、バージョン、設定の読み込み結果を確認してから、この記事のXray設定項目を使うか判断してください。
- 現在の状態を記録:設定をバックアップします。まずTUNを無効にし、従来のシステムプロキシで同じノードから対象のWebページにアクセスできるか確認します。現在のDNS、ルーティングモード、ローカルポートも控えておきます。
- 設定を確認:v2rayNの「設定」→「パラメータ設定」でコアとインバウンド関連の設定を確認し、「設定」→「DNS設定」に現在の設定内容があるかも確認します。バージョンによってメニュー名が異なる場合があるため、実際の画面に従ってください。
- 生成された設定を確認:実行時の設定に、想定した
fakedns、DNSサーバー一覧、インバウンドのsniffing項目が含まれているかを確認します。スイッチがオンになっていることだけで有効と判断しないでください。 - 通信の取り込み範囲を確認:DNSクエリが想定したローカルの処理経路に入り、仮想ネットワーク範囲への接続も取り込まれる必要があります。ブラウザーのセキュアDNS、アプリ内蔵のDoH、IPv6の問い合わせがこの経路を迂回しないか確認してください。
- 1項目ずつ確認:保存後、クライアントの手順に従ってコアを再起動し、まずプロキシ経由の接続先と直接接続先を1つずつ確認してから、LAN内のサービスをテストします。一度に変更する設定は1種類にしてください。
Xrayのアドレスマッピング側
- アドレスプールの項目
fakedns[].ipPool- 容量の項目
fakedns[].poolSize- DNSの入口
dns.servers内のfakedns- 設定例の範囲
198.18.0.0/15
これらの項目はマッピングと名前解決を管理しますが、システムの仮想ネットワークインターフェースを自動で作成するものではありません。
Xrayのインバウンドによる復元側
- スニッフィングの有効化
sniffing.enabledをtrueにする- 復元対象の種類
destOverrideにfakednsを含める- 接続先の処理
routeOnlyと出力先の要件を確認- 必要な条件
- 接続がマッピングを保持する処理経路に入ること
ルール照合に使うだけでは、接続先が置き換わったことにはなりません。最終的に仮想IPをインターネット上の接続先として送信しないでください。
特にrouteOnlyに注意してください。復元したドメイン名をルール照合だけに使う場合と、接続先として使う場合は異なります。後続の出力先が仮想IPのまま接続しようとすると、タイムアウトする可能性があります。使用中のコアの設定説明と、出力先を含む全体の設計を確認してください。特定の真偽値だけを単独でコピーしないでください。
確認方法:名前解決の結果と接続ログをあわせて見る
198.18.x.xのアドレスが表示されても、その問い合わせで仮想アドレスが返ったことしか確認できず、プロキシ経由の接続が成功した証明にはなりません。逆にWebページが開けても、ブラウザーがシステムDNSを迂回している可能性があります。「問い合わせがどの経路を通ったか」と「接続が最終的にどこへ送られたか」の両方を確認してください。
- ブラウザーで開いているテスト用タブを閉じます。Windowsのターミナルで
ipconfig /flushdnsを実行し、ブラウザーを完全に終了してから再起動すると、古いキャッシュの影響を避けられます。 - 以下のコマンドで、システムが現在使っている名前解決経路からプール内のアドレスが返るか確認します。外部DNSを指定すると、従来のシステム経路をテストできません。
- 同じドメイン名にアクセスし、コアのログに記録された接続先ドメイン名と出力先のタグを確認します。必要な場合だけ一時的にログレベルを上げ、確認後は元に戻してください。アクセス情報を長期間記録しすぎないようにします。
- 続いて、直接接続するはずの接続先を1つ確認し、仮想IPが最終的なサーバーアドレスとして使われていないことを確かめます。ルーターやLAN内のサービスにも引き続きアクセスできるか確認してください。
ipconfig /flushdns
nslookup example.com
route print
nslookupは通常のDNSクエリを確認するためのもので、ブラウザー内蔵のDoHの動作を示すものではありません。route printでは仮想ネットワーク範囲のルーティング先を確認できます。ただし、その範囲が個別に表示されなくても、直ちに通信の取り込みに失敗したとは限りません。TUNの設定によっては、より広い範囲のルートが使われるためです。インターフェース、メトリック、クライアントのログをあわせて判断してください。
完了の目安:プロキシ、直接接続、終了後の復旧を確認
プロキシ経由のドメインが想定どおりの出力先へ進み、直接接続先にもアクセスでき、FakeDNSを無効にしてキャッシュを消した後に通常の名前解決が戻ることを確認できれば、テスト完了です。速度測定を1回行うだけで、これら3項目の確認に代えないでください。
よくある問題:キャッシュ、IPv6、無効化後の復旧
TUNを無効にしたら、さっきまで開けたサイトがすべてタイムアウトするのはなぜ?
システムやアプリに仮想アドレスがキャッシュされている一方で、名前を復元する処理経路が停止している可能性があります。まず元のDNSとシステムプロキシの設定に戻し、ipconfig /flushdnsを実行してから、ブラウザーを完全に終了し、再起動してください。特定のアプリだけで問題が起きる場合は、そのアプリのDNSキャッシュを削除するかアプリを再起動します。ノードを何度も切り替える必要はありません。
FakeDNSを有効にしたのに、問い合わせ結果が実IPアドレスになるのはなぜ?
まず、問い合わせがFakeDNSを設定したコアに届いているか確認し、次にDNSルールでそのドメイン名に実際のDNSサーバーが選ばれていないか確認してください。ブラウザーのセキュアDNS、アプリ内蔵の名前解決、別のネットワークインターフェース上のDNSが迂回経路になることがあります。仮想アドレスを返すためだけに、システムDNSを安易に127.0.0.1へ変更しないでください。そのアドレスで確実に待ち受けるサービスがあり、安定して稼働する必要があります。
IPv4では接続できるのに、一部のサイトが開かないのはなぜ?
AAAAクエリとIPv6接続の処理方法を確認してください。IPv4アドレスプールだけを設定しても、IPv6が同じ方針で処理されるとは限りません。実際のIPv6接続が別の経路を通ることもあります。DNS応答、通信の取り込み範囲、ルーティングルールの整合性を保ち、AとAAAAのクエリを個別にテストしてください。どの環境でもIPv6を無効にすれば直るとは限りません。
コアを再起動した後、以前の接続を使い続けられないのはなぜ?
実行中のマッピングが再作成された一方で、アプリが以前の仮想IPを保持している可能性があります。まずキャッシュを消して接続を作り直し、マッピングの復元結果と出力ログを確認してください。設定を元に戻す場合は、バックアップしたDNSとルーティング設定を復元し、クライアントの手順に従ってコアを再起動した後、通常の名前解決と直接接続を確認します。画面上のスイッチを1つ切るだけで完了としないでください。
FakeDNSの役割は、特定の通信取り込み経路でドメイン名の情報を保持することです。VMessやVLESSの認証情報を変更するものではなく、無効なサブスクリプションや到達できないノードを修復するものでもありません。基本の接続が安定し、ドメイン別ルーティングが必要で、設定の検証と復旧もできる場合に有効化を検討してください。ブラウザーが時々遅くなるだけなら、まず「よくある問題」にあるシステムプロキシ、DNS、ルーティングの手順で原因を絞り込みましょう。