上級設定 読了目安：12分

Clash Fake-IPモードとは：DNSが偽アドレスを返す仕組みと適用場面

Fake-IPはDNSに予約アドレスを先に返させ、接続時に実際の名前解決を行うことで、DNSの待ち時間と汚染の影響を抑えます。Redir-Hostとの違い、fake-ip-filterの設定、非対応のケースを解説します。

Fake-IPはエラーアドレスではなく、一時的な番号札

アプリがWebサイトへアクセスするときは、通常まずDNSにドメインに対応するIPアドレスを問い合わせ、その後でTCP、UDP、またはQUIC接続をそのIPへ開始します。従来の流れでは、DNSが実際のアドレスを返して初めて接続を続行できます。Fake-IPが変えるのはこの部分です。Clashまたはmihomoの内蔵DNSが予約アドレスプールからアドレスを割り当て、「ドメイン名—偽アドレス」の対応関係をメモリに保存します。

一般的なアドレスプールは 198.18.0.0/16 です。このIPv4アドレス範囲はRFC 2544でネットワーク機器のベンチマークテスト用に予約されており、インターネット上でルーティングされるべきものではありません。mihomoでは 198.18.0.1/16 と記述することが多く、約65534個のアドレスを割り当てられます。ブラウザーに 198.18.0.23 と表示されても、実際にインターネット上でそのホストを探しに行くわけではありません。

アプリが続けて 198.18.0.23:443 へ接続すると、Clashのコアはマッピングテーブルから元のドメイン名、たとえば www.example.com を取り出します。この時点でルールエンジンは DOMAIN、DOMAIN-SUFFIX、GEOSITE などのルールをドメイン名で直接照合し、プロキシ、ダイレクト接続、拒否のいずれかを選択できます。プロキシを使う場合はドメイン名をプロキシ経路に渡せます。ダイレクト接続の場合は、設定済みのDNSサーバーからコアが実アドレスを取得します。

1回のアクセスで起きていること

  1. ブラウザーが api.example.com のAレコードを問い合わせます。
  2. Clash DNSがFake-IPアドレスプールから 198.18.0.23 を返し、同時にマッピングを保存します。
  3. ブラウザーが 198.18.0.23:443 への接続を確立します。
  4. システムプロキシ、透過プロキシ、またはTUNモードがこの接続をコアへ渡します。
  5. コアがドメイン名を復元し、ルールグループに従って DIRECT、PROXY、その他のポリシーを選択します。
  6. 実IPが必要な場合は、コアまたはプロキシサーバーが名前解決を行い、対象サイトへ接続します。

「DNSの往復を1回省く」とは、アプリがパブリックDNSの権威ある応答を待たず、ローカルの応答を先に受け取って接続を開始できるという意味です。実際の名前解決が消えるわけではなく、後回しにされたり、まとめて処理されたり、プロキシ側で実行されたりします。最終的な遅延はDNSサーバー、プロキシノード、接続先ネットワークの影響を受けます。

Fake-IPとRedir-Hostの主な違い

Redir-Hostは、よく使われるもう一つの拡張DNSモードです。先に通常のDNS解決を完了し、実IPをアプリへ返します。アプリが実IPへ接続すると、コアはDNSマッピング、接続情報、ドメインのスニッフィングなどを組み合わせてドメイン名の復元を試みます。一般的なネットワーク動作に近いため、LAN機器やDNS結果を厳密に確認する一部のアプリとの相性が良好です。

Fake-IPはドメイン名を優先的に保持します。ルールを判定する時点で、コアは接続先が最初にアクセスしたドメイン名を把握しているため、宛先IPだけに頼る必要がなく、1つのIPで複数サイトを運用する構成の影響も受けにくくなります。CDNではこの違いが特に明確です。数百のドメインが同じエッジアドレスを共有することもあり、IPだけではサービスを正確に区別しにくいためです。

比較項目 Fake-IP Redir-Host
アプリに返すアドレス 通常は198.18.0.0/16内の予約アドレス DNS問い合わせで得られる実アドレス
ドメインルールの識別 マッピングから直接復元でき、通常は安定 DNSマッピングまたはスニッフィングによる補完が必要
最初のDNS応答 ローカルでアドレスをすばやく割り当て 上流DNSの応答を待つ
LANとの互換性 一部のドメインをフィルターリストへ追加する必要あり 通常はシステム本来の動作に近い
適した場面 TUN、透過プロキシ、ドメイン単位の細かな振り分け シンプルなシステムプロキシ、特殊な機器との互換性

