Clash Fake-IPモードとは？仮想IPプールの仕組みとDNS応答を速める方法

Fake-IPの仕組み：仮想IPを先に返し、その後に接続を処理

ClashでFake-IPモードを有効にすると、DNSクエリに対して198.18.0.2のようなアドレスが返されることがあります。これは接続先サイトのグローバルIPでも、プロキシノードのアドレスでもありません。ドメイン名に対してコアが割り当てる一時的な仮想IPです。アプリがこのアドレスに接続すると、同じコアが通信を受け取り、対応するドメイン名を特定してルールを適用し、接続先を選びます。

この仕組みでは、「アプリが接続に使うアドレスを返すこと」と「実際のサーバーアドレスを特定すること」を分けて処理します。接続先のドメイン名をリモート側で解決できるプロキシなら、クライアントがローカルで実IPを解決する前に接続を開始できます。短縮できるのは主に接続前のDNS待ち時間であり、回線速度が上がるわけではなく、すべてのサイトが速くなるとは限りません。

198.18.0.0/16がグローバルIPではない理由

198.18.0.0/15はネットワーク機器のベンチマーク用に予約されたIPv4アドレス帯で、通常のグローバルサービス向けではありません。Clashの設定では、この範囲から198.18.0.0/16を使うことが多く、一般的な記述例はfake-ip-range: 198.18.0.1/16です。このプレフィックスには65,536個のIPv4アドレスが含まれますが、コアが同時にその数のマッピングをサポートすると保証するものではありません。

アドレスプールの割り当て、記録、解放はコアが管理します。あるドメインに今日198.18.0.2が割り当てられても、次回の再起動後やマッピング変更後も同じとは限りません。そのため、仮想IPを長期利用する静的ルートやサーバーの許可リスト、アプリの固定設定に登録しないでください。社内ネットワーク、検証環境、別のVPNですでにこのアドレス帯を使っている場合は、ルートの競合を確認してからプールの変更を検討してください。

Fake-IPとredir-hostの違い：DNSの待ち時間はどこで発生する？

2つのモードの主な違いは「アプリに返すアドレス」であり、「プロキシを使うかどうか」ではありません。ルールモードやグローバルモードは接続先の選び方を決め、enhanced-modeはDNSの拡張処理方式を決めます。これらは別の層の設定です。

プロキシ経由のアクセスを1回行う場合の流れ

1. redir-host：アプリがドメイン名を問い合わせると、Clashは上流DNSに実IPを問い合わせ、結果をアプリに返します。アプリがそのアドレスに接続し、ルールに従って接続先が選ばれます。
2. Fake-IP：アプリがドメイン名を問い合わせると、Clashは「ドメイン名と仮想IP」の対応を保存して応答します。接続がコアに届いた後、ドメイン名を復元し、ルールに従って接続先を選びます。
3. プロキシがドメイン名を接続先として扱える場合：実IPの解決はリモート側で行えます。一方、最終的に直結する場合や、ルール判定に接続先IPが必要な場合は、ローカルで実IPを解決することがあります。

たとえば、キャッシュにない上流DNSクエリに120ミリ秒かかるとします。Fake-IPなら、アプリが接続を開始する前にこの応答を待たずに済む場合があります。この120ミリ秒は処理の流れを示す例であり、実測に基づく速度向上の保証ではありません。実際の所要時間はルール、ノードとのハンドシェイク、リモート側での名前解決、サーバーの応答にも左右されるため、ページ全体の読み込みが同じ時間だけ短縮されるとは限りません。

Fake-IPは「DNSをまったく使わない」という意味でもありません。ノードのサーバー名の解決や、直結するドメインの実IP取得、IPルールの判定などでDNSが必要になる場合があります。また、アプリがHTTPプロキシやSOCKSプロキシにドメイン名を直接渡す場合、ここで説明した仮想IPの割り当てを経由しないことがあります。

最小構成：仮想IPマッピングを有効にしてLANの名前解決を維持

以下は、Clash Meta（現mihomo）でよく使われる設定項目の関係を示す例です。サブスクリプションにそのまま置き換えられる完全な設定ではありません。作業前に現在の設定をバックアップし、既存のノード、プロキシグループ、ルールを残したまま、DNS項目をクライアントが対応するオーバーライド設定に統合してください。同じYAMLファイル内にトップレベルのdnsキーを重複して作成しないでください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  fake-ip-filter:
    - localhost
    - '+.lan'
    - '+.local'
    - '+.home.arpa'

