Clash Meta（mihomo）の設定では、DNSモードがドメイン解決、ルール照合、接続確立に直接影響します。Fake-IPは代表的な動作方式の一つです。クライアントは接続先ドメインをすぐに実際のパブリックIPへ解決せず、専用アドレスプールから仮想IPを割り当て、ドメインと仮想IPの対応関係を内部に保存します。アプリからはこの仮想アドレスが見えますが、プロキシコアは後続の接続段階で元のドメインを復元し、ルールに従って直接接続、プロキシ、拒否を判断できます。

この処理はTUNモードと併用されることが多いものの、両者は同じ概念ではありません。Fake-IPが解決するのはDNS応答とドメイン情報の保持であり、TUNが解決するのはシステムやアプリから発生したネットワークトラフィックを受け取る方法です。両者の境界を理解してこそ、障害がDNS、ルール、ルーティング、あるいはアプリ自体のどこで発生したのかを判断できます。本記事では、名前解決の流れ、設定の選び方、利用シーン、トラブルシューティングの順に説明します。

Fake-IPで変わること

従来のredir-hostでは、通常、アプリがシステムのリゾルバーにドメインを問い合わせ、リゾルバーが実際のIPを返し、アプリがそのIPで接続を確立します。プロキシコアから接続先IPしか見えない場合、アクセス先を推測するにはドメインスニッフィング、追加ルール、既知のアドレス範囲などに頼る必要があります。HTTPS通信ではTLSのSNIからドメインを取得できる場合がありますが、一部の暗号化プロトコルや非標準プロトコルでは必ずしも推測できません。

Fake-IPモードでは処理の順序を「先にドメインを保持し、その後で接続する」形に変えます。アプリがexample.comを問い合わせると、DNSモジュールはアドレスプール内の仮想アドレス、たとえば198.18.0.23を返します。このアドレスは対象サーバーの実際のアドレスではなく、コアがドメインを識別するためのインデックスです。アプリが198.18.0.23へ接続すると、プロキシが通信を引き受け、コアはマッピングテーブルからexample.comを復元してドメインルールを適用します。

Fake-IPのアドレスプールには、198.18.0.1/16のような専用の予約テストネットワークがよく使われます。これらのアドレスをパブリックな接続先として扱ってはいけません。アドレスプールのサイズ、除外リスト、マッピングの有効期間は、コアと設定の両方によって決まります。仮想IPとドメインの対応関係は通常キャッシュで管理されるため、同じドメインにしばらく同じアドレスが割り当てられることもあれば、キャッシュの削除、設定の再読み込み、アドレスプールの変更後に再割り当てされることもあります。

1回のリクエストの処理経路

  1. アプリがDNS問い合わせを開始します。問い合わせるのは最終的なIPではなくドメインです。
  2. Clashが問い合わせを受け取り、nameserver、fallback、fake-ip-filterなどの設定に従って処理します。
  3. Fake-IPモジュールがドメインのマッピングを作成し、アドレスプール内の仮想IPをアプリに返します。
  4. アプリが仮想IPへ接続し、システムプロキシ、透過プロキシ、またはTUNがこの接続をClashへ渡します。
  5. Clashがマッピングからドメインを復元し、ドメインルール、プロセスルール、IPルール、フォールバックルールの順に適用します。
  6. ポリシーグループを選択した後、コアが直接接続またはプロキシ経由で実際の接続先へ接続します。

ここで重要なのは「ルールが認識する接続先」です。マッピングが有効で、通信がClashを経由している場合、ドメインルールは通常、接続の早い段階で機能します。アプリがシステムDNSを迂回して固定のIPを直接使用した場合や、通信がClashに入っていない場合、Fake-IPがドメインを自動的に復元することはできず、ルーティングの引き受けを代替することもできません。

Fake-IP、実アドレス解決、TUNモードの関係

Fake-IPとredir-hostは、DNSが返す値に関する二つの方向性です。Fake-IPはドメインのコンテキストを保持することを重視し、ドメインルールに基づく安定した振り分けに適しています。一方、redir-hostは一般的なDNSに近く、アプリが実際のIPを取得するため、実アドレスに依存する一部のプログラムでは互換性が高くなります。どちらのモードでも、正しいDNSハイジャック、システムプロキシ、または通信の引き受けが必要であり、特定のモードが必ず高速になると単純に考えることはできません。

