Fake-IPモードの仕組みを解説：DNS偽アドレスとLAN機器の互換性

1. Fake-IPの役割：アドレスを割り当てて接続先ドメインを保持する

Fake-IPは、Clash系コアが備えるDNS動作モードの一つです。アプリからIPv4アドレスの問い合わせがあると、コアは指定されたアドレスプールからアドレスを割り当て、「ドメイン名と偽アドレス」の対応関係を記録します。このアドレスは、ローカル環境や管理対象ネットワーク内で通信を中継するためのもので、WebサーバーのグローバルIPアドレスではありません。

一般的な設定では、アドレスプールに 198.18.0.1/16 を指定します。これはベンチマーク用に予約された 198.18.0.0/15 の範囲内です。192.168.0.0/16 などのプライベートLANアドレスとは異なり、そのままインターネットに送信するものでもありません。このようなDNS応答が返っても、それだけで名前解決の異常とは判断できません。

接続処理の流れ

アプリが example.com を問い合わせ、そのクエリがコアのDNSサービスに届きます。
コアがアドレスプールから一つ割り当て、対応関係を記録します。たとえば、198.18.0.2 が割り当てられる場合がありますが、実際のアドレスは固定ではありません。
アプリがこの偽アドレスへ接続すると、TUNなどの透過的な中継経路を通じて、通信が同じコアに戻ります。
コアは対応表から接続先ドメインを特定し、ルールに応じて直接接続またはプロキシ経由を選びます。
直接接続では通常、実際のIPアドレスを別途解決する必要があります。プロキシ経由でドメイン名をリモート側に渡して処理できるかは、プロトコルと設定によって異なります。

重要なのは、DNS問い合わせから後続の接続までが一つの経路としてつながっていることです。端末にFake-IPを返すだけで、そのアドレス宛ての通信が対応するコアに戻らなければ、「DNS応答はあるのにWebページが開かない」という状態になります。DNSの待ち受けポートを開いただけでは、この経路はできません。

速度向上の範囲

Fake-IPは、アプリが実際のDNS応答を待つ時間を短縮し、コアが元のドメイン名に基づいてルールを適用しやすくします。ただし、ネットワークの物理的な遅延を減らすものではなく、すべてのWebサイトが速くなるわけでもありません。直接接続時の名前解決、プロキシのハンドシェイク、TLS接続、サーバーの応答が主な待ち時間になる場合もあります。偽アドレスの割り当てが速いことと、ページの読み込みが速いことは同じではありません。

2. Fake-IPとredir-hostの違い：応答内容と通信を中継する条件

比較項目	Fake-IP	redir-host
DNS応答	条件に合う問い合わせには、アドレスプールから割り当てたアドレスを返す	上流DNSが解決した実際のアドレスを返す
ドメイン名の特定	偽アドレスとの対応関係からドメイン名を復元する	DNSレコードとの対応付けなどでドメイン名を特定する。共有IPなどの制約がある
接続前の待ち時間	実際の接続先IPを取得する前に偽アドレスを割り当てられる	通常は実際のIPアドレスを先に解決する必要がある
ネットワーク要件	偽アドレス宛ての通信が対応するコアに戻る必要がある	実際のIPアドレスは通常どおりルーティングできるが、通信の振り分けには中継設定とルールが必要
互換性で確認する点	アドレスの検証、複数端末間の接続、古い対応情報のキャッシュ	上流DNSの応答、ドメイン名の特定、DNSの経路

モードは実際の通信中継方法に合わせて選びます。デスクトップ端末でTUNを有効にし、DNS問い合わせも同じコアで処理する場合は、Fake-IPの通信経路が明確です。一方、プリンター、テレビ、ゲーム機はネットワーク上の動作が複雑です。DNSだけを変更し、透過プロキシのルーティングを設定していない場合、デスクトップ向けの設定をそのまま適用することはできません。

システムプロキシは別の経路です。HTTPプロキシのリクエストにはドメイン名が直接含まれることがあり、ローカルのDNS応答を使わない場合があります。ブラウザーでWebサイトを開けても、システムDNSやTUNが正常に動作しているとは限りません。同様に、特定の診断コマンドが失敗しても、HTTPプロキシが機能していないとは限りません。

3. 最小限のDNS設定とfake-ip-filterの記述方法

以下はDNS設定の一部であり、プロキシノード、プロキシグループ、ルールを含む完全な設定ではありません。例では、システムで一般的な 53 番ポートを避け、ローカルの 1053 番ポートを使用します。TUNによるDNSの横取りやシステムDNSの転送は別途設定が必要です。OSの通常のDNSアドレス欄には、一般にカスタムポートを指定できません。

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:
    - '+.lan'
    - '+.local'
    - '+.home.arpa'
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