• enable：コアのDNS機能を有効にします。DNSを有効にせずモードだけ変更しても、想定した問い合わせ経路にはなりません。
• listen：例ではテストしやすいように、ローカルのUDP/TCP 1053番ポートで待ち受けます。システムの標準DNSは53番ポートを使うため、自動的に1053番ポートへ切り替わるわけではありません。
• enhanced-mode：fake-ipを選択します。比較テストではredir-hostに変更し、ほかの条件は同じにしてください。
• nameserver：実IPの解決が必要な場合に使う上流DNSを指定します。例は通常のDNSで、通信は暗号化されません。ネットワークからの到達性とプライバシー要件に合わせて選んでください。
• fake-ip-filter：一般的な除外方式では、リストに一致したドメイン名に対して実IPを返し、アドレスプールからの割り当てを行いません。

mihomoの一部バージョンには、フィルターリストの扱いを変更するfake-ip-filter-modeがあります。この記事では除外方式を前提に説明しています。既存の設定でwhitelistモードを明示している場合、リスト内のドメインが「Fake-IPを使わない」とは限りません。クライアントに含まれるコアのバージョンや既定のフィルター項目も異なることがあるため、実際に読み込まれた設定を確認してください。

fake-ip-filterの例外設定：不具合が起きるドメインを個別に追加

一般に「Fake-IPのホワイトリスト」と呼ばれるものは、仮想IPを割り当てないドメインの例外リストを指します。リストに追加しても、自動的に直結したりルーターのDNSを使ったりするわけではありません。直結するかどうかはルールで、実IPをどのDNSに問い合わせるかはDNSポリシーで決まるため、それぞれ個別に確認してください。

LAN機器とプライベートドメイン

プリンター、NAS、ルーターの管理画面、社内サービスなどは、LAN内のDNSに依存することがよくあります。home.arpaや組織内ドメインには、正確なサフィックス指定の例外を追加し、そのドメインを適切なローカルDNSで解決してください。パブリックDNSは通常、内部ホストのアドレスを知らないため、フィルター項目を追加するだけでは「ドメインが存在しない」という応答になることがあります。

.localはmDNSで解決されることが多く、mDNSの探索方式は通常のユニキャストDNSとは異なります。フィルターリストに追加して解決できるのは、Fake-IPを割り当てないようにするところまでです。機器を検出できない場合は、パブリックDNSを追加し続けるのではなく、LANへのアクセス許可、マルチキャスト、TUNのルーティングを確認してください。

DNS応答の検証や、別の機器へのアドレス通知を行うアプリ

一部のゲーム、音声通話、時刻同期、デバイス検出アプリは、DNSの応答を検証したり、解決したIPを別の機器に渡したりします。別の機器にはローカルコアのマッピングがないため、その仮想IPでは接続できません。この場合は接続ログから該当ドメイン名を特定し、個別に例外を追加してから機能全体を再テストしてください。

• まずはドメインを個別指定：異常が1つのサービスだけなら、実際に問い合わせられたドメイン名を追加してください。大規模なドメインサフィックス全体を除外するのは避けましょう。
• 症状に合わせて確認：Webページが開いても、音声通話、オンライン対戦、デバイス検出が正常とは限りません。元々失敗していた操作を含めてテストしてください。
• アプリの種類だけで一括除外しない：ゲーム、NTP、STUNが必ずFake-IPと競合するわけではありません。例外が必要かどうかは、実装と通信の捕捉方法によります。

mihomoでよく使われるドメインマッチ構文では、+.home.arpaは該当ドメインとそのサブドメインに一致します。古いClashコアを使う場合は、該当する構文に対応しているか先に確認してください。フィルターを変更した後は、アプリやシステムのキャッシュも消去します。そうしないと、変更前に取得した仮想IPが使われ続けることがあります。

TUNとシステムプロキシ：仮想IPへの接続をコアに戻す

Fake-IPはDNSの動作方式、TUNは通信を捕捉する仕組みです。併用できますが、同じ設定ではありません。TUNはシステムプロキシに従わないアプリの通信も捕捉しやすい方式です。システムプロキシが影響するのは、システムのHTTP、HTTPS、SOCKS設定を利用するアプリが中心で、あらゆるアプリの仮想IP接続を捕捉できるとは限りません。

まずDNSをテストし、その後に接続経路を確認

