Where DNS resolution bottlenecks the proxy chain
To understand what Fake-IP does, first look at the full flow a proxy client goes through without it. When a client visits a domain, the system issues a DNS query, gets the real IP back, and then establishes a TCP connection; if that connection needs to go through a proxy, the core also has to decide which proxy group to use based on rules (domain suffix, IP range, GEOIP, and so on). The catch is that rule matching usually needs the domain name itself, not just the IP resolved afterward—if the DNS query step is also routed through the proxy or intercepted, one or even two extra network round trips get added before the first packet is even sent, and this delay gets amplified on every new connection once TUN mode takes over all traffic.
There's another mismatch: many routing rules are written as domain rules (like DOMAIN-SUFFIX), but the operating system forwards traffic at the IP packet layer. When TUN mode intercepts traffic at the network interface level, it only sees the destination IP—and if that IP is the real address resolved by the ISP's DNS or the proxy node itself, the core loses track of which domain the connection was originally for, so the rule engine can no longer match by domain.
Fake-IP's mapping mechanism: placeholder virtual addresses
Fake-IP's approach solves both problems at once: when the client sends a DNS query, the mihomo core doesn't perform a real resolution—instead, it picks an unused address from a reserved private subnet (commonly configured as 198.18.0.0/16) and returns it to the client right away, while building an in-memory "virtual IP ↔ domain" mapping table. Once the client gets this fake address, it immediately opens a connection; the TUN interface intercepts this destination IP, the core looks it up in the mapping table to find the real domain, and the rule engine matches against that domain as usual to pick a proxy node. The actual domain resolution happens asynchronously at the same time the connection is established, handled by the proxy node or the core itself, without eating up a separate round trip.
This whole process is transparent to the client—the application has no idea it received a fake address; it just sends packets to that IP. This is exactly why Fake-IP noticeably shortens first-packet time: the DNS query step becomes almost a local table lookup instead of depending on network latency.
Lifecycle of the mapping table
- Mappings live in memory, typically with a TTL; entries unused for a while get reclaimed and reassigned to new domains.
- Repeated queries for the same domain within a short window reuse the same virtual IP, keeping the address stable within a session.
- The virtual subnet has limited capacity—under long-running sessions with a very large number of distinct domains, address reuse can occasionally cause brief mapping mix-ups; restarting the client or clearing the DNS cache resolves this.
Fake-IP vs. Redir-Host: behavioral differences
Redir-Host is an earlier approach to DNS handling: the client's DNS query is forwarded directly to a real upstream server, the real IP is returned to the client, and the core then redirects that real IP, relying on a "real IP ↔ domain" reverse lookup table to recover domain information for rule matching. Its advantage is that the client always holds a real address, so compatibility issues are rare; its drawback is that the DNS query step isn't shortcut at all—the usual resolution latency is fully incurred—and because the reverse table depends on real IPs staying stable and non-overlapping, it can go stale quickly for domains behind a CDN that rotates IPs often.
| Comparison | Fake-IP | Redir-Host |
|---|---|---|
| Address seen by client | Fake address in a virtual subnet | Real resolved address |
| DNS query latency | Near-local table lookup, almost no delay | Waits for real upstream resolution |
| Basis for domain matching | Core-maintained virtual IP mapping table | Real IP reverse lookup table |
| Sensitivity to CDN IP rotation | Insensitive—always matches by domain | More sensitive—reverse table can lag |
| Compatibility risk | Some apps are picky about unusual address ranges | Generally good compatibility |
In short, Fake-IP trades a not-quite-real client-side address for speed and stability against CDN behavior. The trade-off is that a small number of apps that actively validate IP legitimacy—beyond what certificate pinning already covers—may misbehave.
Scenarios that need exclusions or whitelisting
Fake-IP has no effect on the vast majority of browsing, streaming, or download traffic, but the following scenarios deserve attention. Typically you exclude the relevant domains from Fake-IP handling via the fake-ip-filter setting, routing them to real DNS resolution instead:
LAN devices and internal services
When accessing a router's admin page, a NAS, a printer, or an internal company system whose domain resolves to a LAN address, if Fake-IP takes over, the client gets a fake address, and the core then has to decide whether that should go direct or through the proxy—any misstep in that chain can break the connection. Most distributions already include common LAN domain suffixes (like .lan, .local) and private IP ranges in the default filter list; for self-hosted internal domains, add them manually.
Online gaming and P2P applications
Some multiplayer games, P2P download tools, and LAN discovery protocols rely on real IPs for peer connection negotiation, or validate that DNS results look legitimate—getting back a reserved-subnet address like 198.18.0.0/16 can cause them to reject the connection or fail matching. Domains used by these apps usually need to go into the fake-ip-filter whitelist, or the entire app should be set to bypass the TUN interface and go direct.
System-level probes and carrier-bound services
Some carrier broadband authentication flows and IoT cloud pairing processes check whether the resolved IP falls within a specific range, and treat a fake address as invalid. If a service shows "internet works but the feature is broken," check whether Fake-IP is the cause before deciding whether to whitelist it.
Config example and troubleshooting steps
Using the mihomo core as an example, a typical DNS section looks like this—pay close attention to enhanced-mode and fake-ip-filter:
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.0/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "+.stun.*.*"
- "+.stun.*.*.*"
- "time.*.com"
- "*.market.xiaomi.com"
nameserver:
- 223.5.5.5
- 8.8.8.8
When troubleshooting a suspected Fake-IP-related issue, follow this order:
- Confirm the issue only shows up under TUN mode or rule mode, and works fine on direct mode—that basically confirms it's related to DNS handling;
- Check the core's logs or the client's connection detail panel to see whether the destination address falls within a reserved range like 198.18.0.0/16, confirming Fake-IP is in play;
- Add the domain or a wildcard pattern for it to fake-ip-filter, restart the core or reapply the config, and retest;
- If the domain isn't fixed (for example, a carrier probe service that changes frequently), consider setting the entire app, or the LAN subnet it lives on, to direct instead of adding filter rules one by one.
When Fake-IP should be the default choice
For everyday use, Fake-IP should stay on as the default, because it measurably reduces connection setup time for the vast majority of traffic—the difference is even more noticeable when switching nodes frequently or visiting a wide variety of domains. Only handle a small set of domains separately once you've identified a specific, reproducible connection issue caused by a reserved-range address—don't disable Fake-IP entirely and fall back to real resolution, since that makes every connection pay the full DNS round-trip cost again, which isn't worth it. Understanding the mapping mechanism lets you keep the speed advantage while still accommodating the handful of services that are sensitive to address authenticity.