#Fake-IP Mode Explained: DNS Response Mechanism, Pros/Cons, and fake-ip-filter Setup

Why DNS mode becomes a real decision

In a typical network setup, an app resolves a domain before connecting: the system asks a DNS server, gets back a real IP, then connects to that IP. For Clash to route traffic by domain (say, "these sites go through a proxy, those go direct"), it needs to intervene at exactly this step — but the problem is that routing rules are usually written against domains (DOMAIN-SUFFIX, DOMAIN-KEYWORD), while the underlying connection is made over IP. Without special handling, the rule engine only sees a bare IP at connection time, and reverse-mapping that IP back to a domain to figure out which rule applies isn't always reliable.

That's why Clash Meta (mihomo) offers several DNS modes, the two most common being Fake-IP and redir-host (the redirect-based mode used as an alternative to fake-ip). Both are solving the same underlying problem: keeping domain-based rules aligned with IP-level connections. They just take completely different routes, and the resulting behavior differs quite a bit.

How Fake-IP actually works

Fake-IP's approach: when an app queries a domain's DNS record, Clash doesn't actually resolve it. Instead, it picks an unassigned address from a reserved private range (commonly 198.18.0.0/16 by default), returns it to the app immediately, and internally maintains a mapping table of "fake IP ↔ real domain".

1. The app queries the A record for example.com;
2. Clash's DNS module intercepts the query, assigns a fake IP (e.g. 198.18.0.23), and records that "198.18.0.23 maps to example.com";
3. The app receives 198.18.0.23 and initiates a TCP/UDP connection;
4. The connection passes through Clash (whether via the system proxy port or the TUN virtual adapter), and Clash looks up the table to recover the original domain example.com;
5. The rule engine matches DOMAIN-based rules against the recovered domain to decide which proxy node to use;
6. Once a policy is confirmed, Clash performs the actual resolution against the real domain (if the target is a direct connection) or hands the domain directly to a proxy protocol that supports SNI, and establishes the real outbound connection.

From the app's perspective, the DNS response arrives instantly — because Fake-IP never goes out over the network to ask an authoritative DNS server; handing out a locally reserved address is basically zero-latency. This is its most direct advantage over redir-host: DNS query latency is essentially zero, and since the rule-matching stage sees a full domain rather than an IP, DOMAIN rules match more accurately as well.

Fake-IP vs. redir-host

redir-host takes a different route: Clash actually resolves the domain to a usable IP and returns that to the app, but during proxy forwarding it re-identifies the domain by reading the HTTP Host header or the TLS SNI field, then matches rules against that. The upside is the app always gets a real IP, which avoids issues in scenarios that strictly rely on real IPs (e.g. apps doing their own IP allowlist checks). The cost is that every query triggers a real resolution — full DNS latency stays in the loop — and its ability to identify traffic without plaintext domain info (some UDP apps, non-standard ports) is limited.

Most default Clash Meta (mihomo) core distributions set Fake-IP as the default or recommended mode, especially when paired with TUN mode — since TUN takes over the entire system's network layer traffic, Fake-IP's domain-recovery mechanism can cover connection requests from all kinds of apps more thoroughly, not just the traffic going through the system proxy port.

Common Fake-IP pitfalls

Fake-IP isn't free of trade-offs. The following scenarios come up most often in community feedback:

• LAN service resolution breaks: if a NAS, router admin page, network printer, or similar device's domain also gets taken over by Fake-IP, the app receives a fake address. If that connection doesn't actually pass through Clash (e.g. direct LAN communication that bypasses the proxy), the connection fails.
• Apps that need to verify a real IP: some client software logs or compares the resolved IP at the application layer (common in certain enterprise VPN clients, or services with strict certificate pinning). The fake address Fake-IP returns will make this kind of check fail outright.
• IP-based geolocation goes wrong: if an app uses the DNS-returned IP for its own geolocation logic (instead of relying on the standard domain-connection flow), Fake-IP's reserved range obviously carries no real geographic info, so the result will be off.
• Conflicts with mDNS/LAN discovery protocols: LAN device discovery relies on address broadcasts within the real subnet; once taken over by Fake-IP, device discovery may stop working.

What these scenarios have in common: the domain should really be going through a "direct connection, unaffected by Clash routing" path, but it ends up caught in Fake-IP's default takeover scope. The fix isn't to disable Fake-IP — it's to precisely exclude these domains from that scope, which is exactly what fake-ip-filter is for.

How to write the fake-ip-filter exclusion list

This option lives under the DNS config block, and declares domain rules that should always resolve for real, never get a fake response, even while in Fake-IP mode. Wildcards are supported; the basic structure looks like this:

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 8.8.8.8
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.market.xiaomi.com"
    - "time.*.com"
    - "ntp.*.com"
    - "*.msftncsi.com"
    - "www.msftconnecttest.com"

A few commonly used tips:

1. Wildcard suffixes like *.lan and *.local exclude common local domain suffixes used by LAN devices;
2. If your router or NAS admin panel uses a fixed domain (e.g. a vendor-assigned DDNS domain), add a dedicated exact-match exclusion for it;
3. Keep system-level connectivity check domains (e.g. Windows's msftncsi.com, msftconnecttest.com) resolving for real, to avoid the OS mistakenly reporting "no network connection";
4. Time-sync (NTP) domains are worth excluding too, since some clients are sensitive to sync response delay;
5. If a specific app's login/verification domain keeps causing odd connection failures, try adding it to the filter on its own first and see if the issue goes away.

When to switch back to redir-host or disable Fake-IP

Fake-IP is a sensible default for most use cases, and pairs especially well with rule-based routing and TUN mode. But in the following situations, switching or adjusting may be worth considering:

• Your network relies heavily on domain-based communication between many devices on the LAN (home NAS clusters, lots of self-hosted LAN services), and maintaining an exclusion list has become more work than it's worth;
• The client software you're using explicitly requires DNS results to be real public IPs, and it can't tolerate the Fake-IP range;
• You only need basic traffic routing, aren't sensitive to DNS latency, and prefer a "what you see is what you get" real-IP troubleshooting experience (so tools like ping and nslookup give directly usable results).

Switching is simple: change enhanced-mode from fake-ip to redir-host. No changes to the rule set itself are needed, since DOMAIN-based rules work fine under both modes — the only difference is the underlying response mechanism.

Quick troubleshooting checklist

If a specific domain won't connect, but direct connections work fine and the proxy rules look correct, try the following steps in order:

1. Check the current DNS mode (look at the enhanced-mode field in your config file, or the DNS settings in the client UI);
2. If it's Fake-IP mode, check whether the domain or its subnet should really be going through direct LAN access but isn't listed in fake-ip-filter;
3. Check the client logs or connection panel to confirm whether this connection's target IP falls within the range declared by fake-ip-range (commonly 198.18.0.0/16 by default);
4. Temporarily add the suspect domain to fake-ip-filter, restart the core, and test whether the issue goes away;
5. If it's still unresolved, try temporarily switching enhanced-mode to redir-host as a comparison test to narrow down the cause.

Once you understand how Fake-IP's response mechanism works, most "DNS-related connection issue" cases boil down to a single question — should this domain be under Fake-IP's takeover at all — and the troubleshooting path becomes much clearer than it first seems.