Fake-IPモードとは:DNSハイジャックの仕組み・メリット/デメリット・活用シーン解説

プロキシソフトがDNS解決に介入する理由

通常のインターネット利用では、デバイスがドメインにアクセスする際まずDNS解決が行われます。システムがドメインをDNSサーバーに渡し、実際のIPアドレスを取得してから接続を確立します。問題は、Clashのようなルールベースで振り分けを行うプロキシツールでは、多くの振り分けルールがドメイン名でマッチングされる点です。たとえばGeoSiteルールで、あるドメインをプロキシ経由にするか直接接続にするかを判断します。もしプロキシソフトがDNS解決に一切関与せず、接続要求を受け取った時点で生のIPアドレスしか見えないなら、そのIPがどのドメインに対応するのか逆引きできず、ルールに書かれたドメインマッチング条件は意味をなさなくなります。

この問題を解決するため、Clash/mihomoカーネルは複数のDNS処理モードを提供しており、Fake-IPはその中でもデフォルトかつ最も広く使われている方式です。考え方はシンプルです。クライアントがドメインを問い合わせた際、実際のIPアドレスをアプリに渡すのではなく、カーネルが独自に生成した、実際には誰にも割り当てられていない疑似アドレスを返します。同時にカーネル内部では、その疑似アドレスがどのドメインに対応するかを記録しておきます。アプリが実際に接続を開始する際、カーネルは記録済みのドメイン名でルールマッチングを行い、プロキシ経由か直接接続かを判断します。この処理は上位のアプリからは完全に透過的です。

Fake-IPモードの仕組み:予約アドレス帯とマッピングテーブル

Fake-IPが返すアドレスは適当に作られたものではなく、実際のネットワークでは絶対にルーティングされない、専用に切り出された予約アドレス帯から割り当てられます。一般的な設定では 198.18.0.0/16 のような予約帯がデフォルトで使われます。このアドレス帯はインターネット上で実際に使われることはなく、カーネルは「一時的な仮の番地」として扱います。おおよその流れは次の通りです。

アプリがDNSクエリを送信し、あるドメインの解決を要求する
Clash/mihomoのDNSモジュールがこのクエリを横取りし、実際の上流DNSサーバーに問い合わせる代わりに、予約アドレスプールから未使用の疑似IPを1つ取得する
カーネルはメモリ上にマッピングテーブルを持ち、「疑似IP ↔ ドメイン」の対応関係を記録した上で、この疑似IPをアプリに返す
アプリは疑似IPを使って接続を開始し、カーネルは接続確立の段階でテーブルを参照して実際のドメイン名を復元し、ルールセットに基づいてどの振り分けポリシー・どのプロキシノードを使うか判断する
ルールでプロキシ経由と判定された場合、カーネルはドメイン名をそのままプロキシノード側に渡して解決・接続させ、実際のIP解決は通信経路の先へと後回しにされる

この仕組みの直接的なメリットは解決遅延が明らかに短縮されることです。多くの場合、カーネルは実際に上流DNSへ問い合わせる必要がなく、ローカルのアドレスプールから疑似アドレスを1つ返すだけなので、応答はほぼ即時です。また、ドメイン情報が常にカーネル内に保持されるため、ドメイン名ベースの振り分けルールが正確に機能し、「IPアドレス帯だけで推測する」という粗い判定に劣化することもありません。

ポイントFake-IPが返すアドレスは、このデバイスのプロキシプロセス内でのみ意味を持ちます。デバイスの外に出た瞬間(たとえば他のプログラムに記録されたり、別のマシンに転送されたりした場合)、そのアドレスは実際に割り当て・ルーティングされたことがないため、まったく使い物になりません。

Fake-IP・Redir-Host・通常解決モードの選び方

Fake-IP以外にも、カーネルは通常2種類のDNS処理方式をサポートしています。それぞれの違いを理解すれば、自分の環境にどれが合うか判断しやすくなります。

Fake-IPモード:前述の通り、疑似アドレスを返し、カーネル内部でドメイン名によるルールマッチングを行います。メリットは低遅延かつドメインマッチングの精度が高いこと。デメリットは、疑似アドレスが実際のIPを必要とする場面では使えないことです。たとえば解決結果のIPをキャッシュしてヘルスチェックや表示に使うアプリでは問題が生じます。
Redir-Hostモード:アプリに返すアドレスを使ってルール判定を行うという点はFake-IPと同様ですが、宛先ポートによるリダイレクト転送に重点を置いた方式で、実装の細部や適用範囲はFake-IPより限定的です。現在の主要クライアントではデフォルトとして採用されることは少なくなっています。
通常解決(Fake-IP以外の直接解決)モード:毎回実際の上流DNSサーバーに問い合わせて、本物のIPアドレスを取得します。メリットはアプリが常に使用可能な実IPを得られ、互換性が最も高いこと。デメリットはドメイン名ベースの精密なルールマッチング能力を失う(IPアドレス帯での判定しかできない)うえ、毎回実際のネットワーク往復による遅延が発生することです。

