Clash Fake-IP Mode: How It Works, How It Compares to redir-host, and When to Use It

1. DNS Mode and Traffic Capture Are Separate Settings

dns.enhanced-mode controls how the core responds to DNS queries; the system proxy and TUN control how app connections reach the core. Neither replaces the other. Enabling Fake-IP does not mean all system DNS requests are being captured, and enabling TUN does not guarantee that a browser’s built-in encrypted DNS will be resolved by the core.

This guide focuses on Clash clients using the mihomo core. Behavior can vary across older Clash versions, core forks, and client-side overrides. Before making changes, back up your current configuration, note the core version, and check the dns section in the active runtime configuration—not just the original subscription file.

• System proxy: When an app sends a domain name to an HTTP proxy, the core can receive the destination name directly, without relying on a local Fake-IP mapping.
• TUN: Captures IP packets from apps. DNS interception and the mapping table are especially important for recovering the original domain name.
• DNS listener: For example, 127.0.0.1:1053 is simply where the core accepts queries. The system still needs a suitable forwarding or interception path to send queries there.

To verify that a setup is working, check separately where DNS queries go and where subsequent connections go. The client’s main toggle alone cannot confirm that both paths are aligned.

2. How Fake-IP Assigns Addresses and Recovers Domains

Fake-IP works by mapping domain names to synthetic IP addresses. When an app requests an IPv4 address for a domain, the core can assign an address from the pool specified by fake-ip-range and return it without first waiting for the domain’s real A record. A common pool is 198.18.0.1/16, which belongs to reserved benchmarking address space—not the public address of a website.

1. The app queries example.com, and the request reaches mihomo DNS.
2. The core returns a synthetic address from the pool and records its mapping to example.com. The specific address depends on the current runtime state and should not be hard-coded.
3. The app connects to this synthetic address, and the connection reaches the same core instance through TUN or another capture path.
4. The core looks up the mapping to recover the domain, then uses its rules to select a direct or proxied outbound.
5. A direct connection usually still needs to resolve the real destination address. If a proxy outbound supports forwarding domain names, it can pass the domain to the remote end for resolution. The exact behavior also depends on the rules, proxy protocol, and related DNS settings.

Why It Can Sometimes Reduce Waiting

For connections that can be routed by domain and pass that domain to a proxy outbound, the local system does not need to resolve the destination’s real IP first. Slow or disrupted local DNS therefore does not necessarily block the initial connection. Fake-IP does not eliminate proxy handshakes, remote DNS lookups, or server response time, and it cannot guarantee faster loading for every site.

Why Losing the Mapping Can Break Connectivity

A synthetic address is only meaningful to the core that holds its mapping. If an app caches an old address and the mapping is lost when the core restarts, later connections may not be able to recover the domain. Switching clients or DNS modes, or routing traffic through a different gateway, can cause similar issues. To fix this, trigger a new DNS lookup rather than adding a regular direct rule for the synthetic address.

3. How redir-host Differs in Lookup Timing and Rule Matching

With redir-host, the core typically queries an upstream DNS server first, then returns the real address to the app. For queries handled by its own DNS, the core uses the results to track domain-to-IP associations and help recover domains for later connections. Its compatibility advantage is that apps still see real addresses, but a real IP and a domain do not always have a one-to-one relationship.

Rules can also change when DNS resolution happens. Even with Fake-IP enabled, the core may still resolve a domain when a rule requires the destination’s real IP. The no-resolve option on rules such as IP-CIDR can prevent that rule from triggering a lookup, but it is not a global switch that disables resolution for the entire connection. Check rule order, whether the real IP is already known, and how other rules behave.

If an app connects directly to an IP without first querying the core for a domain, neither DNS mode can reliably infer the original name. Traffic sniffing may extract a domain from some protocol handshakes, but it is not a substitute for DNS mappings and does not cover every encrypted protocol.

4. Fake-IP and DNS Leaks

A DNS leak generally means a query did not follow the intended resolution path—for example, a query that should use a specified resolver is sent to the DNS server provided by the access network. Fake-IP can reduce local resolution of some domains routed through a proxy, but it is not a universal leak-prevention switch. redir-host does not necessarily leak either. Whether a leak occurs depends on which queries are captured, the upstream protocol, and the selected outbound.

• Browser Secure DNS: A browser may query an external resolver directly over HTTPS, bypassing system DNS. To troubleshoot, temporarily disable this feature and compare the results.
• Standard UDP/TCP DNS: DNS typically uses port 53. TUN DNS interception can capture eligible requests, but encrypted DNS over HTTPS on port 443 or TLS on port 853 cannot be handled with simple port 53 rules.
• IPv6: Checking A records alone is not enough. Also check AAAA queries, IPv6 routing, and the addresses apps actually use. An IPv4 Fake-IP pool does not prove that IPv6 traffic is being captured too.
• Bootstrap and proxy-node resolution: Encrypted DNS service domains and proxy server hostnames may use separate resolution paths. Check fields such as default-nameserver and proxy-server-nameserver.

