Clash Fake-IP Mode Explained

Make sure DNS queries and traffic both reach the core

Before configuring Fake-IP, check two things: the app's DNS queries must reach the Clash core, and its subsequent connections must also be handled by that core. If you enable DNS settings but let connections go straight through the physical network adapter, an app may receive a synthetic address that isn't reachable on the public internet, leaving pages stuck loading.

1. In the client's configuration details or active configuration, confirm that dns.enable is set to true and dns.enhanced-mode to fake-ip.
2. Check whether you're using the system proxy or TUN mode. The system proxy only covers apps that honor proxy settings. TUN can handle more IP traffic, but still requires the right routes and DNS settings.
3. Open the client's connections panel, visit a new domain, and check whether the domain, matched rule, and outbound are shown. Menu names vary by client, so don't rely only on the home screen's “Connected” status.
4. If you're using Clash Meta (now called mihomo), check the effective configuration loaded by the current core. The original subscription shown in the client's editor may differ from the merged configuration with overrides applied.

How DNS mapping feeds into rule-based routing

Replacing real DNS answers with local mappings

In a traditional flow, an app first queries DNS for the destination's real IP, then connects to that IP. With Fake-IP, the core can assign a synthetic IPv4 address from its pool, such as 198.18.0.2, and store a mapping between the domain and that address. This address is just an example; a query won't necessarily return the same one every time.

1. The app queries the A record for www.example.com.
2. The core records the domain-to-Fake-IP mapping and returns the synthetic address to the app.
3. The app connects to that address, and the connection is routed to the core through a handling path such as the system proxy or TUN.
4. The core uses the destination address to look up the domain, selects a policy group based on domain rules, then connects through the chosen outbound.

The commonly used 198.18.0.1/16 falls within the 198.18.0.0/15 benchmarking address block, which is reserved rather than publicly routable. It is not a “free proxy node” address. If a corporate network, lab, or another VPN uses an overlapping subnet, resolve the routing conflict first.

Why it can reduce delays

For connections that can be matched by domain rules and use a proxy protocol that passes the domain through, the proxy connection can start without waiting for a local DNS lookup of the destination's real IP. Resolution can happen remotely instead, so local DNS is less likely to sit on the critical path.

That doesn't mean every connection will be faster. Direct connections usually still need a real IP, and IP-based rules may also trigger a lookup. Node latency, remote DNS, handshakes, and the destination site's response can all dominate the total time. Fake-IP can't make an unavailable node work or automatically improve latency-test results.

Fake-IP vs. redir-host

redir-host doesn't disable domain rules, and Fake-IP doesn't mean upstream DNS is never queried. Connection metadata, the DNS cache, sniffing settings, and rule order can all affect the outcome. When troubleshooting, check the actual domain and matched rule in the connections panel rather than inferring behavior from the mode name.

If only one game or one NAS is having trouble, try excluding the relevant domain before switching all traffic to redir-host. If many apps depend on real addresses and you can't maintain a practical set of exceptions, consider switching modes and compare results on the same network with the same outbound.

Configuring fake-ip-filter and understanding its scope

With the blacklist filtering behavior used by traditional Clash and mihomo, domains listed under fake-ip-filter are resolved to real addresses instead of receiving Fake-IPs. The list is often called a “whitelist,” but “Fake-IP exclusion list” is more precise. It is not a proxy allowlist and doesn't determine whether traffic goes direct.

This DNS snippet is for testing, not a complete subscription. It uses port 1053 on localhost to avoid taking over the commonly used system port 53. The two public upstreams are only there to illustrate the syntax; replace them with resolvers reachable on your network and suitable for your needs.

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

• listen only sets the listening address. This line doesn't automatically point system DNS to port 1053; the client or operating system still needs to forward or capture DNS traffic.
• ipv6: false simplifies the AAAA response path in this example. It doesn't mean every network should disable IPv6, nor does it disable IPv6 in the operating system.
• '*.lan' matches LAN subdomains covered by that pattern. Where supported by the domain-matching syntax, '+.' can match both the domain itself and its subdomains. Single quotes also keep YAML from misreading the wildcard.
• mihomo also supports extensions such as fake-ip-filter-mode. If the active configuration sets it to whitelist, the list's meaning is reversed. Check core support and the current mode before using it; don't mix snippets meant for different modes.

A subscription update may replace the original file. For persistent changes, use the client's supported override or merge configuration, then inspect the final active configuration. Pay special attention to how lists are merged: some clients replace the entire filter list instead of appending entries.