Webブラウジング、動画視聴、SNSといった日常的な用途のほとんどでは、Fake-IPのほうが低遅延かつマッチング精度が高い選択肢であり、これが多くのクライアントでデフォルトモードとして採用されている理由です。

LAN内サービスやオンラインゲームでfake-ip-filterの設定が必須な理由

Fake-IPの疑似アドレス方式は、デバイス間をまたぐシーンで明確な弱点を露呈します。典型的なケースは次の2つです。

LAN内の自宅サーバーやルーター管理画面。 家庭内にNASやルーターがあり、そのドメイン解決が内部DNSを経由する場合、本来なら192.168.x.xのような内部の実アドレスが返されるべきです。しかし、こうしたドメインがFake-IP処理の対象から除外されていないと、カーネルはやはり198.18.x.xのような疑似アドレスを返し、アプリはその疑似アドレスで接続を試みます。カーネルはルールに基づいて転送を試みますが、結果として接続できない、あるいは遠回りしてやっと繋がるといった状態になり、体感としては「LAN内デバイスへのアクセスが遅い、あるいはタイムアウトする」という形で現れます。

オンラインゲームやリアルタイム対戦系アプリ。 多くのゲームクライアントは、サーバードメインの解決結果を直接UDP接続の確立や遅延測定に使い、さらには解決したIPをUI上に表示してユーザーのノード選択に利用させる場合もあります。こうしたシーンで疑似アドレスが使われると、接続失敗、遅延値の異常、あるいはゲーム内のサーバーリストがそもそも正しく読み込めないといった問題が発生します。

解決策として、DNS設定に fake-ip-filter フィールドを追加し、これらの特定ドメインやドメインパターンをFake-IP処理の対象から除外して、実際の解決を行わせる方法があります。よくある設定例:

dns:
  enable: true
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "192.168.*.*.*"
    - "router.asus.com"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"

この中の *.lan や *.local のようなワイルドカード指定は、家庭用LAN内デバイスでよく使われるドメインサフィックスの大半をカバーします。+. というプレフィックス付きの記述は、メインドメインとそのすべてのサブドメインを同時にマッチさせるもので、接続性チェック用のシステムレベルドメインを除外する際によく使われます。これにより、疑似アドレスの干渉によってシステムが「ネットワーク利用不可」と誤判定するのを防げます。ゲーム関連ドメインについては、公式ドキュメントに記載されたサーバードメインの一覧を1件ずつ追加することを推奨します。カテゴリ全体をまとめて除外すると、Fake-IPが本来もたらす振り分け精度が損なわれてしまいます。

トラブルシューティング:「あるサービスに接続できない」ときの調査手順

Fake-IPが原因ではないかと疑う場合、次の順序で調査するとよいでしょう。

まず現在のDNSモードが本当にFake-IPになっているかを確認し、他のモードが原因ではないかを除外する
クライアントの接続ログやドメイン解決記録を確認し、対象ドメインが198.18.x.xのような予約帯のアドレスに解決されていないかを確かめる
もし該当していれば、そのドメインが誤ってFake-IP処理の対象になっていることを意味するので、fake-ip-filter に追加する必要がある
設定変更後はカーネルを再起動するか設定を再読み込みする(クライアントによって操作方法は異なりますが、通常は設定管理画面に「再読み込み」ボタンがあります)。これにより古いマッピングテーブルがそのまま使われ続けるのを防げる
それでも問題が解決しない場合は、DNSモードの問題ではなく、ルールセット自体がそのドメインを使えないプロキシノードに振り分けていないかを確認する

注意fake-ip-filter を変更した後も、すでに確立されたマッピング関係がキャッシュに残っている場合があります。設定ファイルの再読み込みだけでなく、プロキシカーネル自体を再起動して、古い疑似アドレスのマッピングを確実にクリアすることをおすすめします。

Fake-IPをオフにすべきケースとは

すべてのシーンでFake-IPが必須というわけではありません。利用しているネットワーク環境で実IPによる検証に依存するアプリが多い場合や、LAN内サービスが特に多く、フィルタルールを1件ずつ追加するコストが高すぎる場合は、遅延面のメリットを一部犠牲にして互換性問題を減らすため、通常解決モードに全体的に切り替えることも選択肢の一つです。ただし、ブラウザやSNS、動画クライアントを普通に振り分けたいだけというほとんどのユーザーにとっては、Fake-IPのデフォルト設定を維持し、LAN内ドメインや一部の特殊なアプリだけをフィルタリストに追加する方法が、運用コストと利便性のバランスが取れたやり方といえます。