DNS Configuration Guide: fake-ip vs redir-host Deep Dive

DNS is the first step in every network request — and the most common source of problems in a proxy setup. Clash includes a fully-featured DNS processing engine. Understanding how it works is essential for diagnosing issues like "the proxy is running but some sites are still slow," DNS leaks, or "the node pings fine but connections time out." This article compares the two DNS modes — redir-host and fake-ip — and provides a production-ready configuration template.

Why DNS Is Tricky in a Proxy Setup

In a standard browsing session, the flow is simple: DNS lookup → get the real IP → open a TCP connection. With a proxy in the mix, this gets complicated. If DNS queries go through your local resolver without the proxy, you may get hijacked or inaccurate results for domains you want to reach through the proxy. On the other hand, resolving everything through the proxy server adds latency and is unnecessary for direct connections.

Clash must decide whether traffic should be proxied or sent directly before it has the real IP address. This tension is what drives the DNS mode design.

redir-host Mode: Real IP First

redir-host was Clash's original DNS mode. Here's how it works:

1. An app makes a DNS query (e.g., resolving openai.com)
2. Clash queries multiple upstream DNS servers in parallel and returns the fastest result
3. The real IP is returned to the app
4. The app connects using that IP; Clash then applies IP-CIDR or GEOIP rules to decide routing

The downside of redir-host is that rule matching depends on the real IP — but obtaining that IP may itself be affected by DNS hijacking or poisoning, leading to misrouted traffic. Every connection also requires a full DNS round-trip before the proxy decision, adding latency to the first connection.

fake-ip Mode: Assign a Placeholder IP First

fake-ip is the modern approach recommended by Mihomo (formerly Clash.Meta) and the preferred companion to TUN mode. The key idea: don't wait for the real IP — immediately return a fake private IP and defer the actual DNS resolution to the proxy side.

1. An app issues a DNS query
2. Clash instantly assigns a fake IP from the fake-ip-range pool (default: 198.18.0.0/15) and returns it to the app, while maintaining an internal "fake IP ↔ domain" mapping
3. The app tries to connect using the fake IP
4. Clash intercepts the connection, restores the original domain from the mapping, then applies domain-based rules to decide whether to proxy or go direct
5. If proxied, the proxy server resolves DNS on the far end; if direct, Clash issues a real DNS query and forwards the connection

fake-ip-filter: Domains That Need the Real IP

Not every app works well with a fake IP. Some applications (such as desktop games, VoIP clients, or P2P software) rely on the real IP for service discovery or direct connections — returning a fake IP causes them to fail. The fake-ip-filter field excludes those domains from the fake-ip pool so they still receive a real IP via normal DNS resolution.

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 — they receive real IPs
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - +.stun.*.*
    - +.stun.*.*.*
    - +.xbox.*.microsoft.com
    - *.msftncsi.com

  nameserver:
    - 1.1.1.1           # Cloudflare — primary resolver
    - 8.8.8.8           # Google DNS

  fallback:
    - tls://1.1.1.1:853  # Cloudflare DNS over TLS
    - tls://8.8.8.8:853  # Google DNS over TLS

  fallback-filter:
    geoip: true
    geoip-code: US      # Replace with your country code
    ipcidr:
      - 240.0.0.0/4

nameserver vs fallback: How They Work Together

nameserver is your primary DNS resolver, used for all initial queries. fallback is a secondary set of resolvers — when the fallback-filter condition is met (for example, when the resolved IP falls outside your country's GEOIP range), Clash replaces the nameserver result with the fallback result. This design means: traffic you want to go direct uses a fast local/regional resolver, while traffic you want to proxy is resolved via encrypted DNS to avoid interception or tampering.

How to Verify for DNS Leaks

Visit dnsleaktest.com and run the Extended Test. If the results show DNS servers you don't recognize (e.g., your ISP's resolver appearing instead of Cloudflare or Google), you have a DNS leak. After correctly configuring fake-ip with fallback, the results should show only your proxy server's DNS or your configured encrypted resolvers.

Another way to verify: enable log-level: debug in Clash and restart. When connecting to a site that should go through the proxy, the debug logs should show that domain's DNS query going to the fallback resolver.