1. 設定が読み込まれており、DNSの待ち受けアドレスが127.0.0.1:1053であることを確認します。ポート使用中と表示された場合は、ほかのDNSサービスやコアの二重起動を先に調べてください。
2. そのポートに直接問い合わせ、フィルターリストに含まれないドメイン名に対して、アドレスプール内のAレコードが返るか確認します。
3. システムやアプリが実際に使用しているDNSを確認します。直接クエリのテストに成功しても、システムの標準クエリがClashに届いているとは限りません。
4. 対象にアクセスして接続ログを確認し、ドメイン名を復元できていること、適用ルールと接続先が想定どおりであることを確かめます。

# macOS / Linux：digが標準搭載またはインストール済みの場合に使用
dig @127.0.0.1 -p 1053 example.com A

# 標準の名前解決経路と比較
dig example.com A

最初のコマンドでは、198.18.0.2などのプール内アドレスが返ることがあります。割り当てられる値は一定ではありません。最初の結果が仮想IPで、2つ目がグローバルIPなら、Fake-IP設定が読み込まれていないと判断する前に、DNSの入口を確認してください。ブラウザー独自の暗号化DNS、アプリ内蔵のリゾルバー、キャッシュによって、実際のアクセスが別経路になることもあります。

TUN設定のdns-hijackは、条件に合うDNS通信の捕捉に使えます。よくある指定例はany:53ですが、対応状況と対象範囲はコア、プラットフォーム、プロトコルによって異なります。あらゆるDNS通信を捕捉する設定ではありません。HTTPSの443番ポートで送信されるDoHは、従来のDNSの53番ポートを捕捉しても、自動的にコアのDNSへ流れるわけではありません。

よくある不具合：アドレスプール、キャッシュ、ルールを順に確認

198.18のアドレスを取得したのにWebページが開かない

まず、その接続がコアのログに記録されているか確認します。まったく表示されない場合は、アプリがプロキシを回避していないか、TUNルートが有効か、別のVPNがルートを奪っていないかを調べてください。ドメイン名と適用ポリシーが表示される場合は、DNSモード全体をすぐに切り替えるのではなく、ノードの状態、直結時のDNS、ルールを確認します。

コアの再起動後、一部のアプリだけ一時的に使えない

アプリに古い仮想IPがキャッシュされている一方、コア側ではマッピングが作り直されている可能性があります。まず問題のアプリを終了して再起動し、必要に応じてシステムのDNSキャッシュを消去してください。Windowsではターミナルでipconfig /flushdnsを実行できます。systemd-resolvedを使うLinuxではresolvectl flush-cachesを実行できます。これらのコマンドでブラウザーやアプリ独自のキャッシュまで消えるとは限りません。

一部のコアには、マッピングを保存するprofile.store-fake-ipがあり、再起動前後の不一致を軽減できます。ただし、DNSの迂回、複数のコアによる別々のアドレスプール管理、ルート競合は解決できません。対応状況を確認せず、この項目を古いコアの設定に追加しないでください。

フィルターリストに追加しても接続できない

まず再度DNSクエリを実行し、応答が仮想IPから実IPに変わったか確認します。アドレスプール内のIPのままなら、フィルター構文、モード、キャッシュを確認してください。実IPに変わった場合は、その内部ドメインを正しいDNSで解決できているか、接続が適切な接続先を通っているかを調べます。フィルター項目が変えるのはアドレスの生成方法であり、ルールによる振り分けを代替するものではありません。

Fake-IPを維持する場合とredir-hostを比較する場合

• まずはFake-IPを維持：DNSと接続の両方を同じコアで処理し、主にドメイン名で振り分けていて、プロキシ接続前のローカルDNS待ちを減らしたい場合。
• まずは該当ドメインだけ例外に：内部サービス、デバイス検出、特定アプリの一部だけに問題があり、ほかの通信は正常な場合。
• redir-hostと比較テスト：多くのプログラムが実IPに依存する場合や、仮想IPへの接続を安定して捕捉できない環境では、両モードの実際の互換性を比較してください。

一度に変更する設定は1つにし、ドメイン名、DNSの応答、適用ルール、エラー内容を記録してください。まずクエリが正しいDNSに届いていることを確認し、次に接続が正しいコアに戻っていることを確かめてから、上流DNSと接続先の状態を判断します。アドレスプール、ノード、すべてのルールを同時に変更するより原因を特定しやすく、元に戻せる設定も維持できます。