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

Fake-IP is an enhanced DNS handling method commonly used by Clash and mihomo. Instead of replacing a domain lookup with the target server's public IP address, it assigns a virtual address from a dedicated range and stores a domain-to-virtual-address mapping in the core. When an application connects to that virtual address, Clash restores the domain from the mapping, then applies domain rules, selects a proxy group, and performs remote resolution.

The goal is not to alter the destination website, but to preserve accurate domain information at the traffic entry point. For programs routed through a TUN virtual network interface that submit only an IP connection to the operating system, Fake-IP can associate the domain from the earlier DNS query with that connection. This makes it easier for the rules engine to match domain rules such as DOMAIN, DOMAIN-SUFFIX, and rule providers, while reducing mismatches between local DNS results and the actual destination reached through the proxy.

How Fake-IP DNS Mapping Works

A typical request has two stages: DNS lookup and connection establishment. Understanding both helps identify whether a problem lies in DNS resolution, traffic capture, rule matching, or the proxy exit.

1. The application sends a domain lookup to the system DNS, such as a request for an A or AAAA record for a service.
2. The system query is forwarded to Clash's DNS module. With TUN, a common setup uses dns-hijack to receive DNS requests on designated ports; with other capture methods, the operating system's DNS settings may point directly to a local listening address.
3. The Fake-IP module assigns a virtual address to the domain and records the mapping. The address pool commonly uses a reserved benchmark-testing range; the actual range is defined by fake-ip-range.
4. After receiving the virtual address, the application starts a TCP or UDP connection. That connection must continue into Clash; if the traffic bypasses Clash, the virtual address cannot establish a connection directly over the public internet.
5. Clash looks up the original domain from the destination virtual address, passes the domain to the rules engine, and selects direct connection, proxying, rejection, or a specified proxy group.
6. When a real connection is required, Clash obtains the actual address using the configured upstream DNS, proxy-side resolution, or the resolution method required by the destination protocol.

Fake-IP is therefore not a standalone proxy mode. It depends on both the DNS request and the subsequent connection being handled by the same Clash instance. If the DNS query enters Clash but the connection bypasses TUN, or the connection enters Clash while another program intercepts the DNS query, the mapping chain breaks. During troubleshooting, check separately whether DNS passes through Clash and whether the destination connection does too.

Domain rules are usually matched after the mapping has been restored. If a rule contains a domain suffix, Clash can evaluate the restored hostname directly instead of treating the destination as an ordinary public IP and applying IP rules first. A connection made directly to an IP address has no preceding domain lookup and therefore no Fake-IP mapping; it is handled using the IP, port, and other available information.

mihomo Core Configuration and Field Relationships

Different clients may generate configuration through graphical switches or add the DNS section through subscription overrides. The final configuration actually loaded by the client is authoritative. The simplified example below illustrates how the fields relate; adjust the listen address, upstream DNS, and address pool for the device environment.

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"
    - "time.*.com"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

tun:
  enable: true
  stack: mixed
  dns-hijack:
    - any:53

enhanced-mode: fake-ip selects Fake-IP enhanced mode; fake-ip-range defines the virtual address pool; and fake-ip-filter lists domains that should not receive virtual addresses. For a filtered domain, the DNS module returns the real resolution instead of creating a Fake-IP mapping.

dns-hijack and Fake-IP serve different purposes. The former routes device DNS requests into Clash; the latter determines how those requests are answered. Enabling Fake-IP without sending queries to Clash will not affect DNS requests that bypass it. Conversely, DNS hijacking alone does not create virtual address mappings if normal resolution mode remains enabled.

In mihomo, Fake-IP mappings are primarily used to associate connections during runtime. Some configurations can enable Fake-IP persistence in the profile, allowing the core to reuse saved mappings after a restart. Whether persistence is useful depends on how the client manages configuration. After changing the address pool, encountering stale mappings, or seeing inconsistent behavior after switching configurations, stop the core, clear the DNS/Fake-IP cache provided by the client, and reload the configuration.

When Fake-IP Works Well

