Clash Fake-IPモードの仕組み：DNSマッピングの流れ・活用場面・除外設定

Clash、Clash Meta、および後継のメンテナンス系統であるmihomoのDNS設定では、Fake-IPは誤解されやすい項目です。返されるアドレスは実際のIPに見えますが、主な目的はリモートサーバーを直接示すことではなく、コアが接続を引き受けた際に元のドメイン名を復元できるようにすることです。これを理解して初めて、接続失敗の原因がDNS、ルール、プロキシノード、アプリ自体の通信処理のどこにあるのかを切り分けられます。

Fake-IPは、ドメインルールを中心とした設定に特に適しており、TUNモードと併用されることも多い機能です。アプリが先にドメインを解決することでルール判定に必要な情報が失われるのを抑えられますが、すべての機器、プロトコル、LAN内の名前がマッピングアドレスに適しているわけではありません。除外リストをむやみに広げるのではなく、まず検索と接続がどの経路を通るのかを確認し、実アドレスを必要とする対象だけにフィルターを設定するのが基本です。

Fake-IPが解決する主な課題

通常のDNS検索では、ドメイン名が実際のIPアドレスに解決されます。アプリがそのIPへ接続すると、プロキシコアからは宛先アドレスしか見えず、元のドメイン名が接続情報から失われることがあります。その場合、DOMAIN-SUFFIX、DOMAIN-KEYWORD、特定ドメインのルールを直接適用しにくくなり、IP、GeoIP、またはフォールバックルールに頼ることになります。1つのIPで複数サイトを提供するCDNでは、この問題が特に顕著です。

Fake-IPでは、Clash内蔵DNSが検索を受け取り、ドメインに一時的なマッピングアドレスを割り当て、「ドメイン名—マッピングアドレス」の対応関係を保存します。アプリはそのアドレスへ接続し、トラフィックが再びコアに入ります。コアはマッピングテーブルから元のドメイン名を特定し、ドメインルールに基づいてポリシーを選択します。実際にリモートへ接続する際は、設定に従って利用可能な実アドレスを取得し、直接接続または選択したプロキシ経由で通信します。

多くの設定では、198.18.0.1/16をデフォルトのアドレスプールとして使用します。このネットワークはベンチマーク用途に予約されており、通常はインターネット上でルーティングされません。公開インターネットで使われるべきではない範囲を利用してマッピングを作ることで、通常の公開宛先と衝突する可能性を下げられます。自宅や検証環境ですでに同じネットワークを使っている場合は、ルーティング判定が重ならないようアドレスプールを変更してください。

Fake-IPとRedir-Hostの違い

redir-hostモードでは通常、アプリに実際の名前解決結果を返すため、接続先は従来のネットワーク動作に近くなります。実IPに依存する一部のプログラムには分かりやすい一方、ドメインルールが正確に一致するかどうかは、トラフィックの入口、スニッフィング機能、アプリの名前解決経路に左右されます。Fake-IPはマッピングによってドメイン名のコンテキストを積極的に保持するため、細かなドメインルーティングが必要な設定に適しています。

DNS検索からルール判定までの全体フロー

Fake-IPの問題を調べるときは、1回のDNS検索だけを見てはいけません。全体の経路には少なくとも、アプリによる検索、内蔵DNSの応答、アプリによるマッピングアドレスへの接続、コアによるドメイン名の復元、ルール判定、上流DNSでの名前解決という6つの段階があります。どこか1つでもClashを経由しなければ、結果が想定と異なる可能性があります。

1. アプリがドメイン名を検索します。ブラウザー、ゲームクライアント、システムサービスが、設定されたDNSアドレスへAまたはAAAAレコードを問い合わせます。検索がClash内蔵DNSに入らなければ、Fake-IP設定は適用されません。
2. コアが除外ルールを確認します。ドメインがfake-ip-filterに一致すると、コアは実際の名前解決結果を返します。一致しなければ、マッピングアドレスの割り当てに進みます。
3. マッピングを生成または読み込みます。コアはFake-IPアドレスプールからアドレスを取り出し、そのアドレスを元のドメイン名に関連付けます。同じドメインを再検索した場合は既存のマッピングを再利用することがあり、保持期間はコアのキャッシュ管理によって決まります。
4. アプリが接続を開始します。アプリはマッピングアドレスを宛先としてTCPまたはUDPセッションを確立します。システムプロキシモードとTUNモードでは引き受けの経路が異なりますが、重要なのは接続が再びClashに入ることです。
5. 対象ドメインを復元します。コアはマッピングテーブルを読み取り、対象を検索時のドメイン名に戻してルール判定を行います。
6. ポリシーと名前解決経路を選択します。ルールによって、直接接続、プロキシ、または特定のポリシーグループのいずれかが決まります。実際に接続するときは、DNS設定に従ってリモートの実アドレスを取得します。

