Fake-IP Mode in mihomo: How It Works, DNS Setup & When to Use It

How Fake-IP works: domains, synthetic addresses, and real connections

Fake-IP is an enhanced DNS mode in mihomo, enabled with dns.enhanced-mode: fake-ip. It returns a synthetic IPv4 address to the application and keeps a mapping between the domain and that address in the core. This is neither the website server’s real address nor a proxy node address; it acts as a connection lookup key for the application.

A common configuration uses 198.18.0.1/16 as the allocation range. This falls within 198.18.0.0/15, an address block reserved for network benchmarking—not a standard range for hosting public websites. Check whether a corporate or test network already uses this space before enabling it; reserved does not mean conflict-free.

1. The application queries example.com, and the query reaches mihomo’s DNS service.
2. mihomo assigns an address from the pool to the domain and stores the mapping. The application might receive 198.18.0.2, but the specific address can vary.
3. The application connects to this synthetic address, and the connection must pass through the same mihomo core.
4. The core uses the mapping to recover the domain, evaluates the rules, and establishes the actual connection through the selected direct or proxy outbound.

What faster resolution and more precise routing actually mean

Less waiting for upstream DNS

For queries that can be assigned a synthetic address locally, mihomo can respond without first waiting for an upstream DNS server to return the website’s real IPv4 address. If the connection later uses a proxy outbound that can pass along the domain, the remote server can resolve it instead. This reduces DNS wait time on some parts of the route; it does not improve node latency, download bandwidth, or server response times.

If a rule selects DIRECT, a direct connection will generally still need the real address. Filtered domains, certain query types, and other operations that require a real DNS result will also use upstream DNS. So Fake-IP does not mean “DNS is no longer used for any connections,” and there is no fixed speed increase that applies to every network.

Preserve domain context for domain-based rules

When traffic is transparently intercepted, the core initially often sees only the destination IP. The Fake-IP mapping lets it recover the original query domain and then match rules such as DOMAIN and DOMAIN-SUFFIX. For example, DOMAIN-SUFFIX,example.com,Proxy matches the domain and its subdomains; Proxy must be the name of an outbound or proxy group that actually exists in the configuration.

• Rules are still evaluated from top to bottom, so an earlier match can determine the outbound first.
• If an application connects directly to a hard-coded IP, there is no corresponding DNS query for Fake-IP to use to recover a domain.
• If an application bypasses mihomo and uses encrypted DNS on its own, the core might not get a mapping. Sniffing can recover some domain information, but it does not work with every protocol.

Fake-IP vs. redir-host

With redir-host, the application receives the real IP returned by upstream DNS, and the core attempts to associate domains with connections using DNS records. It does not “turn off DNS,” and it is not an outbound mode. Both DNS enhanced modes work with rule-based routing; the main differences are which address the application receives and how the core retains domain information.

Choose based on your needs. If you rely on transparent interception and mostly use domain-based rules, try Fake-IP first. If an application needs to see real addresses or cannot handle synthetic ones, use filter rules or switch to redir-host if needed. After changing DNS modes, clear old caches and reconnect; otherwise, test results might still reflect stale addresses.

Minimal setup: test DNS first, then capture system traffic

This mihomo configuration snippet is for local testing, not a complete subscription. It provides DNS only on the loopback address at port 1053; it does not change system DNS settings or enable TUN automatically. Merge it into the appropriate fields in your existing configuration, and avoid declaring dns more than once in the same YAML document.

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-mode: blacklist
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.local"
    - "+.home.arpa"
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

• listen sets the DNS listening address. System DNS settings usually do not accept a custom port, so you cannot enter “127.0.0.1:1053” as an ordinary DNS server address in the system settings.
• ipv6: false narrows the scope of this DNS test; it does not disable IPv6 in the operating system, and it is not a recommended setting for every deployment.
• nameserver specifies the upstream resolver in this example. Make sure it is reachable on your network. Corporate internal domains usually also need an internal DNS server; do not expect a public resolver to return internal addresses.
• fake-ip-filter-mode requires a mihomo version that supports this field. Older Clash forks support different fields, so check which core your client uses and review any configuration-loading errors.

Desktop clients may generate the runtime configuration through overrides or extension settings, and subscription updates may overwrite direct edits. After making changes, check the final dns section using the client’s runtime configuration viewer, then confirm in the logs that the configuration loaded successfully. Saving a file in an editor does not mean the core has applied the new settings.

How to configure fake-ip-filter: real addresses don’t mean direct connections

In the blacklist mode shown above, domains matching fake-ip-filter skip Fake-IP and use real DNS resolution instead. "localhost" specifies a hostname; "*.lan" matches the corresponding subdomains; "+.home.arpa" can match home.arpa and its subdomains. Quote strings containing asterisks so YAML does not interpret them as syntax.

Add specific domains first; consider filtering an entire suffix only if needed

