How Clash Fake-IP Mode Works: How a Virtual IP Pool Speeds Up DNS and When to Use It

What Fake-IP Does: Return a Mapped Address, Then Handle the Connection

With Clash Fake-IP mode enabled, a DNS query may return an address such as 198.18.0.2. This is neither the target website’s public IP address nor a proxy server address. It’s a temporary mapping assigned to the domain by the core. The app then connects to that address; the same core intercepts the traffic, looks up the domain from the mapping, applies routing rules, and establishes the outbound connection.

This separates “giving the app an address it can connect to” from “resolving the real server address.” With a proxy outbound that accepts domain names for remote resolution, the client doesn’t need to resolve the target domain locally before the app can start connecting. The main benefit is less DNS wait before a connection begins—not higher bandwidth or a guarantee that every page will load faster.

Why 198.18.0.0/16 Isn’t a Public IP Range

198.18.0.0/15 is an IPv4 range reserved for network device benchmarking, not for ordinary public services. Clash configurations commonly use 198.18.0.0/16 from this range, often written as fake-ip-range: 198.18.0.1/16. This prefix contains 65,536 IPv4 addresses, but that doesn’t mean the core guarantees support for that many simultaneous mappings.

The core assigns, tracks, and reclaims addresses in the pool. A domain mapped to 198.18.0.2 today may get a different address after a restart or mapping change. Don’t put virtual addresses in long-term static routes, server allowlists, or fixed app settings. If your corporate network, test environment, or another VPN uses this range, check for route conflicts before changing the pool.

Fake-IP vs. redir-host: Where the DNS Wait Happens

The key difference is “which address the app receives,” not “whether a proxy is used.” Rule and global modes determine how a connection is routed; enhanced-mode determines how DNS is handled. They operate at different layers.

How a Proxied Request Flows

1. redir-host: The app looks up a domain, Clash requests the real address from upstream DNS, then returns the result to the app. The app connects to that address, and routing rules select the outbound.
2. Fake-IP: The app looks up a domain, Clash stores a “domain–virtual address” mapping and returns the virtual address. When the connection reaches the core, it recovers the domain and selects an outbound based on the rules.
3. When the proxy accepts domain names: The domain can be resolved remotely. A direct connection, or a rule that needs the destination IP, may still trigger a local lookup for the real address.

For example, suppose an uncached upstream DNS query takes 120 ms. Fake-IP may let the app start connecting without waiting for that query first. The 120 ms is just an illustration, not a measured speedup or a promise. Actual timing also depends on routing rules, the proxy handshake, remote DNS, and the server response, so it doesn’t mean the whole page will load 120 ms faster.

Fake-IP also doesn’t mean “no DNS at all.” The proxy server may need to resolve domains, direct connections need real addresses, and some IP-based rules need DNS results. If an app submits a domain directly through an HTTP or SOCKS proxy, its request may not use the virtual address mapping process described above.

Minimal Setup: Enable Mappings and Preserve LAN DNS

This example illustrates how commonly used fields relate in Clash Meta (now called mihomo); it isn’t a complete configuration you can use to replace a subscription. Back up your current configuration first, keep your existing proxies, groups, and rules, then merge the DNS fields into a client-supported override. Don’t define two top-level dns keys in the same YAML file.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  fake-ip-filter:
    - localhost
    - '+.lan'
    - '+.local'
    - '+.home.arpa'

• enable: Enables DNS in the core. Changing the mode without enabling DNS won’t create the expected query flow.
• listen: This example listens on local UDP/TCP port 1053 for testing. The system’s default DNS uses port 53; it won’t automatically send queries to port 1053.
• enhanced-mode: Select fake-ip. For a comparison test, switch to redir-host and keep the other conditions the same.
• nameserver: Specifies upstream servers for lookups that need real addresses. The example uses standard DNS without transport encryption; choose servers based on reachability and privacy requirements.
• fake-ip-filter: In the usual exclusion mode, matching domains get real DNS results instead of an address from the pool.

Some mihomo versions provide fake-ip-filter-mode, which changes how the filter list works. This article describes exclusion mode. If your configuration explicitly uses whitelist mode, don’t assume the list means “these domains won’t use Fake-IP.” Bundled core versions and default filter entries also vary by client, so check the configuration that’s actually in effect.

fake-ip-filter Exceptions: Add Domains That Actually Have Problems

What’s commonly called a “Fake-IP whitelist” is usually a list of exceptions that don’t get virtual addresses. Adding a domain to the list doesn’t make it go direct or automatically use the router’s DNS. Routing rules determine whether it connects directly; DNS policy determines where its real address is resolved. Check these settings separately.

LAN Devices and Private Domains

Printers, NAS devices, router admin pages, and internal company services often rely on LAN DNS. For home.arpa or internal domains, add a specific suffix exception and send the lookup to the appropriate local DNS server. Public DNS usually can’t resolve internal hosts; adding a filter entry alone may still result in a nonexistent-domain response.