各項目の意味と適用範囲

enable：コアのDNSサービスを有効にします。クライアントの画面に個別のDNS上書き設定がある場合もあるため、最終的に適用される設定を確認してください。
listen：ここではローカルからの問い合わせだけを受け付け、LANにはDNSサービスを公開しません。
ipv6: false：このDNSモジュールでAAAA問い合わせを処理するかどうかを指定します。OSのIPv6を無効にする設定ではなく、他のリゾルバーがIPv6アドレスを返さないことを保証するものでもありません。
enhanced-mode：DNSの拡張モードを指定します。この例では fake-ip を選択しています。
fake-ip-filter：一般的なデフォルトのブラックリスト方式では、該当するドメインに偽アドレスを割り当てず、実際のDNS応答を取得します。
nameserver：この例では上流DNSを二つ指定しています。リストの順序は「日本国内を優先し、海外を予備にする」といった振り分け設定ではありません。実際の動作はコアの実装や他のDNS項目にも左右されます。

+.home.arpa は、そのドメインとサブドメインに一致します。home.arpa は家庭内ネットワーク用のドメイン空間です。.local はmDNSに使われることが多く、問い合わせの一部はUDP 5353 番ポートを使ってマルチキャストされるため、ここで設定した通常のDNSリスナーは経由しません。フィルターリストに追加しても、mDNSの転送やデバイス検出の代わりにはなりません。

mihomoでは、fake-ip-filter-mode など、より細かいフィルターモードを指定できます。設定をコピーする前に、使用中のコアが対応しているか確認してください。ホワイトリスト方式ではフィルターリストの意味が変わるため、各項目を引き続き「除外」と解釈することはできません。Clash本体や各派生版、リリースによって、対応する設定項目は異なります。

4. LAN機器の互換性：名前解決・ルーティング・デバイス検出を切り分ける

NASのドメイン名が偽アドレスになる

たとえば、NASの実際のアドレスが 192.168.1.20、家庭内ドメインが nas.home.arpa だとします。問い合わせに対して 198.18 で始まるアドレスが返る場合は、まずそのドメインがフィルターに一致しているかを確認し、次に家庭内DNSで名前解決されているかを確認してください。プライベートアドレスを安定して取得するには、この二つの確認が必要です。

mihomoでは、nameserver-policy を使って家庭内ドメインの問い合わせ先を指定できます。以下の例では、ルーターのDNSが 192.168.1.1 であり、コアを実行する端末からアクセスできるものとします。設定は同じ dns オブジェクトに統合してください。トップレベルに二つ目の dns キーを作らないでください。

dns:
  nameserver-policy:
    '+.home.arpa': '192.168.1.1'

この設定例には前述のフィルターリストが含まれていないため、統合する際は fake-ip-filter を残してください。また、ルーターが同じ問い合わせをClashへ再転送していないかも確認してください。DNS転送ループが発生するおそれがあります。

プリンター・テレビ・キャスト機器が見つからない

デバイスの検出には、通常のDNSだけでなくmDNS、SSDP、ブロードキャストが使われる場合があります。mDNSでは 224.0.0.251:5353、SSDPでは 239.255.255.250:1900 がよく使われます。端末がゲスト用Wi-Fiや別のVLANに接続している場合、または無線クライアント間の通信が隔離されている場合は、名前解決が正常でも機器を検出できないことがあります。

まず、機器の実際のプライベートIPアドレスで管理画面を開き、基本的な接続を確認します。
次に機器のドメイン名を問い合わせ、想定どおりのプライベートアドレスが返るか確認します。
自動検出だけが失敗する場合は、マルチキャスト、ブロードキャスト、ネットワークセグメント間の分離を確認します。DNSフィルターの対象をむやみに増やさないでください。

スマートフォンに偽アドレスが返るが、接続先が別のゲートウェイになる

偽アドレスとの対応情報は、個々のコアインスタンスに紐づきます。スマートフォンがゲートウェイAにDNSを問い合わせ、ゲートウェイB経由で接続すると、通常BにはAが保持する対応情報がありません。Aの再起動後にスマートフォンが古いキャッシュを使い続けた場合も、同様の問題が起きることがあります。家庭内ネットワークでは、DNSと透過プロキシの経路を統一してください。PC上のFake-IP DNSを、独立したパブリックDNSのように全端末へ配布することはできません。

5. トラブル対処：DNS応答から実際の通信経路を確認する

手順1：コアのDNSに直接問い合わせる

