Fake-IP Mode Explained: How DNS Resolution Gets Hijacked, When to Enable or Disable It
Starting from the standard DNS query flow, this article explains how Fake-IP uses fake addresses from a reserved IP range to speed up rule matching and reduce DNS leaks, compares it against Redir-Host, and lists typical scenarios—like LAN services and online gaming—where it should be disabled or exempted.
Standard DNS resolution, and the problems it causes with proxying
Before you can reach a domain, the system has to translate that domain into an IP address—that's DNS resolution. By default, the OS sends the query to an ISP-provided or system-configured DNS server, gets back a real IP, and then opens the connection. This works fine without a proxy, but once proxy software enters the picture, it creates at least two headaches.
The first is leaking. If the proxy only intercepts TCP/UDP traffic but doesn't handle DNS queries, domain lookups bypass the proxy and go straight out over the local network. Anyone monitoring that local network or ISP link can see which domains you're querying—this is the classic DNS leak: the traffic goes through the proxy, but the lookup record doesn't.
The second is timing. Clash's routing rules rely heavily on domain-based matches (DOMAIN-SUFFIX, DOMAIN-KEYWORD, etc.), which are naturally suited to matching against a domain string. But in the traditional flow, resolution happens first, so the application layer only ever sees a raw IP. By the time rule matching runs, the domain information is already gone, and matching has to fall back to IP-range based rules—which is harder to maintain and less accurate.
What Fake-IP is: substituting real resolution with fake addresses from a reserved range
Fake-IP is a DNS handling mode built into the Clash / Clash Meta (mihomo) core. The idea is simple: the client runs its own built-in DNS server that intercepts every domain query the system sends out. Instead of asking a real DNS server, it hands out a fake IP for each domain from a reserved private range (commonly 198.18.0.0/16 by default)—an address that's never actually used on the public internet—and keeps a "domain ↔ fake IP" mapping table inside the core.
Once the application gets that fake IP, it connects as normal, and the connection request enters Clash's traffic interception layer (TUN mode or the system proxy). At that point, the core checks the mapping table, recognizes the destination as a fake IP, and immediately reverse-looks-up the corresponding domain—so rule matching gets back a domain string instead of a context-free number. The actual resolution to a real IP is deferred until after the rules have already decided which proxy node the traffic should use, and even that resolution request is forwarded through the proxy node rather than going out over the raw local network.
This solves both problems mentioned earlier at once: DNS queries stay entirely inside the proxy pipeline instead of being exposed to the local network, and rule matching always works against a domain rather than a prematurely resolved IP—improving both accuracy and speed.
Key point: the fake IP only "exists" temporarily inside the local core—it's never actually sent out to the internet and can't be recognized by any other device. Its only job is to act as an intermediate token between the domain and the rule engine.
Fake-IP vs Redir-Host: two ways of preserving domain information
Besides Fake-IP, Clash's enhanced DNS modes also include an older approach called Redir-Host. Both aim for the same goal—carrying domain information through to rule matching—but they get there differently, and that difference directly affects which one you should pick.
| Comparison | Fake-IP | Redir-Host |
|---|---|---|
| DNS query handling | Intercepts the query, returns a locally generated fake IP | Lets the query through normally, returns the real IP |
| Basis for rule matching | Reverse-lookup on the mapping table to recover the domain | Reconstructs the domain from application-layer fields like SNI/Host headers |
| Compatibility risk | Non-HTTP/TLS protocols may lack a domain field, causing mismatches | Less prone to issues in cases that depend on the real IP (e.g. certificates pinned to an IP) |
| Support for protocols without a domain | Some protocols missing Host info can be routed incorrectly | Largely unaffected, since it always works from the real IP |
| Current recommendation | Default in mihomo; better balance of performance and accuracy | Increasingly niche, mostly used as a reference when debugging compatibility issues |
In short: Fake-IP "fakes the resolution first, then recovers the domain from a mapping table in the core"—broad coverage, fast, and the default recommendation in the mihomo core today. Redir-Host "gets the real IP honestly, then extracts the domain from the protocol header"—it's more stable and less likely to break with certain non-standard protocols that don't use TLS/HTTP, but it's no longer the mainstream choice overall. For everyday use, stick with Fake-IP and troubleshoot on a per-app basis if something won't connect—there's no need to switch back to Redir-Host wholesale.
When to disable Fake-IP or add exceptions
Fake-IP isn't a universal switch—it assumes every domain query can safely be handed a fake address first, but some scenarios specifically require getting back the real IP. In those cases you need to disable Fake-IP or add the relevant domains to an exception list (typically the fake-ip-filter setting).
- LAN service discovery: NAS boxes, printers, smart home devices, shared network drives, etc. often resolve to internal addresses like
192.168.x.xor*.local. If these domains get pulled into the fake-IP flow, connections get incorrectly routed into the proxy pipeline and fail. It's a good idea to add*.localand any custom domains for LAN devices tofake-ip-filter. - Online gaming and LAN discovery protocols: many game lobbies and voice services need the real public IP to establish direct connections or P2P channels—a fake IP breaks handshake logic that depends on "seeing the real address." A common fix is to exclude game-related domains from Fake-IP entirely, or route the game process through a direct-connection rule.
- Clients that validate IPs directly: a handful of enterprise intranet tools and some banking/payment clients check at the application layer whether the requester's IP falls within an expected range. A fake IP will fail that check, so these domains usually need a direct-connection rule or an explicit exception.
- Devices relying on mDNS/multicast discovery: Apple ecosystem features like AirPlay and AirDrop discover devices via multicast broadcast, which is a different path from DNS resolution and shouldn't be affected by Fake-IP in theory. If you see odd behavior here, check the scope of TUN mode's route hijacking first rather than jumping straight to disabling Fake-IP.
Note: once TUN mode is enabled, the Fake-IP range is treated by the system as a real route. If that range overlaps with an existing local network segment (say, a private range assigned by a company VPN), you'll run into baffling local-network connectivity issues. When that happens, check first whether fake-ip-range conflicts with your existing network setup before blaming the proxy software.
Configuration and troubleshooting tips
Before tweaking Fake-IP settings, figure out which layer is actually at play—the DNS mapping table or TUN-layer route hijacking. Debugging them separately is far more efficient.
- Check whether
enhanced-modein your client's DNS settings is set tofake-ip. If it showsredir-host, you're running under a different logic, and the behavior comparisons above should be read in reverse. - Check whether the
fake-ip-rangesegment overlaps with your existing network (including VPN adapters or virtual machine NICs)—overlap is a common cause of broken LAN access. - Add domains that specifically need real IPs (internal services, game lobbies, multicast devices) to
fake-ip-filterone at a time. Don't take the shortcut of disabling Fake-IP entirely—that also throws away the matching-speed and leak-prevention benefits described earlier. - If you suspect a specific connection issue is related to Fake-IP, check the client's connection log first to see which rule and destination it actually hit—confirm whether it's a resolution problem or simply a misconfigured rule.
- After changing settings, restart the proxy core entirely rather than just reconnecting to a node—the DNS mapping table and routing table are usually built at core startup, and switching nodes alone won't regenerate them.
In short, Fake-IP is an engineering trick that defers and hides the domain-resolution step, aiming for more accurate rule matching and more private DNS queries. Most use cases are fine leaving it on by default. What actually deserves attention is the small subset of services that genuinely depend on real IP semantics—add exceptions for those specifically, rather than switching off the whole mechanism just because one app won't connect.