Clash Fake-IP Mode Explained: How It Works, When to Use It, and Troubleshooting

In a Clash Meta (mihomo) configuration, the DNS mode directly affects domain resolution, rule matching, and connection establishment. Fake-IP is a commonly used approach: instead of immediately resolving a target domain to its real public IP address, the client assigns it a virtual IP from a dedicated address pool and stores the domain-to-IP mapping internally. The application sees the virtual address, while the proxy core can restore the original domain during the subsequent connection phase and then decide whether to connect directly, use a proxy, or reject the request.

This workflow is often used together with TUN mode, but the two are not the same thing. Fake-IP handles DNS responses and domain preservation; TUN handles how network traffic generated by the system and applications is captured. Understanding the boundary between them helps identify whether a failure lies in DNS, rules, routing, or the application itself. This guide follows the request flow, configuration choices, use cases, and troubleshooting steps.

What Does Fake-IP Actually Change?

The traditional redir-host approach usually works like this: an application asks the system resolver for a domain, the resolver returns the real IP address, and the application uses that IP to establish a connection. If the proxy core sees only the destination IP, it must infer the target from domain sniffing, supplementary rules, or known address ranges. With HTTPS traffic, the core may obtain the domain from the TLS SNI; for some encrypted or non-standard protocols, that inference is not guaranteed.

Fake-IP changes the order to “preserve the domain first, then establish the connection.” When an application queries example.com, the DNS module returns a virtual address from the pool, such as 198.18.0.23. This is not the real address of the target server; it is an index the core uses to identify the domain. The application then connects to 198.18.0.23. Once the proxy takes over the traffic, the core restores example.com from the mapping table and applies the domain rules.

A typical Fake-IP pool uses a specially reserved test network, such as 198.18.0.1/16. These addresses should not be treated as public destinations. The pool size, exclusion list, and mapping lifetime are determined jointly by the core and the configuration. The virtual IP-to-domain mapping is usually kept in a cache, so the same domain may continue receiving the same address for a while, or be assigned a new one after the cache is cleared, the configuration is reloaded, or the pool changes.

The Request Flow

1. The application sends a DNS query containing the domain rather than the final IP address.
2. Clash receives the query and processes it according to settings such as nameserver, fallback, and fake-ip-filter.
3. The Fake-IP module creates a mapping for the domain and returns a virtual IP from the address pool to the application.
4. The application connects to the virtual IP; the system proxy, transparent proxy, or TUN passes that connection to Clash.
5. Clash restores the domain from the mapping and evaluates domain rules, process rules, IP rules, and fallback rules in sequence.
6. After selecting a policy group, the core connects to the real destination through a direct connection or proxy route.

The key point is “the destination seen by the rules.” When the mapping is valid and the traffic passes through Clash, domain rules can usually take effect early in the connection. If an application bypasses the system DNS, uses a hard-coded IP, or sends traffic outside Clash, Fake-IP cannot recover the domain out of nowhere and cannot replace traffic interception by routing.

How Fake-IP, Real Resolution, and TUN Mode Relate

Fake-IP and redir-host represent two approaches to DNS responses. Fake-IP focuses on preserving domain context and works well when stable domain-based rule matching is important. redir-host is closer to ordinary DNS behavior: the application receives a real IP, which can improve compatibility for programs that depend on actual addresses. Both modes require correct DNS hijacking, a system proxy, or traffic interception; neither should be assumed to be faster in every situation.

TUN mode operates at a different layer. When TUN is enabled, the system creates a virtual network interface and sends traffic that matches the routing conditions into Clash. This can capture programs that do not follow HTTP or SOCKS system proxy settings, as well as some background services and UDP traffic. Enabling TUN does not make DNS correct automatically: if the system still sends queries to an external DNS server, or an application uses its own encrypted DNS, the Fake-IP mapping may not participate in the full request flow.

On desktop, the system proxy is usually enough for browsers and applications that follow system settings; consider TUN when broader application coverage is needed. On Android, VpnService is the common foundation for traffic interception, while VPN permissions, battery-saving policies, and other active VPN apps can affect the result. iOS has its own limits around Network Extension permissions and client capabilities, so desktop TUN configurations should not be copied over directly.

