Fake-IP & DNS Leak Prevention: A Deep Dive into Clash's DNS Module

DNS resolution is the most error-prone link in the proxy chain. Misconfiguration leads to two categories of risk: DNS hijacking/spoofing causes remote domains to resolve to incorrect IPs, making them unreachable; DNS leaks expose your real browsing history to your ISP. Clash's built-in DNS module features a Fake-IP mechanism that fundamentally addresses both problems at the system level — one of Clash's core advantages over comparable tools.

The DNS Problem with Traditional Proxies

In traditional HTTP proxy mode, when your browser visits google.com, it first performs a local DNS resolution to get the IP address before establishing a connection. There is an inherent conflict here: if DNS resolution uses your local ISP's DNS server, the result for google.com may be incorrect due to DNS hijacking/spoofing; if DNS resolution goes through the proxy, the proxy needs an existing connection to forward the DNS request, creating a chicken-and-egg deadlock.

Early solutions relied on Remote DNS Resolution — the client sends the domain name directly to the proxy server, which resolves it within its own network and returns the result. This solved the hijacking/spoofing problem but added latency and was incompatible with Clash's IP-based rules (such as GEOIP).

How Fake-IP Works

Fake-IP is a more elegant solution adopted by Clash. The core idea is: when an application issues a DNS request, Clash does not wait for the actual DNS resolution result — instead, it immediately allocates a "fake" IP from a reserved IP range (default 198.18.0.0/16) and returns it to the application. The application receives this fake IP and immediately initiates a connection request. Clash intercepts the connection, looks up the domain name corresponding to the fake IP, and then applies its rules to decide how to handle it.

The benefits are significant: applications can start connecting without waiting for DNS resolution to complete, dramatically reducing first-connection latency; actual DNS resolution happens asynchronously in the background and is sent via the proxy, completely avoiding DNS hijacking/spoofing; and DNS leaks are eliminated — because all DNS requests are managed centrally by Clash, none can escape to a local DNS server.

Complete DNS Configuration Example

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  # Domains excluded from Fake-IP (returns real IP directly)
  fake-ip-filter:
    - "*.lan"
    - accounts.google.com
  # Local DNS: for resolving direct-connect domains, fast
  nameserver:
    - 1.1.1.1        # Cloudflare
    - 8.8.8.8        # Google
  # Remote DNS: for resolving proxied domains, prevents hijacking
  fallback:
    - https://8.8.8.8/dns-query       # Google DoH
    - https://1.1.1.1/dns-query       # Cloudflare DoH
    - tls://8.8.4.4:853               # Google DoT
  # Conditions to trigger fallback
  fallback-filter:
    geoip: true
    geoip-code: US
    ipcidr:
      - 240.0.0.0/4   # Reserved address, usually a hijacking/spoofing result

The Roles of nameserver and fallback

nameserver is the primary DNS server group responsible for handling most DNS requests; it is typically configured with fast, reliable DNS servers (e.g. Cloudflare 1.1.1.1, Google 8.8.8.8). fallback is the secondary DNS server group: when the result returned by nameserver is deemed suspicious by the fallback-filter rules (e.g. a remote/proxied IP is returned, or the result falls within a reserved address range), Clash re-queries using the fallback DNS and uses the fallback result instead.

It is recommended to use DoH (DNS over HTTPS) or DoT (DNS over TLS) for fallback DNS. These protocols encrypt DNS requests in transit, preventing intermediate nodes from tampering with them and thoroughly eliminating DNS hijacking/spoofing.

fake-ip-filter: Which Domains Should Bypass Fake-IP

Not all domains are suitable for Fake-IP. The following categories of domains should be added to the fake-ip-filter exclusion list so that Clash returns the real IP directly:

• LAN domains: Such as *.local and *.lan — these addresses are used within local networks, and Fake-IP can prevent LAN devices from being discovered correctly.
• Game platform domains: Some game clients validate DNS resolution results; Fake-IP may trigger anti-cheat mechanisms.
• NTP time-sync services: Time synchronization requires accurate IPs — real IPs must be returned directly.
• Authentication domains for specific apps: Such as Google account sign-in domains; Fake-IP may cause sign-in failures.

Verifying for DNS Leaks

After completing your configuration, visit dnsleaktest.com or bash.ws/dnsleak to run a DNS leak test. If the results show only DNS servers located in the region of your proxy server, the configuration is correct. If your local ISP's DNS servers appear, there is a DNS leak — check your DNS configuration or combine TUN mode's DNS hijacking feature to resolve the issue.