TUNモードは別の層に位置します。TUNを有効にするとシステムに仮想ネットワークインターフェースが作成され、ルーティング条件に合う通信がClashへ送られます。これにより、HTTPやSOCKSのシステムプロキシに従わないプログラムや、一部のバックグラウンドサービス、UDP通信も引き受けられます。ただし、TUNを有効にしただけでDNSが自動的に正しくなるわけではありません。システムが外部DNSへ問い合わせを送り続けている場合や、アプリが独自の暗号化DNSを使っている場合、Fake-IPのマッピングがリクエスト全体に参加できない可能性があります。

コンポーネント 主な役割 よくある誤解
Fake-IP ドメインに仮想アドレスを割り当て、マッピングを保持する リモートDNSサーバーでもプロキシノードでもない
DNSモジュール 問い合わせを受け取り、リゾルバーを選択して結果を返す nameserverを変更するだけで、すべてのDNSリークを解決できる
TUN システムルーティング上のネットワーク通信を引き受ける TUNを有効にすれば、すべてのアプリが必ずプロキシを経由する
ルールシステム ドメイン、IP、ポートなどの条件に基づいてポリシーを選択する コアに一度も入っていない接続はルールで処理できない

デスクトップでは、システムプロキシでブラウザーやシステム設定に従うアプリを通常カバーできます。より多くのプログラムを対象にする必要がある場合は、TUNを検討できます。Androidでは、VpnServiceが一般的な通信引き受けの基盤となり、システムのVPN権限、省電力設定、他のVPNアプリの状態が結果に影響します。iOSにもネットワーク拡張の権限やクライアント機能上の制限があるため、デスクトップ向けのTUN設定をそのまま適用しないでください。

Fake-IP設定前に確認したい項目

設定ファイルのフィールド名と利用可能なオプションは、使用中のmihomoバージョンのドキュメントとクライアント画面を基準にしてください。クライアントによって、DNS、TUN、オーバーライド設定の編集場所は異なります。以下は全プラットフォームで同一設定をそのまま複製するためではなく、確認の進め方を示すものです。

1. DNS問い合わせを受け取るのは誰かを確認する

まず、クライアントでコアDNSが有効になっているか、システムのDNS問い合わせがClashへ転送されるかを確認します。デスクトップクライアントはローカルのリスニングアドレスで問い合わせを受け取る場合があり、TUNクライアントはDNSハイジャックでUDPまたはTCPの問い合わせを処理する場合があります。ブラウザーで「セキュアDNS」が有効になり、指定したプロバイダーへ直接接続していると、システムDNSの設定が反映されないことがあります。テスト時はアプリ内蔵の暗号化DNSを一時的に無効にするか、明確なネットワークポリシーに組み込んでください。

2. Fake-IPアドレスプールを設計する

アドレスプールには仮想マッピングに適した予約ネットワークを使用し、実際のLAN、社内ネットワーク、コンテナネットワーク、よく使うVPNネットワークとは重複させないでください。たとえばLANが192.168.1.0/24の場合、Fake-IPアドレスプールを同じネットワークに設定してはいけません。アドレスが衝突すると、システムが仮想アドレスをLAN上のホストと誤認し、接続タイムアウト、ルーティング異常、一部の社内サービスにアクセスできないといった症状が出ます。

Fake-IPアドレスプールを一般的な家庭用ネットワークに安易に設定しないでください。設定前に、端末のルーティングテーブル、Dockerブリッジ、仮想マシンのNIC、社内VPNが使用するネットワークを確認します。アドレスプールが実ネットワークと重複している場合は、プロキシノードを何度も切り替えるのではなく、先にアドレスプールを変更し、キャッシュを削除してから再テストしてください。

3. fake-ip-filterを設定する

すべてのドメインがFake-IPに適しているわけではありません。LANホスト名、ルーター管理アドレス、実IPによる判定が必要なサービス、ローカル名前解決に依存する一部のドメインは、通常、除外リストに追加します。除外したドメインは実アドレス解決を使用するか、クライアントの実装に応じて元の結果を返します。最初から除外範囲を広げすぎると、多くのドメインが実アドレス解決に戻り、ルール照合とDNSの挙動を把握しにくくなります。

フィルターリストは実際の障害に応じて追加し、変更の目的を毎回記録してください。プリンターの検出に失敗した場合は、まずLANドメインやマルチキャスト名前解決を確認します。社内ドメインが開かない場合は、特定のネットワーク内で社内DNSを使う必要がないかを確認します。一度の失敗だけを理由に、トップレベルドメイン全体や中国本土のドメインをすべて除外しないでください。

