Fake-IPモードの仕組みを解説：mihomoのDNS強化モードと利用シーン

Fake-IPの動作の流れ：ドメイン、仮想アドレス、実際の接続

Fake-IPはmihomo DNSの拡張モードで、dns.enhanced-mode: fake-ipで有効にします。アプリには合成IPv4アドレスを返し、カーネル内では「ドメインと合成アドレス」の対応関係を保持します。このアドレスはWebサーバーの実IPでもプロキシノードのアドレスでもなく、アプリに渡される接続先の手がかりです。

一般的な設定では、割り当て範囲に198.18.0.1/16を使用します。これはネットワークのベンチマーク用に予約された198.18.0.0/15のアドレス空間で、インターネット上でサービスを公開するための通常のアドレス帯ではありません。使用前に、社内ネットワークや検証用ネットワークですでに使われていないか確認してください。予約アドレスだから競合しないとは限りません。

アプリがexample.comを問い合わせると、そのリクエストはmihomoのDNSサービスに届きます。
mihomoはそのドメインにアドレスプール内のアドレスを割り当て、対応関係を保存します。アプリに返されるアドレスは198.18.0.2などですが、割り当てられる値は固定ではありません。
アプリはこの合成アドレスに接続します。この接続は、同じmihomoカーネルに再び届く必要があります。
カーネルは対応関係からドメインを復元してルールを照合し、選択されたDIRECTまたはプロキシのアウトバウンド経由で実際の接続を確立します。

DNS応答の高速化と振り分け精度の向上とは

上流DNSの応答待ちを減らす

ローカルで合成アドレスを割り当てられる問い合わせでは、mihomoは上流DNSからWebサイトの実IPv4アドレスが返るのを待たずにアプリへ応答できます。その後、ドメインを引き継げるプロキシアウトバウンドを使えば、接続先の名前解決をリモート側に任せることもできます。短縮されるのは一部の通信経路におけるDNSの待ち時間であり、ノードの遅延、ダウンロード速度、サーバーの応答速度が改善するわけではありません。

ルールの結果がDIRECTの場合、直接接続には通常、実アドレスが必要です。フィルター対象のドメイン、一部の問い合わせタイプなど、実際の名前解決結果を必要とする処理でも上流DNSが使われます。Fake-IPにすれば「DNS問い合わせが一切不要になる」わけではなく、あらゆるネットワークに共通する一定の高速化率もありません。

ドメイン情報を保持し、ドメインルールの照合に活用

透過的に接続を取り込む場合、カーネルに渡される情報が最初は接続先IPだけということがあります。Fake-IPの対応関係を使えば、元の問い合わせドメインを復元し、DOMAINやDOMAIN-SUFFIXなどのルールと照合できます。たとえばDOMAIN-SUFFIX,example.com,Proxyは、そのドメインとサブドメインに一致します。Proxyには、設定内に実在するプロキシまたはプロキシグループ名を指定してください。

ルールは引き続き上から順に評価され、先に一致したルールでアウトバウンドが決まることがあります。
アプリがIPアドレスを直接指定して接続する場合、対応するDNS問い合わせがないため、Fake-IPでドメインを復元することはできません。
アプリがmihomoを経由せず独自に暗号化DNSを使うと、カーネルに対応関係が登録されないことがあります。スニッフィングで一部のドメイン情報を補える場合もありますが、すべてのプロトコルを検出できるわけではありません。

Fake-IPとredir-hostの違い

redir-hostは上流DNSで解決した実IPをアプリに返し、DNSレコードを使ってドメインと接続を関連付けます。「DNSを無効にする」モードでも、アウトバウンドの種類でもありません。どちらのDNS拡張モードもルールモードと併用でき、主な違いはアプリに返すアドレスと、カーネルがドメイン情報を保持する方法です。

比較項目	Fake-IP	redir-host
アプリに返すIPv4アドレス	条件に合う場合、アドレスプール内の合成アドレスを返す	実際に名前解決されたアドレスを返す
ドメインの関連付け方法	合成アドレスとドメインの対応関係から復元	DNSレコードを基に関連付ける。同じIPを共有するケースなどでは曖昧になることがある
初回DNS問い合わせ時の待ち時間	一部の問い合わせにはローカルですぐ応答できる	通常は上流DNSの応答を待つ（キャッシュヒット時を除く）
互換性で確認する点	アプリが実アドレスを必要とするか、接続が同じカーネルに戻るか	実際の名前解決の品質、DNSキャッシュ、ドメイン情報の関連付けが完全か
LAN上のアプリ	内部ドメイン用のフィルターと専用DNS設定が必要になる場合がある	内部ドメインを解決できるDNSの設定が必要

