本文へスキップ
上級者向け 読了時間の目安：12分

Clash Fake-IPモードの仕組み｜redir-hostとの違いと使い分け

ClashのFake-IPが予約済みアドレスでドメインを対応付け、DNS応答を高速化する仕組みを解説。fake-ip-filterの役割や、LAN機器と競合した場合の対処法も紹介します。

Fake-IP：先に仮想アドレスを返し、接続時に実際の宛先を特定

Clashまたはmihomoの設定で enhanced-mode: fake-ip と指定すると、コアのDNSモジュールがドメインに合成アドレスを割り当てます。このアドレスはWebサーバーのグローバルIPではなく、ドメインとの対応関係をコアが参照するためのインデックスです。アプリがこのアドレスへ接続すると、その通信が再び同じコアに届き、ドメインが復元されてから処理されます。

一般的な設定では、198.18.0.1/16 を fake-ip-range に指定します。これはネットワーク性能測定用に予約されたアドレスブロック 198.18.0.0/15 に含まれ、通常のグローバルIPアドレスでも、192.168.0.0/16 のようなプライベートLANアドレスでもありません。DNSの応答にこのアドレスが含まれていても、ただちに名前解決の失敗とは判断できません。

接続が処理される流れ

  1. アプリが example.com を問い合わせ、リクエストがコアのDNSに届きます。
  2. コアがドメインと合成アドレスを対応付け、たとえば 198.18.0.10 をアプリに返します。この数値は例であり、実際の割り当ては固定されていません。
  3. アプリがそのアドレスへの接続を開始し、TUNなどの経路を通じて通信がコアに戻ります。
  4. コアが example.com を復元し、ルールに従って直接接続またはプロキシ接続を選択します。実際のIPアドレスが必要な場合は、該当するアウトバウンドとDNSの設定に基づいて名前解決します。

Fake-IPとredir-hostの主な違い

redir-host は通常、先に上流DNSへ問い合わせ、実際のIPアドレスをアプリに返します。コアはDNSレコードなどからドメインとの対応付けを試みますが、同じIPを複数のドメインが共有していたり、対応情報を取得できなかったりする場合があります。Fake-IPは専用のマッピングでドメイン情報を保持するため、ドメインベースのルール適用に向いています。その一方、通信経路全体が正しく機能している必要があります。

比較項目 Fake-IP redir-host
アプリに返されるDNSアドレス 通常はアドレスプールから割り当てられる合成アドレス。フィルター対象のドメインは例外です。 通常は上流DNSで名前解決した実際のアドレス。
DNS応答までの処理 フィルターに該当しない場合、通常は実際のAレコードを先に待つ必要がありません。 通常は実際の名前解決結果を待つか、キャッシュを利用します。
ドメインの識別 合成アドレスとの対応関係からドメインを復元できます。 DNSとの関連付け、リクエスト内のドメイン情報、スニッフィングなどに依存します。
互換性で確認する点 アプリが合成アドレスを受け入れるか、接続がコアに戻るか。 上流DNSの応答品質、実際のアドレスへの到達性、ドメイン情報の対応付けが維持されるか。

「DNSの往復を減らす」ことは「名前解決が不要」という意味ではない

Fake-IPが省くのは、一部のケースでアプリが実際のIPアドレスの解決を待つ前段階です。ルールでドメインに基づいてプロキシが選ばれ、アウトバウンドのプロトコルがドメインをリモート側へ渡せる場合、実際の宛先IPを取得するためのローカルDNS問い合わせを省けることがあります。ただし、直接接続では通常、実際のアドレスが必要です。IPベースのルールやフィルター対象のドメインなど、別の名前解決要件があれば上流DNSへの問い合わせが発生する場合もあります。

そのため、何ミリ秒短縮できるかを一律に示すことはできません。キャッシュのヒット率、上流DNSの応答速度、ノードの場所、接続の再利用などが結果に影響します。2つのモードを比較する場合は、同じネットワーク、同じノード、同じドメインを使い、DNSの応答時間とWebページの最初のバイトを受信するまでの時間をそれぞれ記録してください。1回の測定結果を一般化しないようにしましょう。

mihomoの設定：DNSの待ち受けとプロキシポートを区別する

以下は各項目を説明するためのYAML例で、該当フィールドに対応するmihomo設定を想定しています。ノード、プロキシグループ、ルールは含まれていないため、完全なサブスクリプションとしては使用できません。既存の設定に項目を追加する際は、元のアウトバウンド設定を維持してください。GUIクライアントではオーバーライド機能によって最終的な設定が生成されることがあるため、現在有効な設定を確認してください。