この仕組みから、よくある現象も説明できます。コマンドラインでnslookupを実行してマッピングアドレスが表示されても、アクセスがプロキシ経由になったとは限りません。DNS応答はマッピング段階を完了しただけで、最終的にどのポリシーを使うかは後続の接続とルールによって決まります。逆に、アプリが内蔵DoH、固定IP、独自のDNS経路を使う場合は、システム検索自体が発生せず、Fake-IPがドメイン名を推測することもできません。

システムプロキシモードとTUNモードの違い

システムプロキシモードでは、プロキシ設定に従うHTTPまたはSOCKSアプリがドメイン名をそのままプロキシ側へ渡せるため、場面によってはFake-IPに依存しません。システムプロキシ設定を読み取れないアプリは、別の透過的な引き受け手段がない限り、直接接続する可能性があります。TUNモードは仮想ネットワークインターフェースの層でより多くのシステムトラフィックを受け取るため、DNSハイジャック、Fake-IP、ルーティング設定と組み合わせて使われることが一般的です。

TUNを有効にしたからといって、すべてのDNSが自動的にコアへ入るわけではありません。OSが暗号化DNSを使うこともあれば、ブラウザーが独自のセキュアDNSを有効にしていることもあります。設定時は、DNSハイジャックの範囲、待ち受けポート、LAN共有の方法、システムファイアウォールの状態を確認してください。検索が外部DNSを通り、接続だけがTUNに引き受けられる場合、コアに見えるのは通常実IPであり、ドメインルールの判定にはスニッフィングが必要になることがあります。

mihomoの基本設定方法

以下は、各フィールドの関係を理解するための簡略化した例です。実際のクライアントでは、GUIが一部のフィールドを生成する場合や、ユーザーの上書き設定とサブスクリプション内容を統合する場合があります。変更前に元の設定を保存し、クライアントのログで現在どのファイルが読み込まれているか確認してください。

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"
    - "localhost"
    - "time.*.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

enableは内蔵DNSを制御し、enhanced-modeは拡張モードを選択します。fake-ip-rangeはマッピングアドレスプールを定義し、fake-ip-filterは実際の結果を返すドメインを決めます。nameserverは主な上流リゾルバーです。default-nameserverは、DoHやDoTなど上流サーバー自体のドメイン名を解決する用途で使われることが多いため、通常は直接到達できるIPアドレス形式のリゾルバーを指定します。

設定形式は、コアのバージョンやクライアントのラッパー実装によって変わります。mihomoは比較的豊富なDNSフィールドとルール表現に対応していますが、旧版のClashクライアントがすべての新しいフィールドを認識するとは限りません。複数のクライアントでサブスクリプションを使う場合は、各クライアントが紐付くコアとバージョンを先に確認してください。画面上で保存できるからといって、実行中のコアがその設定を採用しているとは限りません。

上流DNSとルーティングの関係

上流DNSの選択は、実アドレスの取得、DNS汚染の回避、接続遅延に影響しますが、プロキシルールとは別の層です。あるドメインを海外のDoHで解決したからといって、接続まで必ずプロキシ経由になるわけではありません。同様に、国内のDNSを使って解決したからといって、その接続が必ず直接接続になるわけでもありません。最終的なポリシーは、ルールの順序と一致結果によって決まります。

mihomoの設定では、nameserver-policyを使ってドメインルールごとに異なる上流DNSを指定することもできます。たとえば、LAN内や特定地域のドメインにはローカルリゾルバーを使い、それ以外には暗号化リゾルバーを使う設定です。この機能は名前解決の要件を明確に把握している環境に適していますが、ルールが増えすぎるとトラブルシューティングが難しくなります。問題が起きたら、まず利用可能な上流DNSを1つに絞り、Fake-IPの流れが正常だと確認してからルーティングを戻してください。

適した用途とそのまま適用すべきでない環境

ドメインルールを中心とするサブスクリプションに適している

多くのサブスクリプションルールは、ドメインのサフィックス、キーワード、ルールセットを中心に構成されています。Fake-IPを使うと、接続がルールエンジンに入る際もドメイン名を保持でき、同じCDNアドレスで複数のサービスが提供されている場合の誤判定を減らせます。ブラウザー、デスクトップアプリ、モバイルアプリを混在して使う機器では、宛先IPだけに頼るより予測しやすい動作になることが多いでしょう。