What to Check Before Configuring Fake-IP

Field names and available options should be verified against the documentation for the current mihomo version and the client interface. Different clients may expose different editing paths for DNS, TUN, and override settings. The checks below are a troubleshooting framework, not a requirement to copy one identical configuration across every platform.

1. Identify Who Receives DNS Queries

First confirm that the client has core DNS enabled and that system DNS queries are forwarded to Clash. A desktop client may receive queries through a local listening address, while a TUN client may handle UDP or TCP queries through DNS hijacking. If a browser has Secure DNS enabled and connects directly to a specified provider, the system DNS settings may have no effect. During testing, temporarily disable the application's built-in encrypted DNS or include it in an explicit network policy.

2. Plan the Fake-IP Address Pool

The address pool should use a reserved range suitable for virtual mappings and avoid the actual LAN, corporate networks, container networks, and commonly used VPN ranges. For example, if the LAN uses 192.168.1.0/24, do not assign the same range to the Fake-IP pool. An address conflict can make the system mistake a virtual address for a LAN host, resulting in connection timeouts, routing anomalies, or inaccessible internal services.

Do not casually assign the Fake-IP pool to a common home-network range. Before configuring it, check the device's routing table, Docker bridges, virtual machine interfaces, and the ranges used by corporate VPNs. If the pool overlaps with a real network, replace the pool first, then clear the cache and test again instead of repeatedly switching proxy nodes.

3. Configure fake-ip-filter

Not every domain is suitable for a Fake-IP response. LAN hostnames, router administration addresses, services that require the real IP for decisions, and domains that depend on local resolution should generally be added to the exclusion list. These domains will then use real resolution or return the original result, depending on the client implementation. Keep the filter focused at first; excluding too much sends large numbers of domains back to real resolution, making rule matching and DNS behavior harder to assess.

Expand the filter list in response to specific failures and record the purpose of every change. For example, if printer discovery fails, first check LAN domains and multicast name resolution; if a corporate intranet domain will not open, check whether the corporate DNS must be used on a particular network. Do not exclude an entire top-level domain or all domains in mainland China merely because one request failed.

4. Check the roles of nameserver and fallback

nameserver is the regular resolver, while fallback is a backup resolver or an additional source for specific checks; the exact behavior depends on the core version and configuration. When choosing resolvers, consider reachability, response time, support for the required record types, and whether queries should be sent through the proxy. If a resolver itself is unreachable, Fake-IP may still return cached results, but new domains can remain stuck resolving or fail to connect.

If nameserver-policy is configured, verify that its syntax and domain scope are accurate. Its purpose is to send different domains to suitable resolvers, not to replace proxy rules. Successful DNS resolution does not guarantee a successful connection; the selected policy group, node availability, and response from the remote service still matter.

When Is Fake-IP a Good Fit?

Fake-IP is often easier to manage when routing depends on domain rules. Examples include separating direct and proxied traffic by domain suffix, assigning a group of services to a dedicated policy group, or reducing misrouting caused by judging traffic solely by destination IP. Because the domain remains available early in the connection, rule maintenance stays closer to the site names users actually recognize.

In TUN mode, Fake-IP is particularly useful for programs that do not follow the system proxy. As long as a program sends its DNS query through the system network stack and connects to the returned address, the core has a chance to identify the destination from the mapping. However, programs using custom DNS, DoH, DoT, or their own fixed DNS cache require separate handling. Some apps also use QUIC, IPv6, or proprietary network protocols, so protocol differences should be included in testing.

Use Fake-IP cautiously with LAN devices. Printers, NAS devices, smart-home controllers, router dashboards, and LAN game discovery commonly depend on real local addresses, multicast, or broadcast, and this traffic may not be suitable for proxying. Adding the relevant domains to fake-ip-filter and creating direct rules for LAN ranges is a safer starting point.

Common Failures and a Troubleshooting Order

The Browser Shows DNS_PROBE_FINISHED_NXDOMAIN or a DNS Timeout

First determine whether every domain is affected or only one. Check whether DNS requests appear in the Clash logs, verify that the client's DNS listener is running, and confirm that the system or browser is not bypassing it. Then temporarily switch to a reachable resolver, clear the client's DNS cache, and reload the configuration. If only one domain fails, check nameserver-policy, the spelling of the domain, the filter list, and the record types it uses.

