Fake IP vs. redir-host: How mihomo DNS Enhanced Modes Work and When to Use Them

What DNS Enhanced Modes Change

In a mihomo configuration, dns.enhanced-mode controls how the built-in DNS resolver handles lookups and how subsequent connections are associated with domain names. The common options are fake-ip and redir-host. This setting is not a proxy protocol, nor is it the same as rule mode, global mode, or the TUN toggle.

To understand the two modes, separate three steps: an app looks up a domain, the operating system starts a connection, and the core selects an outbound based on rules. The address returned by DNS affects only part of this flow. Whether traffic ultimately goes direct or through a proxy still depends on the rules, policy groups, and available outbounds.

Fake IP: Preserve Domain Names with Virtual Addresses

From DNS Lookup to Connection

1. An app queries the intercepted DNS resolver for a domain's A record.
2. mihomo assigns a virtual IPv4 address from the configured pool and stores the mapping between the domain and that address.
3. The app receives the address and starts a connection. That connection must reach the same core instance that can resolve the mapping.
4. The core looks up the domain associated with the virtual address, evaluates the rules, and connects to the destination through the selected outbound.

For example, if the address pool is set to 198.18.0.1/16, the app may receive an address from that range. It is reserved for benchmarking—not the website's public IP or the proxy server's address. Don't manually set it as a static IP for a website.

The point of Fake IP isn't to spoof website content; it preserves the domain's identity until the connection reaches the core. Even when multiple websites share the same real CDN address, each can be mapped to a different virtual address, making domain-based rules easier to apply.

Why It Can Reduce DNS Lookup Delays

Returning a virtual address usually doesn't require waiting for the target domain's real A record first. For proxy outbounds that can carry the domain name, the core can pass it to the remote side for resolution, reducing the need to wait for a real lookup on the client. This can shorten some upfront waits; it doesn't eliminate DNS for every connection.

• When traffic matches a direct rule: The local machine usually still needs the real destination address to connect directly.
• When traffic matches an IP-based rule: Rule evaluation may require a lookup, depending on the rule type, order, and whether no-resolve is used.
• When the proxy node uses a domain name: The node itself still needs to be resolved; the target website's Fake IP mapping won't help with that.
• Initial handshake and remote network: TCP, TLS, node load, and remote DNS can still be the main sources of delay.

Faster DNS doesn't necessarily mean faster page loads. Don't treat proxy node latency tests as DNS measurements, or judge the modes solely by how quickly a page opens the first time in a browser.

redir-host: Return the Real Address First

With redir-host, the built-in DNS resolver queries an upstream server and returns the real DNS result to the app. The core can use cached domain-to-address associations to help handle subsequent connections, but shared IPs and multiple domains resolving to the same address make the association less reliable. Sniffing can provide additional domain clues, but not every protocol can be identified.

Here, “real address” means the address returned by the upstream DNS server. It isn't guaranteed to be reachable, optimal, or unaffected by the network environment. Check upstream selection, split DNS, caching, and outbound routing separately.

Minimal Configuration and DNS Interception Boundaries

The DNS snippet below illustrates the fields; it is not a complete subscription configuration. It listens on the local address 127.0.0.1:1053, specifies an unencrypted upstream, and returns real DNS results for a few local domains. Choose an upstream address based on your network and privacy requirements.

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:
    - "localhost"
    - "+.lan"
    - "+.local"
    - "+.home.arpa"
  nameserver:
    - 223.5.5.5

listen only specifies a listening address; it does not automatically change the system's DNS settings. Standard system DNS settings usually accept only a server IP, not a port, so you can't enter 127.0.0.1:1053 in a field that accepts IP addresses only. Use the client's DNS interception, TUN DNS hijacking, or a local forwarder to route queries to this listener.

TUN vs. System Proxy

TUN receives IP traffic routed by the system, while DNS enhanced modes handle DNS; they serve different purposes. The dns-hijack setting in a TUN configuration can intercept matching DNS traffic. For example, the common setting any:53 applies to standard DNS queries; TCP DNS may need to be handled separately using the appropriate syntax. DoH on port 443 isn't automatically sent to the built-in resolver just because port 53 hijacking is configured.

With only the system HTTP proxy enabled, some apps pass the target domain directly to the proxy, while others resolve it locally. Seeing a real IP in that case doesn't necessarily mean the configuration is broken. Conversely, if an app gets a Fake IP but connects to it directly over a path that isn't intercepted, the connection may time out.

fake-ip-filter: Make Exceptions Only for Domains That Need Them

