FakeDNSは仮想IPにドメイン情報をひも付ける仕組みで、ドメイン単位のルーティングが必要な透過プロキシ環境に適しています。DNS応答、接続の捕捉、ドメインの復元という流れを解説し、コアの設定例やTUNの確認手順、元に戻す方法も紹介します。大切なのは万能な設定を探すことではなく、DNS問い合わせと後続の接続が、同じ復元可能な処理経路を通るか確認することです。
FakeDNSとは：仮想IPでドメインを識別する仕組み
通常のDNSは、ドメインを接続先の実IPアドレスに変換します。一方FakeDNSは、指定されたアドレスプールから仮想IPを選んでアプリに返し、「ドメインと仮想IP」の対応関係を記録します。アプリは通常どおり接続しますが、そのIPはWebサーバーの実アドレスではないため、ローカルプロキシが接続を受け取り、後続の処理を行う必要があります。
たとえば、アプリがexample.comを問い合わせると、ローカルのFakeDNSは198.18.0.1を割り当てることがあります。アプリがこのアドレスの443番ポートに接続すると、プロキシは対応表を参照して接続先をexample.com:443に復元し、ドメインルールに照らして出力先を選択します。このアドレスは処理の例であり、実際の問い合わせで必ず同じアドレスが割り当てられるわけではありません。
FakeDNSが解決するのは、「接続がプロキシに届いた時点でIPアドレスしか残っておらず、ドメイン情報が失われている」という問題です。サーバーやノードを提供するものではなく、VMess、VLESS、Trojanの代替でもありません。REALITYのハンドシェイク設定にも影響しません。サブスクリプションは接続情報を提供し、FakeDNSはローカル接続とドメインの対応を保持します。両者の役割は異なります。
ドメインの復元と通常のスニッフィングの違い
通常のプロトコルスニッフィングは、HTTPのHostやTLS ClientHelloで確認できるサーバー名など、接続内のアプリケーション層情報を解析します。一方、FakeDNSによる復元は、事前に保存した対応関係を利用するため、アプリが通信内容にドメインを含めるのを待つ必要がありません。両方を併用できますが、「HTTP/TLSスニッフィングを有効にする」だけで「FakeDNSの設定も完了した」とは言えません。
- マッピングによる復元：接続先の仮想IPからドメインを検索します。IPを割り当てた側と接続を受け取る側で、有効なマッピングを共有している必要があります。
- プロトコルスニッフィング：接続内容からドメインを抽出します。識別可能なドメイン情報が含まれない通信では、取得できるとは限りません。
- ドメインルーティング：取得したドメインをルールに照合します。ドメインを復元できても、必ずルールに一致するわけではありません。ルールの順序と出力先も確認してください。
- 実際の接続：プロキシ経由の出力では、ドメイン名の解決をリモート側に任せる場合があります。直接接続では通常、実IPアドレスの取得が必要です。具体的な動作はコアと出力設定によって異なります。
FakeDNSを有効にしても、実DNSが完全に不要になるわけではありません。アプリ側では実IPの名前解決を待つ手順を省ける場合がありますが、直接接続の確立やノードのドメイン名解決などでは、実DNSが必要になることがあります。リモートプロキシ経由の場合、接続先ドメインをリモート側で解決することもあります。
FakeDNSとTUN：接続する必要がある2つの入口
TUNは仮想ネットワークインターフェースを提供し、ルーティング条件に合うIP通信を受け取ります。FakeDNSは仮想DNS応答とマッピングを提供します。TUNを使うと、仮想IP宛ての接続をプロキシに戻せるため、両者はよく併用されます。ただし、TUNを有効にしただけで、すべてのDNSが制御されるわけでも、特定のFakeDNS実装が使われるわけでもありません。
DNS処理の入口
- 入力
- アプリから送信されたドメイン名の問い合わせ
- 処理
- 指定されたDNSモジュールが仮想IPを割り当てる
- 確認項目
- システムDNS、アプリの暗号化DNS、IPv6の問い合わせ
問い合わせがこの入口を通らなければ、後続の復元に使えるマッピングは作成されません。
接続処理の入口
- 入力
- アプリから仮想IP宛てに送られた接続
- 処理
- TUNが受け取り、対応するマッピング復元処理に渡す
- 確認項目
- 仮想アドレス帯のルーティング、マッピングの有効期間、出力先
マッピングを認識できない別のコアに、仮想IPをそのまま渡さないでください。
v2rayNでは、TUN経由の処理と通常のプロキシ経由の処理で、設定の生成方法や使用するモジュールが異なる場合があります。あるコア向けのfakedns JSONを、別のTUN設定形式にそのまま貼り付けないでください。まず現在選択しているコア、使用中の設定、ログを確認し、どのレイヤーがDNSを処理しているかを特定してください。
- まずTUNを無効にし、従来のシステムプロキシでノードに接続できるか確認して、サブスクリプションやサーバー側の問題を切り分けます。
- v2rayNの「設定」→「パラメーター設定」を開き、現在のバージョンで利用できるコアと関連項目を確認してください。タブ名はバージョンによって異なる場合があるため、実際の画面を基準にしてください。
- TUNを有効にしたらシステムルートを確認し、仮想アドレス帯への通信が物理ゲートウェイではなく、制御対象の経路に入っていることを確かめます。
- DNSの制御設定と、アプリ独自の暗号化DNS設定も確認してください。通信だけを捕捉し、ドメインのマッピングが作成されていない状態を避ける必要があります。
V2Ray / Xrayの設定：割り当てと復元をセットで行う
以下は、該当フィールドに対応したV2Ray / Xrayコアの設定例です。フィールド間の関係を示すもので、v2rayNにインポートできる完全な設定ではありません。インバウンドの待ち受け、ノードのアウトバウンド、完全なルーティングルールは含まれていません。GUIクライアントが設定を自動生成することも多く、生成ファイルを編集しても次回の保存時に上書きされる場合があります。
{
"dns": {
"servers": ["fakedns"]
},
"fakedns": [
{
"ipPool": "198.18.0.0/15",
"poolSize": 4096
}
]
}dns.servers内のfakednsは、仮想DNS応答を使う指定です。トップレベルのfakednsではアドレスプールと容量を定義します。この例の4096は容量の一例であり、すべてのコアの既定値でも性能指標でもありません。実際のDNS問い合わせをこのDNSモジュールに送る設定も必要です。フィールドを追加しただけでは、システムの問い合わせは自動的に制御されません。
仮想IP宛ての接続を受け取るインバウンドでは、対応する復元機能も有効にする必要があります。以下のsniffingオブジェクトは、該当するインバウンドオブジェクトに組み込んでください。独立したトップレベル設定ではありません。実際に使うコアが各フィールドに対応しているか確認してください。
{
"sniffing": {
"enabled": true,
"destOverride": ["fakedns"],
"routeOnly": false
}
}enabledは、このインバウンドのスニッフィング処理を有効にします。destOverride内のfakednsは、仮想IPのマッピングを使って接続先を復元する指定です。- この例では
routeOnly: falseを指定し、復元した情報をルーティング判定だけでなく、接続先の置き換えにも使います。アウトバウンドの動作を理解しないまま、ルーティング判定のみに変更しないでください。 - プロキシ経由で接続する場合は、復元したドメインがプロキシ経路に渡されることを確認してください。直接接続する場合は、実IPを取得できる名前解決経路を用意し、再び仮想IPが返されてループするのを防ぎます。
geosite:ルールはドメインの分類に一致し、geoip:ルールはIPアドレスの分類に一致します。仮想IPは接続先サーバーの所在地を示すものではないため、実際の接続先IPの地域判定によるルーティングには使えません。
有効にする場面：接続方式に応じて判断
アプリがHTTPプロキシやドメイン名を含むSOCKSリクエストを使って接続している場合、プロキシはすでにドメインを取得できている可能性があり、FakeDNSを追加するメリットは限られます。透過的に通信を制御しているため接続先IPしか見えず、ドメインルールを安定して使いたい場合に適しています。
| 利用場面 | 推奨 | まず確認すること |
|---|---|---|
| TUNで通信を制御し、主にドメインでルーティングする | 有効化を検討 | DNS問い合わせと接続でマッピングを共有できるか |
| ブラウザーで明示的なプロキシを使用 | まずは現状を維持 | プロキシがすでにドメインを受け取っているか |
| 社内ネットワーク、LAN内サービスの探索 | 先に実DNSを使う例外を設定 | 内部ドメイン、プリンター、ローカル機器へのアクセス |
| アプリが独自の暗号化DNSを強制使用 | まずDNS問い合わせの迂回を解消 | 問い合わせがローカルDNSモジュールを経由しているか |
| 接続先の実IP表示が必要なツール | 該当する問い合わせでは実DNSを使用 | 診断結果が仮想IPに置き換わっていないか |
結論：ドメイン情報が失われているか確認してから有効にする
ログに接続先ドメインが表示され、ドメインルールも正常に適用されているなら、まずは現在のDNS設定を維持してください。透過的な制御経路で実際にドメイン情報が失われ、問い合わせと接続の両方を制御できる場合に限り、FakeDNSを試してください。
198.18.0.0/15はネットワークのベンチマーク用に割り当てられた特殊用途のアドレス帯であり、インターネット上の公開アドレスでも一般的なプライベートアドレス帯でもありません。ローカルのテスト環境や企業ネットワークですでに使われている場合は、先にルートの競合を確認してください。別のアドレスプールを使う場合も、コアの対応状況とルート設計を確認する必要があります。適当な公開アドレス帯で代用しないでください。
確認方法：DNSの問い合わせ結果だけで判断しない
検証では、処理経路全体を確認します。198.18または198.19で始まるアドレスが表示されても、その問い合わせで仮想応答が返されたことしか分かりません。後続の接続でドメインが復元され、正しくルーティングされた証拠にはなりません。反対に、ツールに実IPが表示されても、想定していたDNSの入口を経由していない可能性があります。
- 現在の状態を記録する。設定を保存し、通常アクセスできるドメインを1つ選び、使用中のノードとルーティングモードを記録します。テスト中にプロトコルを切り替えないでください。
- 新しい問い合わせを発生させる。設定を有効にしたら、テストするアプリを再起動します。Windowsでは
ipconfig /flushdnsを実行してシステムDNSキャッシュを消去できます。ただし、ブラウザー独自のDNSキャッシュや接続キャッシュは別途消去が必要な場合があります。 - DNSの入口を確認する。
nslookup example.comでシステムの名前解決経路を確認できます。ただし、このツールではブラウザーの暗号化DNSの動作を再現できない場合があるため、これだけで合否を判断しないでください。 - 接続ログを確認する。仮想IPが元のドメインに復元されているか、最終的にどのアウトバウンドが選ばれたか確認します。テスト中にログの詳細度を一時的に上げた場合は、終了後に元に戻してください。ドメインへのアクセスを長期間記録しないようにしましょう。
- 複数の条件でテストする。プロキシ経由のサイト、直接接続するサイト、内部ドメイン、IPv6の各ケースを確認してください。Webページを1つ試すだけでは、直接接続時の名前解決ループやAAAA問い合わせの迂回を見落としやすくなります。
よくある問題と元に戻す手順
有効にしたらすべてのWebページが開けなくなりました。まず何を確認すればよいですか？
まずDNSモードを元に戻してテストアプリを再起動し、基本的な接続が復旧するか確認してください。その後、仮想アドレス帯宛ての接続が正しいインバウンドに入り、マッピング復元が有効になっているか確認します。最初にサブスクリプションや転送プロトコルを変更しないでください。
Webページは開けますが、内部ドメインを名前解決できません。どうすればよいですか？
内部ドメインには、LAN内のDNSを使う実DNSの例外を設定し、対応する直接接続ルートも維持してください。内部DNSは現在のネットワーク環境に依存することが多いため、内部ドメインをすべて外部DNSに渡しても同じ結果になるとは限りません。
一部のアプリだけ仮想IPが割り当てられないのはなぜですか？
対象アプリが独自の暗号化DNSを使っているか、キャッシュを保持しているか、固定IPに直接接続しているか確認してください。まずシステムDNSを使うテストアプリで処理経路全体を再現し、その後、アプリごとの差異を確認します。IPアドレスを直接使う接続には、復元対象となるDNSマッピング自体がありません。
v2rayNGやv2flyNGでデスクトップ用の設定をそのまま使えますか？
そのまま流用することはできません。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用し、AndroidのVPNによる通信制御とデスクトップのTUNでは設定の入口も異なります。アプリに該当機能があるか、使用中のコアが必要なフィールドに対応しているか確認し、アプリが実際に生成した設定を使って検証してください。
元に戻すときは、「DNS設定を復元、元のルートを復元、通信制御サービスを再起動、アプリのキャッシュを消去」の順に操作します。FakeDNS、IPv6、スニッフィング、ルーティングを同時に変更するより、正常に動作する基準設定を保存しておくほうが原因を特定しやすくなります。再度有効にするときは、一度に変更する項目を1つにしてください。DNS問い合わせの迂回、マッピングの失効、出力ルールのどこに原因があるか切り分けられます。