Which domains should go on the exclusion list?

LAN services and internal DNS zones

NAS devices, printer admin pages, and corporate systems are good places to start. For example, if internal DNS resolves nas.home.arpa to 192.168.1.20 and the app needs to recognize that private address, exclude the name and route its lookup to internal DNS. If your LAN rules and traffic-capture path already work, an exclusion may not be necessary—start with the actual failure.

.local is commonly associated with mDNS. mDNS uses multicast discovery, unlike ordinary unicast DNS. Adding a domain to the filter list won't fix cross-subnet discovery, multicast routing, or firewall issues. If the device's page opens by IP but it doesn't appear in discovery, also check multicast and interface selection.

Apps that explicitly check returned addresses

Some games, device-pairing tools, and network diagnostics use DNS answers for address validation, region checks, or later protocol negotiation. Exclude a domain only after logs or a controlled comparison confirm that Fake-IP is causing the problem. Add one domain at a time and retest after restarting the app; that's easier to troubleshoot than copying hundreds of entries from an unknown list.

• Don't exclude every domain just because it belongs to a site in mainland China. Rules—not Fake-IP addresses—determine whether traffic goes direct or through a proxy.
• Don't use an entire top-level domain as a catch-all fix. A broad exclusion changes the resolution path for a large number of queries.
• Don't assume every node hostname resolution problem is caused by Fake-IP. In mihomo, resolving node hostnames may also involve separate settings such as proxy-server-nameserver.
• Filters are usually configured by domain. Adding a destination IP such as 192.168.1.20 won't fix every kind of LAN access problem.

Verify DNS answers and connection behavior

Back up your configuration before making changes. The commands below query the example listening port directly, so you can test whether the core responds correctly separately from whether the system actually uses it. Run these on macOS or Linux if dig is installed:

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

With this example configuration, the first command should usually return an address in the 198.18.0.0/16 range; the exact address can vary. If internal DNS is wired up correctly, the second should return the internal service's real address. An empty response or NXDOMAIN from a public resolver doesn't prove the filter is broken.

1. Check the response. If it times out, check that the core is listening on 127.0.0.1:1053 and that the configuration loaded successfully. If it returns a real public IP, check the filter rules and the active enhanced mode.
2. Check the app's path. Visit the same domain in a browser and inspect the connections panel. A successful direct query only proves that the test command reached the core; it doesn't mean the browser uses the same DNS path.
3. Check the rule and outbound. Confirm that the expected domain rule and policy group matched. If the domain appears but the connection fails, check the node, destination port, and remote DNS resolution.
4. Record results for comparison. Note the DNS responses, connection logs, and app behavior before and after the change. Change only one thing at a time: the filter list, mode, or DNS upstream.

Don't use ping results for a synthetic address to judge whether a node works. ICMP is different from the TCP or QUIC connections used by browsers, and TUN may handle ICMP differently too. Prioritize testing whether the actual service request succeeds.

Troubleshooting checklist

Some sites still won't load after switching modes

Start by clearing caches. On Windows, run ipconfig /flushdns to clear the system DNS cache, then fully quit and restart the affected app. Browsers, runtimes, and apps may keep their own caches, so clearing the system cache won't remove every stale address. The mapping may change after restarting the core; an app that keeps using an old Fake-IP may fail.

DNS still bypasses the core with TUN enabled

In supported mihomo configurations, a common value for TUN's dns-hijack is any:53. Whether it works depends on the platform, routes, and permissions. This setting mainly handles traditional DNS traffic; it can't decrypt DoH queries sent by browsers over HTTPS. For troubleshooting, temporarily disable the browser's custom secure DNS and compare responses with connection logs, then choose a consistent DNS setup.

A DIRECT rule is set, but LAN devices are still unreachable

DIRECT only selects the outbound; it doesn't provide internal DNS records or resolve subnet conflicts with another VPN. Check in order: whether the internal name resolves to the right address, whether the system has a valid route to it, whether TUN is capturing a subnet it shouldn't, and whether the device's port is reachable.

Choosing which mode to use

For everyday browsing and domain-based routing, Fake-IP is a good starting point. Handle isolated compatibility issues with targeted exclusions; compare against redir-host if many apps genuinely depend on real DNS answers. The deciding factors are whether connections work, the expected rules match, and DNS follows the intended path—not whether an answer looks like a public IP. For more on traffic capture and routing basics, see the rule-based routing guide and port configuration guide.