Clash Fake-IPモードの仕組みを徹底解説：Redir-Hostとの違いと適した利用シーン

Fake-IPは公网の接続先を偽装するのではなく、ドメイン情報を保持する仕組み

アプリがWebサイトへアクセスすると、通常はまずドメインに対応するIPアドレスを問い合わせ、その後にTCPまたはUDP接続を確立します。従来のDNSでは、たとえば example.com を公网のIPv4アドレスへ解決し、その実アドレスをアプリに返します。通信がプロキシコアに届く頃には、コアから見える宛先がIPだけになっていることも少なくありません。ルールがドメイン名、GEOSITE、ドメインサフィックスを条件にしている場合、コアはスニッフィングやDNSマッピング、追加の名前解決によってドメイン名を復元する必要があります。

Fake-IPが変えるのは、端末上で返されるDNS応答の部分です。mihomoはアプリからドメインの問い合わせを受けると、予約済みアドレスプールから合成アドレスを割り当てます。一般的な既定範囲は 198.18.0.1/16 で、「合成アドレス―元のドメイン名」の対応をコアのマッピングテーブルに保存します。アプリがこの合成アドレスへ接続すると、通信はTUN、透過プロキシ、または制御下のネットワークスタックを経由してコアへ戻ります。mihomoはテーブルを参照するだけで、元の宛先ドメインを特定できます。

アプリが www.example.com を問い合わせ
        ↓
mihomo DNSが 198.18.0.23 を返す
        ↓
アプリが 198.18.0.23:443 に接続
        ↓
mihomoがマッピングテーブルから www.example.com を取得
        ↓
ドメインルールに基づいてポリシーグループとノードを選択
        ↓
プロキシノード経由で実際の宛先へ接続

198.18.0.0/15 はネットワーク機器のベンチマークテスト用に予約されたアドレス帯であり、インターネット上のWebサイトが実際に使用する公网アドレスではありません。mihomoは通常、その一部である 198.18.0.1/16 をFake-IPプールとして使用します。合成アドレスはローカルのプロキシ経路でインデックスとして機能するだけで、通常のゲートウェイへ直接送信したり、コアを通さずにそのままルーティングしたりすることはできません。

Fake-IPがRedir-Hostより直接的に動作する理由

Redir-Hostモードでは、アプリに実際のDNS解決結果を返します。アプリは実IPを受け取って接続を開始し、コアは既存のDNSレコード、通信中のホスト名、スニッフィング結果などを使ってドメイン名を関連付けます。ネットワーク動作が一般的なシステムDNSに近く、LAN機器や一部のゲーム、実アドレスだけを受け付けるプログラムとの互換性を確保しやすいのが利点です。一方で、最初の問い合わせでは上流DNSの応答を待つ必要があり、キャッシュ、CDNの複数アドレス、同時接続によってドメインと接続の対応関係が複雑になることがあります。

Fake-IPはローカルのアドレスプールからすぐに応答できるため、公网での名前解決が完了してからアプリへ結果を渡す必要がありません。ここでいう「名前解決を1回省く」とは、アプリが接続を確立する前に実アドレスの解決を待たなくてよいという意味であり、通信経路全体でDNSが不要になるわけではありません。プロキシサーバーのドメインをローカルの名前解決ノードで解決する場合や、最終的な出力接続で宛先IPが必要な場合、mihomoは proxy-server-nameserver、nameserver、ポリシー設定に従って解決を行います。

比較項目	Fake-IP	Redir-Host
アプリに返すアドレス	`198.18.x.x` などの合成アドレス	上流DNSが返す実アドレス
最初のDNS応答	ローカルのマッピングプールから高速に生成	通常は上流の名前解決完了を待つ
ドメインルールの照合	Fake-IPマッピングを直接利用	DNSレコードやスニッフィングによる補完が必要
LANドメインとの互換性	フィルターリストを適切に設定する必要がある	通常の名前解決に近い動作
透過プロキシとの連携	合成アドレス帯をコアが確実に処理する必要がある	通信の宛先自体は実アドレス
代表的な用途	TUNによる全体的な通信の取り込み、ドメイン分割、初回問い合わせの待ち時間短縮	特殊なアプリ、LANサービス、デバッグ環境との互換性確保

1回のリクエストで実際に起きていること

