Clash Fake-IP Mode Explained: DNS Mapping, Use Cases, and Exclusions

In the DNS configurations of Clash, Clash Meta, and its actively maintained successor mihomo, Fake-IP is an option that is easy to misunderstand. The returned address looks like a real IP, but its main purpose is not to represent the remote server directly. Instead, it lets the kernel recover the original domain when it takes over the connection. Understanding this distinction makes it possible to determine whether a failed connection is caused by DNS, rules, a proxy node, or the application's own network behavior.

Fake-IP is especially useful for configurations built around domain rules and is often used together with TUN mode. It reduces the loss of rule context caused by applications resolving domains too early, but not every device, protocol, or LAN hostname is suitable for mapped addresses. The right approach is not to expand the exclusion list blindly. First trace the path taken by the query and connection, then add filters only for targets that genuinely require a real address.

The Core Problem Fake-IP Solves

A conventional DNS lookup resolves a domain to its real IP address. When the application subsequently connects to that IP, the proxy kernel may see only the destination address, with the original domain no longer present in the connection metadata. At that point, rules such as DOMAIN-SUFFIX, DOMAIN-KEYWORD, and exact-domain matches cannot participate directly and the connection falls back to IP, GeoIP, or catch-all rules. This degradation is especially apparent on content delivery networks hosting multiple sites on the same IP.

Fake-IP has the built-in Clash DNS receive the query, assign a temporary mapped address to the domain, and store the relationship between the domain and that address. The application connects to the mapped address, sending the traffic back through the kernel. The kernel uses the mapping table to identify the original domain and then selects a policy through domain rules. When it actually reaches the remote service, the kernel still resolves an available real address according to the configuration and connects either directly or through the selected proxy.

Many configurations use 198.18.0.1/16 as the default address pool. This range is reserved for benchmarking and is generally not routed on the public Internet. By using an address range that should not be used by public Internet hosts, the kernel can create mappings with a lower risk of colliding with ordinary public targets. If the same range is already used on a local test network, change the address pool to prevent overlapping routing decisions.

Fake-IP vs. Redir-Host

The redir-host mode usually returns the real resolution result to the application, so the connection target behaves more like a traditional network connection. This is more intuitive for programs that depend on a real IP, but whether domain rules match accurately depends on the traffic entry point, sniffing support, and the application's resolution path. Fake-IP actively preserves the domain context through a mapping and is better suited to configurations that need fine-grained domain-based routing.

The Complete Path from DNS Lookup to Rule Matching

When troubleshooting Fake-IP, do not look at just one DNS query. The complete path includes at least six stages: the application sends a query, the built-in DNS replies, the application connects to the mapped address, the kernel restores the domain, rules are matched, and the upstream address is resolved. If any stage bypasses Clash, the result may differ from expectations.

1. The application queries the domain. A browser, game client, or system service requests an A or AAAA record from the configured DNS address. If the query never reaches Clash's built-in DNS, the Fake-IP configuration does not participate.
2. The kernel checks the exclusion rules. If the domain matches fake-ip-filter, the kernel returns the real resolution result; otherwise, it continues by assigning a mapped address.
3. The kernel creates or reads a mapping. It takes an address from the Fake-IP pool and associates it with the original domain. Repeated queries may reuse an existing mapping; the exact lifetime is managed by the kernel's cache.
4. The application opens a connection. The application treats the mapped address as the destination and establishes a TCP or UDP session. The interception path differs between system proxy mode and TUN mode, but the critical requirement is that the connection must enter Clash again.
5. The target domain is restored. The kernel reads the mapping table, restores the domain associated with the queried address, and uses it for rule matching.
6. A policy and resolution path are selected. Rules determine whether the connection goes direct, through a proxy, or to a policy group. When an actual connection is needed, the kernel obtains the remote real address according to the DNS configuration.

This mechanism also explains a common observation: seeing a mapped address when running nslookup from the command line does not mean the request has already gone through a proxy. The DNS response only completes the mapping stage; the eventual policy is determined by the subsequent connection and rule match. Conversely, if an application uses built-in DoH, a fixed IP, or its own DNS channel, the system lookup may never appear, so Fake-IP cannot obtain the domain context by itself.

System Proxy Mode vs. TUN Mode

In system proxy mode, HTTP or SOCKS applications that honor the proxy settings can pass the domain directly to the proxy endpoint, and some scenarios do not depend on Fake-IP. Applications that cannot read system proxy settings may connect directly unless another transparent interception method is in place. TUN mode receives more system traffic at the virtual network interface layer, so it is commonly combined with DNS hijacking, Fake-IP, and routing rules.