DoH encrypts queries between your device and the resolver, but it does not automatically route that connection through a proxy or prevent the resolver from seeing the domain. A DNS test site reporting a provider only identifies the resolver it observed. Also check core logs and packet captures to verify the target resolver and actual outbound.

5. Configuring fake-ip-filter and Handling LAN Exceptions

fake-ip-filter specifies which domains should not receive the usual Fake-IP response. This example explicitly uses mihomo’s blacklist filter mode: domains that match the list receive real DNS results, while other domains can still be assigned synthetic addresses. If an older core does not support fake-ip-filter-mode, check the documentation for that version before using this field.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "*.home.arpa"
    - "router.home.arpa"
  nameserver:
    - 223.5.5.5
  nameserver-policy:
    "+.lan": 192.168.1.1
    "+.home.arpa": 192.168.1.1

This example illustrates how the fields relate; it is not a subscription file that can replace your entire configuration. 192.168.1.1 is assumed to be the router that resolves internal domains. Replace it with the internal DNS address used on your network before applying the example. The public resolver shown uses standard DNS to make the flow easier to observe; this is not a recommendation for encrypted or proxied DNS. listen does not change system DNS automatically.

Filtering, Resolution Policies, and Outbound Rules Each Do a Different Job

• fake-ip-filter: Determines whether matching domains bypass synthetic addresses; it does not select a direct connection.
• nameserver-policy: Selects a DNS server that can resolve internal domains. Public resolvers usually do not know private records for corporate or home networks.
• rules: Selects the connection’s outbound. Even if an internal service resolves to a real IP, it still needs a suitable direct rule and a reachable route.

For example, you can add the following two rules before a broad proxy rule. They only control outbound selection; they do not replace DNS policies. Do not delete existing rules just to match this example:

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - DOMAIN-SUFFIX,lan,DIRECT

Why LAN Services Are Often Affected

NAS devices, printers, casting, and some game discovery features check whether a destination is on the local subnet or share DNS results with other devices. If an app receives an address in 198.18.0.0/16, it may refuse to connect. Another device without the same mapping cannot use that address either. Start by excluding the internal domains you actually use; do not filter every domain from the outset.

.local is commonly used with mDNS, which relies on multicast discovery rather than ordinary unicast DNS. Adding *.local to the filter list will not restore mDNS automatically. If casting devices are not visible, also check LAN access permissions, multicast forwarding, TUN routes, and the firewall. If the router distributes DNS to other devices, their traffic to synthetic addresses must also pass through the gateway that holds the mappings.

6. Verify DNS Responses and Traffic Capture

First test the core’s DNS using an explicit listener address, then check the system’s default query path. The commands below require the relevant tools to be installed; the query port 1053 must match your runtime configuration:

# Windows: query the core DNS directly
nslookup -port=1053 example.com 127.0.0.1

# macOS / Linux: query the core DNS directly
dig @127.0.0.1 -p 1053 example.com A

# Check whether the internal domain resolves to a real private IP address
dig @127.0.0.1 -p 1053 router.home.arpa A

1. Check the response: In Fake-IP mode, an unfiltered domain should return an address from the configured pool; a filtered internal domain should return a real address from the internal DNS server. If the query times out, first check the listener and whether the core is running.
2. Check the system path: Next, run nslookup example.com without specifying a server, or test with a regular app. A successful direct query to the core does not mean system queries are reaching it.
3. Check connection records: In the client’s connections page or logs, check the domain, matched rule, and outbound. If DNS works but the connection fails, check whether traffic reaches the same core and whether the wrong proxy node was selected.
4. Check IPv6 separately: Query AAAA records and observe which address family the app actually uses. A successful A record lookup alone does not confirm that the entire DNS path is working.

For troubleshooting, you can temporarily set log-level to debug. Restore your usual level when finished to avoid logging large numbers of domains for too long. Before sharing logs, remove subscription URLs, tokens, proxy credentials, and internal hostnames.

7. Switching Modes and Troubleshooting

If your main goal is domain-based routing under TUN, and both DNS queries and connections reach the same core, Fake-IP is worth trying first. If many apps require real IP addresses, internal services are complex, or your environment makes it hard to ensure synthetic addresses follow the right capture path, compare redir-host for compatibility. Choose based on the traffic path, not the mode’s name.

Change one variable at a time

1. Back up the configuration and note the current enhanced-mode, DNS upstreams, and TUN status.
2. Change only the DNS mode; keep the same proxy node, rules, and test domain.
3. Apply the configuration, close old connections, and clear system and app DNS caches. On Windows, run ipconfig /flushdns; browsers and other apps may need to be restarted separately.
4. Test a public domain, an internal domain, and the app you use, in that order. Record whether the failure occurs during lookup, rule matching, or connection setup.

Do not combine permanently disabling IPv6, filtering every domain, and switching proxy nodes into a single fix. Changing several conditions at once makes it harder to identify the cause. See the configuration reference for field details, and use the Getting Started guide to review traffic capture paths.

A working setup should meet three conditions: queries go to the intended resolver, connections reach the intended core, and rules select the intended outbound. Fake-IP and redir-host are simply two DNS handling methods in that chain. Verify each condition separately to distinguish DNS, routing, and proxy-node issues.