Fake-IP vs. redir-host

DNS mode and traffic interception are separate

dns.enhanced-mode determines how Clash's built-in DNS answers domain queries. fake-ip returns a virtual address mapped to the domain, while redir-host returns the real address resolved by an upstream server. Neither replaces rule or global mode, nor determines which proxy node a connection ultimately uses.

Traffic interception is a separate layer. The system proxy generally affects only apps that honor proxy settings; TUN captures more IP traffic through a virtual network interface and routing. Check separately whether DNS queries reach the core and whether app connections are routed back through it. Changing the configuration to Fake-IP alone does not automatically proxy every app.

• Want to preserve domain names for rule matching, with both DNS and connections handled by the core? Start by testing Fake-IP.
• Does an app require real IP addresses, or do you need local network device discovery? Try targeted exclusions first, then evaluate redir-host.
• Experiencing timeouts? First determine whether the issue is DNS, routing, or the outbound connection. Don't change the mode, node, and rules all at once.

How Fake-IP virtual addresses work

Fake-IP works by mapping domains to virtual addresses; it does not permanently rewrite a website's address. A commonly used address pool is 198.18.0.1/16, within the reserved benchmarking range—not a public address where websites are hosted. The proxy core must interpret these addresses; they cannot be sent to the internet as ordinary destinations.

1. An app requests a domain lookup, and the query reaches Clash's built-in DNS.
2. The core assigns or reuses a virtual address from the pool and stores the domain mapping. For eligible A queries, it usually doesn't need to wait for the domain's real A record.
3. The app connects to that virtual address, and an interception path such as TUN routes the connection back to the core.
4. The core retrieves the domain from the mapping, matches the rules, and sends the connection to the appropriate outbound. Direct connections usually still need the real destination resolved; whether a proxy outbound resolves it remotely depends on the protocol and implementation.

Why the first connection can sometimes be faster

With a traditional setup, a connection may have to wait for a real DNS answer first. Fake-IP can reduce that wait and make domain information more readily available for rule matching. That doesn't mean every request is faster: proxy handshakes, TLS, remote DNS resolution, and server response times still apply, and IP-based rules may trigger real DNS lookups.

Seeing a 198.18.x.x DNS result doesn't mean the website is down, and it isn't your actual exit IP. Pinging this address won't tell you how fast a proxy node is. Test a real connection to the service and check the core's connection panel for the matched rule, policy, and any errors.

How redir-host resolves domains—and its limits

With redir-host, the built-in DNS queries the configured upstream resolver and returns the real address to the app. The core can record the relationship between a resolved domain and its IP to help identify domains in subsequent traffic. However, multiple domains can share an IP, and apps may bypass built-in DNS, so this association can't always recover the original domain uniquely or completely.

Real addresses work better for some apps—for example, when software compares resolved addresses, passes an IP directly to another process, or a device must access a specific local network address. But returning a real IP doesn't guarantee a direct connection. If TUN captures the traffic, rules still determine the outbound.

Neither mode is a DNS leak protection switch. Apps with their own DoH, unhandled IPv6 traffic, and programs that query external DNS directly all need separate troubleshooting. A DNS test in one browser that shows a particular resolver doesn't prove every app uses the same query path.

Fake-IP setup and requirements

The example below shows only the dns section to merge into an existing configuration; it does not include proxies or proxy groups. Keep the rest of your subscription configuration. If your client supports overrides or configuration merging, make changes through its persistent settings so the next subscription update doesn't overwrite them.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.local"

• The 1053 value for listen is the example DNS listening port used in this article, not an HTTP or SOCKS proxy port. It listens only on the loopback address and does not provide DNS services to your local network.
• default-nameserver is used for bootstrap lookups, such as resolving the hostnames of DNS servers. These regular DNS bootstrap queries are not encrypted like DoH.
• nameserver specifies the regular upstream resolvers. Using an HTTPS URL doesn't mean all DNS traffic automatically goes through the proxy; check the actual routing path.
• Standard operating system DNS settings usually can't specify port 1053 directly. For production use, configure DNS interception in your client, TUN DNS hijacking, or a local forwarder. Entering 127.0.0.1 alone does not complete the setup.

To compare with redir-host, temporarily change enhanced-mode to redir-host and keep everything else the same. The Fake-IP address pool and filter list will no longer assign virtual addresses. Back up your configuration before reloading it. If your client manages DNS, verify that the generated runtime configuration actually changed.

