この記事が想定しているつまずき

フル機能のブラウザやクラウド系のアプリには問題がなく、「自宅 LAN のブラウザ管理 UI」「NAS のホスト名」「ネットワークプリンタのドライバだけ」が突然つながらなくなるとき、ひとつの原因として DNS の Fake-IP が絡んでいないか確認する価値があります。体感としては、アドレスバーへ 192.168.1.1 のように数値だけの IP を入れると応答があるのに、http://diskstation/ や printer.local のような 名前ベースのアクセスだけ落ちる ときに効きやすいパターンです。

逆に、「Fake-IP を切ると WAN 側の表示がガタつく」といった運用とのトレードオフも現実にあるため、すべてを止めるのではなく、LAN 側だけ例外を増やして局所復旧させるのが狙いになります。mihomo（Clash Meta）系でも、基本発想と YAML の置き場所はほぼ同じです。

なぜ Fake-IP と LAN が衝突しやすいのか

Fake-IP は、クエリへの応答としてまず「仮想アドレス帯」（多くは 198.18.0.1/16 に近い範囲）をローカルに返し、その後ろのフェーズで本来の名前とトラフィックをコア側で突き合わせるモデルです。外向きのコンテンツ配信とは相性が良い一方、アプリ側が名前解決の結果を自分で記憶し直してから通信する実装だったり、ポート番号だけでなく中間デバイス（プリンタ、NAS、アクセスポイント）が ブロードキャストやマルチキャスト、mDNS（.local） とセットで機能していたりすると、名前と経路が食い違って見えることがあります。

もうひとつのレールはルール評価側です。MATCH まで流す前に、宛先アドレスがすでに「Fake 側の値」となっているとき、広い許可規則（例：MATCH, 任意のグループ）に吸い込まれると経路だけが外向きになり、結果としてタイムアウトに見えることがあります。名前を直したあとも、いったんブラウザや OS がキャッシュした古い名前解決を握り続けていると再現検証だけがずれるので、復旧確認のときはウィンドウを閉じ直す、アプリ再起動、`ipconfig /flushdns`（Windows の例）なども合わせて試すとよいでしょう。

用語そっくりの整理

「Fake-IP モード」を司るのが主として dns ブロックの enhanced-mode です。また tun.auto-route やゲートウェイ級の構成では、クエリ経路ごとひっくり返りやすいので、問題のときはログレベルを一時的に上げ、「どこで名前が返ったか」を追える状態にすると切り分けが速くなります。

RFC1918 と自宅 LAN の線引き（数字の共通言語）

社内資料や検索クエリでも「RFC1918」と並ぶプライベート・アドレスとは、実運用では次の三つの帯として覚えると運びやすいです。

  • 10.0.0.0/8（広い）
  • 172.16.0.0/12（中くらい；172.16〜172.31 の範囲）
  • 192.168.0.0/16（家庭向け機器・ルータ標準）

NAS メーカーの初期設定ページや複合機のスキャナ連携ヘルプは、このいずれかの帯の例を挙げることがほとんどです。また社内 VLAN を跨いだ 10.x だけ別サブネットにある、ゲストWi-Fi と本番 LAN が異なるクラスにある、というケースも珍しくありません。自宅環境だけを切りたいときは 192.168.0.0/16 だけ広げれば足りますが、「同一ルーター配下だけでなく複数セグメント」へアクセスするときは、実際に使っている CIDR に合わせて狭め／広げるのが安全です。いきなり MATCH,DIRECT のような大雑把な特例は後で忘れられやすいので、許可リストは自分の環境へ合わせて最小限へ寄せていくのがコツになります。

第一段：fake-ip-filter で「名前」を実解決側へ逃がす

まず試すべき修正は、この例外リストへの追記です。ここへ載せたパターンは、Fake で包まれる代わりに 従来どおり名前解決経路へ戻されるイメージで捉えると読み進めやすくなります。具体的には、mDNS の *.local、ルータによっては自動登録される *.lan 系、自分で付けている短いホスト名（例：nas, diskstation）、およびメーカーが案内している「設定ページ用ドメイン」や「オンライン解説で使われる仮ホスト」を列挙します。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    # mDNS-ish names
    - "*.local"
    - "*.localhost"
    - "*.lan"
    # typical router / NAS helper hostnames used on LAN (add your real ones)
    - "nas"
    - "router"
    - "diskstation"
    # optional: captive portal helpers that should not be spoofed
    # - '+.msftconnecttest.com'

ワイルドカードの細部（先頭が +. か *. か）は、読み込んでいるコアの世代で解釈差がゼロではありません。そのため運用ファイルでは自分の環境でのヒット実験ログを一度残し、その記録に忠実な列挙に寄せていくほうが再現しやすいです。複数台の複合機をホスト名で使い分けているオフィスだと、このリストだけで百行になることもあるので、その場合はひとつのメモとして外部 YAML に切り出し、生成スクリプトから差し込むと保守が楽になります。

注意（クライアントと OS）

