Fake-IP がローカル到達を壊しやすい理由

Clash／Mihomo（Clash Meta）系で enhanced-mode: fake-ip（または同等の UI 表記）を使うと、クライアントが問い合わせたドメインに対し、設定された fake-ip-range 内の仮想アドレスを返します。アプリケーションはその仮想 IP で接続を開始し、コア側が実ドメインへマッピングしてプロキシ処理します。これにより「アプリが勝手にシステム DNS を使う」問題を抑えやすい反面、ローカル専用の名前や ルータの管理 FQDN まで fake-ip の対象に含めると、本来は同一 LAN 内で完結すべき通信が、意図せずプロキシ経路や誤ったルールに乗ることがあります。

また 198.18.0.0/15 などよく使われる fake-ip レンジは、RFC のテスト用帯域と重なるため、ルールの並びと MATCH の行き先次第では、見た目の挙動が分かりにくくなります。ここは「fake-ip は万能」ではなく、プライベートとローカル名をどこで切るかをプロファイルに明示するのが安定です。TUN を併用する場合はスタックがさらに複雑になるため、TUN モードの整理 とセットで読むと層の混同が減ります。

ℹ 整理：「Fake-IP を切れば直る」ケースもありますが、運用では fake-ip の利点（アプリごとの DNS 取りこぼし軽減）を残したまま、ルールと DNS の例外でローカルだけ DIRECT に逃がす方が再現性が高いです。

症状の整理：IP 直打ちとホスト名

典型的には次のようなパターンです。ブラウザで http://192.168.1.1 のように IPv4 を直接指定しても応答がない、同じマシンから ping 192.168.x.x は通るのに HTTP だけ失敗する、NAS のホスト名（例：nas.local やメーカー既定のドメイン）が開けない、ネットワークプリンタのポートがタイムアウトする、などです。いずれも「外向きのノードは生きているのに、LAN だけおかしい」という切り分けになりやすく、ログでは DIRECT になっていない、あるいは期待したインターフェースから出ていない、という痕跡が残ります。

まずは Clash を一時停止したときに同じ URL が開けるかを確認してください。開けるなら、OS の物理経路より前に Clash のルール／DNS が介入している可能性が高いです。ログの読み方は 接続ログの記事 と併用し、DIRECT か PROXY か、どのポリシーに落ちたかを確認します。

バイパスルール：プライベート帯を DIRECT へ

実務では、ルールの上の方（具体的な例外ほど先）に、プライベート IPv4／IPv6 帯を DIRECT へ送る行を置きます。Mihomo／Meta 系では IP-CIDR や GEOIP、クライアントによっては GEOSITE の private 系セットも利用できます。ポイントは、サブスク由来の巨大ルールセットより先に、自宅 LAN とルータ管理に触れる帯を固定で逃がすことです。

例として、よく使われるプライベート帯をまとめて DIRECT にする最小例を示します（ご利用のコアのバージョンでキー名が異なる場合は読み替えてください）。ルールの全体設計は ルール分流の考え方 も参照してください。

rules: private bypass (example) 
rules:
  - IP-CIDR,127.0.0.0/8,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - IP-CIDR,169.254.0.0/16,DIRECT
  - IP-CIDR,fc00::/7,DIRECT
  - IP-CIDR,fe80::/10,DIRECT
  # ... subscription / GEOSITE rules ...
  - MATCH,PROXY

ルータの管理画面が 192.168.x.x ではなくキャリアグレードの別セグメントにある場合は、その CIDR を追加します。社内イントラの固定ドメインがあるなら DOMAIN-SUFFIX や DOMAIN-KEYWORD で DIRECT に寄せる行も検討してください。いずれも「許可されたネットワークでの運用」を前提とし、職場ポリシーに反しない範囲で調整します。

DNS と fake-ip の合わせ方

fake-ip を使い続けるなら、どのドメインを fake-ip に載せないか を DNS セクションで制御します。多くの構成では、nameserver-policy または同等の機構で、*.local やルータメーカーの管理ドメイン、社内サフィックスを システム DNS もしくは信頼できるローカル DNS に直接問い合わせさせ、それ以外は fake-ip へ、という二段構えにします。これにより「仮想 IP にマッピングされるべきでない名前」がコア側で一貫して扱われます。

