Fake-IPモードの仕組み解説:DNS解決はどう乗っ取られるのか、有効・無効にすべき場面
DNSクエリの流れから、Fake-IPが予約網の仮IPでルール照合を高速化しDNS漏洩を防ぐ仕組みを解説。Redir-Hostとの違いや、LAN内サービスやゲーム対戦などで無効化・例外設定が必要な場面も紹介する。
通常のDNS解決の流れと、プロキシ環境で生じる問題
あるドメインにアクセスする前には、まずドメイン名をIPアドレスに変換する必要がある。この工程をDNS解決と呼ぶ。デフォルトでは、OSはこのクエリを回線事業者やシステム設定のDNSサーバーへ送り、実IPを取得してから接続を確立する。プロキシを使わない環境ではこの流れに問題はないが、プロキシソフトを併用すると、少なくとも2つの厄介事が生じる。
1つ目は漏洩だ。プロキシソフトがTCP/UDPの通信のみを引き受け、DNSクエリを管理していない場合、ドメイン解決の問い合わせはプロキシを経由せずローカルネットワークへ直接出ていく。回線事業者やローカルネットワークの監視者は、利用者がどのドメインを問い合わせているかを把握できてしまう。これがいわゆるDNSリークで、トラフィックはプロキシを通っているのに、問い合わせの記録だけが漏れている状態だ。
2つ目はマッチングのタイミングだ。Clashの振り分けルールには、ドメインに基づくもの(DOMAIN-SUFFIX、DOMAIN-KEYWORDなど)が多数あり、これらは本来ドメイン文字列でマッチングする方が向いている。しかし従来の流れではまずIPが解決され、アプリケーション層が受け取るのは数字の並びだ。その時点でルール照合をしようとしてもドメイン情報はすでに失われており、IPレンジベースの照合に頼るしかなくなる。ルールセットの維持コストとカバー率はどうしても下がってしまう。
Fake-IPとは:予約網の仮アドレスで実解決を代替する仕組み
Fake-IPは、Clash / Clash Meta(mihomo)のコアが提供するDNS処理モードの1つだ。基本の考え方はシンプルで、クライアント内部にDNSサーバーを内蔵し、OSから発行される全てのドメインクエリを横取りする。実際のDNSサーバーには問い合わせず、予約されたプライベートアドレス帯(デフォルトでは 198.18.0.0/16 が一般的)から、公衆インターネット上で使われたことのない仮IPを各ドメインに割り当て、コア内部に「ドメイン⇔仮IP」の対応表を保持する。
アプリケーションはこの仮IPを受け取り、通常どおり接続を開始する。その接続要求はClashのトラフィック引き受け層(TUNモードやシステムプロキシ)に入る。ここでコアが対応表を照会し、宛先アドレスが仮IPであることを検知すると、即座に対応するドメインへ逆引きする。これによりルール照合の段では、文脈を失った数字の並びではなく、再びドメイン文字列を手にすることになる。実際のドメイン解決は、ルールが「このトラフィックをどのノードへ流すか」を判断した後まで遅延され、しかも解決リクエスト自体もプロキシノード経由で送信されるため、ローカルネットワークに素通しになることはない。
この仕組みによって、前述の2つの問題は同時に解決される。DNSクエリは終始プロキシ経路の内側で完結し、ローカルネットワークに晒されなくなる。ルール照合は常にドメインを対象に行われ、先に固定化されたIPに頼ることがないため、照合の精度と応答速度がどちらも確保される。
ポイント:仮IPはローカルのコア内で「一時的に存在」するだけで、実際に公衆インターネットへ送信されることも、他のデバイスに認識されることもない。その唯一の役割は、ドメインとルールエンジンの間をつなぐ中間トークンとして機能することだ。
Fake-IPとRedir-Host:2つのドメイン保持方式の違い
ClashのDNS拡張モードには、Fake-IPのほかに、より古くからあるRedir-Hostという方式もある。両者の目的は同じ――ドメイン情報をルール照合の段階まで持ち込むこと――だが、実現方法が異なり、その挙動の違いがどちらを選ぶべきかに直結する。
| 比較項目 | Fake-IP | Redir-Host |
|---|---|---|
| DNSクエリの処理 | クエリを横取りし、ローカル生成の仮IPを返す | クエリを通常どおり通過させ、実IPを取得 |
| ルール照合の根拠 | 対応表を逆引きしてドメインを取得 | SNIやHostヘッダーなどアプリケーション層のフィールドからドメインを復元 |
| 互換性リスク | 非HTTP/TLSプロトコルではドメインフィールドが取れず誤判定の可能性 | 実IPに依存する場面(証明書のIP検証など)での問題が少ない |
| ドメイン情報のないプロトコルへの対応 | Hostが欠落するプロトコルでは振り分けが不正確になる場合がある | 実IPを使うためほぼ影響を受けない |
| 現在の主流としての位置づけ | mihomoのデフォルト推奨。性能と精度のバランスが良い | 徐々に周縁化。互換性問題の切り分け時に比較用として使われることが多い |
簡単に言えば、Fake-IPは「まず仮の解決を返し、コア内の対応表でドメインを復元する」方式で、カバー範囲が広く速度も速いため、現在のmihomoコアのデフォルト推奨となっている。一方Redir-Hostは「実直に実IPを取得し、プロトコルヘッダーからドメインフィールドを抜き出す」方式で、安定性に優れ、標準的なTLS/HTTPに乗らない一部のプライベートプロトコルでは問題が起きにくいが、全体としてはもはや主流ではない。日常利用では基本的にFake-IPをそのまま使い、特定のアプリが接続できない場合に個別に切り分ければよく、最初から全体をRedir-Hostに切り替える必要はない。
Fake-IPを無効化、あるいは例外設定が必要な場面
Fake-IPは万能スイッチではない。「すべてのドメインクエリに先に仮アドレスを返してよい」という前提に立っているが、一部のケースはまさに「取得するのは実IPでなければならない」ことを前提にしている。そうした場合はFake-IPを無効化するか、対象ドメインを例外リスト(通常は fake-ip-filter 設定項目)に加える必要がある。
- LAN内部のサービス探索:NAS、プリンター、スマート家電、LAN内共有ドライブなどは、ドメインが
192.168.x.xや*.localといった内部アドレスに解決されることが多い。これらのドメインが仮IPロジックに取り込まれると、接続が誤ってプロキシ経路に送られて失敗する。*.localや内部デバイスのカスタムドメインはfake-ip-filterに登録しておくことを推奨する。 - オンライン対戦やLAN探索プロトコル:多くのゲームのマッチングロビーやボイスサービスは、直接接続やP2Pチャネルの確立に実際の公衆IPを必要とする。仮IPはこうした「実アドレスの取得」を前提としたハンドシェイクを壊してしまうため、ゲーム関連のドメインをFake-IPから全体的に除外するか、ゲームプロセス自体を直接接続ルールに加えるのが一般的な対処法だ。
- アプリ側でIPホワイトリスト検証を行う一部クライアント:一部の社内ネットワークツールや決済・金融系クライアントでは、アプリケーション層でリクエスト元のIPが想定範囲内かを検証する場合がある。仮IPはこの検証を失敗させるため、対象ドメインには個別に直接接続を設定するか、例外リストに加える必要がある。
- mDNS/マルチキャスト探索に依存するデバイス:AppleのAirPlayやAirDropなどはマルチキャストブロードキャストでデバイス探索を行い、DNS解決の経路とは異なるため理論上Fake-IPの影響を受けない。異常が見られた場合は、先にTUNモードのルーティング乗っ取り範囲を確認すべきで、いきなりFake-IPを切るのは早計だ。
注意:TUNモードを有効にすると、Fake-IPのアドレス帯はシステムから実際のルーティングとして扱われる。このアドレス帯がすでに存在する社内ネットワーク(会社のVPNが割り当てるプライベートアドレス帯など)と重複すると、社内ネットワークに接続できないという原因不明の不具合が発生する。この場合はまず fake-ip-range が既存のネットワーク環境と衝突していないかを確認すべきで、いきなりプロキシソフトの不具合と決めつけないこと。
設定と切り分けのヒント
Fake-IP関連の設定を触る前に、自分が問題視しているのがDNS層の対応表か、それともTUN層のルーティング乗っ取りかをまず特定しておくと、切り分けの効率が上がる。
- クライアントのDNS設定で
enhanced-modeがfake-ipになっているか確認する。redir-hostと表示されている場合は別のロジックが動いているので、前章の挙動比較を逆に読み替える必要がある。 fake-ip-rangeのアドレス帯が、既存のネットワーク(VPNや仮想マシンの仮想NICを含む)と重複していないか確認する。重複は社内ネットワークへのアクセス異常のよくある原因だ。- 実IPが明確に必要なドメイン(社内サービス、ゲームロビー、マルチキャストデバイス)は1件ずつ
fake-ip-filterに追加する。手間を省こうとFake-IP全体を無効化すると、前述のマッチング高速化と漏洩防止の効果もまとめて失われてしまう。 - ある接続の異常がFake-IPに関係していると疑う場合は、まずクライアントのログ画面で該当接続が実際にどのルールとどの宛先アドレスにヒットしているかを確認し、解決段階の問題なのか、ルール自体の記述ミスなのかを見極める。
- 設定変更後はノードの再接続だけでなく、プロキシコア自体を再起動する。DNS対応表とルーティングテーブルは通常コア起動時に構築されるため、ノードの切り替えだけでは再生成されない。
まとめると、Fake-IPはドメイン解決という工程を「後ろに回し」かつ「隠す」ための技術的な工夫であり、ルール照合の精度を上げ、DNSクエリの秘匿性を高めることを目的としている。ほとんどの利用場面ではデフォルトの有効設定のままで問題ない。本当に注意を払うべきは、実IPのセマンティクスに依存する一部のサービスだけであり、そこにだけ例外を設定すればよく、一部のアプリが接続できないという理由だけで仕組み全体を無効化する必要はない。