Fake-IPモード徹底解説:DNSマッピングプール・ハイジャックの流れ・適用シーン

プロキシ経路におけるDNS解決の位置づけ

すべてのネットワークアクセスはドメイン名解決から始まります。アプリケーションはまずシステムまたはクライアント内蔵のDNSモジュールに、あるドメイン名がどのIPに対応するかを問い合わせ、応答を受け取ってからTCPまたはUDP接続を開始します。プロキシソフトが介入していない状態では、このIPは実在のもので、ルーティングや振り分けに直接使える情報です。しかしClash / mihomoのようにルールベースでトラフィックを振り分けるツールにとって、IPだけに依存すると厄介な問題が生じます。多くのドメイン名の背後にはCDNがあり、同じサイトでも時間帯や地域によって解決されるIPが大きく異なるため、IPレンジを固定で書いたルールはすぐに機能しなくなります。そのためルールエンジンは、変動しやすいIPよりもドメイン名そのものを取得したいのです。これこそがDNSモード設計が解決すべき核心課題——「ドメイン情報」を接続確立とルールマッチングのすべての段階に伝達できるようにすることです。

ClashのDNSモジュールはいくつかの動作モードを提供していますが、その中で最も話題になり、同時に最も誤解されやすいのがFake-IPです。これを理解するには、まず「DNS解決で得られるIPが接続先の実アドレスである」というデフォルトの前提を一旦捨てる必要があります。

Fake-IPのマッピングプール機構

Fake-IPモードの考え方はこうです。クライアントが本機のDNSリクエストを乗っ取り、アプリケーションが何らかのドメイン名を問い合わせた際、実際に上流DNSサーバーへ連絡して本物のIPを取得するのではなく、予約済みのプライベートアドレス帯(デフォルトは198.18.0.0/16)の中から、順序またはキャッシュ戦略に基づいて未使用のIPを1つ割り当て、そのままアプリケーションに返します。このIP自体はどの実サーバーも指しておらず、単なる「プレースホルダー」です。クライアントは内部でマッピングテーブルを保持し、「この仮想IPがどのドメイン名に対応するか」を記録しています。

全体の流れは3ステップに分けられます:

1. アプリケーションがDNSクエリを発行し、そのリクエストはTUNまたはシステムDNSによってClash内部のDNSサーバーコンポーネントへ横取りされます。
2. Clashはマッピングプールを確認し、そのドメイン名にまだFake-IPが割り当てられていない場合、未使用のアドレスを1つ取得して「ドメイン名 ↔ 仮想IP」の双方向レコードを作成し、メモリテーブルに書き込みます。
3. Clashはこの仮想IPをDNS応答としてアプリケーションに返し、アプリケーションはこのIPを使って接続を確立します。

重要なのはステップ3以降です。アプリケーションが仮想IPで接続を開始すると、その接続はTUNネットワークインターフェースまたはシステムプロキシを経由してClashの転送エンジンに入ります。この時Clashは実際に198.18.x.xというアドレスへパケットを送るわけではなく、まずマッピングテーブルを確認して仮想IPから元のドメイン名を逆引きし、実際のドメイン名を取得した上でプロキシルールに従ってどのプロキシグループを使うかを決定し、実ドメイン名に対して改めて実際のDNS解決を行います(あるいはSNI/HTTP Hostに対応する下流プロキシにドメイン名をそのまま渡して処理させます)。このステップは「接続段階での復元」と呼ばれ、Fake-IPが正常に機能するための核心です——ドメイン情報は一貫して保持され、仮想IPはあくまで一時的な運び役にすぎず、実際の下層ネットワーク伝送には関与しません。

ルールマッチングの精度が上がる理由

Fake-IPによって「ドメイン名」が接続確立の段階まで一貫して伝わるため、ルールエンジンがDOMAIN-SUFFIX、DOMAIN-KEYWORD、RULE-SETといったドメイン名ベースのマッチングを行う際、常に信頼できる元のドメイン名を取得でき、いつでも変わりうるCDN出口IPに依存しません。これはCDNが密集するシーンで特に重要です——同じドメイン名でも今日はAレコードに解決され、明日は別のIP群に解決されることがあり、ルールがIPレンジで書かれていると「昨日はマッチしたのに今日はマッチしない」という事態が起きやすくなります。ドメイン名は比較的安定しており、ドメイン名ベースのルールセットは現在のmihomoエコシステムの中でも更新頻度が最も高く、カバー範囲も最も広い形式です。

また、Fake-IPモードでは、プロキシを使うかどうかを判断するために毎回システムレベルで実際のDNSクエリを発行する必要がありません——仮想IPの割り当てとルールマッチングはローカルのメモリ内で完結し、ネットワークの往復を1回減らせます。これは、Fake-IPを有効にするとウェブページの表示速度がわずかに向上したと報告するユーザーが多い理由の一つでもあります。

Fake-IPとRedir-Hostの違い