TUN does not mean that every DNS query automatically enters the kernel. The operating system may use encrypted DNS, and browsers may enable their own secure DNS. When configuring it, verify the DNS hijacking scope, listening port, LAN sharing method, and system firewall state. If queries go to an external DNS service while connections are intercepted by TUN, the kernel will usually see a real IP, and domain rules may depend on sniffing to recover the domain.

Basic mihomo Configuration

The simplified example below is intended to clarify how the fields relate to one another. An actual client may generate some fields through its interface or merge user overrides with subscription content. Preserve the original configuration before editing, and check the client logs to confirm which file is currently loaded.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "time.*.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

enable controls the built-in DNS, enhanced-mode selects the enhanced mode, fake-ip-range defines the mapped address pool, and fake-ip-filter determines which domains return real results. nameserver lists the primary upstream resolvers. default-nameserver is commonly used to resolve the domains of upstream servers such as DoH and DoT endpoints, so it generally needs resolvers reachable directly by IP address.

The configuration format varies with the kernel version and the way each client packages it. mihomo supports a broad set of DNS fields and rule expressions, but older Clash clients may not recognize every new field. If a subscription is used across multiple clients, first verify the kernel and version assigned to each client. The fact that an interface can save a field does not mean the running kernel has adopted it.

How Upstream DNS Relates to Routing

The choice of upstream DNS affects real-address resolution, contamination avoidance, and connection latency, but it is a separate layer from proxy rules. Resolving a domain through an overseas DoH service does not mean the connection will use a proxy; likewise, using a local DNS service does not guarantee a direct connection. The final policy still depends on rule order and the match result.

Some mihomo configurations also use nameserver-policy to assign different upstream resolvers according to domain rules. For example, LAN or region-specific domains can use a local resolver while other domains use an encrypted resolver. This is useful when the resolution requirements are well understood, but too many rules make troubleshooting harder. When problems occur, first reduce the setup to one known-good upstream, verify that the Fake-IP flow works, and only then restore split DNS.

Use Cases and Environments That Need Care

Subscriptions Built Around Domain Rules

Many subscription rule sets are built around domain suffixes, keywords, and rule providers. Fake-IP keeps the domain available when a connection reaches the rule engine, reducing false matches when multiple services share a CDN address. On devices that mix browsers, desktop applications, and mobile applications, this is usually more predictable than relying on the destination IP alone.

Desktop Environments Using TUN Interception

Some applications do not read system proxy settings, while others use both TCP and UDP. TUN mode can intercept a broader range of traffic, and Fake-IP helps the kernel associate DNS queries with later connections. When using them together, check “does the query enter the built-in DNS?” and “does the connection pass through TUN?” as two separate items. Do not assume the DNS path is correct just because TUN is running.

LAN Gateways Require More Care

When Clash or mihomo runs on a router, transparent gateway, or home server, client devices may use the gateway as their DNS or continue using an ISP DNS service, router-provided IPv6 DNS, or application-level DoH. If the gateway returns Fake-IP addresses to the entire LAN, every mapped connection must be able to return to the same kernel. Otherwise, clients will try to route the mapped address elsewhere and eventually time out.

LAN device discovery, printers, NAS devices, smart-home systems, and media casting often rely on .local, single-label hostnames, mDNS, LLMNR, or vendor-specific domains. These names should not necessarily be handled by public DNS. A gateway setup usually needs to preserve the local resolver and configure real resolution or a dedicated upstream for internal domains.

Evaluate Games and Real-Time Communications by Symptoms

Some game launchers use domains to download resources but communicate during gameplay through UDP, fixed IPs, or regional scheduling services. Fake-IP may work normally for a launcher's web interface while affecting latency probes, server lists, or address checks by anti-cheat components. When problems occur, do not disable all DNS features immediately. First use the logs to identify the failing domain, then add only domains that genuinely require a real address to the filter list.

How to Design Fake-IP Exclusions

The purpose of fake-ip-filter is to let selected domains bypass mapping and return a real IP directly to the application. The broader the exclusion scope, the fewer connections remain available for domain-rule matching. Build the list around concrete compatibility requirements rather than copying an unexplained, oversized list.

LAN and Local Domains

*.lan, *.local, and custom suffixes used inside a home network are usually worth checking first. If a NAS uses storage.home.arpa, configure the corresponding rule based on the local DNS service and the actual suffix. Excluding a domain without a local resolver capable of answering the query still will not produce the correct address.

