Clash Fake-IP Mode Explained: Fake-IP vs. redir-host and When to Use Each

Fake-IP: Return a mapped address first, then handle the real connection

In a Clash or mihomo config, enhanced-mode: fake-ip tells the core's DNS module to assign a synthetic address to a domain. This isn't the website server's public IP; it's an index the core uses to look up the domain mapping. When an app connects to that address, the traffic must pass through the same core again so it can recover the domain and continue processing the connection.

A common setting uses 198.18.0.1/16 as fake-ip-range. This falls within the reserved 198.18.0.0/15 block used for network benchmarking. It is neither a public website address nor a private LAN address like 192.168.0.0/16. Seeing it in DNS results does not, by itself, mean name resolution has failed.

What happens during a connection

1. The app queries example.com, and the request reaches the core's DNS module.
2. The core maps the domain to a synthetic address and returns it to the app, for example 198.18.0.10. This address is illustrative; the actual assignment can vary.
3. The app connects to that address, and TUN or another traffic capture path routes the connection back through the core.
4. The core recovers example.com and selects a direct or proxied route based on the rules. If a real address is needed, it resolves the domain according to the relevant outbound and DNS settings.

Key differences between Fake-IP and redir-host

With redir-host, the core typically queries upstream DNS first and returns the real IP to the app. It may associate the domain with the DNS record, but one IP can host multiple domains, and the association may be missing. Fake-IP preserves the domain in a dedicated mapping, which usually makes domain-based routing more reliable, but requires the full connection path to pass through the core.

“Fewer DNS round trips” doesn't mean “no DNS resolution”

Fake-IP can skip the step of waiting for a real address in some situations. If a domain rule selects a proxy and the outbound protocol can pass the domain to the remote end, the local device may avoid a lookup for the destination's real IP. A direct connection usually still needs a real address, and IP-based rules, filtered domains, and other DNS needs can still trigger upstream queries.

There is no guaranteed number of milliseconds saved. Cache hit rates, upstream DNS latency, node location, and connection reuse all affect the result. To compare modes, use the same network, node, and domain; record DNS lookup time and time to first byte separately. Don't treat a single speed test as a general result.

mihomo DNS settings: DNS listener vs. proxy port

This YAML snippet illustrates the fields and applies to mihomo configs that support them. It omits nodes, proxy groups, and rules, so it is not a complete subscription config. When merging these fields into an existing config, keep your current outbound settings. GUI clients may generate the active config through overrides, so check the config currently in use.

mixed-port: 7890
mode: rule

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "localhost"
    - "+.lan"
    - "+.local"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

• mixed-port: 7890: Provides a combined HTTP and SOCKS proxy listener; it is not a DNS port. Use the port shown in your client.
• listen: 127.0.0.1:1053: Listens for DNS requests on this device only, which is useful for targeted testing. Windows network adapters typically use port 53 for DNS; entering just 127.0.0.1 won't automatically direct requests to port 1053.
• ipv6: false: Controls how this DNS module handles AAAA queries. It does not disable the Windows IPv6 protocol stack.
• nameserver: Lists upstream resolvers. This example uses standard DNS; it does not enable encrypted DNS or guarantee reachability on every network.

Subscription updates may overwrite direct config edits. If your client offers an override or config merge option, use it to change DNS fields. After saving, reload the config and check the logs for YAML parse errors, listener failures, or upstream timeouts. A toggle shown as enabled in the UI doesn't confirm that the setting is active.

fake-ip-filter: Exclude only domains that need real addresses

With the usual filter semantics, domains matched by fake-ip-filter aren't assigned a Fake-IP and instead use real DNS resolution. mihomo also supports changing how matches work with fake-ip-filter-mode. If your config uses this field, check the documentation for your current version and the actual setting—don't assume the default blacklist behavior applies.

Find the specific domain before adding a filter

• LAN admin pages: First check the hostname the device actually uses, such as nas.home.arpa, then add an exception for that name or the required suffix.
• Internal company services: Confirm that your corporate DNS can resolve internal domains. If needed, use nameserver-policy to route those queries to a corporate resolver.
• Apps that require real DNS results: Find the failing domains in the logs and add them one at a time, leaving Fake-IP enabled for other domains.