Full-Traffic TUN Capture on Desktop Devices

TUN creates a virtual network interface that receives TCP, UDP, and some system-service traffic that does not follow the system HTTP proxy settings. Many programs submit only the resolved IP to the network stack when opening a connection, so the rules engine may not be able to derive the domain from the connection itself. Fake-IP restores the domain from the preceding DNS query, making it a natural fit for TUN.

Browsers, command-line tools, game platforms, and background update services may use different interfaces and proxy mechanisms. Routing both DNS queries and connections through TUN can reduce split-routing differences caused by one program following the system proxy while another bypasses it. After enabling it, still check the routing table, DNS hijacking, and client logs to confirm that traffic from more than just the browser is working.

Large Rule Sets Built Around Domains

Subscription configurations often contain extensive domain suffixes, domain keywords, and rule providers. With Fake-IP, the core can restore the queried domain when the connection arrives and apply these rules first. Domain rules are more stable than judging by server IP alone because a service may use a CDN, dynamic routing, or shared addresses, while one public IP can host many unrelated domains.

If a rule should connect to a LAN service directly, proxy a public site, or reject a specific domain, Fake-IP makes the target easier to identify. Rule order still matters, however. A broad rule placed first can override a later, more precise domain rule; Fake-IP supplies matching information but does not change rule priority.

Proxy Connections That Need Consistent DNS Results

In ordinary DNS mode, the local network usually resolves the real IP first, after which the rules engine decides based on the domain or IP. If the proxy exit receives a different CDN address from the local network, traffic may take an inefficient route or produce inconsistent results. Fake-IP can defer selection of the real destination, allowing the core to choose the resolution path according to the policy and upstream settings. It suits environments that rely on domain-based routing and proxy-side resolution.

Common Issues with LAN Devices, Games, and Special Domains

LAN Hostnames and Device Discovery

Printers, NAS devices, TV casting, and router administration pages often use .local, .lan, or vendor-specific hostnames. Some are resolved through mDNS, LLMNR, a router's local DNS service, or a search domain, and should not be sent to public upstream DNS. If these names receive Fake-IP addresses, applications may fail to discover devices on the same network or send management requests that should stay direct through proxy rules.

First determine which protocol resolves the name, then add a precise exclusion. For fixed devices, preserve DHCP hostname resolution or use a clear LAN domain suffix where possible. Add only locally resolved suffixes to fake-ip-filter, and ensure LAN IP ranges have direct-connection rules. Excluding a domain without a direct route can still result in the wrong policy being selected when the connection is established.

Game Login, Voice Chat, and UDP Sessions

Some games use account-login domains, content-download domains, match-server IPs, voice UDP, and NAT-detection services at the same time. A working login page does not mean the entire game path is healthy. If the launcher resolves a domain and passes the result to a separate process, while that process is not captured by the same TUN, the virtual address may lose its forwarding path.

For login loops, empty region lists, or failed voice connections, first check the core logs for the relevant UDP/TCP connections, then confirm that the process entered TUN. Add a domain to the filter list only when the logs show it is unsuitable for Fake-IP. Games typically use multiple service domains; excluding an entire top-level domain or disabling all Fake-IP can easily break existing domain-based routing.

Time Sync, Connectivity Checks, and Captive Portals

System time synchronization, connectivity checks, and campus or hotel login portals may expect real DNS results or need access before the proxy core starts. If such a request receives a virtual address before the connection enters Clash, the system may incorrectly report that it is offline. Time-sync domains, operating-system connectivity-check domains, and portal authentication domains are common candidates for exclusion.

Build exclusions from actual logs and captured results rather than copying a long generic list. Detection domains vary by operating-system version, region, and network environment. Reproduce the issue first, record the queried domain, and add the smallest practical rule to avoid switching ordinary application traffic back to real IPs.

IP Addresses Stored in Configuration or Reused by Other Devices

Some programs cache DNS results for long periods or write the returned address into a configuration file. Fake-IP works only within the Clash instance that owns the mapping; copying the address to another device is meaningless. Take extra care with a gateway setup: if DNS relay A returns a virtual address but the connection goes through gateway B, gateway B cannot know which domain that virtual address represents.