Time Synchronization and Connectivity Checks

Some system services use specific domains to find NTP servers, check whether the network is available, or determine whether a captive portal login is required. These programs may expect a real address and may even compare DNS and HTTP responses. If a device frequently reports “no network” while browsers work normally, start by checking the logs for system connectivity-check and time-synchronization domains.

Device Discovery, Voice, and Game Services

Devices that depend on LAN broadcasts generally should not have local names mapped to Fake-IP. For games and voice applications, distinguish domains used for login, updates, matchmaking, and real-time communication. Avoid using one overly broad wildcard to exclude an entire vendor domain. An overly broad exclusion can remove the original proxy rules from download domains, leaving them to be handled only by real-IP or catch-all rules.

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.home.arpa"
    - "localhost"
    - "time.windows.com"
    - "time.apple.com"

Support for wildcards, rule providers, and additional matching syntax can vary between kernel versions. The safest approach is to verify a complete, explicit domain first and expand to the necessary subdomain range based on the logs. After loading the configuration, clear the system DNS cache, close existing long-lived application connections, and query again so stale cache entries do not hide the result of the change.

Common Failures and Troubleshooting Order

The Lookup Still Returns a Real IP

First verify that the client displays the expected operating mode and that the active kernel configuration contains enhanced-mode: fake-ip. Then check whether the domain matches a filter entry. Next, confirm which DNS server the test tool is using. Browser secure DNS, system DoH, VPN software, or another DNS server supplied by LAN DHCP can all bypass Clash.

Resolution Works, but the Connection Times Out

Seeing a mapped address suggests that the DNS stage may have entered the kernel, but the later connection may still not be intercepted. In system proxy mode, applications that ignore proxy settings may connect directly to 198.18.x.x. In TUN mode, check the virtual interface, routing table, firewall permissions, and DNS hijacking settings. On a gateway, also confirm that traffic to the Fake-IP pool is correctly routed back to the gateway kernel.

Rules Do Not Match by Domain

Check the destination type shown in the logs. If the log shows only a real IP, the query may have bypassed the built-in DNS, the application may connect directly to a fixed IP, or the domain may be in the Fake-IP filter. If the log shows the domain but the policy is still wrong, inspect rule order. Clash generally matches from top to bottom, so a broad rule placed first can intercept the connection prematurely.

LAN Device Names Cannot Be Reached

Determine which mechanism resolves the name. .local is commonly associated with mDNS and does not necessarily use ordinary unicast DNS; a custom NAS domain may be answered by the router's DNS service. Send the relevant domain to a resolver that can return an internal address and add a Fake-IP exclusion if needed. A DIRECT rule alone cannot fix an incorrect DNS response because rule matching happens after the resolution path.

Changing the Configuration Has No Effect

DNS results may be cached by the operating system, browser, application, and kernel. During testing, reload the configuration, clear the system DNS cache, and fully quit and reopen the application in sequence. Do not just refresh the page, because the browser may continue reusing an existing connection. If the client can display its active configuration, confirm that a subscription update or override process has not overwritten the manual change.

Recommended Minimal Checklist

1. Confirm that the active kernel and its version support the DNS fields in use.
2. Confirm that built-in DNS is enabled and that the test query is actually sent to the corresponding listening address.
3. Temporarily keep one known-good upstream resolver to rule out complex DNS split-routing effects.
4. Check whether the target domain matches fake-ip-filter.
5. Confirm that connections to the mapped address enter the system proxy or TUN.
6. Use the logs to verify the domain, rule name, final policy, and connection error.
7. Only then check node connectivity, UDP support, and the status of the remote service.

Configuration Takeaway: Close the Loop Before Adding Exclusions

The key to Fake-IP is not “returning a special IP,” but completing the mapping loop between the DNS query and the subsequent connection. The query enters Clash, the connection enters Clash again, the mapping table restores the domain, and the rules select a policy. Once all four steps work, domain-based routing has a stable foundation. If any step bypasses the kernel, you may see successful resolution with no connection, or a successful connection matched by the wrong rule.

On desktop devices using mihomo with TUN, start with a basic Fake-IP configuration and add LAN, time-synchronization, game, and device-discovery domains according to the logs. Routers and transparent gateways also require checks for DHCP, IPv6 DNS, address-pool routing, and client-side encrypted DNS. Keep exclusions small and explicit, with each one tied to a reproducible compatibility requirement. This makes the configuration easier to maintain after subscription updates, kernel upgrades, and device migrations.