Suppose your NAS uses nas.home.arpa and an application needs its real LAN address. Add the hostname to the filter list, and make sure the domain is sent to your home router’s DNS server for resolution. Adding a filter entry does not automatically identify the right internal DNS server; if queries still go to a public resolver, the domain might still come back as nonexistent.

.local is commonly used by mDNS, which discovers devices differently from ordinary unicast DNS. Adding "*.local" to the filter list only prevents synthetic addresses from being returned; it does not guarantee that printers, casting devices, or other LAN services can be discovered across subnets.

Manage filter lists and outbound rules separately

Adding a domain to the filter list does not automatically create a DIRECT rule. Its outbound is still determined by rules. Conversely, adding a direct rule does not mean you must disable Fake-IP for that domain: the core can recover the domain first, resolve its real address, and connect directly.

How TUN, system proxy, and DNS hijacking work together

Fake-IP operates at the DNS layer, TUN is one way to route traffic through the core, and a system proxy tells applications that honor the setting to use a local proxy port. These are not interchangeable. In particular, when a browser sends the destination domain through an HTTP proxy, the proxy chain might handle DNS resolution, so the browser’s local Fake-IP lookup is not necessarily used.

• System proxy: Best for applications that read the system proxy settings. Games, command-line tools, and background services that ignore those settings might still connect through their usual network path.
• TUN: Captures traffic that matches the routing conditions through a virtual network interface. Check the routes, exclusions, and whether DNS queries reach the core as well.
• DNS hijacking: For example, dns-hijack in a TUN configuration can handle the specified DNS traffic. Hijacking port 53 does not intercept all DoH, DoT, or app-specific DNS resolution.

When multiple network interfaces, VPNs, and corporate security software are active, route priorities might send synthetic-address connections through the wrong interface. Another common issue is running one core on the device and another on the router: the DNS mapping is on the router, but the connection goes to the local core. Separate mappings do not work together automatically; DNS responses and connection handling must use the same traffic interception path.

For the basics, see system proxy setup and rule-based mode. When troubleshooting, change one variable at a time: test DNS first, then traffic interception, and finally the rules and proxy group selection.

How to verify: DNS results, connection logs, and caches

Step 1: Query mihomo’s listening port directly

With the local test configuration above, run one of these commands. On Windows, use nslookup; on Linux or macOS with dig installed, you can use the second command. The test domain must not be in the filter list.

nslookup -port=1053 example.com 127.0.0.1

dig @127.0.0.1 -p 1053 example.com A

If the response falls within the configured 198.18.0.0/16 range, Fake-IP was assigned for that query. If you get a real public IP, check the filter list, the final runtime configuration, and the queried domain. If the request times out, first check whether DNS is enabled, whether the listening port is already in use, and whether the core started successfully.

Step 2: Check the application’s actual connection

After setting up traffic interception, visit the same domain and check the destination domain, matched rule, and outbound chain in the client’s Connections or Logs page. Getting a synthetic address from a query command proves only that DNS assignment worked; the full path is working only when the application connects and matches the expected rule. Do not use the result of ping against a synthetic address to decide whether a website is reachable.

Step 3: Clear caches and test again

On Windows, clear the system DNS cache with ipconfig /flushdns. On Linux systems using systemd-resolved, run resolvectl flush-caches. Browsers and applications might also have their own caches and persistent connections, so close those connections or restart the application. Clearing the system cache does not guarantee that every application cache is cleared.

mihomo’s profile.store-fake-ip: true can persist Fake-IP mappings, but it cannot fix incorrect routing or share mappings across devices. If you rebuild mappings, change the address pool, or switch modes, also clear stale addresses held by applications to avoid a mismatch where an application still has an old address but the core no longer has its mapping.

When not to enable Fake-IP and how to roll back

Some software treats DNS results as real service addresses—for example, embedding them in signaling data, passing them to another device, or using them to detect whether it is on a LAN. A synthetic address could then be sent to a device that cannot access its mapping. Corporate networks, test networks, and some game connection flows also deserve separate testing; don’t enable Fake-IP system-wide and check only whether a browser works.

1. Only one application is affected: Check which domains it uses, whether it has its own DNS, and whether it connects directly to IP addresses. Add filter entries only for domains with a confirmed compatibility issue.
2. Only internal services are affected: Check internal DNS, domain filters, private network routes, and outbound rules. If DNS resolves correctly but the service is still unreachable, investigate routing and access permissions.
3. All applications are affected: Check that synthetic-address connections reach the same core, that TUN routes are active, and that there are no conflicts with another VPN.
4. The application must receive real addresses: Back up the runtime configuration, switch to enhanced-mode: redir-host, reload the configuration, then clear caches, reconnect, and verify the rules.

Finally, keep the privacy boundaries in mind: Fake-IP is not encrypted DNS, and it does not guarantee that every DNS query goes through a proxy. The upstream protocol, DNS outbound policy, app-specific resolvers, and direct rules all affect the actual path. Verify the behavior using query results, routes, and logs—not just the client’s Fake-IP toggle.