Fake-IP vs. redir-host in Clash: DNS Modes Explained

First, understand this: DNS mode is not proxy mode

dns.enhanced-mode determines how the core handles DNS queries and associates subsequent connections with domain names. mode: rule determines how connections are routed. These are separate settings. Choosing Fake-IP does not mean all traffic goes through a proxy; choosing redir-host does not mean connections will always go direct.

This guide uses common configuration fields from Clash Meta (now called mihomo). Supported options may vary between older Clash versions and clients, so check the client’s core information to confirm which core is running before editing your configuration. GUI settings may also override the configuration file, so verify the configuration actually loaded by the core rather than relying on the original subscription text.

• DNS layer: Handles domain lookups and returns addresses to applications.
• Traffic entry point: System proxy, TUN, or transparent router interception forwards connections to the core.
• Rules layer: Applies rules in order to select a direct connection, proxy group, or rejection.

Fake-IP must be paired with traffic interception. If an application receives a synthetic address but its connection does not reach the core holding the corresponding mapping, it cannot reach the destination as expected.

How Fake-IP works: return a synthetic address, then connect by domain name

Suppose an application looks up www.example.com. In Fake-IP mode, the core can assign a synthetic IPv4 address from the configured pool and store a mapping from that address to the domain name. When the application connects to that address, the core intercepts the connection, retrieves the original domain, and applies the routing rules.

1. The application sends its DNS query to the DNS service provided by Clash or mihomo.
2. The core returns an address from the pool, such as 198.18.0.2; the specific address assigned can vary.
3. The application connects to that address, and an entry point such as TUN routes the connection back to the same core.
4. The core recovers the domain name, matches the rules, and establishes the actual connection through the selected outbound route.

Why addresses often start with 198.18

198.18.0.0/15 is a special-purpose range reserved for benchmarking network devices, not a public address range for destination websites. The commonly seen 198.18.0.1/16 falls within this range. It is also not one of the RFC 1918 private ranges typically used on home networks. If a corporate network or lab uses the same range, check for routing conflicts first.

Faster lookups don’t mean every request skips DNS resolution

For queries that can use Fake-IP, the core can usually return a synthetic address without waiting for the destination’s real address. This reduces the application’s wait during DNS lookup while preserving the domain name for routing. A direct connection still needs the real address eventually; whether a proxy resolves the domain remotely depends on the protocol and connection method. Initial page load time also depends on handshakes, network routes, and server response, so no fixed speedup can be guaranteed.

How redir-host differs: returns real addresses and supports IP-dependent applications

redir-host queries an upstream DNS server for the real address and returns it to the application, while using DNS query records to maintain associations between domains and addresses. When a subsequent connection reaches the core, these associations can help match domain-based rules. However, associations may be ambiguous when multiple domains share an address, an application uses its own DNS, or DNS caches have different sources.

redir-host is not a “privacy mode,” and Fake-IP does not automatically ensure that all DNS traffic goes through a proxy. Whether DoH or DoT is used, which route carries upstream queries, and whether an application bypasses system DNS are separate concerns. If browser Secure DNS is enabled, queries may bypass the core’s DNS service. Don’t use enhanced-mode alone to determine whether DNS is leaking.

Fake-IP configuration: check the DNS entry point, then set a filter list

The mihomo DNS snippet below illustrates how the fields relate. Merge it into an existing working configuration; it is not a complete configuration with proxy nodes and rules. If the file already contains dns:, edit that section instead of adding a second top-level key with the same name.

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

• listen: This example accepts queries only on the local loopback address at port 1053. It does not change system DNS automatically or listen for devices on the LAN.
• enhanced-mode: Set this to fake-ip to enable this enhanced mode.
• fake-ip-range: Defines the synthetic address pool. It is neither a proxy node address nor an upstream DNS address.
• fake-ip-filter: This example uses the default blacklist behavior, so matching domains receive real DNS results.
• nameserver: This example uses two specific standard DNS servers. Adjust them based on network reachability and your privacy needs.

Some newer mihomo versions support changing the filter behavior with fake-ip-filter-mode. If your configuration explicitly uses whitelist, the list works in reverse, so you cannot apply the exclusion list in this guide as-is. Check field support before moving a configuration between cores.

fake-ip-filter only controls whether DNS returns a synthetic address; it does not add a DIRECT rule. Add suitable routing rules under rules for destinations that should connect directly.

Treat TUN DNS interception and the DNS listen port as separate settings

In mihomo configurations that support the relevant fields, tun.dns-hijack can send standard DNS traffic to the core. For example, the snippet below intercepts queries on UDP and TCP port 53; it does not mean the core can decrypt an application's own DoH traffic. Check TUN permissions, routing, and client overrides separately.

tun:
  enable: true
  auto-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

