Symptoms That Scream “DNS Semantics,” Not “Bad Hardware”
The failure stories cluster into a few archetypes. Your router admin page opens on another machine but not on the laptop running Clash. A NAS hostname that used to resolve to 192.168.x.x now pings something inside 198.18.0.0/16 (or whichever fake-ip-range you configured). Printers disappear from discovery UIs, AirPlay-style devices vanish, and anything ending in .local behaves like it lives on another planet. Meanwhile, ordinary websites still load through the tunnel because their names never depended on your living-room subnet.
If that pattern sounds familiar, resist the urge to flip enhanced-mode back to redir-host on the first day. You can almost always recover the ergonomics of FakeIP for the wide-area network while teaching the core which names must bypass the synthetic resolver. The companion Meta core DNS leak prevention guide explains the broader resolver stack; here we zoom into the allowlist that keeps split DNS honest when FakeIP is on.
What fake-ip-filter Actually Changes
Under dns.enhanced-mode: fake-ip, most queries receive a fast answer drawn from fake-ip-range. That answer exists so the proxy can attach metadata to flows before TLS exposes everything. Entries under fake-ip-filter are exceptions: matching names skip the synthetic pool and go through the normal resolver path so applications receive real A/AAAA records suitable for direct sockets on your LAN or for domains that break when any middle layer lies about addresses.
Think of the filter as a precision tool, not a second copy of your entire rules file. Routing still happens in rules:; the filter only prevents FakeIP from poisoning the address phase for specific namespaces. If you add a hostname here but your rules still send its TCP traffic to a remote node, you have fixed DNS semantics without guaranteeing a direct path. That separation matters when debugging: first confirm the client sees the IP you expect, then argue about DIRECT versus PROXY in the log lines.
A Practical Starter List (Merge, Do Not Cargo-Cult)
The snippet below is intentionally conservative. Your household may need extra OEM-specific lines; your corporate VLAN may need an internal suffix your subscription maintainer never heard of. Treat the block as a reviewed starting point, then grow it when logs prove a name is missing.
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "+.msftconnecttest.com"
- "time.windows.com"
- "time.apple.com"
- geosite:private
# nameserver / fallback / policy blocks continue below…
geosite:private (when your geodata files are current) bundles a large set of non-public suffixes and special-use names that commonly belong on the direct side of a consumer router. Wildcards such as *.local cover mDNS style host advertising used by many printers and media boxes. The Microsoft and Apple time-check hosts are frequent guests in real-world profiles because captive portals and sleep/wake cycles still probe them aggressively; excluding them from FakeIP reduces weird first-boot behavior on hotel Wi-Fi and home labs alike.
Router Admin Pages and OEM Portal Domains
Consumer gateways love branded hostnames that resolve only on the LAN DNS stub your router ships. Examples include routerlogin.net, tplinkwifi.net, and similar marketing-friendly strings. They are not “magic protocols”; they are ordinary DNS names that must return the CPE’s RFC1918 address. If FakeIP answers first, the browser happily connects to a synthetic address that has nothing to do with your actual gateway.
Add those domains explicitly with DOMAIN-SUFFIX-style thinking even though YAML uses plain strings: include both the vendor portal and any captive portal detection endpoints your ISP injects. When a hostname is unique to your ISP, keep a tiny private YAML fragment under source control so subscription refreshes do not erase your line. Pair the DNS exemption with a matching DIRECT rule above broad GEOIP matches so the TCP session stays on the LAN after resolution recovers.
NAS Shares, Printers, and Discovery-Oriented Apps
Network Attached Storage boxes often advertise multiple names: a short NetBIOS label, an .local mDNS alias, and sometimes a split-horizon FQDN for VPN users. FakeIP does not understand intent; it only sees another query. When SMB clients cache a wrong address, Explorer or Finder looks hung even though ping to the numeric IP still works. Exempting the suffixes you actually use—for example nas.home.arpa if you adopted modern residential naming—keeps file shares boring again.
Printers and scanners frequently mix multicast discovery with HTTPS management UIs. Multicast itself is not “fixed” by fake-ip-filter, but many management stacks still perform a unicast DNS lookup first. If that lookup was swallowed by FakeIP, the UI never reaches the stage where Bonjour would have helped. After updating the filter, clear the OS DNS cache or reboot the spooler service once; stale negative caching can masquerade as a persistent Clash bug for hours.
When a Public Domain Still Belongs in the Filter
Not every problematic hostname lives on RFC1918. Some direct-only domains are public on paper but assume the resolver sits inside the same country or enterprise network as the user. Banking portals, certain university SSO stacks, and hyper-local CDNs occasionally behave poorly when any intermediate layer synthesizes addresses. If your logs show repeated TLS failures only while FakeIP is active, try a short-lived exemption for that exact suffix, verify behavior, then decide whether to keep it or move the fix to nameserver-policy instead.
Avoid turning the filter into a dumping ground for “sites I want to go fast.” Each extra line widens the surface where your resolver bypasses the FakeIP abstraction, which can reintroduce subtle inconsistencies between domain rules and observed IPs. Prefer nameserver-policy when the issue is which upstream answers, and reserve fake-ip-filter for cases where the client truly needs a truthful address list.
Align nameserver-policy, Rules, and the Filter Together
Advanced profiles often combine three layers: fake-ip-filter for names that must never be synthetic, nameserver-policy for choosing which resolver sees a zone, and rules: for picking outbounds. Misalignment produces the worst kind of ticket: everything “looks configured” yet a browser still picks the wrong POP or a DIRECT rule never triggers because the sniffer and the resolver disagree about identity.
After you touch any one layer, re-run a quick matrix: same hostname, compare answers from the OS resolver, from Clash’s built-in DNS log, and from your fallback DoH path. The workflow mirrors the triage order described in the DNS leak article; reread that section whenever you change both policy tables and filters in one sitting.
TUN, Hijack, and Why DNS Fixes Are Still Not Magic
If part of your traffic never reaches Clash’s DNS module, no amount of YAML beautification will help. System resolver bypass, split tunnel corporate VPNs, and virtualization bridges all recreate the same symptoms with different fingerprints. When you already enabled TUN, double-check tun.dns-hijack and friends using the Clash Verge Rev TUN mode guide so queries actually land where fake-ip-filter can see them.
Range collision: ensure fake-ip-range does not overlap Docker bridges, corporate VPN virtual adapters, or other overlay subnets. Collisions look exactly like “random LAN breakage” until you chart interface addresses.
Verification Checklist You Can Finish in One Coffee
1Confirm the answer shape
From the affected machine, resolve a LAN hostname with Clash enabled. You should see RFC1918 (or your ULA) numbers, not 198.18.x.x. If you still see synthetic addresses, the name is not matching your filter strings—typo, missing leading wildcard, or a different suffix than the app uses in practice.
2Confirm the TCP path
Watch the core log while opening the router page. The matched rule should be the DIRECT (or LAN-friendly) branch you expect, and the destination IP should match the resolver output from step one. If DNS is real but the rule still sends traffic offshore, reorder rules rather than expanding the filter blindly.
3Regression-test WAN sites
Spot-check a few international domains you care about. A sloppy wildcard in fake-ip-filter can accidentally exempt an entire public suffix. If performance regresses only after your edit, binary-search the list until the culprit line reveals itself.
Upstream Source and Packaged Clients
Mihomo publishes source and issue trackers for users who want to read resolver internals or confirm behavior across releases. That transparency is invaluable when debugging edge cases, but day-to-day installs should still flow through curated client channels. Keep the upstream repository for code review and bug reports; use the official Clash download page when teammates simply need a reproducible build of Verge Rev or another maintained GUI.
Closing Thoughts
FakeIP remains one of the best ways to keep Clash Meta rules readable in 2026, provided you respect its contract with the operating system: synthesize widely, but never lie to names that must stay local. A tight fake-ip-filter list, refreshed when your network changes, delivers that balance with less drama than disabling enhanced mode globally. Compared with toggling entire resolver modes every time your NAS firmware updates, the incremental approach scales from a single apartment router to a small office VLAN without turning your profile into folklore.
Once router pages open instantly again and .local devices reappear in discovery panels, you can go back to optimizing latency-sensitive proxy groups instead of fighting ghost addresses.