アプリがシステムDNSへAまたはAAAA問い合わせを送り、一般的な宛先ポートはUDPまたはTCP 53 です。
システムDNSの通信はmihomoのDNSモジュールへ送られ、制御されないままルーターやISPのDNSへ転送されることはありません。
mihomoがドメインにFake-IPを割り当て、その対応情報をメモリキャッシュへ書き込みます。
アプリがそのアドレスへ接続します。例：198.18.0.23:443。
TUNルーティングまたは透過プロキシのルールが接続をmihomoへ戻します。
コアがドメイン名を復元し、DOMAIN-SUFFIX、ルールセット、プロセスルールなどの順に照合します。
DIRECTまたはプロキシポリシーを選択した後、コアが対応する実際の出力接続を実行します。

mihomo Fake-IPの基本設定と各フィールドの解説

コア設定では、YAMLの dns セクションでFake-IPを有効にできます。GUIクライアントに上書き機能がある場合は、通常「設定」→「構成」または「設定」→「パラメーター設定」からDNSまたはグローバル拡張設定を開きます。クライアントによってメニュー名はバージョンごとに異なるため、最終的にはmihomoへ渡される実際のYAMLを確認してください。

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-mode: blacklist
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "time.*.com"
    - "time.*.gov"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

基本フィールドの役割

enable：mihomo内蔵DNSモジュールを有効にします。enhanced-mode だけを記述してDNSモジュールが動作していない場合、アプリの問い合わせがシステムの上流DNSへ流れる可能性があります。
listen：DNSの待ち受けアドレスとポートです。例では 1053 を使用し、一般ユーザー権限で 53 を直接使用することを避けています。ルーターに導入する場合は、dnsmasqからこのポートへ問い合わせを転送する設定も必要です。
enhanced-mode: fake-ip：条件に一致するドメインへ合成アドレスを返します。redir-host に切り替えると、実際の名前解決結果を返します。
fake-ip-range：合成アドレスプールです。変更後はTUNルーティング、ファイアウォール、透過ルーターのポリシーも確認し、アドレス帯全体がmihomoへ入るようにします。
default-nameserver：通常は直接到達できるIPアドレスを指定します。DoHなどのDNSサーバー自身のドメインを解決し、名前解決の循環を防ぐために使われます。
nameserver：通常のドメイン解決に使う上流サーバーです。実際の問い合わせがプロキシを経由するかどうかは、DNSの追従ポリシーと出力設定にも左右されます。
proxy-server-nameserver：プロキシノードのサーバードメインを専用に処理します。ノードアドレスをドメインで指定する場合、通常の宛先解決とノード解決を分離できます。
fake-ip-filter-mode: blacklist：リスト内のドメインではFake-IPを使わず、実際の解決結果を返します。ホワイトリスト方式に変更するとリストの意味が逆になるため、設定を移行する際は必ず併せて確認してください。

fake-ip-filterで除外すべきドメイン

fake-ip-filter の目的は、よく使うWebサイトをすべて除外することではありません。実アドレスが必要な問い合わせだけを、実際の名前解決へ戻すためのものです。範囲が広すぎると、Fake-IPによるドメインの高速な関連付けという利点が失われます。逆に狭すぎると、LAN探索、時刻同期、ログイン確認、リアルタイム通信が直接使えない合成アドレスを受け取る可能性があります。

LANホストとローカルドメイン

NAS、プリンター、ルーターの管理画面、ホームオートメーション機器では、.lan、.local、または独自の内部サフィックスがよく使われます。機器が 192.168.1.20 を返す場合、アプリはその実際のLANアドレスへ直接接続する必要があることが多いです。対応するサフィックスをフィルターリストへ追加し、ローカルDNSサーバーがこれらの名前に応答できることも確認してください。

.local はmDNSと組み合わせて使われることも多く、mDNSはマルチキャストアドレスとUDP 5353 を使用します。通常のユニキャストDNSとは別物です。フィルターを追加するだけでは、セグメントをまたぐ探索問題が解決しない場合があります。VLAN、ゲストWi-Fi、透過ルーター環境では、マルチキャスト転送とファイアウォールの境界も確認してください。

STUN、ゲーム、リアルタイム通信

一部のゲーム、音声通話、WebRTCアプリは、STUNを使って公网側の出口やNATタイプを判定します。この種のアプリは、DNSの返却値をUDPの検査に直接使ったり、サーバーが返す候補アドレスを照合したりすることがあります。Fake-IPを有効にした後に、音声は接続できるのに聞こえない、ルーム参加後に切断される、NATタイプがオープンからストリクトへ変わるといった症状が出た場合は、すぐにDNS全体をRedir-Hostへ戻すのではなく、該当するSTUNドメインだけを対象にフィルターを設定してみてください。

