FakeDNSはドメイン名を一時的に仮想IPへ割り当て、接続がプロキシに入った段階でドメイン名に戻します。ドメイン情報を保持したい透過プロキシに適していますが、単独で通信を高速化する機能ではありません。アドレスの割り当て、DNSの制御、TUN経由の転送、スニッフィングによる復元の4段階に分けて、仕組みや設定例、確認方法、無効化後の戻し方を解説します。接続が安定しており、DNS設定を見直したい方向けです。
FakeDNSとは：Webサイトの実IPではなく、対応付け用アドレスを返す仕組み
通常のDNSはドメイン名をサーバーの実IPアドレスに変換します。一方、FakeDNSはまず、現在のプロキシ経路で識別するためのアドレスを割り当てます。たとえば、アプリがexample.comを問い合わせると、FakeDNSはプール内の198.18.0.1を返し、同時に両者の対応関係をメモリに記録します。このアドレスはWebサイトのサーバーではなく、インターネット上の通常の経路でアクセスするものでもありません。
続いてアプリは仮想アドレスへ接続します。接続を受け取ったプロキシは、対応表から元のドメイン名を復元し、ドメイン名に基づくルールで直結かプロキシ経由かを判断します。最終的に実IPを取得する方法は、アウトバウンドの種類と名前解決の設定によって異なります。ローカルの直結アウトバウンドが名前解決する場合もあれば、ドメイン名をリモートプロキシに渡す場合もあります。FakeDNSを使っても、実際のサーバーへの接続が不要になるわけではありません。
よく使われる例は198.18.0.0/15で、198.18.0.0から198.19.255.255までの特殊用途アドレス空間です。もともとはネットワーク機器のベンチマーク用で、一般公開されているWebサイトのアドレスでも、一般的な家庭内LANで使うプライベートアドレス帯でもありません。仮想アドレスのプールに使う前に、社内ネットワークや検証環境で実際に使われていないことを確認してください。
FakeDNS・スニッフィング・TUNの役割
3つの機能は同じ設定画面に並ぶことがありますが、役割はそれぞれ異なります。FakeDNSはアドレスとドメイン名の対応関係を管理します。TUNは仮想ネットワークインターフェースを通じて、対象のIP通信をクライアントへ送ります。スニッフィングやインバウンドの宛先復元機能は、接続情報からルーティングやアウトバウンドに使える宛先を特定します。どれか1つだけを有効にしても、通信経路全体が成立するとは限りません。
| 段階 | 役割 | 機能がない場合に起きること |
|---|---|---|
| FakeDNS | DNS問い合わせに仮想アドレスを割り当て、ドメイン名との対応を保存する | アプリには実IPが返るため、対応付けの経路が機能しているか判断できない |
| TUNまたは透過的な通信の取り込み | 仮想アドレス宛ての接続をプロキシに戻す | アプリが仮想アドレスを取得しても、接続が対応するプロキシのインバウンドに入らない |
| FakeDNSの宛先復元 | 対応表を参照して、仮想アドレスをドメイン名に戻す | ログに仮想アドレスが残り続け、アウトバウンドが誤った宛先へ接続しようとする |
| 実DNSとアウトバウンド | 必要な実IPの名前解決を行い、サーバーに接続する | ドメイン名の復元には成功しても、直結時の名前解決やプロキシ経由の接続に失敗する |
HTTP HostやTLS SNIのスニッフィングと、FakeDNSによる対応関係の復元は同じものではありません。前者はプロトコルデータからドメイン名を特定しようとするため、プロトコルや暗号化方式、アプリの動作に左右されます。FakeDNSの復元は、事前に保存した対応関係を主に利用します。アプリが実IPへ直接接続する場合や、クライアントを介さずに名前解決する場合、前回の起動時に残った仮想アドレスを使う場合には、対応関係を参照できないことがあります。
確認のポイント：DNS問い合わせと接続が同じ対応付けの経路を通っているか
あるFakeDNSがアドレスを割り当てても、接続が別のプロセスや別の対応表に入るなら、まず通信の取り込み経路を修正してください。VMessやVLESSへの切り替え、ノードの変更では、失われたドメイン名の対応関係を補えません。
有効にする前に確認：ドメイン名ベースのルールと通信の取り込み条件
FakeDNSを検討するのは、透過プロキシが主にIPアドレス宛ての接続を受け取り、ルーティングには元のドメイン名が必要な場合です。実IPを先に取得してから、そのIPがどのドメイン名に属するか推測する曖昧さを減らせます。また、ローカルで実IPを取得する前に後続の処理へ進められるリクエストもあります。ただし、ダウンロード速度を上げる機能ではなく、ノードの帯域幅や回線の混雑状況も変わりません。
- 試す価値があるケース：TUNが安定して動作しており、ドメイン名で通信を振り分けたい場合。DNS問い合わせ、仮想アドレスへのルーティング、宛先の復元をクライアントがまとめて処理できることが条件です。
- 通常は追加不要：システムプロキシだけを使い、アプリがHTTP CONNECTやドメイン名を指定できるSOCKSリクエストでプロキシにドメイン名を渡しており、現在のルールも正しく適用されている場合。
- 実IPでの名前解決を優先：社内ネットワーク、LAN機器の検出、実IPによるアクセス制御が必要なソフトウェア、名前解決結果を直接確認するネットワーク診断。
- 有効化を保留：別のVPNや透過プロキシも同時に動作しており、DNSやデフォルトルート、仮想アドレス帯をどちらが管理しているか確認できていない場合。
ブラウザー内蔵のセキュアDNSやアプリ独自のDoHも確認が必要です。従来のUDP 53の問い合わせを取り込めても、HTTPS経由のDNS問い合わせまでFakeDNSに渡るとは限りません。443番ポートを遮断すると通常のWeb閲覧にも支障が出るため、一般的な対処法にはなりません。アプリ側のDNS設定を確認し、アプリ自身が名前解決するのか、クライアントに一元管理させるのかを決めてください。
設定項目：アドレスプール・DNS・インバウンドでの復元を連携させる
v2rayNはデスクトップクライアント、v2rayNGはXrayコアを使うAndroidクライアント、v2flyNGはv2flyコアを使うクライアントです。各クライアントの画面ではコアの設定を生成または読み込みますが、メニューや利用できる設定項目、生成される内容はそれぞれ異なります。特定クライアントの画面を、すべてのバージョンに共通する手順として扱わないでください。実際に稼働しているコアが受け付ける設定とログを基準に確認します。
アドレス割り当て側
- アドレスプールの項目
fakedns[].ipPool- ネットワーク範囲の例
198.18.0.0/15- 容量の項目
fakedns[].poolSize- 容量の例
65535件のマッピング容量
容量は有効期間や同時接続数の上限ではありません。マッピングの削除・入れ替え動作は、使用するコアの実装に応じて確認してください。
問い合わせと復元側
- DNSサーバーの項目
dns.servers内のfakedns- インバウンドの設定
sniffing.enabled- 復元タイプ
destOverride内のfakedns- 通信の条件
- 仮想アドレス宛ての接続が対象のインバウンドに入る
DNSを設定しただけでは、システムの問い合わせが取り込まれるとは限りません。クライアントのDNS転送設定とルーティングも確認してください。
以下は各項目の関係を理解するためのJSON例で、一般的なV2Ray形式のIPv4 FakeDNS設定を示しています。インバウンド、アウトバウンド、ルーティング、実DNSの設定は省略しているため、クライアントの設定全体を置き換えて使えるものではありません。Xrayとv2flyではバージョンによって動作や項目が異なる場合があります。保存前に、使用中のコアが対応していることを確認してください。
{
"fakedns": [
{
"ipPool": "198.18.0.0/15",
"poolSize": 65535
}
],
"dns": {
"servers": [
"fakedns"
]
}
}仮想アドレス宛ての接続を復元するインバウンドでは、次のようなスニッフィング設定がよく使われます。ここでのfakednsは宛先を復元するタイプであり、HTTPやTLSのスニッフィング機能をすべて有効にするという意味ではありません。「設定項目を揃える」ために、別バージョンのタイプ名までまとめてコピーしないでください。
{
"sniffing": {
"enabled": true,
"destOverride": [
"fakedns"
]
}
}有効化後の確認：DNS・マッピング・ルーティングを順にチェック
確認すべきなのは「設定が有効」と表示されることではなく、1回のアクセスでドメイン名の問い合わせから最終的なアウトバウンドまで正しく処理されることです。まず現在のプロキシモード、DNS設定、コアの種類を記録し、設定は1項目ずつ変更してください。サブスクリプションに含まれるサーバーアドレス、ポート、ユーザー識別子はFakeDNSのアドレスプール設定ではないため、テストのために変更する必要はありません。
- 変更前の状態を記録する。FakeDNSを無効にした状態で、同じネットワークから対象サイトにアクセスできることを確認します。システムプロキシとTUNのどちらを使っているか記録し、現在の設定を保存してください。
- 問い合わせ経路を確認する。有効にした後、名前解決を新たに実行するドメイン名でアクセスし、DNSログが想定した処理経路に入るか確認します。FakeDNSを使う設定なら、応答が設定したアドレスプールの範囲内にあることも確認してください。
- 接続が戻る経路を確認する。接続ログまたはコアのログを見て、仮想アドレスへの接続がプロキシに入り、ログで確認できる段階でドメイン名に復元されることを確認します。表示される情報はログレベルによって異なるため、IPアドレスが記録された1行だけで失敗と判断しないでください。
- 振り分け結果を確認する。直結する想定のドメイン名とプロキシ経由にする想定のドメイン名をそれぞれ試し、実際のアウトバウンドを確認します。Webページを開けるかどうかだけでは、ルールが正しく適用された証拠になりません。
- 互換性を追加確認する。LANサービス、アプリ内ログイン、バックグラウンド通信を確認してください。IPv6を有効にしている場合はAAAAレコードの問い合わせも確認し、Aレコードだけのテストで全通信が取り込まれたと思い込まないようにします。
Windowsではipconfig /flushdnsを実行してシステムのDNSキャッシュを削除できます。ブラウザーなどのアプリには独自のキャッシュや接続が残る場合があるため、アプリを終了してから再起動してください。Androidではクライアントの接続を停止してから、テストするアプリを終了し、再度起動します。新しい結果を得ようとして、ネットワーク、ノード、プロトコル、DNSを同時に何度も切り替えないでください。比較の意味がなくなります。
テストの注意点：アドレスプールから応答があっても成功とは限らない
問い合わせに対して仮想アドレスが返れば、アドレスの割り当て処理が行われたことは確認できます。設定が一連の流れとして機能していると判断するには、接続が正しいインバウンドに入り、ドメイン名が復元され、想定したアウトバウンドに振り分けられることも確認してください。
よくある質問：遅延・名前解決結果・再起動後の接続不良
有効にすると名前解決は速いのに、ダウンロード速度が変わらないのはなぜですか？
仮想アドレスを返すことで短縮されるのは、ローカルでの名前解決待ちの一部です。リモートノードの帯域幅は向上しません。Webページを初めて開くまでの時間と、ダウンロード中の速度を分けて記録してください。ダウンロードが遅いままなら、回線、ノードの負荷、パケットロスを確認しましょう。アドレスプールを広げても改善しません。
名前解決ツールが実IPを返しました。FakeDNSが機能していないのでしょうか？
まず、そのツールが実際にどのDNSサーバーへ問い合わせたか、そのドメイン名がFakeDNSの対象かを確認してください。ツールがシステムの名前解決機能を使わず、別のサーバーを明示して問い合わせている場合や、実DNSを使う例外ルールに該当している場合があります。1回の問い合わせ結果だけで判断せず、DNSログと合わせて経路を確認してください。
クライアントの再起動後、一部のアプリが突然接続できなくなりました。
アプリが古い仮想アドレスをキャッシュしている一方で、新しいプロセスでは対応表が作り直されている可能性があります。まず該当アプリを終了し、削除できるDNSキャッシュを消してから、名前解決と接続をやり直してください。クライアントの再起動後も以前のアドレスとの対応関係が残るとは限りません。
LAN内のドメイン名やプリンター接続に問題がある場合、どこを変更すればよいですか？
まず一時的に実DNSへ戻して、問題との関連を確認してください。そのうえで、クライアントが対応するDNSの振り分けや直結ルールを使い、LAN内のドメイン名を処理します。LAN内のDNSサーバーに問い合わせる必要がある名前を、すべて仮想アドレスプールに送らないでください。社内ネットワークでは、アドレスプールと既存のルーティングが競合しないことも確認してください。
無効化と復元：DNSの割り当てと通信の取り込みを両方解除する
無効化するときは、DNSがアプリに仮想アドレスを返し続ける一方で、復元を担うインバウンドやTUNが停止する中途半端な状態に注意してください。テスト中のアプリを一時停止し、DNSとプロキシ設定を元の組み合わせに戻してから、接続を再起動し、古いキャッシュを削除するのが安全です。クライアントにFakeDNSの一括設定がある場合は、コア設定の1行だけを手動で削除するのではなく、同じ設定画面から元に戻してください。
- DNSを復元する：新たな問い合わせで想定どおりの実IPが返ること、システムに到達不能なローカルDNSアドレスが残っていないことを確認します。
- ルーティングを復元する：不要になった仮想アドレスプールのルート、仮想インターフェース、通信の取り込みルールがクライアントによって正常に解除されたことを確認します。
- アプリを復元する：古い接続を閉じ、ドメイン名を再解決してから、Webページ、LANサービス、バックグラウンド通信を確認します。
- 調査に役立つ情報を残す：どの段階で問題が起きたか、特定のアプリだけに影響するかを記録します。ログを共有する前に、サブスクリプションのURLやユーザー識別子などの機密情報を削除してください。
FakeDNSの利点は、透過プロキシのルーティング判断にドメイン名の情報を戻せることです。システムプロキシが安定して動いているなら、設定をシンプルに保つほうが管理しやすくなります。ドメイン名での振り分けが必要なTUN環境では、DNS問い合わせ、マッピング、インバウンド、アウトバウンドが連携しているかが重要です。基本設定については総合ガイドのDNS設定を参照し、まず通常の名前解決経路を確認してから、仮想アドレスの仕組みを追加してください。