Fake-IP vs. Redir-Host: How Clash DNS Modes Work and When to Use Them

The key differences between the two enhanced DNS modes

Fake-IP and Redir-Host determine what address Clash returns to an application after handling its DNS query, and how the subsequent connection is associated with a domain. They are not alternatives to rule or global mode, and they do not determine the proxy protocol. When troubleshooting, inspect DNS responses, traffic interception, rule matching, and outbound connections separately.

The configuration examples below primarily target Clash Meta (mihomo). Traditional Clash, different ClashX cores, and various GUI clients may support different fields and configuration override methods. Check the client’s About page or core information first, then inspect the runtime configuration. Don’t assume compatibility based on the app’s name alone.

Fake-IP: Assign a virtual address, then map it to the domain

How a connection is handled

1. The app queries the A record for a domain, and the query reaches the core’s DNS service.
2. The core assigns an address from the configured virtual address pool and stores a mapping between the domain and virtual address.
3. The app connects to that virtual address, and TUN or another interception mechanism routes the connection back to the core.
4. The core uses the mapping to recover the domain and select an outbound based on the rules. Whether it resolves the real address locally depends on the rules, outbound type, and protocol capabilities.

The commonly used fake-ip-range: 198.18.0.1/16 comes from the reserved benchmarking address space. These are not public addresses for destination websites or proxy node addresses. If a page loads in your browser while system lookups show 198.18.x.x, that is expected with this connection flow.

Fake-IP explicitly maps the address an app is about to connect to back to a domain, so the core doesn’t have to infer the destination from a real IP alone. Multiple domains can share a CDN address, so real IPs and domains don’t map one-to-one; virtual address mappings reduce that ambiguity. But Fake-IP doesn’t guarantee faster requests, and it can’t fix an expired subscription, an unreachable node, or incorrect rules.

Redir-Host: Return the real address and preserve domain associations

Redir-Host resolves the real DNS address first, then returns it to the app. The app sees the actual resolved address, while the core associates it with a domain using observed DNS records and other information. It doesn’t perform a public PTR reverse lookup for every connection; “domain lookup” here mainly means recovering domain context from an existing mapping.

This approach is more straightforward for apps that inspect DNS results, compare interface addresses, or handle network connectivity themselves. However, domain associations may be incomplete if an app uses its own encrypted DNS, connects directly to a hard-coded IP, or sends queries that bypass the core. And when multiple domains share an address, an IP alone can’t identify a unique domain.

Before switching to Redir-Host, confirm it addresses the problem

• Only one printer or internal domain is affected: Add a Fake-IP exception for that destination and configure the correct internal DNS. There’s no need to switch modes globally right away.
• The app explicitly requires real DNS results: Try Redir-Host for comparison, and record which rules match and what addresses DNS returns.
• The proxy node connection times out: Check the outbound address and network reachability first. Changing the enhanced DNS mode may not affect the node handshake.

Why Fake-IP is often used with TUN mode

TUN operates at the system network layer, receiving IP packets routed through a virtual network interface. It’s useful for intercepting apps that don’t use the system HTTP proxy. But IP packets usually don’t carry the original domain. With Fake-IP, the core can recover the domain when it receives a connection to a virtual destination address, which is why it’s often used for domain-based routing with TUN.

These are still independent settings: enabling TUN doesn’t guarantee that DNS queries reach the core, and choosing Fake-IP doesn’t mean every app connection is intercepted. Browser Secure DNS, routes from another VPN, or DNS policies pushed by an organization can send queries and connections along different paths.

mihomo configuration example

This example covers DNS and TUN only. It doesn’t include proxy nodes, policy groups, or complete rules, so it isn’t a ready-to-use subscription. When merging it into an existing config, update the existing sections with the same names to avoid duplicate top-level dns or tun keys.

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

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

Here, 1053 is a local DNS test listener port, not an HTTP, SOCKS, or mixed-proxy port. The example’s upstream DoH address must be reachable under your current network and the core’s DNS outbound policy. If it isn’t reachable, use a resolver available in your environment instead of repeatedly restarting the client.