ゲームの高速化も、単純に「Fake-IPを必ず無効にすべき」とは限りません。HTTPSログイン、コンテンツのダウンロード、ドメイン振り分けを中心とするゲームランチャーの多くはFake-IPで正常に動作します。重要なのは、ゲーム本体がUDPに依存しているか、サーバーアドレスを厳密に検証するか、関連通信がTUNに完全に取り込まれているかです。検証時は、ランチャーのログイン、リソース取得、マッチングサービス、リアルタイム対戦を分けてテストしてください。

ネットワーク検査、時刻同期、デバイスログイン

システムの接続検査用ドメインは、特定のステータスコードや固定アドレスに基づいて認証ページを開く必要があるか判定することがあります。
NTPはUDP 123 を使うことが多く、一部の機器は返されたアドレスを直接検証したり、システムプロキシを迂回したりします。
スマートテレビ、ゲーム機、IoT機器は実際のAレコードしか受け付けず、後続の通信をPC上のmihomoへ送らない場合があります。
企業内ドメインではスプリットDNSが使われることがあります。同じドメインでも社内ネットワークと公网では異なる結果が返るため、指定された内部DNSに処理させる必要があります。

フィルターは障害が確認されたドメインを1件ずつ追加し、理由を記録してください。保守しやすいリストには通常、ローカルドメイン、互換性問題が確認されたサービスドメイン、必要な検査用ドメインを含めます。出所不明のルールを何百件もコピーするのは避けましょう。

TUNモードでFake-IPが動作するかは、通信を完全に取り込めるかで決まる

Fake-IPが返すアドレスには公网ルーティング上の意味がないため、アプリの接続はmihomoへ入る必要があります。デスクトップクライアントでTUNを有効にすると、通常はコアが仮想NICを作成してルートを書き込みます。ルーターの透過プロキシでは、ポリシールーティング、nftables、iptablesに依存することがあります。DNS拡張モードだけを有効にして 198.18.0.0/16 を取り込まない場合、名前解決は速いのにWebページがタイムアウトすることがよくあります。

同時に確認すべき4つの経路

DNS問い合わせ経路：アプリの問い合わせが本当にmihomoへ届いているか確認します。ブラウザー内蔵のセキュアDNS、AndroidのプライベートDNS、LAN側で手動設定したDNSが経路を変えることがあります。
Fake-IPルート：198.18.0.0/16 がデフォルトゲートウェイではなく、TUNまたは透過プロキシの処理経路へ向いているか確認します。
ルール照合：接続から復元されたドメインが想定したルールに一致し、最終的なポリシーグループが利用可能なノードを選択しているか確認します。
実際の出力接続：ノードのドメイン、宛先ドメイン、IPv4・IPv6の経路が正しく解決され、到達できるか確認します。

システムでIPv6が有効なのに、設定でIPv4しか取り込んでいない場合、アプリがAAAAレコードを優先して別経路を使う可能性があります。テスト中は一時的に ipv6: false を設定して範囲を絞り、IPv4のFake-IP経路が正常になってからIPv6のルーティングとDNSポリシーを整えてください。長期運用では、安定したIPv6出口が利用できるかどうかに応じて判断し、オプションを無効にしてルーティング問題を隠さないことが重要です。

具体的なコマンドでFake-IPとルール一致を確認する

Webページが開くかどうかだけで設定を判断しないでください。まずmihomoのDNS待ち受けポートへ直接問い合わせ、続いてシステムのルーティングとコアのログを確認します。以下の例では、DNSがローカルの 1053 で待ち受け、混合プロキシポートは一般的な 7890 であると仮定します。

nslookup www.example.com 127.0.0.1
dig @127.0.0.1 -p 1053 www.example.com A
curl -x http://127.0.0.1:7890 https://www.example.com/

dig が 198.18.x.x を返す場合、そのドメインがFake-IP経路に入ったことを示します。実際の公网アドレスが返る場合は、ドメインが fake-ip-filter に一致していないか、現在の実行設定が redir-host になっていないか、問い合わせが設定済みの待ち受けポートへ正しく送られているかを確認してください。

ローカル問い合わせの応答時間は通常ミリ秒単位です。同じ端末・同じネットワークで10回連続して問い合わせ、初回応答を比較してみてください。たとえば、Fake-IPのローカル応答は2〜8ミリ秒、実際のDoHによる初回問い合わせは30〜150ミリ秒になることがあります。数値は端末性能、上流サーバーまでの距離、キャッシュの影響を受けるため、重要なのは同じ環境内で差を比較することであり、特定の遅延値を一般的な基準にしないことです。

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