When providing Fake-IP DNS to multiple devices on the same LAN, ensure their subsequent traffic consistently passes through the same core instance and that the virtual address pool routes to it. Otherwise, use a DNS mode that returns real addresses, or limit Fake-IP to the local client.

How to Write Fake-IP Exclusion Rules

The goal of an exclusion rule is to return real addresses for a small number of incompatible domains, not to maintain an exception list covering every service. Expand gradually in this order: exact domain, limited wildcard, then suffix range.

mihomo's exact matching capabilities can change with its version and configuration format, and the client may alter fields while merging subscriptions and overrides. After editing, open the client's final configuration view to confirm that fake-ip-filter was not overwritten by a subscription update, and check the core startup log for field errors.

Some newer mihomo configurations support blacklist or whitelist logic for Fake-IP filtering. In blacklist mode, domains in the list use real resolution while all others use Fake-IP; whitelist mode reverses this, allowing only matching domains to use Fake-IP. For everyday desktop use, starting with a small number of exclusions is usually safer. If whitelist mode is enabled, ensure that returning real addresses for the many non-matching domains is intentional rather than the result of misunderstanding the field's meaning.

Fake-IP Troubleshooting Order

1. Confirm that the configuration is loaded. In the client's active configuration, verify that DNS is enabled, enhanced mode is set to Fake-IP, and the core startup log is clean. Subscription files, override files, and client switches may all modify the DNS section.
2. Confirm that DNS queries reach the core. Check connection or DNS logs for the target domain. If encrypted DNS, browser-specific DNS, or another DNS tool is enabled, verify that it is not bypassing the local listener.
3. Confirm that the virtual address belongs to the configured pool. The result should fall within fake-ip-range. If a normal public IP is returned, the domain may have matched a filter, or the query may not have passed through Clash.
4. Confirm that subsequent connections are also captured. After the application receives a virtual address, the corresponding connection should appear in the logs. If no connection is recorded, check TUN permissions, system routes, and application bypass settings first.
5. Check whether the mapping restores the domain. Connection logs should show the original domain or a matched domain rule. If only a virtual IP appears, clear the DNS and Fake-IP caches and confirm that the query and connection are handled by the same core.
6. Check rule order and the proxy group. If the domain is restored but the exit is wrong, the issue is usually rule priority, a rule-provider update, or proxy-group selection—not Fake-IP itself.
7. Add an exclusion last. Add the precise domain to the filter list only after confirming that the service genuinely requires a real DNS result.

After changing DNS settings, browsers, the operating system, and applications may continue using stale caches. Reload the Clash configuration first, then clear the system DNS cache and fully exit the affected applications. If the client provides a Clear DNS Cache or Refresh Fake-IP Cache action, run it after stopping the relevant connections. When switching between multiple core instances, also confirm that the system DNS and default route point to the active instance.

Choosing Between Fake-IP and Redir-Host

Fake-IP preserves domain mappings through virtual addresses. It suits TUN capture, domain-heavy rules, and devices where DNS and connection paths can be controlled consistently. Redir-Host-style modes return real addresses and behave more like conventional DNS, making them easier to use with LAN services, cross-device DNS, and some special applications that require real addresses. However, domain association and resolution paths depend on the client implementation and connection type.

Do not choose based only on whether one webpage opens. Test the browser, system updates, LAN devices, game UDP, sleep-and-resume behavior, and network switching together. On a standalone desktop, start with Fake-IP and add narrowly scoped exclusions for confirmed issues. When a router provides service to multiple devices, design the DNS request and return-traffic paths first so virtual addresses always return to the same instance.

The decisive test is whether the entire chain is intact: the DNS query enters Clash, the current core assigns the virtual address, the subsequent connection returns to that same core, domain rules match correctly, and the proxy group establishes a real connection. Following this order in the logs usually isolates a Fake-IP issue to one specific stage without repeatedly changing every DNS setting.