fake-ip-range はデフォルトのままにせず、既存 VPN や企業ポータルと衝突しない帯を選ぶと安全です。IPv6 のみの環境では、期待する挙動が IPv4 前提の説明とズレることがあるため、切り分けのときは一度 IPv4 に寄せて試すのも有効です。DNS 全般は FAQ の DNS の項 もあわせて確認してください。

dns: nameserver-policy sketch (adapt keys to your core) 
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
  nameserver-policy:
    "geosite:private":
      - system
    "+.lan":
      - system
    "+.local":
      - system
⚠ 注意：上記はあくまで構造の例です。geosite:private やポリシー名は、利用中のコア・ルールセットのバージョンで利用可能な表記に合わせてください。取り込み後は必ず構文チェックと実接続テストを行ってください。

Sniffer（スニッフィング）でドメインを復元する

TLS や QUIC など暗号化された接続では、コアがパケットから意図したドメインを推定しにくく、ルールが IP ベースに落ちてしまうことがあります。Sniffer は、そのような流量からドメイン名を復元し、ドメイン系のルール（DOMAIN-SUFFIX など）へ正しくマッチさせるための機能です。Fake-IP と併用する構成では、「ローカルは DIRECT だが、一部のドメインだけ誤ってプロキシに乗る」といった細かいズレを、スニッファーでルール判定の精度を上げる方向に寄せられます。

ただしスニッファーは処理コストとプライバシー配慮の両面があり、常にすべてのプロトコルで最大限有効にする必要はありません。まずは問題のドメインがルール上どう見えているかをログで押さえ、必要なスニーフ対象だけを有効化するのがおすすめです。

TUN モードやシステムプロキシとの併用メモ

TUN をオンにすると、OS のルーティングテーブルと Clash のポリシーが強く結びつきます。プライベート帯を DIRECT にしても、除外ルート（exclude interface / bypass） の指定が競合すると、想定外のインターフェースから SYN が出ることがあります。クライアントに「ローカル／China／LAN バイパス」などの UI がある場合は、説明文が指す実体が rules なのかルーティングなのかを確認し、二重に矛盾しないようにします。

システムプロキシのみのモードでは、ブラウザ以外のアプリがプロキシを経由しない場合もあります。症状がアプリごとに違うときは、モードを一時的に切り替えて層を特定してください。

コピペ用：ルールと sniffer の断片

以下は 新規プロファイルにそのまま足すのではなく、既存の rules: の先頭付近や sniffer: ブロックにマージする前提の断片です。インデントとキー名は環境に合わせて調整してください。

sniffer: minimal example (merge into your config) 
sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443, 8443]
    HTTP:
      ports: [80, 8080-8880]
  skip-domain:
    - Mijia Cloud
    - '+.lan'
  skip-src-address:
    - 192.168.0.0/16
    - 10.0.0.0/8

skip-src-address にプライベート帯を入れると、その送信元からの接続ではスニッファーを走らせず、ローカル機器間の挙動を素直に保ちやすくなります。ドメイン側のスキップは、メーカー固定のクラウド名など、誤検知が出やすいものを列挙する用途です。

チェックリスト

  1. Clash 停止時に、同じ 192.168.x.x や NAS の URL が開けるか。
  2. rules 先頭付近にプライベート IPv4／IPv6 の DIRECT 行があるか。
  3. DNS で local／社内サフィックス／ルータ名が fake-ip 汚染されないか。
  4. ログで該当フローが DIRECT に落ちているか、意図したインターフェースか。
  5. TUN 利用時、除外ルートとルールの両方が矛盾していないか。
  6. 必要なら Sniffer を限定有効化し、ドメインルールへ正しく載るか確認したか。

まとめ

Fake-IP はアプリの DNS 取りこぼしを抑える強力なモードですが、プライベートとローカル名の扱いをプロファイルに書かないと、LAN やルータ管理だけが静かに壊れることがあります。対処の中心は、ルールでプライベート帯を DIRECT に固定すること、続いて DNS の例外、必要に応じて Sniffer でドメイン判定を補正することの三段です。TUN やシステムプロキシとの組み合わせは、同じ「直通すべき流量」でも経路が変わるため、設定をいじるたびにチェックリストへ戻ると迷走が減ります。

クライアントによって編集 UI とキー名は違っても、考え方は共通です。視覚的にプロファイルを触りやすい実装を選ぶと、試行錯誤の負担が下がります。

→ 手元の環境に合うクライアントでルールと DNS を安全に試したい方は、Clash を無料ダウンロードし、Fake-IP とローカルバイパスを同じ画面から管理できる構成から始めてみてください。