1. Symptoms that point to fake-ip
At a high level, fake-ip changes what applications see during the local DNS phase. For hostnames that match your DNS rules, Clash (for example Mihomo / Meta-class cores) can answer with a synthetic IPv4 drawn from fake-ip-range—commonly a reserved-looking segment such as 198.18.0.1/16. The real resolution to an upstream CDN or origin often happens later, when the connection is actually established and the proxy stack has enough context. For most browsing and API traffic that model feels faster and simpler; the client gets an address immediately and work continues.
Problems appear when a particular app or site still insists on treating the first answer as “the truth” for its own logic: it may try to validate TLS against that synthetic target, perform a second lookup that no longer lines up with how Clash steered the flow, or depend on geo- or ISP-specific DNS results that never materialize at the right stage. The user experience is frustratingly narrow: everything else works, but a bank portal, an internal SSO page, a game launcher, or a voice client fails in a repeatable way. Browser tabs may sit empty while the spinner runs; HTTPS errors may mention name mismatch even though the site is legitimate; WebSocket-heavy dashboards may connect on one machine profile and not another.
If flipping dns.enhanced-mode (or the equivalent knob in your build) from fake-ip to something like redir-host makes the same URL work instantly, you have strong evidence the breakage lives in the fake address path or in lists that should bypass fake-ip, not in a dead remote hop. That mental model matches what we stress in the Perplexity routing guide: split rules are only half the story—you still need DNS, DoH, and fake-ip behavior aligned with how the tunnel captures traffic.
Before you edit huge rule files, write down exact hostnames from DevTools or your client log: apex domain, login redirects, static asset hosts, API subdomains, and any wss:// endpoint. Those strings are what you will feed into fake-ip-filter or DNS policy next.
2. A/B test: tie failures to fake-ip
Large configs tempt people to change five things at once. For fake-ip issues, that is a recipe for unreadable logs. Start with a minimal comparison. First, for the broken hostname, confirm in the client UI or log that the resolved address falls inside fake-ip-range. If it does not, you may be looking at an ordinary DNS or routing bug; if it does, keep going.
Second, temporarily set enhanced mode from fake-ip to redir-host, reload the profile, and hit the same URL with the same outbound selection. If the symptom disappears, you have confirmed the failure correlates with fake-ip semantics. Your next moves are almost always fake-ip-filter entries and DNS tuning—not “try ten different nodes.”
Third, optional but useful: keep fake-ip enabled, but on a test device or browser profile bypass Clash’s DNS resolver (for example by pointing the OS to a public resolver briefly). If the site recovers only when Clash is out of the DNS path, suspect upstream reachability, hijack, or an over-tight fallback-filter. If it still fails, return to rules, node path, and sniffer settings.
Document each step: timestamp, mode, and outcome. When you escalate to a forum thread, that table saves everyone time.
3. fake-ip-filter: who needs a real IP
fake-ip-filter lists hostnames (or patterns, depending on core version) that must not receive a synthetic address. For those names the resolver should behave like a more traditional stub: return real A/AAAA records so picky clients see consistent endpoints through their own validation chain. One missing line here is a classic reason a single domain family breaks while the rest of the internet feels normal.
What to prioritize in the filter
- LAN and mDNS-style names—patterns like
*.local, router admin hosts, NAS portals, printers, and corporate intranet zones. A fake address cannot describe your actual L2/L3 path on the LAN. - Certificate-sensitive services—some banking, payment, government SSO, and zero-trust gateways pin expectations to specific resolution or handshake ordering. A placeholder IP at the wrong stage can surface as endless redirects or TLS errors.
- CDN edge selection oddities—most sites are fine with deferred resolution, but a minority behave poorly if the client “locks in” too early. Symptoms may look like extreme latency or handshake timeouts rather than a clean DNS failure.
- Domains you mark DIRECT—if policy sends traffic straight out but DNS still hands the app a fake IP, you can create a semantic mismatch between what the stack thinks the destination is and how the kernel routes the packet. Adding those hosts to
fake-ip-filteroften removes edge cases.
Example snippet (adjust field names to your core)
The block below is illustrative; always cross-check keys against your Mihomo / Meta documentation. When merging subscriptions, avoid duplicating entire dns: trees.
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "+.msftconnecttest.com"
- "stun.*.*"
- "+.srv.nintendo.net"
# add hostnames that break with fake-ip belowIn practice, collect every hostname the broken page touches: HTML document host, auth redirects, asset CDNs, analytics (if the page hard-blocks without them), and WebSocket hosts. Add them one batch at a time, then reload DNS or restart the core so caches do not fool you. If the list grows large, consider geosite-style sets for recurring categories and keep a short manual override list for one-off corporate domains.
fake-ip-filter is not an adblock list. It is a compatibility tool. Stuffing it indiscriminately defeats much of why fake-ip feels fast.
4. DNS: nameserver, fallback, and order
Even a perfect fake-ip-filter cannot compensate for a broken DNS chain. Users often describe that as “randomly fails on mobile data,” “fine at home, bad at the office,” or “only after the VPN tab toggles.” Work top-down.
Can your nameservers be reached?
Verify each configured DoH, DoT, or plain UDP resolver is actually reachable from the network you are on. Enterprise Wi-Fi and some ISPs block non-standard ports, rewrite certain DoH hostnames, or rate-limit aggressive clients. The symptom is intermittent resolution: fake-ip amplifies the pain because apps time out waiting for a coherent path. Swap to a different resolver group temporarily; if failures track the upstream rather than the hostname, fix reachability first.
fallback and fallback-filter
When primary servers return poisoned or absurd answers, whether fallback activates—and how fallback-filter classifies “bad” results—determines whether you ever feed rules sensible geography and routing hints. Templates copied from forums sometimes ship an overly aggressive fallback-filter. Re-read the upstream docs, trim what you do not understand, and retest with logging enabled so you can see which server actually answered.
nameserver-policy for split worlds
If you routinely mix domestic and international destinations, nameserver-policy to route specific suffixes to dedicated resolvers is usually more stable than one global pool. That lines up with the layered DNS story in WSL2 and Windows localhost DNS: first guarantee queries reach the intended upstream, then worry about fake-ip toggles.
On laptops, remember captive portals and split-tunnel corporate VPNs: the resolver that worked at a café may be wrong inside the office VLAN. A short policy table per environment beats perpetual manual edits if you switch locations often.
| What you see | Check first |
|---|---|
| Only certain domains fail | Whether they belong in fake-ip-filter; whether a long CNAME chain left a related hostname uncovered in your rule sets |
| Failures follow the network, not the hostname | Resolver blocking, captive portal quirks, or DoH hostname filtering on that network |
| TLS or SNI errors in logs | Sniffer interference; TUN stack vs. system trust store (see the next section and the TUN guide) |
5. Sniffer and certificates
The sniffer tries to recover domain names from encrypted flows—typically from TLS ClientHello fields such as SNI—so policy can still route when fake-ip or tunneling hides the original Host header. That is powerful, but it stacks with fake-ip in ways that confuse people: both features exist to paper over incomplete visibility, and when either is too broad you can see certificate warnings, abrupt connection resets, odd HTTP/2 or QUIC downgrades, or apps that detect “something unusual” about the handshake path.
Use a methodical sequence. First, confirm in logs whether failing flows are even hitting the sniffer. Second, narrow sniffing to the protocols and ports you truly need—some users only require it for certain inbounds or for TCP 443 toward specific subnets. Third, if the site suddenly works when sniffing is disabled briefly, treat that as a compatibility signal: tighten rules before you disable fake-ip globally.
Desktop GUIs sometimes bind “auto sniff” to system proxy or TUN modes. After you change sniff settings, restart the helper service or virtual adapter so no stale process keeps the old behavior. On mobile tethering, also watch for MTU or middlebox oddities that show up only when the sniffer and fake-ip both touch the same flow.
If you are debugging a proprietary app, compare against a known-good browser session with the same profile. Divergence usually means the app uses its own TLS stack or certificate store, which interacts differently with synthetic addresses and sniff metadata.
6. TUN, system proxy, and stacked clients
TUN mode plus fake-ip can create a dependency loop in how the OS thinks DNS should work versus when Clash finishes resolution. The symptoms resemble “pure fake-ip” bugs—certain sites never load, or DNS seems flaky—but the fix may live in route exclusions, bypass lists, or hijack toggles rather than in a single hostname line.
Walk through Clash TUN on Windows: routing and firewall to ensure the tunnel is not starving traffic globally before you spend hours on DNS lists. Once TUN is verifiably healthy, return here to refine fake-ip-filter and resolver policy.
Another frequent scenario is multiple clients—a corporate VPN, another “accelerator,” or a browser-only extension—each installing filters or virtual interfaces. Only a handful of domains may take the wrong stack if one app pins its own proxy while the OS default points at Clash. For troubleshooting, reduce to one active forwarder, validate, then reintroduce layers deliberately.
Long term, keep a short internal note: which domains required filter entries and why (LAN, cert pinning, CDN, DIRECT mismatch). After subscription refreshes or GUI upgrades, you will know what to re-merge instead of rediscovering the same failure mode.
7. Summary
Clash fake-ip is a net win for many users, but a few sites breaking is rarely proof of a bad exit node. In practice the culprits cluster around incomplete fake-ip-filter coverage, unstable or mis-scoped DNS (nameservers, fallback, and policy), and sniffer settings that disagree with picky TLS stacks—often amplified when TUN or other VPN software shares the machine. Following controlled A/B tests → filter additions → DNS verification → sniffer narrowing → TUN sanity checks resolves most cases without turning off fake-ip entirely.
Building a habit of logging each odd hostname pays off: over time your profile becomes self-documenting. If you want a trustworthy starting point for client builds and baseline YAML, read our configuration documentation first, import your subscription, then apply the checks above to the DNS and fake-ip sections deliberately.
Clash-family cores expose more knobs than many alternatives; that power is manageable once you separate name resolution compatibility from routing policy. Getting the boundary between fake addresses and real ones right is what keeps day-to-day browsing and developer tooling steady.
→ Download Clash for free and put the smoother stack into practice