+.lan matches domains associated with that suffix; it is not a universal way to identify local devices. .local is commonly used for mDNS, which relies on multicast discovery. Adding +.local to the filter won't turn a standard upstream DNS server into an mDNS relay. If printer discovery fails, also check the app's discovery method, firewall, and network segment.

A filter rule is not a direct-connection rule. It only determines whether DNS returns a synthetic address; it does not route the connection to DIRECT. If a NAS domain should connect directly, add a separate rule for that domain. If only corporate DNS knows the real address, make sure the right resolver is selected too. Expanding the filter to cover every domain weakens Fake-IP without necessarily fixing the actual routing issue.

How TUN, system proxy, and encrypted DNS work together

Fake-IP is a DNS mode; TUN is a way to capture traffic. They are separate settings. TUN is generally better suited to capturing connections apps make to synthetic addresses, while the system proxy mainly affects apps that follow Windows proxy settings. Enabling the system proxy alone doesn't ensure every app's DNS queries and connections pass through the core.

Check these four points along the request path

1. Windows DNS: In Windows 11, open Settings → Network & internet → the current connection's Properties → DNS server assignment, and check which resolver is in use. Wording may vary slightly between Windows versions.
2. Client TUN: Confirm that the virtual adapter is up, the service is running, and the routes cover the Fake-IP address pool in use. If your client requires service permissions, install its service first.
3. DNS hijacking: Check tun.dns-hijack in the active config. Hijacking traffic on port 53 won't automatically capture every app's DoH requests.
4. Browser Secure DNS: In Microsoft Edge, open Settings → Privacy, search, and services → Security, then check the Secure DNS setting. On managed devices, this may be controlled by policy.

If a browser queries an external DoH service directly, it may get a real IP and bypass the core's Fake-IP mapping. The site may still load, but the connection might not have the DNS mapping you expect. Domain sniffing can sometimes fill in the missing information, but it can't recover domains from every protocol. For diagnosis, temporarily disable the app's own Secure DNS and compare results. Once you identify the cause, decide whether to use a single DNS path or keep separate resolution.

Verify on Windows: check DNS queries, connections, and logs separately

First check whether the core's DNS responds as expected, then test the app's connection. For the port 1053 listener shown above, open nslookup in PowerShell or Command Prompt and enter the following commands in order. The interactive port setting applies only to this test; it won't change your Windows adapter's DNS settings.

nslookup
server 127.0.0.1
set port=1053
set type=A
example.com
exit

If no filter rule matches and the config has loaded correctly, the answer should fall within the configured Fake-IP pool. Don't expect a particular final octet. If the query times out, first check that DNS is enabled, the listener address matches, and the core logs show no errors. If it returns a real IP, check the filter rules and the active enhanced-mode setting.

Clear stale state after switching modes

ipconfig /flushdns

This command clears the Windows DNS client cache; it does not clear every browser cache, app connection pool, or core mapping. After switching between Fake-IP and redir-host, close old connections in affected apps and restart them if needed. If reloading the config invalidates mappings while an app still holds an old synthetic address, connections may fail temporarily.

Next, open the client's Connections page and check the destination domain, matched rule, policy group, and outbound node. If DNS returned a synthetic address but there's no matching connection entry, focus on whether traffic is reaching the core. If the connection is listed but fails, check real DNS resolution, node connectivity, and outbound errors. Don't use ping alone to judge whether web proxying works: ICMP and a browser's TCP or UDP requests take different paths.

LAN conflicts and choosing a mode

If a VPN, lab environment, or corporate network already uses addresses in 198.18.0.0/15, Fake-IP routes may conflict with real destinations. Run route print first and check the destination networks, interfaces, and metrics, then confirm how those addresses are used in the VPN config. Don't delete a system route just because it uses a reserved address.

When changing fake-ip-range, confirm that the new range won't conflict with real networks and that capture routes and exclusion rules are updated too. Don't change it to an address range already used by your home LAN. If you can't reconcile the corporate VPN and virtual adapter policies, switching to redir-host can help with compatibility testing—but still verify domain rules, DNS quality, and access to internal services.

Fake-IP is a good first mode to test on Windows when domain-based routing is the priority and DNS and connections can be fully captured. For networks that need real DNS answers, rely on special LAN discovery, or are governed by corporate policies, start with domain-specific exceptions. If exceptions aren't enough, evaluate redir-host. Choose based on actual request paths and app compatibility, not on the assumption that one mode works best for every network.