どちらのモードが絶対に優れているということはありません。デスクトップ機器でTUNを使って通信を取り込み、ルールを主にドメイン名で管理する場合は、Fake-IPのほうが扱いやすいことが多いでしょう。ルーターの旁路構成、LAN探索、プリンター操作、古いアプリを多用する場合は、まずフィルタールールを試してください。それでも問題が残るなら、Redir-Hostへ切り替えて比較します。

mihomoでFake-IPを設定する方法

以下の例は、mihomo 1.19系でよく使われる設定構成に対応しています。GUIクライアントによっては項目が画面上で分かれている場合がありますが、最終的には対応するYAMLが生成されます。変更前に現在の設定をコピーしてください。サブスクリプション設定は更新時にローカル内容を上書きするため、クライアントのオーバーライド、Mixin、拡張スクリプト機能を優先して使いましょう。

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-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "localhost.ptlogin2.qq.com"
    - "+.pool.ntp.org"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.12.12.12/dns-query
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query

設定項目を理解する

  • enable: true：内蔵DNSを有効にします。enhanced-mode だけを記述してDNSを有効にしていない場合、期待した動作にはなりません。
  • listen: 127.0.0.1:1053：ローカルの1053番ポートだけで待ち受けます。一般ユーザーのプロセスが53番ポートを直接待ち受けるには権限が必要な場合があり、システムDNSサービスと競合することもあります。
  • ipv6: false：アプリへAAAAレコードを返しません。IPv6ネットワークが安定しており、ルールもIPv6に対応している場合は有効にできますが、ダイレクト接続とプロキシ経路を同時に確認してください。
  • enhanced-mode: fake-ip：Fake-IP拡張モードを選択します。redir-host と記述すると、DNSは実アドレスを返します。
  • fake-ip-range：IPv4アドレスプールを指定します。通常はデフォルト値を維持し、家庭内LANで使う 192.168.0.0/16 や 10.0.0.0/8 に変更しないでください。
  • fake-ip-filter-mode: blacklist：リスト内のドメインではFake-IPを使わず、実際の名前解決結果を返します。最も一般的な動作です。
  • nameserver：通常のドメイン解決を処理します。例ではDoHを使用しており、接続ポートは通常443です。
  • proxy-server-nameserver：プロキシノードのホスト名を専用に解決し、ノードアドレスの解決時に循環依存が起きるのを防ぎます。

Fake-IPが有効か確認する

macOSまたはLinuxでは、dig でローカルDNSのポートを指定できます。Windowsではカスタムポートに対応したDNSツールを使うか、一時的に待受ポートをシステムから問い合わせ可能な53番へ変更してテストします。以下のコマンドはシステム設定を変更しません。

dig @127.0.0.1 -p 1053 www.example.com A

# 期待される結果の例：
# www.example.com.  1  IN  A  198.18.0.2

パブリックDNSの実IPが返る場合は、実際に読み込まれている設定がまだ redir-host になっていないか確認し、次にそのドメインが fake-ip-filter に一致していないか確認します。問い合わせがタイムアウトする場合は、lsof -nP -iUDP:1053 または ss -lunp でポートが待ち受け状態か確認してください。GUIクライアントでは、サブスクリプション元ファイルだけでなく、現在実行中の設定も確認します。

mihomoで external-controller: 127.0.0.1:9090 を有効にすると、コントロールAPIからDNSを確認することもできます。コントロールAPIのシークレットを設定していない場合のリクエスト例は次のとおりです。

curl "http://127.0.0.1:9090/dns/query?name=www.example.com&type=A"

コントロールAPIに secret を設定している場合、リクエストには対応するBearer認証情報を付ける必要があります。9090番の制御ポートをインターネットへ直接公開してはいけません。家庭内LANで共有する場合もアクセス制限を設定してください。

fake-ip-filterの書き方

fake-ip-filter は、特定のドメインで偽アドレスの割り当てを回避し、実際のDNS結果を直接取得させるための設定です。対象になるのは通常「開けないサイト」ではなく、実アドレス、LANアドレス、特殊なDNSレコードに依存するサービスです。リストを広げすぎると、Fake-IPのドメインマッピングという利点が弱まります。