fake-ip-filter controls which domains use a different address response; it's neither an ad-block list nor an outbound rule. In the blacklist mode shown above, domains matching the list don't receive Fake IP addresses; they get real DNS results instead. With whitelist, the list means the opposite, so don't reuse a blacklist unchanged.

• localhost is an example of an exact domain match.
• +.lan covers the domain and its subdomains; it isn't a substring match.
• +.home.arpa can be used for home network domains, but a DNS server still needs to resolve them.
• +.local only affects queries that actually reach the built-in DNS resolver. mDNS typically uses UDP 5353, and multicast discovery isn't fully handled by this list.

Adding a domain to the filter doesn't automatically make it go direct. For a local network service, also check that the relevant rule selects DIRECT, the route can reach the private address, and an appropriate DNS upstream or nameserver-policy can resolve internal records. The filter only controls whether the response is a virtual or real address.

Don't add an overly broad suffix or switch all domains to real addresses just to troubleshoot one issue. Find the specific domain that failed in the connection logs, then add the narrowest possible exception. If your subscription already includes filter entries, check whether the client merges or replaces them when applying overrides.

Apps and Networks That May Not Work Well Out of the Box

Tools That Depend on Real IP Addresses

Network diagnostics, IP geolocation checks, and tools that add resolved addresses to access-control lists may treat a Fake IP as the server's real address, making the results meaningless. To check the real address, resolve the target domain directly or switch to redir-host in a controlled test.

LAN Discovery and Internal Enterprise Services

NAS devices, printers, casting, and enterprise domains often rely on local DNS, multicast, broadcast, or dedicated routing. Returning a real address is only part of the solution. If split DNS for an enterprise VPN conflicts with TUN routing or private address ranges, you may need to adjust what's intercepted; a filter list alone won't fix it.

Apps That Share Resolved Addresses with Other Devices

If an app resolves a domain locally and sends the resulting address to another device to connect, that device usually won't have the corresponding Fake IP mapping. Some peer-to-peer, media, or control apps may work this way, but that doesn't mean all games, video apps, or UDP-based apps are incompatible. Check the actual domain, connection path, and error logs.

Apps with hard-coded real IPs don't perform DNS lookups, so Fake IP filtering can't affect them. Check IP rules, UDP support, routing, and the firewall instead of adding more domain exceptions.

Verify and Troubleshoot: Check the Query, Mapping, and Outbound

1. Check the active configuration: Verify which Profile is loaded and the effective value of dns.enhanced-mode. Remote subscription updates may overwrite direct file edits, so use the client's persistent override mechanism where possible.
2. Test the listener directly: If dig is installed, run the command below to query the example listener directly, bypassing the system's default DNS.
3. Check connection logs: Visit the same domain and see whether the core recorded a connection, associated it with the domain, matched a rule, and selected an outbound.
4. Check for DNS bypass: If a direct query works but the app behaves differently, check browser Secure DNS, built-in app DoH, the system cache, and other VPNs.
5. Change one thing at a time: First, filter only the domain that fails. If that doesn't help, compare with redir-host. Change one variable at a time and keep a restorable copy of your configuration.

dig @127.0.0.1 -p 1053 example.com A

With the Fake IP configuration above, an A query for a domain not on the filter list should return an address from the configured pool. Switch to redir-host and it should return the upstream result. This command only checks the DNS listener and its response; it can't confirm that TUN interception or proxy outbounds are working.

After switching modes, an app may still have the previous virtual address cached. On Windows, run ipconfig /flushdns to clear the system DNS cache, but browser and app caches may require restarting the app. If you clear the mapping but the app continues using an old Fake IP, new connections may still fail.

For a speed comparison, keep the network, node, target domain, and outbound rules the same, and record results with both cold and warm caches. For example, run 10 queries per mode, report the first result separately, then compare the median of the remaining results. This is a testing method, not a performance measurement by this site. Record DNS lookup, connection setup, and page load times separately.

Choosing a Mode and Keeping Your Configuration

• Consider Fake IP first: DNS and app traffic reliably reach the same mihomo core, you need clear domain associations, and your apps don't depend on real DNS results.
• Consider redir-host first: Your workflow needs real IPs, compatibility is the priority, or your network can't ensure that connections to virtual addresses return to the core.
• Use targeted filtering: Most apps work, but a few internal domains or specific apps fail, and you've confirmed they need real addresses.

To retain mappings across restarts, check profile.store-fake-ip in your configuration. Persistence can help prevent issues caused by lost mappings, but it won't fix incorrect routing or guarantee old addresses remain valid after changing configurations, modifying the address pool, or clearing data. Make sure the active configuration, DNS responses, and connection logs all agree.