Fake-IPは、Clashとmihomoで広く使われている拡張DNS処理方式です。ドメインの問い合わせ結果を接続先サーバーのグローバルIPへ直接置き換えるのではなく、専用のアドレス範囲から仮想アドレスを割り当て、カーネル内に「ドメイン名—仮想アドレス」の対応関係を保存します。アプリがこの仮想アドレスへ接続すると、Clashはマッピングを使ってドメイン名を復元し、ドメインルール、プロキシグループの選択、リモートDNS解決を順に実行します。
この方式の目的は接続先のWebサイトを変更することではなく、通信の入口に正確なドメイン情報を保持することです。TUN仮想NICで取り込まれ、OSへIP接続だけを渡すアプリでも、Fake-IPなら先ほどのDNS問い合わせで得たドメイン名を接続に再関連付けできます。そのため、ルールエンジンはDOMAIN、DOMAIN-SUFFIX、ルールセットなどのドメインルールにマッチしやすくなり、ローカルDNSの結果とプロキシ出口から実際にアクセスする結果の不一致も抑えられます。
Fake-IPのDNSマッピング処理
典型的なアクセスは、DNS問い合わせと接続確立の2段階に分けて考えられます。この2段階を理解しておくと、問題が名前解決、通信の取り込み、ルールマッチ、プロキシ出口のどこで起きているかを判断できます。
- アプリがシステムDNSへドメイン名を問い合わせます。たとえば、サービスのAレコードやAAAAレコードを要求します。
- システムからの問い合わせはClashのDNSモジュールへ送られます。TUNを使用する場合は、
dns-hijackで指定ポートのDNSリクエストを受け取る構成が一般的です。ほかの取り込み方式では、OSのDNS設定からローカルの待受アドレスへ直接向けることもあります。 - Fake-IPモジュールがドメイン名に仮想アドレスを割り当て、マッピングを記録します。アドレスプールはベンチマーク用途に予約されたネットワーク内に置かれることが多く、実際の範囲は
fake-ip-rangeで決まります。 - アプリは仮想アドレスを受け取ると、TCPまたはUDP接続を開始します。この接続もClashへ入り続けなければなりません。通信がClashを迂回すると、仮想アドレスだけではインターネット上に直接接続できません。
- Clashは接続先の仮想アドレスから元のドメイン名を検索し、ルールエンジンへ渡します。そのうえで、ダイレクト接続、プロキシ、拒否、指定したプロキシグループのいずれかを選択します。
- 実際の接続を確立する必要がある場合、Clashは設定に従い、上流DNS、プロキシ側の名前解決、または接続先プロトコルに必要な方式で実アドレスを取得します。
したがって、Fake-IPは単独で動作するプロキシモードではありません。DNSリクエストと後続の接続を、同じClashインスタンスが受け取る必要があります。DNS問い合わせはClashへ入るのに接続がTUNを迂回する、または接続はClashへ入るのにDNS問い合わせを別のプログラムが横取りする、といった状態ではマッピングの経路が壊れます。切り分けでは、「DNSがClashを経由しているか」と「接続先への通信がClashを経由しているか」を分けて確認してください。
ドメインルールは通常、マッピングを復元した後にマッチします。たとえば、ルールに特定のドメインサフィックスがあれば、Clashは復元後のホスト名をそのまま判定でき、通常のグローバルIPとしてIPルールへ渡す必要がありません。IPアドレスを直接指定した接続は、事前のドメイン問い合わせがないためFake-IPマッピングも作成されません。その場合は、IP、ポート、その他利用可能な情報に基づいて処理されます。
mihomoの基本設定とフィールドの関係
クライアントによっては、画面上のスイッチから設定を生成したり、サブスクリプションの上書きでDNSセクションを書き換えたりします。最終的には、クライアントが実際に読み込んだ設定を基準にしてください。以下はフィールドの関係を理解するための簡略例です。待受アドレス、上流DNS、アドレスプールは端末環境に合わせて調整します。
dns:
enable: true
listen: 0.0.0.0:1053
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "time.*.com"
nameserver:
- 1.1.1.1
- 8.8.8.8
tun:
enable: true
stack: mixed
dns-hijack:
- any:53enhanced-mode: fake-ipはFake-IP拡張モードを選択します。fake-ip-rangeは仮想アドレスプールを定義し、fake-ip-filterには仮想アドレスを返さないドメインを指定します。除外項目にマッチすると、DNSモジュールはFake-IPマッピングを作成せず、実際の名前解決結果を返します。
dns-hijackとFake-IPの役割は異なります。前者は端末上のDNSリクエストをClashへ入れるための機能で、後者は受け取った問い合わせにどのような応答を返すかを決めます。Fake-IPだけを有効にしても、Clashへ届かないDNSリクエストには適用されません。DNSハイジャックだけを設定して通常の名前解決を使う場合も、仮想アドレスのマッピングは生成されません。
mihomoでは、Fake-IPマッピングはデフォルトで主に実行中の接続との関連付けに使われます。一部の設定ではprofileでFake-IPデータの永続化を有効にし、コアの再起動後も保存済みマッピングを利用できます。永続化が必要かどうかは、クライアントの設定管理方式によって異なります。アドレスプールの変更、過去のマッピング異常、設定切り替え後の挙動不一致が発生した場合は、コアを停止してクライアントが提供するDNS/Fake-IPキャッシュを削除し、設定を再読み込みしてください。
Fake-IPが適している環境
デスクトップ端末でのTUNによる全通信の取り込み
TUNは仮想ネットワークインターフェースを作成し、システムのHTTPプロキシ設定に従わないTCP、UDP、一部のシステムサービスの通信を受け取ります。多くのプログラムは接続時に名前解決後のIPだけをネットワークスタックへ渡すため、ルールエンジンが接続自体からドメイン名を取得できるとは限りません。Fake-IPは直前のDNS問い合わせからドメイン情報を補えるため、TUNとの相性が良い方式です。
ブラウザー、コマンドラインツール、ゲームプラットフォーム、バックグラウンド更新サービスは、それぞれ異なるネットワークインターフェースやプロキシ方式を使うことがあります。DNS問い合わせと接続を一貫してTUNへ通せば、あるプログラムはシステムプロキシに従い、別のプログラムは迂回するといった経路差を減らせます。有効化後も、ブラウザーの通信だけが対象になっていないか、ルーティングテーブル、DNSハイジャック、クライアントログを確認してください。
ドメインルールを多用する大規模ルールセット
サブスクリプション設定には、多数のドメインサフィックス、ドメインキーワード、ルールセットが含まれることがあります。Fake-IPを使うと、接続時にコアが問い合わせたドメイン名を復元し、これらのルールを優先して適用できます。ドメインルールはサーバーIPだけで判定するより安定します。同じサービスがCDNや動的振り分け、共有アドレスを使うことがあり、1つのグローバルIPにまったく異なる複数のドメインが載る場合もあるためです。
LANサービスはダイレクト接続、公開サイトはプロキシ、特定ドメインは拒否、といったルールを設定したい場合、Fake-IPによって判定対象が明確になります。ただし、ルールの順序はそのまま有効です。広すぎるルールを前に置くと、後ろの精密なドメインルールが上書きされることがあります。Fake-IPはマッチング情報を提供するだけで、ルールの優先順位を自動修正するものではありません。
ローカルDNSとの差異を抑えたいプロキシ接続
通常のDNSモードでは、まずローカルで実IPを取得し、その後にルールエンジンがドメイン名やIPを基に判断します。プロキシ出口とローカルネットワークでCDNアドレスが異なると、経路の迂回や接続結果の不一致が起こることがあります。Fake-IPなら実際の接続先アドレスの確定を遅らせ、ポリシーと上流設定に応じてコアが名前解決経路を選べます。ドメインベースの振り分けと、プロキシ側での後続接続が必要な環境に適しています。
LAN、ゲーム、特殊ドメインで起きやすい問題
LANホスト名とデバイス検出
プリンター、NAS、テレビへのキャスト、ルーター管理画面では、.local、.lan、メーカー独自のホスト名がよく使われます。これらの名前はmDNS、LLMNR、ルーターのローカルDNS、検索ドメインで解決されることがあり、パブリックな上流DNSへ渡すのには適しません。こうした名前にFake-IPが返されると、アプリが同一ネットワーク内のデバイスを検出できなかったり、本来ダイレクト接続すべき管理リクエストがプロキシルールへ送られたりします。
まず、その名前がどのプロトコルで解決されているかを確認し、その後に正確な除外項目を追加します。固定端末であれば、DHCPホスト名の解決を優先して維持するか、明確なLANドメインサフィックスを使います。ローカル解決が必要なサフィックスだけをfake-ip-filterへ追加し、同時にLANのIP範囲をダイレクト接続にするルールも設定してください。ドメインだけを除外してダイレクトルートを設定しないと、接続時に誤ったポリシーが選ばれる可能性があります。
ゲームのログイン、ボイスチャット、UDPセッション
ゲームによっては、アカウントログイン用ドメイン、コンテンツ配信用ドメイン、対戦サーバーのIP、音声通信用UDP、NAT検出サービスを同時に利用します。ログインページが正常に開けても、ゲーム全体の通信経路が正常とは限りません。ランチャーがドメインを問い合わせた後、その結果を別プロセスへ渡し、後続プロセスが同じTUNの取り込み対象になっていない場合、仮想アドレスに対応する転送経路が失われることがあります。
ログインループ、リージョン一覧の空白、ボイスチャット接続の失敗が発生したら、まずコアのログに該当するUDP/TCP接続が表示されるか確認し、次にプロセスがTUNへ入っているかを確認します。ログからFake-IPに適さないドメインだと判断できた場合に限り、そのドメインをフィルターへ追加してください。ゲームは通常複数のサービスドメインを使うため、トップレベルドメイン全体を除外したり、Fake-IPを全面的に無効化したりすると、既存のドメイン振り分けが機能しなくなることがあります。
時刻同期、ネットワーク検知、キャプティブポータル
システム時刻の同期、ネットワーク接続性の検知、学校やホテルのログインポータルでは、実際のDNS結果が必要な場合や、プロキシコアの起動前にアクセスしなければならない場合があります。こうしたリクエストに仮想アドレスが返されても、接続がClashへ入っていなければ、システムがオフラインと誤判定することがあります。時刻同期用ドメイン、OSのネットワーク検知用ドメイン、ポータル認証用ドメインは、除外ルールの候補になりやすい対象です。
除外項目は、長い汎用リストをそのままコピーするのではなく、実際のログやキャプチャ結果から決めてください。OSのバージョン、地域、ネットワーク環境によって検知用ドメインは変わります。まず問題を再現して問い合わせ先のドメインを記録し、最小限のルールを追加すれば、通常の通信まで実IPへ戻してしまうことを防げます。
IPアドレスを設定へ保存する、または別の端末で再利用する場合
プログラムによってはDNS結果を長期間キャッシュし、取得したアドレスを設定ファイルへ書き込むこともあります。Fake-IPが有効なのはマッピングを保持しているClashインスタンス内だけで、そのアドレスを別の端末へコピーしても意味はありません。透過ルーター環境でも注意が必要です。ゲートウェイAがFake-IPを返し、実際の接続がゲートウェイBを通る場合、Bはその仮想アドレスがどのドメインに対応するかを知ることができません。
同一LAN内の複数端末へFake-IP DNSを提供する場合は、各端末の後続通信が常に同じコアインスタンスを通り、仮想アドレスプールへのルートもそのインスタンスを指すようにしてください。難しい場合は、実アドレスを返すDNSモードを使うか、Fake-IPをローカル端末のクライアントだけに限定する方が適しています。
Fake-IP除外ルールの書き方
除外ルールの目的は、互換性のない少数のドメインに実アドレスを返すことであり、すべてのサービスを網羅する例外リストを作ることではありません。「完全一致のドメイン、限定的なワイルドカード、サフィックス範囲」の順に、必要な範囲だけ段階的に広げます。
| ルールの種類 | 適用するケース | 注意点 |
|---|---|---|
host.example.com |
異常が確認されたホスト名が1つだけの場合 | 影響範囲が最小のため、優先して使用 |
*.example.com |
同一サービスの複数サブドメインで実アドレスが必要な場合 | ワイルドカードの意味が現在のコアバージョンと一致するか確認 |
*.local |
LANデバイスの検出とローカル名の解決 | mDNSまたはローカルDNSの経路も維持する必要がある |
time.*.com |
命名パターンが固定された時刻同期サービス | 広すぎるワイルドカードで通常のサイトまで対象にしない |
mihomoの具体的なマッチング機能は、バージョンや設定形式によって変わることがあります。サブスクリプションと上書き設定を統合する際に、クライアントがフィールドを書き換える場合もあります。変更後はクライアントの最終設定ビューを開き、fake-ip-filterがサブスクリプション更新で上書きされていないことを確認し、コアの起動ログにフィールドエラーがないか確認してください。
一部の新しいmihomo設定では、Fake-IPフィルターにブラックリストまたはホワイトリスト方式を指定できます。ブラックリスト方式では、リスト内のドメインに実アドレスを返し、それ以外にはFake-IPを使います。ホワイトリスト方式では逆に、リストにマッチしたドメインだけがFake-IPになります。日常的なデスクトップ環境では、少数の除外項目から始める方法が一般的に適しています。ホワイトリストを有効にする場合は、マッチしない大量のドメインに実アドレスを返す設計が意図したものか、フィールドの意味を逆に理解していないかを確認してください。
Fake-IPの異常を切り分ける順番
- 設定が読み込まれているか確認します。クライアントの実行設定でDNSが有効になっていること、拡張モードがFake-IPであることを確認し、コアの起動ログも確認します。サブスクリプションファイル、上書きファイル、クライアントのスイッチが、同時にDNSセクションを書き換えている可能性があります。
- DNS問い合わせがコアへ届いているか確認します。接続ログまたはDNSログを確認し、対象ドメインが表示されるかを見ます。システムで暗号化DNS、ブラウザー独自のDNS、その他のDNSツールを使用している場合は、ローカルの待受を迂回していないか確認してください。
- 仮想アドレスが設定したアドレスプールに含まれるか確認します。問い合わせ結果は
fake-ip-rangeの範囲内になるはずです。通常のグローバルIPが返される場合は、除外項目にマッチしたか、問い合わせがClashを経由していない可能性があります。 - 後続の接続も取り込まれているか確認します。アプリが仮想アドレスを取得した後、ログに対応する接続が表示されるはずです。接続記録がまったくない場合は、まずTUNの権限、システムルート、アプリの迂回設定を確認してください。
- マッピングからドメイン名を復元できるか確認します。接続ログには元のドメイン名またはマッチしたドメインルールが表示されるはずです。仮想IPしか表示されない場合は、DNSとFake-IPのキャッシュを削除し、問い合わせと接続が同じコアで処理されていることを確認してください。
- ルールの順序とプロキシグループを確認します。ドメイン名が復元されているのに出口が誤っている場合、問題は通常、Fake-IPそのものではなく、ルールの優先順位、ルールセットの更新、プロキシグループの選択にあります。
- 最後に除外項目を追加します。対象サービスが実際のDNS結果を必要とすると確認できた場合に限り、完全一致のドメインをフィルターへ追加してください。
DNS設定を変更した後も、ブラウザー、OS、アプリが古いキャッシュを使い続けることがあります。まずClashの設定を再読み込みし、次にシステムのDNSキャッシュを削除して、関連アプリを完全に終了してください。クライアントに「DNSキャッシュを削除」または「Fake-IPキャッシュを更新」といった機能がある場合は、関連する接続を停止してから実行します。複数のコアインスタンスを頻繁に切り替える場合は、システムDNSとデフォルトルートが現在のインスタンスを向いていることも確認してください。
Fake-IPとRedir-Hostの選び方
Fake-IPは、仮想アドレスを使ってドメイン名とのマッピングを保持する方式です。TUNによる取り込み、ドメインルールの多用、DNSと接続経路の一元管理が必要な端末に適しています。Redir-Hostのように実アドレスを返す方式は、一般的なDNSの挙動に近く、実アドレスを必要とするLANサービス、複数端末でのDNS利用、一部の特殊なアプリと互換性を保ちやすい一方、ドメインとの関連付けや名前解決経路は、クライアントの実装や接続種別の影響を受けます。
選択時は、特定のWebページが開くかどうかだけで比較しないでください。ブラウザー、システム更新、LAN機器、ゲームのUDP、スリープ復帰、ネットワーク切り替えも確認します。単一のデスクトップ端末なら、まずFake-IPを使い、明確な異常に対して小範囲のフィルターを追加する方法が現実的です。ルーターから複数端末へ一括提供する場合は、DNSリクエストと戻りの通信経路を先に設計し、仮想アドレスが常に同じインスタンスへ戻るようにしてください。
最終的な判断基準は、通信経路が完全につながっているかどうかです。DNS問い合わせがClashへ入り、仮想アドレスが現在のコアによって割り当てられ、後続の接続も同じコアへ入り、ドメインルールが正しくマッチし、プロキシグループが実接続を確立できる必要があります。この順番でログを確認すれば、Fake-IPの問題は通常、DNS設定全体を何度も切り替えなくても具体的な箇所まで特定できます。