Don’t treat this configuration as the same entry point as a system proxy. A browser using an HTTP proxy may send the domain directly to the proxy without using local DNS. TUN, by contrast, often needs to intercept the full path from an application’s DNS lookup through its connection to the IP address.

Games, LAN devices, and where to use fake-ip-filter

LAN NAS and printers: make sure local names resolve correctly first

If your router provides nas.home.arpa through standard DNS, exclude that name and send the query to the router’s DNS server that knows the record. Assuming the router’s address is 192.168.1.1, merge the following entries into your existing DNS section:

  fake-ip-filter:
    - 'localhost'
    - '*.lan'
    - '*.local'
    - 'nas.home.arpa'
  nameserver-policy:
    'nas.home.arpa':
      - 192.168.1.1

The router address here must match your current network. A filter list cannot create local DNS records. If you access the NAS directly at 192.168.1.20, no domain lookup is involved, so changing the Fake-IP filter usually won’t help. Check private-network routing, TUN bypass rules, and the firewall instead.

.local is also commonly used for mDNS discovery. Adding *.local to the filter list does not automatically forward mDNS multicast traffic or fix printer discovery across subnets. Troubleshoot “device not found” separately from “known address won’t connect.”

Games and voice chat: filter specific problem domains, not entire categories

Some games, voice apps, and connectivity tests check the address returned by DNS or pass the lookup result to another device. Such workflows may not work with synthetic addresses. Check the logs for the actual domain queried during login, matchmaking, voice chat, or STUN, then add exact domain names to the filter list. Don’t guess a long list of domains based on a service name.

• Login works, but voice chat fails: Check the node’s UDP support, UDP routing rules, and NAT conditions as well. DNS filtering cannot add UDP support.
• Only one test fails: Exclude just the domain used by that test and leave Fake-IP enabled for other traffic.
• Phone uses a proxy shared from a computer: Make sure connections to synthetic addresses from the phone still pass through the computer’s core, which holds the mappings. Pointing the phone’s DNS at the computer alone is not enough.

Don’t add '*' to “fix every compatibility issue.” With blacklist behavior, this makes all matching queries bypass Fake-IP, removing the address-mapping mechanism and making it harder to identify which item caused the original problem.

How to verify a mode change and avoid common misdiagnoses

1. Back up your configuration and change one variable at a time. Save the current configuration, then change only the DNS mode or one filter entry. Don’t also change nodes, rules, and TUN routing at the same time.
2. Reload the configuration. Check the logs for YAML indentation errors, unknown fields, or port conflicts. If loading fails, the core may still be using the previous configuration.
3. Check the DNS response. Run the query below against the listen address used in this guide to confirm that the request reaches the core.
4. Clear old DNS state. Close and reopen the affected application, and clear the system DNS cache if needed. Existing connections and app-specific caches won’t disappear as soon as you edit the file.
5. Check the actual connection. Review the destination domain, matched rule, and outbound route in the client’s connection log to determine whether the issue is with resolution, routing, or the connection itself.

dig @127.0.0.1 -p 1053 www.example.com A

# Windows PowerShell: clear the system DNS cache
Clear-DnsClientCache

# Windows Command Prompt: equivalent command
ipconfig /flushdns

dig requires the relevant tool to be installed on your system. This command explicitly uses port 1053; a standard nslookup command usually tests the system-configured DNS server, which may not be the listener described here. In Fake-IP mode, an unfiltered domain returning an A record from the address pool is expected and is not evidence that public DNS results have been tampered with.

Why am I still connecting to a 198.18 address after switching to redir-host?

Common causes include the application retaining an old address or the client failing to pass the new configuration to the core. First verify the mode actually in use, then close existing connections, clear caches, and try again. If restarting the core clears the Fake-IP mappings while the application still holds an old synthetic address, the connection may fail. Supported cores can persist mappings with profile.store-fake-ip, but this does not replace proper traffic interception.

Do IP-based rules still work?

Fake-IP does not disable IP-based rules. When needed, the core can resolve the real destination address to apply them; the result also depends on rule order, caching, and options such as no-resolve. Don’t use a synthetic address to determine the destination’s region, and don’t add a DIRECT rule for the entire Fake-IP range to fix website access.

Recommendation: prioritize stability for everyday use and handle compatibility issues individually

For everyday browsing, try Fake-IP when traffic interception is clear and DNS queries reach the core. If only a NAS, game login, or specific test has issues, start with a small number of evidence-based filters, along with correct local DNS and routing rules. Test redir-host as an alternative only when an application genuinely depends on real addresses or your setup cannot fully intercept traffic to synthetic addresses.

The real test isn’t DNS lookup time alone; it’s whether the application can reliably complete the full process: domain resolution, rule matching, connection setup, and data transfer. Keep a working configuration and record each change and reproduction step. That makes issues easier to isolate than repeatedly changing multiple settings at once. For initial setup, see the subscription import and configuration guide. If you run into connection problems, consult the troubleshooting handbook.