mixed-port: 7890
mode: rule

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:
    - "localhost"
    - "+.lan"
    - "+.local"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  • mixed-port: 7890：HTTPとSOCKSを兼ねるプロキシの接続口です。DNSポートではありません。実際のポート番号はクライアントの表示を確認してください。
  • listen: 127.0.0.1:1053：DNSをローカルホストだけで待ち受けます。個別の動作確認に便利です。Windowsのネットワークアダプターで使われるDNSポートは通常53番です。127.0.0.1 とだけ指定しても、1053番ポートへ自動的に接続されるわけではありません。
  • ipv6: false：このDNSモジュールがAAAA問い合わせを処理するかどうかを設定します。WindowsのIPv6プロトコルスタックを無効にする設定ではありません。
  • nameserver：上流のDNSリゾルバーを指定します。例では通常のDNSを使っており、暗号化DNSが有効になるわけではありません。また、どのネットワークからも到達できるとは限りません。

サブスクリプションの更新で、直接編集した設定が上書きされることがあります。クライアントに「オーバーライド」や設定のマージ機能がある場合は、DNS項目の変更にその機能を利用してください。保存後に設定を再読み込みし、YAMLの解析エラー、待ち受けの失敗、上流への問い合わせタイムアウトがログに出ていないか確認します。画面上のスイッチが有効でも、実際に反映された設定を確認する必要があります。

fake-ip-filter：実アドレスが必要なドメインだけを例外にする

一般的なフィルターの動作では、fake-ip-filter に該当するドメインにはFake-IPを割り当てず、実際のアドレスを名前解決します。mihomoでは fake-ip-filter-mode でマッチングの動作を変更することもできます。この項目を設定している場合は、使用中のバージョンのドキュメントと実際の値を確認し、デフォルトのブラックリスト方式を前提に判断しないでください。

対象のドメインを特定してからフィルターに追加する

  • LAN内の管理画面：たとえば nas.home.arpa のように、機器が実際に使用しているホスト名を確認し、その名前または必要なサフィックスを例外に追加します。
  • 社内サービス：社内DNSで内部ドメインを解決できるか確認します。必要に応じて nameserver-policy で社内のDNSリゾルバーを指定してください。
  • 実際の名前解決結果を必要とするアプリ：ログから失敗したドメインを特定し、個別に追加します。それ以外のドメインではFake-IPを引き続き使用できます。

+.lan は該当するサフィックスのドメインにマッチするもので、すべてのローカル機器を判別する汎用機能ではありません。.local はマルチキャストを使うmDNSでよく利用されます。+.local をフィルターに追加しても、通常の上流DNSがmDNSの転送役になるわけではありません。プリンターが見つからない場合は、アプリが使う検出方式、ファイアウォール、接続先のネットワークセグメントも確認してください。

フィルタールールは直接接続のルールとは異なります。DNSが合成アドレスを返すかどうかを決めるもので、接続先を DIRECT に指定する機能はありません。NASのドメインを直接接続したい場合は、別途そのドメインに対応するルールを設定してください。社内DNSでしか実際のアドレスを解決できない場合は、リゾルバーの選択も正しく設定する必要があります。フィルターをすべてのドメインに広げるとFake-IPの利点が薄れる一方で、根本的なルーティングの問題が解決するとは限りません。

TUN・システムプロキシ・暗号化DNSの組み合わせ

Fake-IPはDNSの動作モード、TUNは通信を取り込む方式であり、同じ設定ではありません。TUNモードは、合成アドレスへの接続をアプリから取り込むのに適しています。一方、システムプロキシの影響を受けるのは主にWindowsのプロキシ設定に従うアプリです。システムプロキシを有効にしても、すべてのアプリのDNS問い合わせや接続がコアを経由するわけではありません。

リクエスト経路に沿って4か所を確認する

  1. WindowsのDNS：Windows 11で「設定」→「ネットワークとインターネット」→現在の接続の「プロパティ」→「DNSサーバーの割り当て」を開き、使用中のリゾルバーを確認します。OSのバージョンによって画面上の表記は多少異なります。
  2. クライアントのTUN：仮想ネットワークアダプターが作成され、サービスが正常に動作していることと、ルートが使用中のFake-IPアドレスプールをカバーしていることを確認してください。サービス権限が必要なクライアントでは、対応するサービスを先にインストールします。
  3. DNSハイジャック：有効な設定で tun.dns-hijack を確認します。53番ポートへの一般的なハイジャックでは、アプリ内のDoHリクエストをすべて取り込めるわけではありません。
  4. ブラウザーのセキュアDNS：Microsoft Edgeで「設定」→「プライバシー、検索、サービス」→「セキュリティ」を開き、「セキュアDNSを使用する」関連の設定を確認します。組織の管理下にある端末では、ポリシーで制御されている場合があります。

