FakeDNSの仕組みと使い方｜v2rayNGで有効にするタイミング

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

通常のDNS問い合わせでは、ドメイン名がサーバーの実IPアドレスに変換され、アプリはそのIPアドレスへ接続します。通信が透過的に取り込まれると、プロキシのコアは接続先IPしか認識できず、アプリが最初に問い合わせたドメイン名が分からなくなることがあります。その結果、ドメイン名に基づくルーティングルールが適用されず、スニッフィングやIPアドレスによる判定を試すか、デフォルトのアウトバウンドへ送られる場合があります。

FakeDNSは「ドメイン名と仮想IPアドレス」の対応表を管理します。アプリからドメイン名の問い合わせがあると、プール内のアドレスを割り当てます。アプリがそのアドレスへ接続すると、コアがドメイン名を引き戻し、ルーティングに従って直接接続またはプロキシ経由で通信します。このアドレスはWebサーバーのものではなく、そのままインターネットへ送ってはいけません。

XrayのFakeDNSでよく使われるIPv4プールは198.18.0.0/15で、範囲は198.18.0.0から198.19.255.255です。このアドレス帯はネットワーク機器のベンチマーク用に予約されており、インターネット上のWebサイトにアクセスするためのアドレスではありません。また、一般的な家庭内LANのプライベートアドレスとも異なります。DNS応答にこの範囲が含まれていても、それだけでDNSの改ざんを意味するわけではありません。

DNSリークと名前解決の遅延：改善できること、保証できないこと

FakeDNSは、取り込まれたDNS問い合わせに対してローカルで応答できるため、この段階で外部DNSに実IPアドレスを問い合わせる必要がありません。これにより、ローカルDNSに接続先ドメインを知られる機会を減らし、外部問い合わせを待つ時間も省けます。ただし、最終的にはWebサイトの実サーバーを特定する必要があります。名前解決はプロキシサーバー側で行われる場合も、直接接続時に必要となる場合もあります。

「DNSリーク」かどうかは、想定する通信経路と照らして判断しましょう。ルール上、一部のドメインを直接接続する設定なら、そのドメインが直接接続側で名前解決されても、必ずしも設定の不具合ではありません。確認すべきなのは、本来プロキシ経由にするドメインがローカルネットワークのDNSサーバーへ送られていないかです。DNSチェックサイトに表示された事業者だけでは、端末上のすべてのアプリが同じ経路を使っているとは判断できません。

v2rayNGで有効にする前に確認：VPN、DNS、ドメイン名の復元

Android版v2rayNGは通常、システムのVPNサービスで仮想ネットワークインターフェースを作成し、通信をコアに渡して処理します。デスクトップでいうTUNによる通信制御と似た仕組みですが、画面に「TUNモード」という独立したスイッチがあるとは限りません。まずVPNが起動していること、対象アプリが除外されていないことを確認してからFakeDNSを設定しましょう。v2rayNのデスクトップ版メニューをそのまま当てはめることはできません。

「設定」にあるDNS、トラフィックスニッフィング、ルーティングの項目を記録してから、「FakeDNSを有効にする」をオンにします。現在のバージョンで関連する依存設定が案内された場合は、その指示に従って設定してください。念のためといってDNS関連の項目をすべて同時にオンにするのは避けましょう。カスタム設定では画面から自動生成される項目が使われない場合があります。画面のスイッチだけでなく、実際に動作している設定を確認してください。

• 通常の設定：クライアントに用意されたFakeDNS関連の設定を優先し、出所が不明なDNS設定を別途手作業で組み合わせないでください。
• カスタム設定：DNSでfakednsが使われているか、また対応するインバウンドのsniffingとdestOverrideに必要なFakeDNS復元処理が含まれているかを確認します。
• アプリごとのプロキシ：テスト対象のアプリがVPNの通信制御対象に含まれていることを確認します。設定変更後にVPNを再接続し、アプリもいったん終了してから再起動してください。
• システムDNS：Androidの「設定」で「プライベートDNS」を検索し、現在の状態を記録します。独自の暗号化DNSを使用している場合は、VPNとの実際の関係を確認してください。UDP 53のルールですべての問い合わせを取り込めるとは限りません。

