Fake-IP vs. redir-host

DNS enhanced mode determines which address is returned

Mihomo's dns.enhanced-mode mainly controls how its built-in DNS responds to queries and how subsequent connections are associated with domain names. It is not a proxy mode and does not determine whether all traffic is proxied. Rule, Global, and Direct are separate settings; TUN handles system traffic.

Here's the key difference: fake-ip typically returns a synthetic IPv4 address assigned by the core, while redir-host returns the real address resolved by upstream DNS. Both modes require DNS queries to reach the core. Enabling DNS in the config alone won't make the system or browser send queries to it.

How Fake-IP connections work—and their performance limits

A synthetic address isn't the target server's address

A common configuration uses 198.18.0.1/16 as the Fake-IP address range. It falls within 198.18.0.0/15, reserved for network benchmarking. This range isn't publicly routable and isn't a private address range defined by RFC 1918. The core maps each assigned address to the requested domain.

1. An app queries the A record for a domain, and the query reaches Mihomo DNS.
2. The core assigns a synthetic address to the domain and returns it to the app.
3. The app connects to the synthetic address; the connection must pass through the core that holds the mapping.
4. The core recovers the domain, applies the rules, then connects through the selected direct or proxy route.

A synthetic address only works with its corresponding mapping. If an app passes it to a process that bypasses the core, or TUN doesn't capture traffic to that address, the connection may fail. If programs keep accessing 198.18.x.x after the client is closed, the app or system may still have an old result cached.

Less DNS waiting doesn't mean every connection is faster

Fake-IP can defer real DNS resolution until it's needed. If a domain rule matches and the proxy protocol supports sending the domain name, the remote side may resolve the target. With DIRECT, the core still needs the real address. IP-based rules may also trigger resolution, so the rule setup affects the actual benefit.

Fake-IP mainly cuts some DNS wait time before a connection starts. It doesn't shorten the physical route or increase proxy server bandwidth. Game latency, video throughput, and packet loss still depend on the exit node, routing, and protocol. This article doesn't claim a measured speedup: changes during DNS resolution shouldn't be mistaken for overall connection performance.

When to use redir-host

With redir-host, apps receive the real resolved address, and the core keeps DNS-related mappings to help identify the domain associated with a connection. This behaves more like a traditional network for apps that rely on real IPs, but domain attribution isn't always unambiguous: multiple domains can share a CDN address, and one domain can resolve to multiple addresses.

• Worth trying when: An app checks the target IP, passes addresses to other devices, or shares DNS results across network stacks.
• Won't fix: An upstream DNS server returning the wrong address, unreachable internal DNS, an unavailable UDP route, or a connection that never reaches the core.
• Watch out for: Apps with built-in encrypted DNS can prevent the core from seeing regular DNS queries, leaving domain rules without a match to work with.

Sniffing can recover domain information from some TLS, HTTP, or QUIC traffic, but not every protocol exposes a usable domain. Results depend on encryption, the client implementation, and sniffing settings. Don't treat sniffing as a universal fix for domain-routing problems.

fake-ip-filter: exclude only the domains you need to

fake-ip-filter controls which domains don't use synthetic addresses. In blacklist mode, matching domains are resolved normally; other domains can still receive Fake-IP addresses. Mihomo supports other filter modes too, so check fake-ip-filter-mode along with the list itself.

Here's a sample DNS config. The listener at 127.0.0.1:1053 is available only on the local machine. This isn't a complete TUN configuration and won't change system DNS automatically. If your existing config already has dns:, merge these fields rather than adding a duplicate top-level key.

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:
    - '+.home.arpa'
    - '+.lan'
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

Excluding a domain from Fake-IP doesn't make it direct

+.home.arpa matches the domain and its subdomains. It's used here to illustrate handling names on a home network; .lan is another suffix used on some local networks. A filter only changes the DNS response—it doesn't add a DIRECT rule or send queries to your router.

For internal network access, three things usually need to work together: return a real address, query the right internal DNS server, and route the connection through an internal path that's reachable. Doing only the first can still leave public DNS returning a nonexistent-domain error.

DNS settings for LANs and corporate networks