Targeted exceptions with fake-ip-filter

With the commonly used default blacklist behavior, fake-ip-filter means “don't assign Fake-IP to these domains; return their real DNS results”—not “don't proxy these domains.” The rules determine whether traffic connects directly. Some mihomo versions support other filter modes, so check that whitelist mode isn't enabled before copying a list.

Start with specific domains, then widen the scope

Suppose your home NAS uses nas.home.arpa, and an app refuses to connect after receiving a virtual address. Add that exact domain first. If other devices in the same domain have the same issue, broaden the pattern using syntax supported by your core. In common mihomo matching behavior, +.home.arpa matches the root domain and its subdomains; don't assume every older core supports this syntax.

dns:
  fake-ip-filter:
    - "localhost"
    - "nas.home.arpa"
    - "+.home.arpa"
    - "*.lan"
    - "*.local"

This is a targeted change to merge into the existing dns section above. Don't add a second dns key at the YAML top level. Use either the exact entry or a wildcard that covers it, as needed; remove redundant entries from long-term configurations.

Filtering doesn't provide answers for internal DNS

After adding a NAS domain to the filter list, the upstream resolver still needs to know its real address. Public DNS servers generally don't know about home network domains. Forward those queries to your router or internal DNS server, using nameserver-policy for domain-specific resolution if needed. Without a suitable upstream, filtering turns a virtual-address compatibility issue into a DNS resolution failure.

.local is commonly used by mDNS, which relies on multicast within the local network. Adding *.local only prevents those queries from receiving virtual addresses; it doesn't make the core perform mDNS discovery on behalf of the system. Printers and casting devices may still need multicast discovery and a working local network route.

Check DNS answers and the connection path

Troubleshoot in three steps: confirm the runtime configuration, query the built-in DNS directly, then inspect the app's connection. Don't rely only on the configuration editor or whether a page opens in your browser.

1. Query port 1053 directly

In an environment with dig installed, run the two commands below. They explicitly query port 1053 on the loopback address, so differences in system DNS settings won't send the test to another resolver.

dig @127.0.0.1 -p 1053 example.com A +short
dig @127.0.0.1 -p 1053 nas.home.arpa A +short

With Fake-IP enabled, an unfiltered domain should usually return an address from the configured pool; the specific address can vary. A NAS domain should return its real address only if the filter matches and the internal upstream is available. If the query times out, check that DNS is listening and that the configuration loaded without errors. If it returns a real public address, check the mode, filter rules, and client overrides.

2. Check rules and outbound connections

Open the client's connection panel, visit the site you're testing, and check the destination domain, matched rule, and policy. If you get a virtual address but see no corresponding connection, check whether traffic bypassed the core, routing conflicts exist, or the app is using that address on another device without interception.

3. Clear old state and test again

After switching modes, an app may keep using a cached answer or an existing connection. Quit the app, clear the system DNS cache, then reopen it. On Windows, run ipconfig /flushdns; on Linux with systemd-resolved, run resolvectl flush-caches. An app's own DNS cache may not be cleared with the system cache.

If profile.store-fake-ip is enabled, some cores persist mappings. This can help restore existing mappings, but it won't fix every timeout. Before changing the address pool, clear old mappings and reconnect using the method supported by your client. Don't delete configuration files if you're unsure what they contain.

Choose a mode based on the symptoms

• Websites and everyday apps work normally: Keep the current mode. There's no need to keep switching just for a vague promise of “more speed.”
• Only the NAS, printer, or local domain is failing: Check the filter, internal DNS, and local network routing first. Don't rush to switch the entire setup.
• An app explicitly rejects virtual IPs: Add an exception for the domain it actually queries. If it depends on many domains and maintaining exceptions becomes difficult, test redir-host.
• All Fake-IP connections time out: Check routing and interception for the virtual address range first. A successful DNS response doesn't mean the connection reached TUN.
• Some sites resolve to unsuitable addresses with redir-host: Check whether the DNS resolution route matches the proxy exit route. Set resolution policies by domain instead of blindly adding more upstream servers.

Judge the result by repeatable behavior: on the same device, through the same node, and for the same domain, check the DNS answer, matched rule, and connection success. Fake-IP focuses on preserving domain information through mappings and changing when resolution happens; redir-host focuses on returning real addresses to apps. Choose based on how traffic is intercepted and what the apps require—not on the assumption that one mode is right for every situation.