4. nameserverとfallbackの役割分担を確認する

nameserverは通常のリゾルバー、fallbackは予備のリゾルバーまたは特定の判定に使う名前解決元です。具体的な動作はコアのバージョンと設定によって異なります。リゾルバーを設定する際は、到達性、応答速度、必要なレコード種別への対応、リクエストをプロキシ経由で送るべきかを確認してください。リゾルバー自体に到達できない場合でも、Fake-IPがキャッシュ結果を返すことはありますが、新しいドメインでは解決待ちや接続失敗が発生します。

nameserver-policyを設定している場合は、ルールの記述とドメイン範囲が正確か確認してください。ポリシーの目的は、ドメインごとに適切なリゾルバーを使い分けることであり、プロキシルールの代替ではありません。DNS解決に成功しても接続先への接続が成功するとは限らず、最終的にはルールが選んだポリシーグループ、ノードの可用性、リモートサービスの応答も確認する必要があります。

Fake-IPが適しているシーン

設定がドメインルールによる振り分けに依存している場合、Fake-IPを使うとルールのコンテキストを保ちやすくなります。たとえばドメインのサフィックスで直接接続とプロキシを分ける場合、複数のサービスに独立したポリシーグループを割り当てる場合、接続先IPだけで判定したことによる誤振り分けを減らしたい場合などです。接続の早い段階でドメインを利用できるため、ルールの管理も実際に表示されるサイト名に近くなります。

TUNモードでは、システムプロキシに従わないプログラムにFake-IPが特に役立ちます。プログラムがシステムネットワークスタック経由でDNS問い合わせを行い、返されたアドレスへ接続すれば、コアがマッピングから接続先を識別できる可能性があります。ただし、独自DNS、DoH、DoTを使うプログラムや、ドメイン解決結果を独自キャッシュに固定するプログラムには別途対応が必要です。QUIC、IPv6、独自ネットワークプロトコルを使うアプリもあるため、テストではプロトコルの違いを考慮してください。

LAN機器ではFake-IPの使用に注意が必要です。プリンター、NAS、スマートホームコントローラー、ルーター管理画面、LANゲームの検出は、実際のLANアドレス、マルチキャスト、ブロードキャストに依存することが多く、これらの通信はプロキシに適さない場合があります。関連ドメインをfake-ip-filterに追加し、LANネットワークには直接接続ルールを設定するのが安全な出発点です。

よくある異常とトラブルシューティングの順序

ブラウザーにDNS_PROBE_FINISHED_NXDOMAINが表示される、または名前解決がタイムアウトする

まず、すべてのドメインで発生しているのか、特定のドメインだけなのかを確認します。ClashのログにDNSリクエストが出ているか、クライアントのDNSリスナーが起動しているかを確認し、システムやブラウザーがそのリスナーを迂回していないかも調べます。次に、到達可能なリゾルバーへ一時的に切り替え、クライアントのDNSキャッシュを削除して設定を再読み込みします。特定のドメインだけ失敗する場合は、nameserver-policy、ドメインの綴り、フィルターリスト、レコード種別を確認してください。

Webページは開くが、ルールが直接接続または誤ったプロキシに振り分けられる

接続詳細で、接続先ドメイン、接続先IP、適用されたルールを確認します。接続詳細にFake-IPアドレスしか表示されない場合は、マッピングが正しく復元されていません。接続がClashから受け取られていないか、アプリがキャッシュ済みのIPを使っている可能性があります。実際のドメインが表示されているのに想定どおりのルールにならない場合は、ルールの順序を確認します。より具体的なDOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDは、より広範なルールより前に置き、MATCHのフォールバック項目はルール末尾に配置してください。

ルールを変更したら保存して設定を再読み込みします。ファイルを編集しただけで再読み込みをしていない場合、実行中のコアは古いルールを使い続ける可能性があります。テストには新しい接続を使用してください。既存の接続やキャッシュは、名前解決と照合の全工程を再実行しないことがあります。

TUNを有効にするとLAN機器や社内ネットワークに接続できない