まず要件に合わせて選びましょう。通信を透過的に取り込み、主にドメインルールで振り分けたい場合は、Fake-IPから試すのがおすすめです。アプリに実アドレスを渡す必要がある場合や、合成アドレスに対応できないソフトがある場合は、フィルタールールを使い、必要に応じてredir-hostに切り替えてください。DNSモードを切り替えたら、古いキャッシュを消して接続を確立し直しましょう。古いアドレスが残ると、検証結果に影響します。

最小構成：まずDNSを確認し、その後システム通信を取り込む

以下はローカルで動作確認するためのmihomo設定例で、完全なサブスクリプション設定ではありません。ループバックアドレスの1053番ポートでDNSを提供するだけで、システムDNSの変更やTUNの有効化は自動で行いません。既存設定の該当項目に統合し、同じYAMLドキュメント内でdnsを重複して定義しないでください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.local"
    - "+.home.arpa"
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

listenはDNSの待ち受け先を指定します。通常、システムのDNS設定には任意のポート番号を指定できないため、「127.0.0.1:1053」を通常のDNSサーバーアドレスとして入力することはできません。
ipv6: falseはこの例でDNSの検証範囲を絞るための設定です。OSのIPv6を無効にするものではなく、すべての環境で推奨される設定でもありません。
nameserverは上流DNSの設定例です。現在のネットワークから到達できることを確認してください。社内ドメインの名前解決には通常、社内DNSも必要です。パブリックDNSから社内アドレスが返るとは限りません。
fake-ip-filter-modeを使うには、この項目に対応したmihomoが必要です。旧Clash系の派生版では対応状況が異なるため、まずクライアントが使用するカーネルを確認し、設定の読み込みエラーもチェックしてください。

デスクトップクライアントでは、「オーバーライド」や「拡張設定」から実行用設定を生成する場合があります。また、サブスクリプションの更新で直接編集した内容が上書きされることもあります。変更後はクライアントの実行設定を確認できる画面で最終的なdnsセクションを確認し、ログ画面で設定の読み込みが成功したことも確かめてください。エディターで保存できたことだけでは、カーネルに新しい設定が適用されたとは限りません。

fake-ip-filterの設定方法：実アドレスを返してもDIRECTとは限らない

上記のblacklistモードでは、fake-ip-filterに一致したドメインにはFake-IPを使わず、実アドレスを名前解決して返します。"localhost"はその名前を指定し、"*.lan"は該当するサブドメインに一致します。"+.home.arpa"はhome.arpaとそのサブドメインを対象にできます。アスタリスクを含む文字列は、YAMLで別の構文として解釈されないよう引用符で囲んでください。

まず個別のドメインを追加し、必要に応じてサフィックス全体に広げる

NASがnas.home.arpaを使っており、アプリが実際のLANアドレスを必要とする場合、このドメインをフィルターリストに追加できます。そのうえで、このドメインを家庭内ルーターのDNSで解決できるようにしてください。フィルターを追加するだけでは、正しい内部DNSが自動的に見つかるわけではありません。上流DNSがパブリックDNSのままだと、ドメインが存在しないという結果になることがあります。

.localはmDNSでよく使われますが、mDNSの検出方法は通常のユニキャストDNSとは異なります。"*.local"をフィルターリストに加えても、「合成アドレスを使わない」ようにするだけです。別セグメントにあるプリンターやキャスト機器などのLANサービスを検出できるとは限りません。

フィルターリストとアウトバウンドルールは別々に管理する

ドメインをフィルターリストに追加しても、DIRECTルールが自動で作られるわけではありません。アウトバウンドは引き続きrulesに従って決まります。逆に、DIRECTルールを追加したからといって、そのドメインのFake-IPを必ず無効にする必要もありません。カーネルはまずドメインを復元し、その後実アドレスを解決して直接接続できます。

TUN、システムプロキシ、DNSハイジャックの連携

Fake-IPはDNS層の動作、TUNは通信をカーネルに取り込む方法のひとつ、システムプロキシはその設定に従うアプリにローカルのプロキシポートを使わせる仕組みです。これらは互いに代用できません。特に、ブラウザーがHTTPプロキシ経由で接続先ドメインを渡す場合、名前解決はプロキシ経路上で行われ、ブラウザー側のFake-IP問い合わせを経由しないことがあります。

システムプロキシ：システムプロキシ設定を参照するアプリに適しています。この設定を参照しないゲーム、コマンドラインツール、バックグラウンドサービスなどは、従来のネットワーク経路で接続する場合があります。
TUN：仮想ネットワークインターフェースを使い、ルーティング条件に一致する通信を取り込みます。ルート、除外設定、DNS問い合わせがカーネルに届いているかも確認してください。
DNSハイジャック：TUN設定のdns-hijackなどを使って、指定したDNS通信を処理できます。ただし、ポート53をハイジャックしても、すべてのDoH、DoT、アプリ内蔵の名前解決を捕捉できるわけではありません。

