How Fake-IP uses a reserved address block to speed up connection setup and cut DNS leaks, how it differs from Redir-Host, and which domains — LAN services, game platforms, and more — need to go in fake-ip-filter.
Before getting into Fake-IP, it's worth clearing up a question that's easy to overlook: when a client visits a domain, does it resolve the real IP first and then decide which path to take, or the other way around? This ordering directly determines how accurate and how fast a proxy client's routing decisions are. Traditional operating system network stacks follow a "resolve first, connect second" sequence — the application calls the system's DNS resolver to get a real IP, then uses that IP to open a TCP or UDP connection. If a proxy client copies this exact order, it runs into an awkward problem: the domain resolution step often happens before any proxy is involved, exposing it directly to the local network's DNS server, while the subsequent connection still needs to go through proxy rule matching.
When the Clash core (including Clash Premium and Clash Meta/mihomo) matches rules, many rule types are domain-based, such as DOMAIN-SUFFIX and DOMAIN-KEYWORD. These can be matched at connection time without needing an IP. But some rules depend on IP, such as GEOIP and IP-CIDR — these require the client to already have a usable IP address before it can make a routing decision. That's where the conflict arises: if you follow the normal flow and do a real DNS resolution first, the resolution request itself may already leak to your local ISP or LAN DNS server — this is what's known as a DNS leak. But if you skip resolution entirely and hand the domain straight to the remote proxy node, local IP-based rules stop working. Fake-IP was designed specifically to strike a balance between these two.
The core idea behind Fake-IP can be summed up in one sentence: the client maintains a local "domain to fake IP" mapping table. When an application requests resolution for a domain, the Clash core doesn't actually query a public DNS server — instead, it hands out an unused address from a reserved private block (typically 198.18.0.0/16) and returns that directly to the application. The application takes this seemingly ordinary IP and opens a connection as usual; the packet is intercepted by local routing or the TUN adapter, and the core then looks up which original domain that fake IP corresponds to, passing the domain along to the remote proxy node to perform the actual DNS resolution and connection.
The first benefit of this flow is speed. Since handing out a fake IP is essentially a zero-latency local operation with no need to wait for any real network round trip, the wait time before the first packet goes out is drastically cut down. The second benefit is privacy: the local network environment can't see the real IP behind the domain the user is actually visiting, and no DNS query is actually sent to the local network's resolver, reducing exposure at the DNS layer. The third benefit is rule compatibility: since every fake IP maps uniquely back to its original domain, domain-based rules can still be matched locally right away, without waiting on a remote resolution result.
A typical Fake-IP DNS configuration looks roughly like this (using the mihomo core as an example):
dns:
enable: true
ipv6: false
default-nameserver:
- 223.5.5.5
- 119.29.29.29
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- '*.lan'
- '*.local'
- 'time.*.com'
- 'ntp.*.com'
- '+.push.apple.com'
nameserver:
- https://doh.pub/dns-query
- https://dns.alidns.com/dns-query
Here enhanced-mode: fake-ip explicitly enables Fake-IP enhanced resolution, fake-ip-range defines the fake address pool's network block, and fake-ip-filter is the key setting that decides which domains skip Fake-IP and use real resolution instead — we'll go into why this matters later.
The fake address Fake-IP assigns to a given domain generally stays stable for the duration of a session — repeated visits to the same domain won't keep getting a different fake IP. This is worth knowing for scenarios that rely on IP consistency.
Before Fake-IP came along, Redir-Host mode was the more widely used approach in the Clash ecosystem. Both are values of the "enhanced DNS mode" (enhanced-mode) setting, but they work in completely different ways — understanding this difference helps you decide which one fits your situation.
This difference produces a few practical, noticeable effects. First, speed: Redir-Host has to wait for a real DNS round trip on every resolution, while Fake-IP skips that step entirely, making the first connection noticeably faster — especially over cross-border links. Second, the privacy boundary: under Redir-Host, the real domain still gets handed to an upstream DNS server for resolution; even if that upstream uses encrypted DNS, the resolution record still passes through the local network's egress. Fake-IP moves this resolution step entirely past the proxy node, so the local network never sees any resolution activity tied to a real domain. Third, compatibility: some scenarios that depend on the application layer getting a genuinely real IP (for example, certain game clients that use the server IP for connection-quality checks, or certain NAT traversal tools that need a real address for verification) may behave oddly under Fake-IP, since the application always receives a fake address — whereas Redir-Host at least guarantees the IP the application sees is real.
Because of this, most mainstream clients today (including the various GUI clients built on the mihomo core) recommend Fake-IP by default, keeping Redir-Host as a fallback for compatibility issues rather than the other way around. If you notice an app misbehaving, showing a garbled address, or failing to handshake, first check whether it's Fake-IP hiding the real IP before considering a temporary switch to Redir-Host to troubleshoot.
Fake-IP brings both speed and privacy benefits, but it isn't suited to every domain. There are scenarios where an application genuinely needs the real IP to function correctly — in those cases, you need to add the relevant domains to fake-ip-filter so they skip Fake-IP logic and go through real resolution instead.
If you access a NAS, router admin page, or an internal tunneling service by domain name on your home or office network, resolving that domain should return the actual LAN IP, not a fake address — otherwise the device won't be able to locate the real host on your internal network. A common approach is to add *.lan, *.local, and any custom internal domain suffixes to the filter list. Some corporate networks also resolve self-hosted domains to private address ranges, and those should be included in the filter as well.
The operating system's time-sync protocol (NTP) typically communicates directly over IP rather than through the proxy — if Fake-IP takes it over, time sync can fail or show erratic latency. The same applies to certain system-level network-quality probes, which don't need to go through the proxy and shouldn't be interfered with by a fake address either. This is why common config templates pre-populate rules like ntp.*.com and time.*.com.
Some OS-level push channels (such as the persistent connection a device keeps open with a vendor's push server) demand high connection stability and a genuine address — if Fake-IP takes over, push notifications can be delayed or dropped. The common wildcard rule +.push.apple.com found in config templates exists specifically to avoid this.
Some game clients actively probe network quality against the target IP before connecting to a server, or display the server's real latency and address in-game. In these cases, if the application layer only sees a fake IP, the probe results become meaningless and may even trigger the game client's own connection-error handling. For game platform domains that keep causing connection errors or matchmaking failures, try adding them to fake-ip-filter first and see if the issue disappears before deciding whether you need a dedicated routing rule for that game.
Stuffing lots of domains into fake-ip-filter isn't "the more the safer." Domains on the filter list skip Fake-IP and go through real DNS resolution, which means those resolution requests are exposed to the local network again, undercutting the privacy benefit Fake-IP is supposed to provide. Add entries only as needed — put in the domains that actually cause problems, rather than whitelisting an entire category at once.
After enabling Fake-IP, some users run into things that look strange at first glance. Here are a few typical cases and how to investigate them.
That's the Fake-IP address block at work — any address matching 198.18.x.x shown in an app's connection info generally means that connection has been taken over by Fake-IP, and the "resolved" address is fake rather than real. This is normal behavior, not a misconfiguration, unless it's causing an actual feature to break.
The Fake-IP mapping table is maintained locally on the client and usually resets when the process restarts or when the DNS cache is cleared manually. If you run into connection issues after switching networks, look for a "clear Fake-IP cache" option or similar in the client — many GUI clients place this under DNS settings or an advanced settings section.
By default, Fake-IP mainly covers the IPv4 address pool. If your local network also has IPv6 enabled and the system prefers IPv6 connections, some traffic may bypass Fake-IP logic and connect directly over IPv6. Most config templates explicitly set the ipv6 field under DNS to false, or handle IPv6 traffic separately with rule sets, to avoid connections slipping past proxy routing decisions.
You can use an online tool that shows where a DNS resolution originated from, testing once before and once after enabling Fake-IP, and compare where the resolution appears to come from. Under normal conditions, once Fake-IP is enabled together with a trusted remote DNS resolver, the test should show resolution happening on the network the proxy node sits on, not your local ISP's DNS server.
Fake-IP is often mentioned alongside TUN mode, but they solve different problems and shouldn't be conflated. TUN mode sets up a virtual network adapter at the system network layer so that all outbound traffic (not just from the browser or a handful of apps) passes through the Clash core — it solves the question of "which traffic gets included in the proxy." Fake-IP solves the separate question of "how domain resolution should be handled." The two can be enabled independently or together. In practice, once TUN mode is turned on, enabling Fake-IP alongside it is usually recommended, since that ensures the traffic intercepted by the TUN adapter has enough information for domain-rule matching, while also preventing system-level DNS requests from bypassing the virtual adapter and going straight to the local network — closing the loop end to end.
If TUN mode is enabled but the DNS enhanced mode is left blank or set to the system default resolver, DNS requests may still bypass the proxy and go directly to whatever DNS server is configured on the machine. This is the first setting to check when troubleshooting "TUN mode is on but I'm still seeing resolution failures or DNS leaks."
Putting all of this together, here's what to actually do: regular users without special internal-network needs can just keep the client's default Fake-IP configuration as-is, no extra tuning needed. Users with internal services or corporate domain resolution needs should proactively check and extend the fake-ip-filter list, adding their internal domain suffixes to it. When a game or real-time communication app shows connection errors, suspect Fake-IP first — temporarily filter the relevant domain or switch to Redir-Host for a side-by-side comparison to pin down the cause. Users running TUN mode should confirm the DNS enhanced mode and the Fake-IP address range are actually in effect together, to avoid a half-configured state where traffic is intercepted but resolution still falls back to the machine's default DNS.
Pick the Clash client that matches your system, then follow the setup guide to import your subscription and configure enhanced DNS mode.