TUNでの引き受けに適したデスクトップ環境

システムプロキシを読み取らないアプリや、TCPとUDPを同時に使うプログラムがあります。TUNモードはより幅広いトラフィックを引き受け、Fake-IPはDNS検索と後続の接続をコア内で関連付けるのに役立ちます。両者を組み合わせる場合は、「検索が内蔵DNSに入っているか」と「接続がTUNを通っているか」を別々に確認してください。TUNが起動しているだけでDNS経路も正しいと判断してはいけません。

LANゲートウェイではより慎重な設定が必要

Clashやmihomoをルーター、透過ゲートウェイ、ホームサーバーに導入すると、クライアント機器がゲートウェイをDNSとして使う場合もあれば、ISPのDNS、ルーターから配布されたIPv6 DNS、アプリ内蔵DoHを使い続ける場合もあります。ゲートウェイがLAN全体にFake-IPを返すなら、マッピングされた接続が同じコアへ戻ることを保証しなければなりません。そうでなければ、クライアントはマッピングアドレスを別のルーターへ直接送ろうとし、最終的に接続タイムアウトになります。

LAN内のデバイス検出、プリンター、NAS、スマートホーム、メディアキャストでは、.local、単一ラベルのホスト名、mDNS、LLMNR、メーカー独自のドメイン名に依存することがあります。これらの名前は、必ずしもパブリックDNSで処理すべきものではありません。ゲートウェイ構成では通常、ローカルリゾルバーを保持し、内部ドメインに実アドレスの解決または専用の上流DNSを設定します。

ゲームとリアルタイム通信は症状から判断する

ゲームランチャーがドメイン名でリソースをダウンロードしていても、実際の対戦中はUDP、固定IP、地域別のディスパッチサービスで通信することがあります。Fake-IPはランチャーのWebインターフェースでは正常に動作しても、遅延測定、サーバー一覧、アンチチートコンポーネントによるアドレス判定に影響する可能性があります。問題が起きても、DNS機能をすべて無効にするのではなく、まずログで失敗したドメインを確認し、実アドレスを必要とするドメインだけをフィルターに追加してください。

Fake-IP除外設定の設計方法

fake-ip-filterの目的は、特定のドメインをマッピングから除外し、アプリへ実際のIPを直接返すことです。除外範囲が広いほど、ドメインルールに利用できる接続は少なくなります。そのため、除外リストは出所の分からない長大な一覧をコピーするのではなく、具体的な互換性要件に沿って作成してください。

LAN内ドメインとローカルドメイン

*.lan、*.local、家庭内で使う独自サフィックスは、優先的に確認する価値があります。NASがstorage.home.arpaを使っているなら、ローカルDNSと実際のサフィックスに合わせてルールを設定します。ドメインを除外するだけで、その検索に応答できるローカルリゾルバーがなければ、正しいアドレスは取得できません。

時刻同期とネットワーク接続性の確認

システムサービスの中には、特定のドメインからNTPサーバーを探したり、ネットワークが利用可能か確認したり、ログイン認証ポータルが必要か判定したりするものがあります。こうしたプログラムは実アドレスを必要とし、DNS応答とHTTP応答を比較することさえあります。ブラウザーは正常に使えるのに機器が頻繁に「ネットワークに接続できません」と表示する場合は、システムの接続性確認ドメインと時刻同期ドメインからログを確認してください。

デバイス検出、音声通信、ゲームサービス

LANブロードキャストに依存する機器では、ローカル名をFake-IPへマッピングすべきでないことが一般的です。ゲームや音声アプリでは、ログイン、更新、マッチング、リアルタイム通信のドメインを分けて考え、メーカーのドメイン全体を広すぎるワイルドカードで除外しないようにします。除外範囲が広すぎると、ダウンロード用ドメインが本来のプロキシルールを失い、実IPルールやフォールバックルールだけで処理される可能性があります。

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.home.arpa"
    - "localhost"
    - "time.windows.com"
    - "time.apple.com"

ワイルドカード、ルールセット、追加の一致構文への対応は、コアのバージョンによって異なる場合があります。最も安全なのは、まず完全なドメイン名を明示して検証し、ログを見ながら必要なサブドメイン範囲へ広げる方法です。設定を読み込んだ後は、システムDNSキャッシュを消去し、アプリの既存の長時間接続を閉じてから再検索してください。古いキャッシュによって変更結果が隠れるのを防げます。

