Fake-IP Explained: DNS Mapping Pool, Hijack Flow, and When to Use It

Where DNS resolution sits in the proxy chain

Every network request starts with a domain lookup: the app asks the system or the client's built-in DNS module which IP a domain maps to, then opens a TCP or UDP connection to that IP. Without a proxy client in the loop, that IP is a real, routable address you can use directly for splitting traffic. But for rule-based tools like Clash / mihomo, relying purely on IPs is problematic: many domains sit behind a CDN, and the same site can resolve to completely different IPs depending on time and region. Rules hard-coded to IP ranges break quickly. What the rule engine really wants is the domain itself, not a constantly shifting IP. That's the core problem DNS modes are designed to solve — how to carry "domain information" through every step from connection setup to rule matching.

Clash's DNS module offers several modes, and the one most discussed — and most misunderstood — is Fake-IP. Understanding it requires dropping the default assumption that "the IP a DNS lookup returns is the real address you're connecting to."

How the Fake-IP mapping pool works

The idea behind Fake-IP: the client intercepts local DNS requests, and when an app queries a domain, instead of actually contacting an upstream DNS server for a real IP, it hands out a never-used address from a reserved private range (198.18.0.0/16 by default), following either sequential allocation or a caching policy. This IP doesn't point to any real server — it's just a placeholder. The client keeps an internal table mapping "this fake IP corresponds to this domain."

The whole flow breaks down into three steps:

1. The app issues a DNS query, which gets intercepted by TUN or the system DNS hook and routed to Clash's internal DNS server component.
2. Clash checks the mapping pool. If this domain has never been assigned a Fake-IP before, it grabs an unused address, creates a bidirectional "domain ↔ fake IP" record, and stores it in memory.
3. Clash returns this fake IP as the DNS answer to the app, and the app uses it to open a connection.

The key part happens after step three: when the app connects using the fake IP, that connection passes through the TUN adapter or system proxy into Clash's forwarding engine. At this point, Clash doesn't actually send packets to 198.18.x.x — it first checks the mapping table, reverse-looks-up the fake IP back to the real domain, then decides which proxy group to route through based on the rules, and performs an actual DNS resolution against the real domain (or simply hands the domain to a downstream proxy that supports SNI/HTTP Host). This step is called "restoration at connection time," and it's the core of how Fake-IP works — the domain information is preserved end to end, while the fake IP is only a temporary carrier that never actually participates in the underlying network transport.

Why rule matching gets more accurate

Because Fake-IP lets the "domain" survive all the way to connection setup, when the rule engine does domain-based matching like DOMAIN-SUFFIX, DOMAIN-KEYWORD, or RULE-SET, it's always working with the original, reliable domain name — not a CDN exit IP that could change at any moment. This matters a lot in CDN-heavy scenarios: the same domain might resolve to one A record today and a different set of IPs tomorrow, so rules written against IP ranges tend to work today and fail tomorrow. Domains are far more stable, which is also why domain-based rule sets are the most actively updated and widely used format in today's mihomo ecosystem.

On top of that, in Fake-IP mode the client doesn't need to fire off a real DNS query every single time at the system level just to decide whether to proxy a request — fake IP allocation and rule matching can happen entirely in local memory, cutting out a network round trip. That's part of why many users report pages loading noticeably faster after turning Fake-IP on.

Fake-IP vs. Redir-Host

Before Fake-IP existed, another common approach was Redir-Host: the client intercepts the DNS request, but instead of returning a fake address, it queries the real upstream DNS server directly, gets the real IP, and passes it straight back to the app. Rule matching then relies on the client having already recorded "which IPs this domain resolved to" during the DNS query stage, so it can reverse-look-up the domain at connection time. On the surface, both approaches let domains participate in rule matching, but the mechanics and the boundaries where they apply differ.

In short, Fake-IP has the edge in speed and rule accuracy, making it the default choice for today's TUN mode. Redir-Host, since the app always gets a real IP, is a safer bet for scenarios that depend directly on IP-level communication without going through domain resolution — but overall it's increasingly being replaced by the combination of Fake-IP plus an exclusion allowlist.

Scenarios that require fake-ip-filter exclusions

A fake IP is only meant to be a placeholder for Clash's internal use. If an app bypasses Clash's connection-hijacking logic and treats that IP as a real address, things break. A few common scenarios need an explicit fake-ip-filter entry to exclude the relevant domains from Fake-IP allocation and force real DNS resolution instead:

• Local network services and router admin pages — domains like *.lan or router.asus.com that point to local network devices. If given a fake IP, the browser will try to connect to an address that doesn't actually exist, and the admin page simply won't load.
• Apps that need the exact real IP — some cloud storage clients, live-streaming tools, and P2P apps read the DNS-returned IP directly at the application layer to display it or set up a peer-to-peer connection. A fake IP is meaningless to them.
• Private domains in corporate LANs and VPN setups — internal company system domains often resolve to a private range. These should also go on the exclusion list to avoid conflicting with proxy logic.
• Client components with known Fake-IP compatibility issues — for example, certain built-in OS network diagnostics or connectivity-probing services. It's better to exclude these using the official docs or a community-maintained rule set rather than adding them one by one manually.

In practice you don't need to write this exclusion list from scratch: mainstream rule set repositories usually maintain a fairly complete recommended fake-ip-filter list, and clients typically ship a basic version of it when generating default configs or applying rule subscriptions. Just add to it as specific apps run into trouble.

When to enable it, and when to turn it off

General guidance for Fake-IP mode:

• Keep it on in TUN mode. TUN mode takes over the entire network stack and needs an efficient, accurate domain-restoration mechanism to work with the rule engine. Fake-IP was designed exactly for this, and it's the default DNS type in TUN mode for most clients.
• In pure system-proxy mode (HTTP/SOCKS), it's optional. If you're only routing apps that respect system proxy settings — like a browser — through Clash, Redir-Host or direct upstream DNS are both viable alternatives, and the difference mainly shows up in how fine-grained the rule matching is.
• When a local device or internal system stops working, check fake-ip-filter first instead of disabling Fake-IP entirely. Most "proxy is on and my LAN device won't connect" issues come down to the exclusion list not covering that domain. Adding a targeted rule is far more efficient than dropping the whole mechanism.
• For the rare app that strictly needs the real IP, route it direct or exclude that domain individually. There's no need to disable Fake-IP globally over one app's edge case — rule-based splitting already supports exceptions by domain or by process.

Overall, Fake-IP isn't a simple on/off switch — it's a dynamic mechanism that needs to be maintained alongside an exclusion list. Rule-set communities keep updating the domains known to need exclusion, and clients keep refining how the fake IP pool is allocated and recycled. Once you understand how it actually works, you can quickly figure out where to look when something breaks, instead of treating the whole DNS mode as an inscrutable black box.