こんなときに fake-ip-filter を疑う
典型例は次のようなものです。プロキシは普通に効いているのに、ゲートウェイの Web 設定（例：192.168.1.1）だけ真っ白、NAS のホスト名（nas.lan など）が解決しない、AirPrint や社内 Wiki の短い名前が不安定、*.local が突然使えなくなる。共通項は、OS やアプリが握っている名前解決の答えが、意図せず 198.18.0.0/15 付近の仮想 IPv4になっていることです。ここでいう「誤爆」とは、本来ローカルで完結すべき名前まで FakeIP の対象に入り、接続先 IP がLANではない状態を指します。
逆に、海外 CDN のドメインが遅い・切れるといった症状の主因が必ずしも fake-ip-filter とは限りません。ルール順・ノード品質・QUIC など別レイヤの問題と混ざりやすいので、まずはクライアントの接続ログで「そのホスト名に対して返っている IP が Fake レンジか」を確認すると判断が早いです。
仕組み：fake-ip-filter が変えるのは DNS 応答だけ
FakeIP モードでは、多くのクエリに対してコアが一時的な仮想アドレスを返し、実際の接続フェーズで目的ホストへ誘導します。一方 fake-ip-filter にマッチした名前（および環境によっては IP レンジ）については、通常の再帰 DNS を通じた実アドレスを返す流れになります。つまり「プロキシを直結に切り替える」キーではなく、名前解決のスタイルを局所だけ切り替えるキーです。誤解しやすいのは、rules で DIRECT を書いたのに効かない、という報告の多くが、実は先に返ってきた IP が Fake で、OS 側ソケットが別物を見ているパターンだという点です。
DNS 分流（どの上流へ問い合わせるか）を nameserver-policy などで細かく切る構成では、fake-ip-filter で「実 IP モードに降ろす名前」と、その名前をどの上流で解くかをセットで決める必要があります。社内 DNS だけが知っているゾーンを、意図せずパブリック DoH に投げないよう、方針を揃えてください。
隣接トピック：TUN で 53 番を拾う話は Clash Verge Rev の TUN ガイド とセットで読むと、DNS がコアに届かないケースを切り分けやすくなります。
切り分けの順番（短く三歩）
1症状ホスト名を一つ特定する
「LAN 全体が死んだ」ではなく、再現手順とホスト名を一組にしてください。ブラウザの開発者ツールや ping の出力、NAS クライアントのエラーダイアログからFQDNを抜き出します。mDNS の something.local なのか、ルーターが配っている *.lan なのかで、fake-ip-filter に書く文字列が変わります。
2その名前が Fake レンジに落ちているか確認する
Clash 側のログや、クライアント付属の DNS 表示があれば、当該名前に対する応答が 198.18.x.x 系かどうかを見ます。ここが Fake のままなら、フィルタに載っていないか、別のプロファイルが上書きしている可能性が高いです。
3fake-ip-filter を最小追加して再読み込みする
一度に二十行足すより、問題のサフィックス一行を足してリロードし、症状が消えるかを見た方がロールバックも簡単です。購読テンプレが毎回上書きする運用なら、ローカル専用の上書きファイルや GUI の「追記欄」に置くなど、マージ規則に合わせた置き場所を決めてください。
最小の dns ブロック例（教育用）
次の例は説明用の骨格です。利用中のコア版・購読 YAML と矛盾しないよう、既存の nameserver や fallback はそのまま残し、fake-ip-filter だけを参考にしてください。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
# LAN and local discovery names — adjust suffixes to your network
- "*.lan"
- "*.local"
- "*.home.arpa"
- stun.*.*
nameserver:
- tls://1.1.1.1
*.lan や *.local はコミュニティでよく使われる出発点です。自宅ではルーターが *.home を配っていることもあるため、実際に使っているサフィックスをルーターの DHCP/DNS 画面で確認し、リストを自分の環境用に置換してください。一部バージョンではワイルドカードや接頭辞演算子の解釈が細かく異なるため、反映後は必ずログで確認します。
プライベート IP 名と「IP そのもの」を除外する考え方
ブラウザで http://192.168.1.1 のようにリテラル IP を叩く場合、名前ではなくアドレス文字列として扱われます。環境によっては fake-ip-filter に RFC1918 相当の CIDR を列挙しておく例も見られますが、テンプレートによっては既にデフォルト相当が入っていることもあります。重複は害になりにくい一方、何を除外しているか分からない長大リストはデバッグを難しくするので、増やしすぎない方が運用では安全です。
NAS やプリンタが固定ホスト名と固定 IPの両方を併記している場合、ルールは IP-CIDR,192.168.0.0/16,DIRECT のように書けても、名前解決が先に Fake に滑ると挙動が噛み合いません。fake-ip-filter で名前を実レコード側へ戻し、rules 側の DIRECT と同じストーリーに揃える、という順序を意識してください。
「直結ドメイン」：グローバル名なのに実体は LAN という罠
DNS 分流の文脈で厄介なのが、パブリックに見える FQDN が、企業や ISP のスプリットホライズンで自宅 LAN の IPを返すケースです。このとき DOMAIN-SUFFIX,example.com,DIRECT を書いていても、FakeIP が先に勝ってしまうと期待とズレます。対策はシンプルで、その example.com ツリーを fake-ip-filter に入れ、社内リゾルバまたは意図した上流で実 IP を取りに行くようにします。
逆に、動画 CDN のように意図的に Fake を使いたいドメインまで広いサフィックスで除外すると、ルールマッチの安定性を損ねることがあります。「広く書くほど安全」とは限らず、必要最小限のサフィックスに留めるのがコツです。
Sniffer 併用時の読み替え
HTTPS の SNI からドメインを復元する Sniffer を有効にしていると、ログ上の見え方が変わり、DOMAIN ルールの命中タイミングの説明が難しくなります。FakeIP とセットで運用する場合の整理は Sniffer 向けの稿 も参照しつつ、本稿の範囲では「まず名前が実 IP に戻っているか」を優先して確認してください。
検証チェックリスト
- 再現手順を一行に書けるようにする（例：Safari で
router.lanを開く）。 - 変更前後で、当該名前の応答が Fake レンジから自宅レンジへ変わったかを見る。
rulesでDIRECTに落ちているか、意図したポリシーグループに落ちているかをログで確認する。- TUN 利用時は TUN と DNS ハイジャック が有効かを同じセッションで見直す。
- 社内 DNS を使うなら、そのサーバへ至る経路がプロキシで遮られていないかを別途確認する。
よくある落とし穴
テンプレート更新で消えた：購読生成物だけを編集していると、アップデートのたびに fake-ip-filter が戻ります。ローカル上書きの置き場所を決めておいてください。
二重定義で片方だけが効く：GUI と生 YAML の両方に dns があると、見た目は保存できているのに実際に動いているのは片方という事故が起きます。有効な一本の YAML を export して確認するのが確実です。
IPv6 だけ別物：IPv4 だけフィルタを整えても、AAAA 経路が別ルートを行くと症状が残ります。家庭用プロファイルでは ipv6: false にしている例もありますが、それ自体にトレードオフがあるため、環境に合わせて選んでください。
法令と規約：ネットワーク設定の変更は、居住地域の法律および契約・職場方針に従ってください。本稿は技術的一般論であり、特定サービスへの不適切なアクセスを助長する意図はありません。
上流実装と入手先
Mihomo（Clash Meta）のキー解釈の差は、リリースノートとソースが最終回答です。挙動を詰めるときは GitHub 上の公式情報を参照しつつ、署名付きクライアントの入手は 本サイトのダウンロードページ を主渠道にすると、再インストール時の迷いが減ります。用語索引として ドキュメント索引 も併用してください。
LAN 共有プロキシとの棲み分け
同一 Wi‑Fi 上の端末から PC の Clash を使う構成では、mixed-port や allow-lan の話が前面に出ますが、名前解決が Fake のままだと、スマホから管理 UI に入れない、といった別症状に化けることがあります。配線レベルの手順は LAN 共有とファイアウォールの稿 に譲り、ここでは「まず DNS の答えを人間が理解できる形に戻す」優先度で読み替えてください。
まとめ
fake-ip-filter は、FakeIP をやめずに、LAN 名・mDNS・社内サフィックス・スプリットホライズンだけを実レコード世界へ逃がすためのスイッチです。書き方の本質は難しくなく、ログでホスト名を特定し、必要最小限のサフィックスを追加し、YAML のマージ順を把握するの三拍子で大半は片付きます。DNS 全体の哲学や暗号化上流の話は DNS リーク防止の総覧稿 と補完関係にあり、本稿はそのなかでも検索されやすい単一キーに絞った実務メモとして使ってください。
GUI クライアントの中でも、設定画面とログを往復しやすいものを選ぶと、フィルタ一行の効果を短時間で試せます。CLI 派でも、最終的に「家族の PC で同じ再現があるか」まで持っていけると運用は楽になります。