The Page Opens, but the Wrong Direct or Proxy Rule Is Selected

Check the connection details for the destination domain, destination IP, and matched rule. If the details show only a Fake-IP address, the mapping may not have been restored correctly because the connection was not received by Clash or the application used a cached IP. If the real domain is shown but the rule is unexpected, review rule order: more specific DOMAIN, DOMAIN-SUFFIX, or DOMAIN-KEYWORD rules should come before broader rules, and the MATCH fallback should be last.

Save the rule changes and reload the configuration. Editing the file without reloading it leaves the running core using the old rules. Test with a new connection; existing connections and cached data may not repeat the full resolution and matching flow.

LAN Devices or the Corporate Network Stop Working After TUN Is Enabled

Disable TUN first and use that as a comparison test. If connectivity returns, check TUN routing, auto-route, strict-route, DNS hijacking, and bypass-range settings. Make sure the home router, corporate network, and printer subnets are not being incorrectly sent through a proxy policy. LAN traffic needs both rules and routes that permit direct access; an IP-CIDR rule alone cannot fix the issue if the traffic never enters the core.

Multiple VPNs, virtual machines, containers, and security tools may modify the routing table at the same time. During troubleshooting, temporarily disable unnecessary VPNs or virtual interfaces and record the default route and DNS servers before and after enabling TUN. Windows, Linux, and Android use different permission models; a client showing “enabled” does not mean the system granted every permission it needs.

Some Applications Cannot Connect at All

Check whether the application uses IPv6, QUIC, a hard-coded IP, built-in DoH, or its own proxy. Fake-IP primarily builds mappings around domain resolution, so connections that use an IP directly may rely only on IP rules. If the application prefers IPv6 while the current TUN setup, nodes, or rules do not cover IPv6, the browser may work while one app fails. During testing, verify IPv4, IPv6, TCP, and UDP separately before changing the protocol or routing scope.

# For troubleshooting guidance only; confirm the actual fields against the current client and mihomo version
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

tun:
  enable: true
  auto-route: true
  dns-hijack:
    - any:53

The snippet above shows how the fields relate to one another; it is not intended for every system to use unchanged. dns-hijack, TUN routes, and filter entries may vary with the client wrapper and version. For LAN domains, corporate DNS, and IPv6 environments in particular, understand the existing network first and add settings one at a time.

A Repeatable Checklist

1. Record the current client version, core version, operating system version, and network environment, and keep the original configuration.
2. Disable other VPNs, proxy software, and browser-specific DNS to create a test environment with a single variable.
3. Confirm that ordinary domains resolve successfully and check whether the corresponding DNS requests appear in Clash.
4. Check that the returned address belongs to the Fake-IP pool and confirm that the pool does not overlap with the LAN.
5. Review the connection details to confirm that the mapping restores the domain, then verify the matched rule and policy group.
6. Test ordinary websites, LAN devices, apps that require sign-in, UDP services, and IPv6 services separately.
7. Change one item at a time, then save, reload, clear the cache, and repeat the same set of tests.

If an application works again after switching to redir-host, it may depend on a real IP, LAN resolution, or a special protocol; this does not automatically mean the Fake-IP configuration is wrong. Start by adding the specific domain to the filter list or assigning the application's traffic an explicit direct policy. Conversely, if domain rules are unreliable under redir-host but stable under Fake-IP, check DNS hijacking and mapping expiry before simply changing nodes.

Conclusion: Trace the Request Flow to Find the Problem

Fake-IP is valuable because it carries domain information through DNS, connection interception, and rule matching. It is not a standalone speed switch and cannot replace a reachable resolver, correct routing, or an effective proxy policy. Whether it fits depends on the device type, application protocols, LAN structure, and whether TUN interception is needed.

When something fails, follow the sequence “application queries DNS → Clash returns an address → traffic enters the core → the mapping restores the domain → rules select a policy → the node establishes the connection.” This usually identifies the cause faster than repeatedly switching DNS servers or nodes. Keep explicit exceptions for LANs, corporate networks, and special applications, then verify every change with logs and connection details to keep the Fake-IP configuration maintainable.