Suppose a home network provides internal DNS at 192.168.50.53, and a device is named nas.home.arpa. Add the following fields under the existing dns: section. This address is just an example; replace it with a DNS server that's reachable on your network.

  nameserver-policy:
    '+.home.arpa':
      - 192.168.50.53

Also add LAN rules to your existing rules: section, before the final catch-all rule. These two examples cover the domain and the sample subnet, respectively. Don't overwrite existing subscription rules or remove policy groups.

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,PROXY

The last line assumes your config already has a policy group named PROXY; use the exact name from your config. no-resolve prevents this IP rule from triggering a DNS lookup just for a match. It won't make an unresolvable internal domain work.

Handle corporate VPNs and .local names separately

• Corporate VPN: Make sure routes to internal DNS go through the corporate VPN. If TUN and the corporate VPN both manage routing, check for subnet conflicts, route priority, and any bypass options provided by the VPN client.
• Short hostnames: Looking up nas may depend on the system search domain. Test with the full hostname first so a missing search domain isn't mistaken for a Fake-IP issue.
• .local: This suffix is commonly used by mDNS, which typically relies on UDP port 5353 and multicast. Adding a regular DNS filter entry won't enable mDNS; check LAN discovery and multicast routing instead.
• Switching networks: Internal DNS may be unreachable when you're away from the office or home network. Keep domain-based routing scoped to internal names rather than sending all DNS queries to an internal server.

Choosing a mode for games and TUN

If websites work but a game won't sign in, that alone doesn't prove Fake-IP is incompatible. Games may use HTTPS for sign-in, UDP for matches and voice chat, and LAN discovery. A system proxy usually can't capture all of this traffic. TUN can capture more IP traffic, but it also needs the right permissions, routes, and UDP support on the exit.

1. Check whether traffic reaches the core. Open the client's connection list or logs, then start the game. If no matching connection appears, check the traffic capture method before changing the filter list.
2. Separate sign-in from gameplay. If sign-in fails, note the authentication domain. If the game disconnects after you join a match, check UDP, the exit policy, and NAT behavior. These issues may follow different network paths.
3. Check whether the app needs a real address. If the logs show that a specific domain fails after receiving a synthetic address, add only that domain to the filter list and test again without changing the exit or other settings.
4. Compare modes last. Temporarily switch to redir-host, reload the config, and clear the cache. A comparison is useful for judging mode compatibility only if the network and exit remain the same.

With TUN, check that DNS hijacking captures the queries you want to test. Regular DNS commonly uses port 53, while browser DoH usually travels over HTTPS on port 443; capturing port 53 alone won't intercept all encrypted DNS. For testing, you can temporarily turn off Secure DNS in the browser. Note the original setting and restore it afterward if needed.

Verify results and restore settings

Check core DNS first, then system traffic capture

If you're using the local port 1053 example above, run these commands on macOS or Linux with dig installed. The first checks whether a regular domain gets a synthetic address. The second checks whether an internal domain gets a real address from the right DNS server. Use a name that actually exists on your network.

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

These commands query the specified port directly. They show how the core DNS responds, but don't prove the system or browser is using it. Next, connect from the app you want to test and check the client logs for the domain, destination address, matched rule, and exit. If direct queries work but browser behavior differs, check browser DNS, the system cache, and the app cache first.

Clear stale state after switching modes

• Back up your current config, and change only the DNS mode or one filter entry at a time.
• Reload the config. If the client offers an option to clear its DNS cache or Fake-IP mappings, use it.
• On Windows, run ipconfig /flushdns to clear the system DNS cache.
• On macOS, run sudo dscacheutil -flushcache, then sudo killall -HUP mDNSResponder. These commands may not clear the browser's own cache.
• Fully quit and restart affected apps so stale connections and addresses don't skew the comparison.

For everyday domain-based routing, Fake-IP is a good starting point when connections pass through the core. If a few internal domains or apps have compatibility issues, add domain-specific exceptions and configure the right resolver first. Consider switching everything to redir-host only if an app consistently needs real IPs, exceptions are hard to maintain, or a controlled comparison clearly points to a mode-specific issue.

To check the traffic capture path, see the connection troubleshooting steps. To distinguish DNS, routing rules, and maintenance settings, read the DNS configuration guide. The key is to identify where the query went, what answer it returned, and which exit handled the connection.