iOS はローカルネットワーク許可など OS 側の壁が別レーンにあります。Fake-IP 以前に許可対話がブロックされていないか、ルール修正と別に確認すると徒労を減らせます。詳しいチェックリストはiOS とローカルネットワーク周りのまとめにも触れているので参照できます。

第二段：rules 側へ RFC1918 の直結（IP-CIDR）を置く

fake-ip-filter だけで片付くときもありますが、アプリによっては名前ではなく事前にキャッシュしていた IP と突き合わせる順序があるため、その場合経路側を明示したほうが素直な直結になります。典型的にはリストのできるだけ上位（つまり先に評価される位置）へ、RFC1918 相当の広い直結規則を置きます。そのすぐ後に自分のサイト用の広い許可規則を続ける、という形です。

rules:
  # Private IPv4 LAN / office segments — keep order above broad proxy 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

  # (your domain rules …)

  - MATCH,FALLBACK_DEFAULT

no-resolve を付ける意図は、Fake-IP 生成の副産物ともいえる「名前→一時値」の再解釈サイクルを避け、評価を IP 側に固定させることが多いです。実際の自分のリストでは、より狭い自分専用の帯だけを並べ、その外側は広域ルールに任せる、という段階的な書き方が事故を減らします。GEOIP と併記している環境でも、評価は常にリストの上面から最初の一本で終わるという順序鉄則を忘れず、国内向け広域ルールの位置と「LAN 特例」の位置関係だけは毎回手で確認しましょう。

mihomo では RULE-SET や GEOSITE,private,DIRECT のような表現でも近い結果を組めますが、自分のリストと外部プロバイダの更新サイクルを切り離したいときは、上記のような短い明示 CIDR が読みやすいです。また「Fake-IP と DNS とルールの関係」を体系立てて押さえたい場合はFake-IP を含む YAML 解説記事とセットで読むと、一覧の順序決めにも迷いにくくなります。

復旧チェックリスト（順番におすすめ）

  1. GUI だけでなく、テキストで dns.fake-ip-filter と rules が保存されているパスへ同一内容が載っていることを確認します（自動マージ済み構成と編集ウィンドウの差分だけで敗けることがあります）。
  2. 対象ホストへの名前解決を、OS が参照している名前解決器から一度追います。どの値が返るかを見てから、アプリ側のタイムアウトと突き合わせます。
  3. ブラウザのシークレット／別ブラウザで管理 UI を試し、アドオンや企業証明書の影響を切り離します。
  4. プリンタ共有 PC を経由しない「生の」LAN ポートへ直接届くテストページを印刷して、ドライバ側とネットワーク側のどちらで止まっているかを分けます。
  5. ルールセットを更新したばかりの環境では、古いセットが読み込まれたままのプロセスだけが残っていることもあり、クライアントの再起動とコアログの両方で更新時刻が揃っているかを見ます。

ログを見られるコアほど復旧サイクルは短くなりますが、ログが読めなくても、上記の順序で「名前の例外」を足してから「宛先 IPv4 の特例」を足すだけで体感の八割ほどまで戻るケースがあります。残った二割が社内だけの名前空間だったり、mDNS と TCP の交互依存だったりするところまで来たら、その時点でネットワーク担当とアプリ両方へエスカレーションする判断材料にもなります。

関連：Windows と LAN で混線しがちな例

スマホをスマホ用サブネットだけプロキシしつつ LAN 側の共有フォルダは直結させる、といった混在構成では、環境によりシステムプロキシと例外リストの両方へ手が必要になることがあります。似た構成のときの思考のひとつの糸口はWindows と LAN でのプロキシ周りに関する別稿にもまとめてあります。本記事との違いは、こちらでは Fake-IP 特有の名前解決の逃がし方まで踏み込んでいる点になります。

まとめ

Fake-IP は外向きサービスとの相性改善に効くことが多い一方、「LAN でだけ名前と経路の見え方がズレる」というタイプの不具合を招きやすくもあります。対処も二段構成で捉えると失敗が減ります。まず DNS 側の fake-ip-filter で除外したいホストやサフィックスを足し、それでも経路側がぐちゃぐちゃなときは RFC1918 相当を IP-CIDR で明示的に直結させる。そしてリストの並び順を毎回落ち着いて見直すだけで、NAS・プリンタ・ルーターのローカル管理 UI の体感は大きく戻りやすいです。

コアのアップストリーム仕様そのものより、自分のリストを安全に増やしていくときの体感速度を優先したいときは、まず試せる検証順を頭に入れ、そのあとゆっくり全体設計へ戻るのが運用にも優しい順番です。mihomo や各 GUI では設定画面と生成 YAML の双方を往復することが多く、テキストの筋が読めるとトラブル時の復旧だけでなく変更レビューの効率にも直結します。ビルドの入手と更新だけは共通の動線として公式のダウンロードページへ寄せておくと、コアやクライアントの組み合わせがぶれません。セットアップ済み環境での微調整に集中したい方は→ 無料で Clash をダウンロードし、Fake-IP 例外の検証を始める