What Is Fake-IP Mode: DNS Hijacking Explained, Pros, Cons & Use Cases

Why Proxy Software Gets Involved in DNS Resolution

Under normal browsing, visiting a domain triggers a DNS lookup: the system hands the domain to a DNS server and gets back a real IP, which it then uses to open the connection. The catch is that rule-based proxy tools like Clash mostly route traffic by domain name — for example, matching GeoSite rules to decide whether a domain should go through the proxy or connect directly. If the proxy never touches DNS resolution and only sees a bare IP when a connection request comes in, it has no way to reverse-map that IP back to a domain, and any domain-based rule becomes meaningless.

To get around this, the Clash/mihomo core offers several DNS handling modes, and Fake-IP is the default and most widely used one. The idea is straightforward: when the client queries a domain, the core doesn't hand back the real IP — instead it returns a made-up address from a range that's never actually been assigned anywhere, while internally keeping track of which domain that fake address belongs to. When the app actually opens a connection, the core looks up the domain it remembered and applies routing rules to decide whether to proxy or connect directly, all completely transparent to the app above it.

How Fake-IP Works: Reserved Address Ranges and the Mapping Table

The addresses Fake-IP hands out aren't random — they're pulled from a dedicated block that's never actually routed on any real network. Most default configs use a reserved range like 198.18.0.0/16. Since this range is never used on the public internet, the core treats it as a "temporary address tag." Here's roughly how it plays out:

1. An app fires off a DNS query asking to resolve a domain;
2. The Clash/mihomo DNS module intercepts the query instead of forwarding it to a real upstream DNS server, and pulls an unused fake IP from its reserved address pool;
3. The core keeps an in-memory table mapping that fake IP to the domain, then hands the fake IP back to the app;
4. The app connects using the fake IP; the core looks up the table when the connection is established, recovers the real domain, and checks the rule set to decide which policy and which proxy node to use;
5. If the rule says to proxy the traffic, the core passes the domain along to the proxy node for resolution and connection — the actual DNS lookup for the real IP is deferred to the other end of the tunnel.

The direct payoff is noticeably lower resolution latency — in most cases the core doesn't need to query a real upstream DNS server at all, it just hands out an address from its local pool almost instantly. And because the domain name is preserved throughout, domain-based routing rules can match with precision instead of falling back to rough guesswork based on IP ranges.

Fake-IP vs. Redir-Host vs. Plain DNS Resolution

Beyond Fake-IP, the core usually supports two other DNS handling approaches. Knowing the differences helps you pick the right one for your situation:

• Fake-IP mode: as described above, it returns fake addresses and matches rules against domains internally. It's fast and matches domains precisely, but the fake addresses can't be used in situations that need a real IP — for example, some apps cache the resolved IP for health checks or display it directly.
• Redir-Host mode: also relies on the address handed to the app to trigger rule matching, but leans more toward redirecting based on the destination port. It's more limited in implementation and scope than Fake-IP, and mainstream clients rarely set it as the default anymore.
• Plain resolution mode (direct lookup, non-Fake-IP): every query goes straight to a real upstream DNS server and returns a real IP. Apps always get a usable real address, giving the best compatibility, but you lose precise domain-based routing (you're stuck matching by IP range), and every lookup carries real network round-trip latency.

For the vast majority of everyday use — browsing, video, social apps — Fake-IP delivers lower latency and more accurate matching, which is why most clients set it as the default.

Why LAN Services and Online Gaming Need fake-ip-filter

Fake-IP's address trick runs into real trouble when devices need to talk across a network. Two cases come up most often:

Self-hosted LAN services or router admin pages. Say you've got a NAS or router at home, and its domain resolves through your internal DNS — normally you'd get back a real internal address like 192.168.x.x. But if that domain isn't excluded from Fake-IP handling, the core will still hand back a fake 198.18.x.x address. The app tries to connect using that fake address, the core tries to match it against rules and forward it, and the result is usually a failed connection or a roundabout one — showing up as "LAN devices are slow or timing out."

Online gaming and real-time multiplayer apps. Many game clients use the resolved server IP directly to open UDP connections, run latency checks, or even display the resolved IP in the UI for server selection. Fake addresses in this context cause connection failures, bogus ping readings, or a server list that simply won't load.

The fix is adding a fake-ip-filter entry to your DNS config to exclude these specific domains or domain patterns from Fake-IP handling, so they resolve to real addresses instead. A typical config example:

dns:
  enable: true
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "192.168.*.*.*"
    - "router.asus.com"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"

Wildcards like *.lan and *.local cover most domain suffixes used by common home LAN devices. Entries prefixed with +. match both the root domain and all its subdomains, which is handy for excluding system-level connectivity-check domains so fake addresses don't trip up the OS into thinking the network is down. For game-related domains, it's better to add each official server domain individually rather than excluding a whole broad category — otherwise you lose the routing precision Fake-IP is supposed to give you.

Troubleshooting: What to Do When a Service Won't Connect

If you suspect Fake-IP is the culprit, work through these steps in order:

1. First confirm the current DNS mode is actually Fake-IP, not something else causing the issue;
2. Check the client's connection logs or resolved-domain records to see whether the target domain resolved to a 198.18.x.x address or similar reserved range;
3. If it did, that domain has been wrongly caught by Fake-IP handling and needs to be added to fake-ip-filter;
4. After editing the config, restart the core or reload the config (the exact button varies by client, but there's usually a "reload" option on the config management page) — this clears out the old mapping table;
5. If the problem persists, check whether the rule set is routing that domain to a dead proxy node — that's a rule issue, not a DNS mode issue.

When It Makes Sense to Turn Off Fake-IP

Fake-IP isn't mandatory for every setup. If your network has a lot of apps that depend on real IPs for validation, or you're running so many LAN services that maintaining filter rules one by one becomes a hassle, it's fine to switch entirely to plain resolution mode — trading some latency benefit for fewer compatibility headaches. That said, for most users who just want their browser, social apps, and video clients to route correctly, keeping the Fake-IP default and only adding a short filter list for LAN domains and a handful of special apps strikes the best balance between upkeep and experience.