LinuxまたはmacOSに dig がインストールされていれば、この例のローカルポートに直接問い合わせできます。以下は確認用のコマンドで、特定の出力を前提としていません。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 nas.home.arpa A

最初のコマンドでは、通常のFake-IP割り当て経路ならアドレスプール内のアドレスが返ります。次のコマンドでは、フィルターと家庭内DNSの設定が正しければ、実際の家庭内レコードが返ります。タイムアウトする場合は、まずDNSの待ち受け状態とプロセスを確認してください。NXDOMAIN が返る場合は、レコードの有無や問い合わせ先のリゾルバーを確認します。

手順2：システムが実際に使うリゾルバーを確認する

Windowsでは ipconfig /all でネットワークアダプターのDNSアドレスを確認し、nslookup example.com で通常の問い合わせ経路を調べられます。ブラウザーのセキュアDNS、アプリ内蔵のDoH、VPN、他の仮想ネットワークアダプターによって経路が変わることがあります。コマンドラインとブラウザーで異なるリゾルバーを使っていれば、結果が異なるのは珍しくありません。

ipconfig /all
nslookup example.com
ipconfig /flushdns

ipconfig /flushdns で消去されるのはWindows DNSクライアントのキャッシュだけです。ブラウザーやアプリ、コアの対応情報のキャッシュは消去されません。モードの変更後やコアの再起動後は、古い接続を保持しているアプリも再起動してから、同じ問い合わせを再度実行してください。ページを再読み込みしただけで、設定が反映されていないと判断しないでください。

手順3：ルールの一致状況とプライベートネットワークを確認する

クライアントの接続一覧やログで、接続先のドメイン名とアドレス、適用されたルール、通信の出口を確認します。家庭内ネットワークを直接接続にする場合は、以下のルール例を参考にし、広範囲なプロキシルールや最後の MATCH より前に配置してください。

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve

これはルールセット全体ではありません。既存の rules リストに統合してください。no-resolve は、そのIPルールとの照合のために追加のドメイン名解決を行わないという意味です。すでに接続先IPがある場合は、引き続き照合対象になります。コアがドメイン名を復元できている接続は、先にあるドメインルールで判定できるため、IPルールを予備として使う必要はありません。

Fake-IPのアドレスプール全体を直接接続ルールに追加し、OSから直接アクセスさせようとしないでください。偽アドレスは、対応情報を保持するコアに渡す必要があります。実在するWebサイトのアドレスのようにルーティングすることはできません。

6. よくある質問とモード切り替えの目安

198.18で始まるアドレスにpingが通らない場合、Webサイトの障害ですか？

いいえ。そのアドレスは、現在のドメインに割り当てられた偽アドレスかもしれません。ICMPの処理経路はTCPやUDPのプロキシとは異なるため、pingの結果だけではWebサイトにアクセスできるか判断できません。DNS応答、接続ログ、実際のアプリの通信をあわせて確認してください。

fake-ip-filterでゲームやスマート機器のエラーをすべて解決できますか？

できません。fake-ip-filterが変更するのは、該当ドメインに割り当てるアドレスです。UDP転送、NATタイプ、アプリに埋め込まれたIPアドレス、証明書エラー、マルチキャストの遮断は、それぞれ別に調べる必要があります。アプリが実際のDNSアドレスを必要としていると確認できた場合に限り、対象ドメインをフィルターに追加してください。

Fake-IPを使うにはTUNも必須ですか？

必ずしも必要ではありません。TUNは一般的な通信中継方法ですが、ルーターの透過プロキシでも同様の処理が可能です。必要なのは、偽アドレス宛ての通信を、対応情報を保持するコアで処理することです。画面上の特定のスイッチを必ず有効にすることではありません。

redir-hostへの切り替えを検討するのはどんな場合ですか？

特定の機器がDNSアドレスを継続的に検証する場合、コアを経由しない他の機器にDNSの解決結果を渡す必要がある場合、またはDNSと接続経路を統一できない場合は、redir-hostを試すことができます。切り替えた後は関連するキャッシュを消去して接続を確立し直し、ドメインルールと実際のDNS解決経路も再確認してください。

安定した設定かどうかは、次の三点が一致しているかで判断できます。ドメイン名が想定したリゾルバーで処理されること、接続が正しいコアに届くこと、通信の出口がルールどおりであることです。まず一つのアプリと一つのドメインで確認してから、フィルターを増やしたりモードを変更したりしましょう。DNS、TUN、サブスクリプション全体を同時に変更するより、問題を特定しやすくなります。基本項目はプロトコルリファレンス、ネットワーク用語は用語集をご覧ください。