ドメインルーティングとIPルーティング：ルールの順序も確認

FakeDNSの主なメリットの一つはドメイン名を復元し、ドメインルールで照合できるようにすることです。たとえば、コアが接続先のドメイン名を復元した後、指定したドメインルールを先に適用し、続いてほかのルールを処理できます。ただし、どのサイトを直接接続するかを決める機能ではなく、不足しているルールを自動で補うこともありません。

ルーティングルールは通常、設定された順に照合されます。カスタムルールで仮想アドレスプール全体を先に直接接続と判定し、その時点で接続先が正しく復元されていないと、到達できないアドレスへ通信が送られる可能性があります。また、「IPアドレスが属する地域」と「ドメインが属するカテゴリ」を混同しないでください。仮想IPはローカルな対応付けを示すだけで、実サーバーの地理的な判定には使えません。

1. まずドメイン名の復元を確認します。利用可能なログまたは実行中の設定で、インバウンドがFakeDNSのアドレスを復元できているか確認します。最初に198.18.0.0/15への直接接続ルールを追加するのは避けてください。
2. 次にドメインルールを確認します。指定ドメイン、ドメインリスト、デフォルトのアウトバウンドが想定どおりの順序になっているか、特に条件の広いルールが早い段階で適用されていないかを確認します。
3. 最後にIPアドレスによる判定を確認します。IPIfNonMatchやIPOnDemandなどのドメイン名前解決方式が有効な場合、ルーティング中に実アドレスの名前解決が行われることがあります。これはFakeDNSが自動的に無効になった証拠ではありません。
4. LANは個別にテストします。プリンター、ルーターの管理画面、内部ドメインではローカルDNSが必要な場合があります。明示的なLAN接続ルールを維持し、VPNのルーティング対象に該当アドレスが含まれているか確認してください。

有効化と元に戻す方法：同じアプリで一項目ずつ検証

ノードには接続できているものの、通信を透過的に取り込んだ後にドメインルールが適用されないことが多い、または取り込まれた通常のDNS問い合わせで明らかに待たされる場合は、FakeDNSを試す価値があります。現在の名前解決とルーティングが安定しているなら、有効にしても目に見える効果がないことがあります。サーバーの接続拒否、TLSハンドシェイクの失敗、サブスクリプションの更新失敗などは、まずそれぞれの原因を調べてください。FakeDNSはあらゆる障害を解決する機能ではありません。

1. 変更前の状態を記録します。FakeDNSをオフにし、ノード、ルーティング、ネットワークを変えずに、ブラウザー、対象アプリ、LAN上のサービスを確認します。「速い」「遅い」だけでなく、接続できるか、想定したアウトバウンドを通るかを記録してください。
2. FakeDNS関連の設定だけを変更します。「設定」で機能と、クライアントが必要と案内する項目を有効にしてから、VPNを停止・再起動します。このとき、ノード、DNSサービス、ルーティングモードは同時に変更しないでください。
3. 古い接続の影響を取り除きます。テスト対象のアプリを完全に終了してから再起動します。アプリがDNSキャッシュを使い続ける場合は、強制停止してから再テストしてください。ブラウザーでは「セキュアDNS」の設定も確認します。
4. DNS応答と接続の両方を確認します。通常のDNSテストではプール内のアドレスが表示されることがあります。その後、実際にサイトへアクセスできる必要があります。DNS応答だけ成功して接続に失敗する場合は、アドレス対応の復元、VPNによる通信制御、古いキャッシュを重点的に確認してください。
5. 問題があれば設定を元に戻します。元のスイッチ設定に戻し、VPNを再起動してからアプリを開き直します。古い仮想アドレスが残っている場合は、アプリのキャッシュが消えるまで待つか端末を再起動してください。仮想IPを固定して長期的に使う方法で回避しないでください。

FakeDNSのよくある問題：見慣れないアドレス、アプリの不具合、ネットワーク切り替え