複数のネットワークアダプター、VPN、企業向けセキュリティソフトが同時に動作していると、ルーティングの優先順位によって合成アドレスへの接続が誤ったインターフェースに流れることがあります。また、PCとルーターの両方で別々のカーネルを動かしているケースにも注意が必要です。DNSの対応関係はルーターにあるのに、接続はPC側のカーネルに渡されることがあります。独立した2つの対応関係は自動では共有されないため、DNS応答と接続処理が同じ通信取り込み経路に集まるようにしてください。

基本設定はシステムプロキシの設定とルールモードの説明を参照してください。トラブルシューティングでは、一度に変更する項目をひとつに絞りましょう。まずDNS、次に通信の取り込み、最後にルールとプロキシグループの選択を確認します。

動作確認：DNS応答、接続ログ、キャッシュ

手順1：mihomoの待ち受けポートに直接問い合わせる

前述のローカル検証用設定では、次のコマンドを実行できます。Windowsではnslookupを、digをインストール済みのLinuxまたはmacOSでは2つ目のコマンドを使えます。テストするドメインがフィルターリストに含まれていないことを確認してください。

nslookup -port=1053 example.com 127.0.0.1

dig @127.0.0.1 -p 1053 example.com A

応答が設定した198.18.0.0/16の範囲内であれば、その問い合わせにFake-IPが割り当てられています。実際のパブリックIPが返る場合は、フィルターリスト、最終的な実行設定、問い合わせ先を確認してください。タイムアウトする場合は、DNSが有効か、待ち受けポートが使用中でないか、カーネルが正常に起動したかを確認します。

手順2：実際のアプリ接続を確認する

通信の取り込み経路を設定したうえで同じドメインにアクセスし、クライアントの「接続」画面またはログ画面で、接続先ドメイン、一致したルール、アウトバウンドの経路を確認します。問い合わせコマンドで合成アドレスが返っても、確認できるのはDNSの割り当てだけです。アプリが接続でき、想定どおりのルールに一致して初めて、経路全体が機能していると判断できます。合成アドレスへのpingの結果を、Webサイトが利用できるかどうかの判定に使わないでください。

手順3：キャッシュを消去して再テストする

Windowsではipconfig /flushdnsでシステムのDNSキャッシュを消去できます。systemd-resolvedを使うLinuxではresolvectl flush-cachesを実行します。ブラウザーやアプリが独自のキャッシュや長時間接続を保持している場合もあるため、関連する接続を閉じるか、アプリを再起動してください。システムキャッシュを消去しても、すべてのアプリのキャッシュが消えるとは限りません。

mihomoのprofile.store-fake-ip: trueを使うと、Fake-IPの対応関係を永続化できます。ただし、誤ったルーティングは修正されず、別の端末と対応関係が共有されるわけでもありません。対応関係を再構築した場合、アドレスプールを変更した場合、またはモードを切り替えた場合は、アプリに残った古いアドレスも処理してください。「アプリは古いアドレスを保持しているが、カーネルには対応する記録がない」という状態を避けられます。

そのまま有効にしないほうがよいケースと切り戻し手順

DNSの結果を実際のサービスアドレスとして使うソフトもあります。たとえば、シグナリング情報にアドレスを含める、別の端末に接続先として渡す、LAN内にいるかどうかの判定に使うといったケースです。この場合、合成アドレスが、その対応関係にアクセスできない端末へ渡される可能性があります。社内ネットワーク、検証用ネットワーク、一部のゲームの接続手順も個別にテストしてください。端末全体で有効にしてブラウザーだけ確認するのでは不十分です。

特定のアプリだけで問題が起きる：使用するドメイン、独自DNSの有無、IPアドレスへの直接接続の有無を確認してください。互換性に問題があると確認できたドメインだけを、まずフィルターに追加します。
LAN内のサービスだけで問題が起きる：内部DNS、ドメインフィルター、プライベートネットワークへのルート、アウトバウンドルールを確認してください。名前解決が正しいのに接続できない場合は、ルーティングとアクセス権も調べます。
すべてのアプリで同時に問題が起きる：合成アドレスへの接続が同じカーネルに届いているか、TUNルートが有効か、ほかのVPNと競合していないかを確認してください。
アプリに実アドレスを渡す必要がある：実行設定をバックアップし、enhanced-mode: redir-hostに切り替えて設定を再読み込みします。その後、キャッシュを消去して接続を確立し直し、ルールの動作を確認してください。

最後に、プライバシー上の境界を区別しておきましょう。Fake-IPは暗号化DNSではなく、すべてのDNS問い合わせがプロキシ経由で送信されることも保証しません。上流DNSのプロトコル、DNSのアウトバウンド設定、アプリ独自の名前解決、DIRECTルールによって実際の経路は変わります。想定どおりに動いているかは、クライアントの「Fake-IP」スイッチがオンかどうかだけでなく、問い合わせ、ルーティング、ログの情報を合わせて判断してください。