まずTUNを無効にして比較テストを行います。無効にすると復旧する場合は、TUNのルーティング、自動ルート、厳格ルート、DNSハイジャック、バイパスするネットワークの設定を確認してください。家庭用ルーター、社内ネットワーク、プリンターがあるネットワークが、誤ってプロキシポリシーへ送られていないことを確認します。LAN通信では、ルールとルートの両方で直接接続が許可されている必要があります。IP-CIDRルールを1つ書くだけで、通信がコアに入っていなければ問題は解決しません。

複数のVPN、仮想マシン、コンテナ、セキュリティソフトが同時にルーティングテーブルを変更している可能性があります。トラブルシューティングでは、不要なVPNや仮想NICを一時停止し、TUN有効化前後のデフォルトルートとDNSサーバーを記録してください。Windows、Linux、Androidでは権限モデルが異なります。クライアントに「有効」と表示されても、システムが必要な権限をすべて付与しているとは限りません。

一部のアプリだけ完全にネットワークへ接続できない

アプリがIPv6、QUIC、固定IP、内蔵DoH、独自プロキシを使っていないか確認します。Fake-IPは主にドメイン解決を基盤としてマッピングを作るため、IPを直接使う接続はIPルールに頼って処理することになります。アプリがIPv6を優先する一方で、現在のTUN、ノード、ルールがIPv6に対応していない場合、ブラウザーは正常なのに特定のアプリだけ失敗することがあります。テスト段階ではIPv4、IPv6、TCP、UDPを個別に検証し、そのうえでプロトコルやルーティング範囲を調整してください。

# トラブルシューティングの考え方のみ。実際のフィールドは使用中のクライアントとmihomoのバージョンに合わせて確認
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

tun:
  enable: true
  auto-route: true
  dns-hijack:
    - any:53

上の断片はフィールド間の関係を示すものであり、すべてのシステムでそのまま使える設定ではありません。dns-hijack、TUNルート、フィルター項目は、クライアントのラッパーやバージョンの違いによって影響を受ける場合があります。特にLANドメイン、社内DNS、IPv6環境では、まず現在のネットワークを把握してから項目を一つずつ追加してください。

再現性のあるチェックリスト

  1. 現在のクライアントバージョン、コアバージョン、OSバージョン、ネットワーク環境を記録し、元の設定を保存する。
  2. 他のVPN、プロキシソフト、ブラウザー独自のDNSを無効にし、変数を一つに絞ったテスト環境を作る。
  3. 通常のドメインが名前解決できることを確認し、Clashに対応するDNSリクエストが表示されるか観察する。
  4. 返されたアドレスがFake-IPアドレスプールに属するか確認し、アドレスプールがLANと重複していないことを確認する。
  5. 接続詳細を確認し、マッピングからドメインを復元できているか、実際に適用されたルールとポリシーグループが正しいか照合する。
  6. 通常のWebページ、LAN機器、ログインが必要なアプリ、UDPサービス、IPv6サービスを個別にテストする。
  7. 一度に変更する項目は一つだけにし、保存、再読み込み、キャッシュ削除を行ってから同じテストを繰り返す。

redir-hostへ切り替えると特定のアプリが復旧する場合、そのアプリが実IP、LAN名前解決、または特殊なプロトコルに依存している可能性があります。これはFake-IP設定が誤っていることを自動的に意味するわけではありません。まず該当ドメインをフィルターリストに追加するか、そのアプリの通信に明確な直接接続ポリシーを設定してください。逆に、redir-hostではドメインルールが不安定で、Fake-IPでは安定する場合は、ノードを変更するだけでなく、DNSハイジャックとマッピングの破棄処理を優先して確認します。

まとめ：リクエスト経路に沿って原因を特定する

Fake-IPの価値は、DNS、接続の引き受け、ルール照合を通じてドメイン情報を維持できる点にあります。単独の高速化スイッチではなく、利用可能なリゾルバー、正しいルーティング、有効なプロキシポリシーの代わりにもなりません。適切な設定は、端末の種類、アプリのプロトコル、LAN構成、TUNによる通信の引き受けが必要かどうかによって決まります。

異常が発生したら、「アプリがDNSを問い合わせる—Clashがアドレスを返す—通信がコアに入る—マッピングからドメインを復元する—ルールがポリシーを選ぶ—ノードが接続を確立する」という順番で確認すると、DNSやノードを何度も切り替えるより早く原因を特定できます。LAN、社内ネットワーク、特殊なアプリには明確な例外処理を用意し、ログと接続詳細で変更のたびに検証すれば、Fake-IP設定を保守しやすくできます。