ブラウザーが外部のDoHサービスへ直接問い合わせると、実際のIPアドレスが返され、コアによるFake-IPの割り当てを経由しないことがあります。Webサイトが開いても、その接続で想定したDNSの対応付けが使われているとは限りません。ドメインスニッフィングで情報を補える場合もありますが、すべてのプロトコルでドメインを復元できる保証はありません。原因を調べる際は、比較のため一時的にアプリ独自のセキュアDNSを無効にし、確認後にDNS経路を統一するか、独立した名前解決を維持するか判断してください。

Windowsでの確認：DNS問い合わせ・接続・ログを分けて調べる

まずコアのDNSが想定どおり応答するかを確認し、その後アプリの接続をテストします。上記の1053番ポートで待ち受ける例では、PowerShellまたはコマンドプロンプトで nslookup を起動し、以下のコマンドを順番に入力します。対話モードで指定するポートは今回のテストにのみ適用され、WindowsのネットワークアダプターのDNS設定は変更されません。

nslookup
server 127.0.0.1
set port=1053
set type=A
example.com
exit

フィルターに該当せず、設定が正しく読み込まれていれば、応答は設定したFake-IPアドレスプールの範囲内になるはずです。特定の末尾の数値が返されることを期待しないでください。タイムアウトする場合は、DNSが有効か、待ち受けアドレスが一致しているか、コアのログに問題がないかを先に確認します。実際のIPアドレスが返る場合は、フィルタールールと有効な enhanced-mode を確認してください。

モード切り替え後に古い状態をクリアする

ipconfig /flushdns

このコマンドでクリアされるのはWindows DNSクライアントのキャッシュです。ブラウザーのキャッシュ、アプリの接続プール、コアのマッピングすべてが消えるわけではありません。Fake-IPとredir-hostを切り替えた後は、影響を受けるアプリの既存接続も閉じ、必要に応じてアプリを再起動してください。設定の再読み込みでマッピングが無効になった後も、アプリが古い合成アドレスを保持していると、一時的に接続できないことがあります。

続いてクライアントの「接続」画面で、対象ドメイン、適用ルール、プロキシグループ、アウトバウンドノードを確認します。DNSが合成アドレスを返しているのに接続一覧に該当記録がない場合は、通信がコアに届いているかを重点的に確認してください。接続記録があるのに失敗する場合は、実際の名前解決、ノードへの接続、アウトバウンドのエラーを調べます。ping の結果だけでWebサイトへのプロキシ接続を判断しないでください。ICMPとブラウザーのTCP・UDPリクエストでは、確認する経路が異なります。

LANとの競合とモードの選び方

VPN、検証環境、社内ネットワークなどが 198.18.0.0/15 内のアドレスをすでに使用している場合、Fake-IPのルーティングが実際の宛先と競合することがあります。まず route print を実行し、宛先ネットワーク、インターフェイス、メトリックを確認したうえで、VPNの設定からアドレスの用途を調べてください。予約済みアドレスだからといって、システムルートをすぐに削除しないでください。

症状 優先して確認すること
インターネット上のサイトは開くが、NASのドメインに接続できない NASドメインの実際の名前解決に使うDNS、フィルターの例外、直接接続ルールを確認します。
合成アドレスが返るが、すべての接続に失敗する TUNのルート、アプリによる迂回、コアのマッピングが有効かを確認します。
社内VPNの接続後、一部のアドレスに到達できない アドレスプールとVPNルートの重複を確認し、ネットワーク管理者の指示に従って調整します。
特定のアプリだけが合成アドレスを拒否する まず必要最小限の範囲でフィルター例外を追加し、その後redir-hostを検討します。

fake-ip-range を変更する場合は、新しいアドレス範囲が実ネットワークと競合しないことを確認し、通信を取り込むルートと除外ルールも合わせて更新してください。現在使われている家庭内LANのセグメントを安易に指定しないでください。社内VPNと仮想ネットワークアダプターのルールを両立できない場合は、互換性を比較するためにredir-hostへ切り替える方法もあります。ただし、ドメインルール、名前解決の品質、社内サービスへの接続を引き続き検証してください。

ドメインベースのルールを主に使い、DNSと接続を問題なく取り込めるWindows環境では、まずFake-IPを試すとよいでしょう。実際のDNS応答を維持する必要がある環境、特殊なLAN内検出方式を使う環境、社内ネットワークのポリシーに制約される環境では、まずドメイン単位で例外を設定します。それでも要件を満たせない場合は、redir-hostを検討してください。選択の基準は実際のリクエスト経路とアプリの互換性です。どちらか一方があらゆるネットワークで最適だと決めつけないでください。

Clashをダウンロード