フィルターリストに追加しやすい種類

  • LAN名：*.lan、+.local、ルーター管理用ドメイン、NASのカスタムドメイン。
  • 時刻同期：一部のNTPクライアントは直接解決されたUDPの宛先だけを受け付けるため、+.pool.ntp.org をフィルターできます。
  • ネットワーク接続チェック：システムによっては、固定ドメインと応答内容でホテル、空港、学校ネットワークの認証ページを表示するか判断します。
  • 機器の検出とキャスト：プリンター、テレビ、スピーカー、キャスト機器は、mDNS、ユニキャストDNS、LANアドレスの連携に依存する場合があります。
  • DNSアドレスを明示的に検証するアプリ：一部のプログラムはDNS結果と実際の接続先アドレスを比較するため、予約アドレスによって異常が起きることがあります。
dns:
  enhanced-mode: fake-ip
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "router.asus.com"
    - "miwifi.com"
    - "+.pool.ntp.org"
    - "time.windows.com"
    - "time.apple.com"

*.lan は通常サブドメインの照合に使い、+.local はmihomoのドメイン照合構文でルートドメインとそのサブドメインをカバーできます。ワイルドカード表現への対応はコアのバージョンによって異なる場合があるため、旧Clash設定を移行する際は実行ログを確認してください。最も確実な切り分け方法は、まず完全なドメイン名を記述し、復旧を確認してから照合範囲を広げることです。

ホワイトリストモードは万能な最適化ではない

mihomoでは fake-ip-filter-mode を whitelist に設定できます。この場合は動作が反転し、リスト内のドメインだけがFake-IPを使い、それ以外は実アドレスを返します。Fake-IPを段階的に有効化したい特殊な環境には適していますが、ルールの動作が不統一になりやすいため、「偽アドレスを減らしたい」という理由だけで安易に有効化することはおすすめしません。

dns:
  enhanced-mode: fake-ip
  fake-ip-filter-mode: whitelist
  fake-ip-filter:
    - "+.example.com"
    - "+.example.net"

フィルターリストを調整するときは、一度に1～2項目だけ追加してください。設定を保存し、コアをリロードし、システムのDNSキャッシュを消去してから問題を再現します。macOSでは sudo dscacheutil -flushcache、Windowsでは ipconfig /flushdns を実行できます。ブラウザーが独自のDNSキャッシュを保持している場合もあるため、完全に終了してからテストすると確実です。

Fake-IPに向いている場面

TUNモードで端末全体の通信を取り込む

TUNは仮想ネットワークインターフェースを作成し、システムプロキシより広い範囲の通信をネットワーク層で受け取ります。コマンドラインツール、一部のゲームランチャー、システムプロキシを参照しないアプリもコアへ取り込めます。Fake-IPが返す予約アドレスをコアが受け止める必要があるため、TUN、透過プロキシ、ルーターのリダイレクトとの組み合わせが最も自然です。

Fake-IPだけを有効にし、システムプロキシ、TUN、透過転送を有効にしていない場合、アプリが 198.18.0.0/16 へ直接パケットを送り、接続がタイムアウトすることがあります。DNSは正常に見えても、実際には通信を取り込む経路が不足しています。切り分けではDNS問い合わせログと接続ログを同時に確認してください。

ルールを主にドメイン名で管理する

設定で DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOSITE、またはルールセットを多用する場合、Fake-IPは接続確立時までドメイン名のコンテキストを保持できます。CDNのIPだけを受け取ってからドメイン名を推測するより、ルールが一致した理由を把握しやすくなります。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

GEOIP,CN,DIRECT,no-resolve の no-resolve は、このIPルールに一致させるためだけに追加のDNS解決を行わないことを意味します。Fake-IP環境では不要な問い合わせを減らせますが、前に置いたドメインルールの順序も考慮してください。ルールは上から順に照合され、最初に一致した時点で停止します。

ローカルDNS汚染の影響を抑えたい

アプリはまずローカルのFake-IPを受け取るため、通信事業者のDNSが返す宛先アドレスに直接依存しません。実際の名前解決を暗号化DNSまたはプロキシ経路に任せることで、誤った応答や解決経路の漏えいを管理しやすくなります。ただし、Fake-IP単体がセキュリティ機能になるわけではありません。nameserver が不安定な平文DNSを指していたり、プロキシノードのドメイン解決設定に誤りがあったりすれば、問題は残ります。

Fake-IPに向かない、または注意が必要な場面

LAN機器や社内ネットワークのドメインが多い

社内DNSが git.company.test を 10.20.0.15 に解決し、家庭のNASがルーターから配布された検索ドメインに依存していることがあります。すべての問い合わせをパブリックDoHへ送ると、社内ドメインの解決に失敗します。Fake-IPの割り当てに成功しても、その先にある実サービスを見つけられません。