よくある障害と切り分けの順序

検索結果が実IPのままになる

まず、クライアントに表示される動作モードと、実際のコア設定がenhanced-mode: fake-ipになっているか確認します。次に、ドメインがフィルター項目に一致していないかを確認してください。その後、テストツールがどのDNSサーバーを使っているかを確認します。ブラウザーのセキュアDNS、システムDoH、VPNソフト、LANのDHCPで配布された別のDNSによって、検索がClashを迂回することがあります。

名前解決はできるが接続がタイムアウトする

マッピングアドレスが表示されるなら、DNS段階はコアに入っている可能性がありますが、後続の接続まで引き受けられているとは限りません。システムプロキシモードでは、プロキシ設定に従わないアプリが198.18.x.xへ直接アクセスすることがあります。TUNモードでは、仮想ネットワークインターフェース、ルーティングテーブル、ファイアウォール権限、DNSハイジャック設定を確認してください。ゲートウェイに導入している場合は、Fake-IPアドレスプール宛てのトラフィックが正しくゲートウェイのコアへ戻ることも確認します。

ルールがドメイン名で一致しない

ログに表示される対象の種類を確認してください。ログが実IPしか示さない場合、検索が内蔵DNSを迂回している、アプリが固定IPへ直接接続している、またはドメインがFake-IPフィルターに追加されている可能性があります。ログにドメイン名が表示されるのにポリシーが正しくない場合は、ルールの順序を確認します。Clashは通常、上から下へ順に判定するため、広すぎるルールが前にあると接続を先に捕捉します。

LAN機器の名前でアクセスできない

まず、その名前がどの仕組みで解決されているか確認します。.localはmDNSに関係することが多く、通常のユニキャストDNSを通るとは限りません。独自のNASドメインは、ルーターのDNSが応答している場合があります。対応するドメインをLAN内アドレスを返せるリゾルバーへ渡し、必要に応じてFake-IPから除外してください。DIRECTルールを設定するだけでは、DNS応答が誤っている問題は直せません。ルール判定は名前解決の後に行われるためです。

設定を切り替えても結果が変わらない

DNSの結果は、OS、ブラウザー、アプリ、コアにキャッシュされている可能性があります。テスト時は、設定の再読み込み、システムDNSキャッシュの消去、アプリの完全終了と再起動を順番に行ってください。Webページを再読み込みするだけでは不十分です。ブラウザーが既存の接続を再利用する場合があるためです。クライアントが現在の設定を表示できるなら、サブスクリプションの更新や上書き処理によって手動変更が戻されていないか確認します。

推奨する最小チェックリスト

1. 現在実行中のコアとそのバージョンが、使用するDNSフィールドに対応していることを確認する。
2. 内蔵DNSが有効で、テスト検索が実際に対応する待ち受けアドレスへ送信されていることを確認する。
3. 複雑なDNSルーティングの影響を除くため、一時的に利用可能な上流DNSを1つだけ残す。
4. 対象ドメインがfake-ip-filterに一致していないか確認する。
5. マッピングアドレス宛ての接続が、システムプロキシまたはTUNに入ることを確認する。
6. ログでドメイン名、ルール名、最終ポリシー、接続エラーを照合する。
7. 最後に、ノードの接続性、UDP対応、リモートサービスの状態を確認する。

設定の結論：まず経路を完成させ、その後に除外を追加する

Fake-IPの要点は「特殊なIPを返すこと」ではなく、DNS検索と後続の接続を結び付けるマッピングの循環を完成させることです。検索がClashに入り、接続が再びClashに入り、マッピングテーブルがドメイン名を復元し、ルールがポリシーを選択する。この4段階が揃って初めて、ドメインルーティングの安定した基盤ができます。どこか1つでもコアを迂回すると、名前解決は正常なのに接続できない、または接続は成功するのに誤ったルールに一致するといった問題が起こります。

デスクトップ機器でmihomoとTUNを使う場合は、基本的なFake-IP設定から始め、ログを確認しながらLAN、時刻同期、ゲーム、デバイス検出のドメインを追加します。ルーターや透過ゲートウェイでは、DHCP、IPv6 DNS、アドレスプールのルーティング、クライアント側の暗号化DNSも確認が必要です。除外項目は少数かつ明確にし、それぞれを再現可能な互換性要件に対応させてください。そうすれば、サブスクリプション更新、コアのアップグレード、機器の移行後も設定を保守しやすくなります。