dns-hijack applies to DNS traffic received by TUN that is destined for a specified port. It doesn’t automatically decrypt DoH requests sent by browsers over HTTPS, nor does it guarantee interception of all local DNS traffic on every system. TUN also requires the appropriate system permissions or service support; if permissions are missing, check the startup logs for errors first.

Configuring fake-ip-filter and LAN exceptions

With the commonly used default blacklist behavior, domains listed under fake-ip-filter don’t receive Fake-IP addresses; they’re resolved through the real DNS path instead. Newer mihomo versions also offer additional fields, including filter modes. If your config explicitly sets fake-ip-filter-mode, check what that mode means rather than assuming the default behavior applies.

Limit exceptions to the domains that actually need them

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "printer.home.arpa"

printer.home.arpa is an example LAN hostname for illustration; replace it with the device’s actual domain. An exact hostname is suitable for a single device, while an entry like *.lan applies to subdomains with the matching suffix. Wildcard boundaries can vary between cores. These strings aren’t regular expressions, so don’t copy them into a rules list without checking its syntax.

• Filtering doesn’t mean direct access: It changes the DNS response so the app doesn’t receive a virtual address. Whether the connection goes direct still depends on the rules and outbound policy.
• Filtering doesn’t choose a DNS server: Internal domains usually need to be resolved by your router or company DNS. If needed, use the core-supported nameserver-policy setting to specify the resolver for those domains.
• Filtering doesn’t replace service discovery: .local often involves mDNS. Printer discovery may also depend on multicast, network adapter selection, and firewall settings. Adding a domain exception won’t necessarily restore discovery.

How to verify a mode change

Change one variable at a time. Save the working config and note the original enhanced DNS mode, upstream DNS, TUN status, and affected domain. GUI clients may override subscriptions with UI settings or override files. After editing the original subscription, confirm the final values changed in the runtime config.

1. Reload the config and check the logs: Confirm the DNS listener and TUN started successfully, with no port conflicts or config parsing errors.
2. Query the core’s DNS directly: On macOS or Linux with dig installed, use the command below to query the example domain.
3. Compare with the system resolver: Then run a query without specifying a server. If the results differ, first confirm that the system query is actually going through the core.
4. Reconnect the app: Quit and reopen the affected app. If needed, clear the system DNS cache to avoid misleading results from an old real or virtual address.
5. Check connection logs: Verify the destination domain, matched rule, and actual outbound instead of checking only whether the page loads.

# Query the core DNS configured above
dig @127.0.0.1 -p 1053 example.com A +short

# Query the system default resolver
dig example.com A +short

In Fake-IP mode, A queries that aren’t filtered should generally return an address from the configured pool. In Redir-Host mode, they should return the real record provided by the upstream resolver. example.com is used to demonstrate the test; for troubleshooting, query the domain that’s actually failing. Don’t use the presence or absence of a virtual IPv4 address in an AAAA query to determine whether Fake-IP is working.

Clear the DNS cache for your operating system

On Windows, run ipconfig /flushdns in Command Prompt. On macOS, use the commands below; the second sends a signal to the system DNS service. Enter your local administrator password when prompted. On Linux with systemd-resolved, run resolvectl flush-caches. For other distributions, use the command for your DNS service.

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Clearing the system cache doesn’t automatically clear the browser’s internal cache, and it won’t restore expired Fake-IP mappings. After switching modes, close existing connections and test again. If stale virtual addresses keep causing problems after the core restarts, check whether the client supports and has enabled persistent Fake-IP mappings.

Common issues and what to check first

Also, a failed ping alone doesn’t prove a website is inaccessible. ICMP is different from the TCP or QUIC requests used by browsers, and how Fake-IP handles ICMP depends on the core and interception method. Verify using a real app request alongside the connection logs.

Choosing a mode and final checks

For setups that rely on TUN and need consistent domain-based routing, start with Fake-IP and add narrowly scoped exceptions only for domains with a confirmed compatibility issue. For apps that depend on real DNS responses, compare results with Redir-Host. Either way, keep the upstream DNS and domain rules configured correctly.

Check four things: who handles DNS queries, what address the app receives, who intercepts the connection, and which outbound the rules select. Gather evidence for all four before changing the enhanced DNS mode, editing the filter list, or fixing routes. For more on proxy ports and routing rules, see the user guide and glossary.