.local is commonly resolved through mDNS, which uses a discovery mechanism distinct from regular unicast DNS. Adding it to the filter list only prevents Fake-IP assignment. If device discovery still fails, check LAN access permissions, multicast, and TUN routes rather than adding more public DNS servers.

Apps That Validate DNS Results or Share Addresses Across Devices

Some games, voice apps, time-sync tools, and device discovery apps validate DNS results or pass a resolved IP to another device. That device doesn’t have the local core’s mapping, so it can’t connect using the virtual address. Check connection logs to find the specific domain, add a single exception, then retest the full feature.

• Use the narrowest match: If only one service is affected, start with the exact domain it queries. Don’t exclude a large domain suffix right away.
• Test the affected feature: A working webpage doesn’t mean voice chat, multiplayer, or device discovery works. Test the operation that originally failed.
• Don’t exclude entire app categories: Games, NTP, and STUN aren’t inherently incompatible with Fake-IP. Whether an exception is needed depends on the app and how its traffic is intercepted.

In common mihomo domain-matching syntax, +.home.arpa matches the domain and its subdomains. If you’re using an older Clash core, check whether it supports this syntax. After changing filter entries, clear the app and system caches too; otherwise, an app may keep using a virtual address it received earlier.

TUN and System Proxy: Route Virtual Addresses Back to the Core

Fake-IP is a DNS behavior; TUN is a traffic interception mechanism. They can work together, but they aren’t the same setting. TUN is generally better for apps that ignore the system proxy. A system proxy mainly affects apps that actively use the system’s HTTP, HTTPS, or SOCKS settings, and doesn’t guarantee interception of every connection to a virtual address.

Test DNS First, Then Check the Connection Path

1. Confirm the configuration is loaded and the DNS listener is actually bound to 127.0.0.1:1053. If the port is already in use, check for another DNS service or a second running core.
2. Query that port directly and check whether a domain not in the filter list gets an A record from the address pool.
3. Check which DNS server the system or app actually uses. A successful direct query doesn’t prove that the system’s default queries reach Clash.
4. Visit the target and check the connection logs. Confirm that the target domain is recovered and the matched rule and outbound are as expected.

# macOS / Linux: use this if dig is available or installed
dig @127.0.0.1 -p 1053 example.com A

# Compare with the default DNS resolution path
dig example.com A

The first command may return an address from the pool, such as 198.18.0.2; the specific address varies. If the first command returns a virtual address and the second returns a public IP, check the DNS entry point first rather than assuming Fake-IP wasn’t loaded. Browser-encrypted DNS, app-specific resolvers, and caches can also send actual requests through a different path.

In a TUN configuration, dns-hijack can intercept matching DNS traffic. A common target is any:53, but support and coverage depend on the core, platform, and protocol. It isn’t a catch-all for every kind of DNS: DoH over HTTPS port 443 won’t automatically reach the core’s DNS just because traditional DNS on port 53 is intercepted.

Common Issues: Troubleshoot the Pool, Cache, and Rules

The Page Won’t Load After Getting a 198.18 Address

First, check whether the connection appears in the core logs. If it doesn’t, investigate whether the app is bypassing the proxy, TUN routing is inactive, or another VPN has taken over the route. If the domain and policy appear in the logs, check the proxy node, direct DNS, and routing rules rather than switching the entire DNS mode right away.

A Few Apps Stop Working After the Core Restarts

An app may have cached an old virtual address while the core has rebuilt its mappings. First, quit and reopen the affected app, then clear the DNS cache as required by your system. On Windows, run ipconfig /flushdns in a terminal. On Linux with systemd-resolved, use resolvectl flush-caches. These commands may not clear browser or app-specific caches.

Some cores support profile.store-fake-ip to save mappings and reduce inconsistencies across restarts. It won’t fix bypassed DNS, multiple cores maintaining separate address pools, or route conflicts. Don’t add this field to an older core’s configuration without confirming that it’s supported.

Still Can’t Connect After Adding a Filter Entry

Run the query again and confirm that the result changed from a virtual address to a real one. If it’s still from the pool, check the filter syntax, mode, and cache. If it’s a real address, check whether the internal domain is resolved by the right DNS server and whether the connection uses the right outbound. A filter entry only changes how the address is generated; it doesn’t replace routing rules.

When to Keep Fake-IP and When to Compare It with redir-host

• Keep Fake-IP by default: The same core handles DNS and connections, routing is mainly domain-based, and you want to reduce local DNS wait before proxy connections.
• Add a specific exception first: Only a few internal services, device discovery features, or individual apps are affected while everything else works.
• Compare with redir-host: Many apps depend on real IP addresses, or your current setup can’t reliably intercept connections to virtual addresses. Test actual compatibility in both modes.

Change one variable at a time, recording the domain, DNS response, matched rule, and error. First confirm that queries reach the right DNS server, then that connections return to the right core, and finally assess upstream resolution and outbound performance. This makes the cause easier to find than changing the pool, proxy node, and every rule at once, and leaves you with a configuration you can roll back.