症状	優先して確認する項目	対処の方向性
Fake-IPは返るが接続がタイムアウトする	Fake-IPアドレス帯のルーティング	TUN、ポリシールーティング、透過プロキシが通信を完全に取り込んでいるか確認する
すべての問い合わせが実アドレスを返す	実行中のDNSモード	設定の上書き、フィルタールール、実際の待ち受けポートを確認する
Webサイトは開くがLANのNASに接続できない	内部ドメインとローカルDNS	LANサフィックスをフィルターし、内部レコードを解決できるサーバーを指定する
ブラウザーは正常だがゲームのUDP通信に失敗する	TUNによるUDP取り込みとSTUN	UDP対応、ルーティング、必要なSTUNドメインのフィルターを確認する
設定変更後、ときどき以前の宛先へアクセスする	システムとアプリのDNSキャッシュ	キャッシュを削除し、関連アプリを再起動してから設定を再読み込みする
ノードのドメインを解決できない	`proxy-server-nameserver`	到達可能な上流DNSを用意し、まだ確立していないプロキシ経路への依存を避ける

Fake-IPが向くケース、まずRedir-Hostを使うケース

Fake-IPを優先的に検討したいケース

デスクトップでTUNを使って大半のアプリを取り込み、ドメインルールを安定して一致させたい。
サブスクリプションに多数のドメインルール、ルールセット、ドメイン別のポリシーグループが含まれている。
ローカル上流DNSへの初回問い合わせが明らかに遅く、アプリが実際の名前解決を待つ時間を短縮したい。
システムプロキシ設定に従わないアプリをプロキシ経由にしたい、かつTCPとUDPの両方をmihomoで管理している。
LAN、ゲーム、リアルタイム通信の状況に応じて、精度の高いフィルターリストを維持できる。

まずRedir-Hostを使うほうが安全なケース

端末はDNSだけをmihomoへ渡し、実際の接続はTUNや透過プロキシを経由していない。
企業内ネットワークでスプリットDNS、固定の実アドレス、内部セキュリティ機器に大きく依存している。
LANに古い機器が多数あり、アプリの挙動を確認できず、フィルタードメインを個別に管理できない。
UDP、ゲーム、デバイス探索の障害を調査中で、まず一般的なDNSに近い比較環境を作りたい。
既存のルーティングルールでは、198.18.0.0/16 を常にmihomoへ戻せる保証がない。

2つのモードはコアの新旧の違いではなく、DNSを取り込む方式の違いです。mihomoは旧Clash Metaコアを引き継いだ後も、DNS、ルールセット、TUN機能を拡張しています。ただし、モードの選択はネットワーク構成に従う必要があります。単体のデスクトップ、透過ルーター、メインルーター、コンテナ環境ではDNSの入口が異なるため、同じ設定をそのままコピーしても同じ結果になるとは限りません。

移行・調整時の実践的な手順

Redir-HostからFake-IPへ切り替えるときは、既存のプロキシルールとノードを残し、DNS拡張モードだけを変更するのがおすすめです。複数の変数を同時に変えないようにします。設定を読み込んだら、通常の公网ドメイン、LANドメイン、フィルター対象として既知のドメインの3つを確認します。公网ドメインは合成アドレスを返し、後者2つは設計どおり実アドレスを返すはずです。

現在正常に動作している設定をバックアップし、DNSの待ち受けポート、TUNの有効・無効、システムプロキシのポートを記録する。
enhanced-mode: fake-ip を有効にし、既定のアドレスプールを使うか、カスタム範囲を明確に設計する。
システムルートがFake-IPアドレス帯全体をカバーしていることを確認する。
まず *.lan、*.local など、明確なローカル用フィルター項目を追加する。
ブラウザー、メッセージング、ゲーム、NAS、ストリーミング端末を個別にテストし、1つのWebサイトだけで判断しない。
ログに基づいて必要最小限のフィルタールールを追加し、各ルールに対応する障害を記録する。
期限切れのフィルター項目を整理し、リストが肥大化してRedir-Hostに近い状態へ退行するのを防ぐ。

切り替え後に問題が多い場合、比較のためRedir-Hostへ戻すのは有効なエンジニアリング上の切り分け方法です。障害がFake-IPでのみ発生すると確認できたら、DNSの入口、アドレスプールのルート、フィルターリスト、UDPの取り込みを確認します。サブスクリプション、ノード、設定全体を何度も交換するより、経路を層ごとに調べるほうが本当の原因を見つけやすくなります。