Fake-IPが登場する以前、よく使われていたもう一つの方式がRedir-Hostです。クライアントはDNSリクエストを乗っ取った後、仮想アドレスを返すのではなく、直接実際の上流DNSサーバーに問い合わせて本物のIPを取得し、そのままアプリケーションに返します。ルールマッチングの段階では、クライアントがDNSクエリの時点で「ドメイン名がどのIPに対応するか」を記録しておき、接続段階でこの記録を使ってドメイン名を逆引きする仕組みに依存します。表面的には両者とも「ドメイン名がルールマッチングに参加する」ことを実現していますが、動作の詳細と適用範囲は異なります。

簡単に言えば、Fake-IPは速度とルールの正確性の面で優位性があり、現在のTUNモードにおけるデフォルトの選択となっています。Redir-Hostはアプリケーションが常に本物のIPを取得できるため、IP通信に直接依存し、ドメイン名解決を経由しない一部のシーンでは互換性がより安定していますが、全体としてはFake-IP+ホワイトリスト除外の組み合わせ方式に徐々に取って代わられています。

fake-ip-filterによる除外が必須となるシーン

仮想IPはあくまで「Clash内部で使うためのプレースホルダー」であり、あるアプリケーションがClashの接続ハイジャックロジックを経由せず、このIPをそのまま実アドレスとして扱ってしまうと問題が発生します。よくあるいくつかのシーンでは、明示的にfake-ip-filterを設定し、対応するドメイン名をFake-IPの割り当て範囲から除外して、実際のDNS解決を行わせる必要があります:

• LAN内部サービスとルーター管理ページ——*.lanやrouter.asus.comのようにローカルネットワーク機器を指すドメイン名に仮想IPが割り当てられると、ブラウザは実在しないアドレスへ接続を試みることになり、管理ページが開けなくなります。
• 実IPを正確に取得する必要があるアプリケーション——一部のオンラインストレージクライアント、ライブ配信ツール、P2P系アプリはアプリケーション層でDNSが返すIPを直接読み取り、表示やピアツーピア接続の確立に使うため、仮想IPは意味を持ちません。
• 企業内ネットワークやVPNシーンのプライベートドメイン——社内システムのドメイン名は多くの場合プライベートアドレス帯に解決されるため、こうしたドメイン名も除外リストに加え、プロキシロジックとの衝突を避けるべきです。
• Fake-IPとの互換性問題が既知のクライアントコンポーネント——例えば一部のOS標準搭載のネットワーク検知・接続確認サービスなどは、1件ずつ手動で追加するのではなく、公式ドキュメントやコミュニティが管理するルールセットに従って一括で除外することを推奨します。

実践においては、この除外リストをゼロから手書きする必要はありません。主要なルールセットリポジトリは通常、比較的完備されたfake-ip-filterの推奨リストを維持しており、クライアントがデフォルト設定を生成する際やルールサブスクリプションを使う際にも基本版が付属します。具体的なアプリが開けない状況に遭遇したら、必要に応じて追加すれば十分です。

有効化すべき場面と無効化すべき場面

Fake-IPモードの利用に関する基本的な推奨事項は以下の通りです:

• TUNモードでは有効のままにすることを推奨します。TUNモードはグローバルなネットワークスタックを乗っ取るため、ルールエンジンと連携する高効率かつ正確なドメイン名復元機構が必要です。Fake-IPはまさにこのシーン向けに設計されており、ほとんどのクライアントでTUNモード時のデフォルトDNSタイプとなっています。
• 純粋なシステムプロキシモード(HTTP/SOCKS)では必要に応じて選択できます。ブラウザなどシステムプロキシ設定に対応するアプリのみをClash経由にする場合、Redir-Hostや上流DNSへの直接接続も実用的な代替案となり、差異は主にルールマッチングの精度に表れます。
• LAN内の機器や内部システムへのアクセスに異常が出た場合、Fake-IP全体をすぐに無効化するのではなく、まずfake-ip-filterを確認してください。「プロキシを有効にすると内部機器に接続できない」という問題の多くは、除外リストが該当ドメイン名をカバーしていないことが原因であり、機構全体を放棄するより、狙いを絞ってルールを追加する方が得策です。
• 正確なIPに強く依存する少数のアプリケーションについては、個別に直接接続させるかドメイン名を除外してください。個々のアプリの特殊な要件のためにグローバルなFake-IPを無効化する必要はなく、ルールによる振り分け自体がドメイン名単位・プロセス単位での例外処理に対応しています。

全体として、Fake-IPは「有効にするかしないか」という単純な二択のスイッチではなく、除外リストと合わせて維持していく必要がある動的な機構です。ルールセットコミュニティは除外が必要と判明したドメイン名を継続的に更新し、クライアント側も仮想IPプールの割り当て・回収戦略を絶え間なく最適化しています。その動作原理を理解しておけば、具体的な問題に遭遇した際にどの方向を調査すべきか素早く判断できるようになり、DNSモード全体を分解不能なブラックボックスとして扱わずに済みます。