この場合は、すべてのドメインを無差別にフィルターリストへ入れるのではなく、nameserver-policy で社内ドメインのサフィックスに内部DNSを指定します。たとえば内部DNSが 10.20.0.53 にある場合は次のようにします。

dns:
  enhanced-mode: fake-ip
  nameserver:
    - https://223.5.5.5/dns-query
  nameserver-policy:
    "+.company.test":
      - 10.20.0.53
  fake-ip-filter:
    - "+.company.test"

旁路ルーターが予約アドレス帯を完全に回収していない

ルーターがクライアントへFake-IPを返した後は、198.18.0.0/16 宛ての通信がmihomoを実行している機器へ戻るようにする必要があります。ポリシールーティング、iptables、nftablesのルールでUDPを取りこぼすと、Webページは開くのにQUIC、音声通話、ゲーム接続だけが失敗することがあります。TCPとUDPの両方がTUNまたは透過プロキシ経路へ入っているか確認してください。

アプリが実際のDNS応答を必要とする

ネットワーク診断ツール、DNS管理ツール、一部のアンチチートや機器検出プログラムは、実際のA、AAAA、PTR、SRVレコードを必要とする場合があります。このようなプログラムのために全体をRedir-Hostへ切り替えるのは過剰です。まず明確なドメインをフィルターリストへ追加するか、そのプログラムのDNS問い合わせをClash経由から外してください。

よくあるトラブルと切り分けの順番

DNSは198.18アドレスを返すが、Webページが開かない

  1. 内蔵DNSだけでなく、システムプロキシまたはTUNが有効になっていることを確認します。
  2. 接続ログに対象ドメインが表示されるか確認します。ログがまったくない場合は、通信がコアへ入っていない可能性が高いです。
  3. 198.18.0.0/16 が別のVPN、仮想マシンソフト、社内ルーターに使用されていないか確認します。
  4. QUICを一時的に無効にし、TCP 443で比較テストして、UDPだけが取りこぼされていないか判断します。
  5. 対象ドメインを fake-ip-filter に追加します。すぐに復旧した場合は、引き続きアプリの互換性を確認してください。

LAN内のドメインだけ開けない

まず内部DNSへ直接問い合わせます。たとえば dig @192.168.1.1 nas.lan を実行します。192.168.1.20 が返れば、内部名前解決は正常です。次に、そのサフィックスへ nameserver-policy を設定し、フィルターリストにも追加します。プライベートアドレス帯のルールがプロキシのフォールバックルールより前にあることも確認してください。

rules:
  - 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
  - MATCH,PROXY

サブスクリプション更新後に設定が元へ戻る

サブスクリプションはリモート設定のスナップショットです。クライアントがサブスクリプションを更新すると、ローカルで直接編集したYAMLが上書きされることがあります。DNS関連の設定はクライアントのオーバーライド機能で管理してください。たとえば「設定」→「構成」→「グローバル拡張」、または対応するMixin画面を開きます。名称はクライアントのバージョンによって変わりますが、原則は同じです。サブスクリプションにはノードとルールを保存し、ローカル拡張には機器固有のDNS、TUN、待受ポートを保存します。

モードを切り替えても古い結果が表示される

DNSキャッシュはOS、ブラウザー、Clashコアの3層に残る可能性があります。まず設定をリロードするかコアを再起動し、次にシステムのDNSキャッシュを消去し、最後にブラウザーを完全終了します。Fake-IPレコードのTTLは短く設定されることが多いものの、確立済みの接続はDNSモードを切り替えただけでは再構築されません。

設定の結論：まず通信の取り込みを確保し、その後DNSを最適化する

Fake-IPの価値は特殊なアドレスを返すことではなく、ルール照合の段階までドメイン情報を安定して保持することにあります。TUNや透過プロキシでドメイン単位の振り分けを行いやすくし、実際の名前解決をより適切なネットワーク経路へ移すこともできます。198.18.x.x が表示されても、後続の接続が実際にClashコアへ入っているなら、DNS障害を意味するわけではありません。

実用的な設定は、デフォルトのアドレスプール、ブラックリスト方式のフィルター、信頼できる2つのDNS上流から始められます。LAN内ドメインは nameserver-policy に任せ、実アドレスが必要なドメインは fake-ip-filter に追加します。問題が起きたら「DNSが待ち受けているか—問い合わせが応答するか—通信が取り込まれているか—ルールが一致したか—実際の名前解決に成功したか」の順で確認すると、ノードを何度も切り替えるより早く原因を特定できます。

Clashクライアントをダウンロード 各プラットフォームのインストーラーを見る