How to Detect Clash DNS Leaks: fake-ip Mode and Leak-Proof Config

▶What DNS Leaks Are and Why They Happen

Proxy clients do two jobs: resolve a domain to an IP, then route traffic to that IP through the tunnel. Rule-based routing (say, direct connect for domestic domains, proxy for everything else) depends on Clash actually performing the resolution itself and routing based on the result. If a DNS query never passes through Clash — instead going straight from the system's network interface to a local ISP resolver or some unproxied DNS server — whoever's monitoring gets a full record of every domain you visited. That's a DNS leak. It doesn't stop pages from loading, so it's easy to miss, but it's a real hit to both privacy and routing accuracy.

The common causes aren't mysterious — they mostly fall into a handful of categories:

• Browsers with built-in secure DNS (DoH) enabled bypass the system resolver entirely and connect straight to a fixed encrypted DNS provider, outside Clash's control.
• Virtual machines, containers, or certain sandboxed environments run their own network stack and resolv.conf, ignoring the host's proxy config.
• TUN mode is on but DNS hijacking isn't configured properly, so UDP requests on port 53 bypass the virtual adapter and go straight out.
• The system still has an active IPv6 network path while Clash's dns block only handles IPv4 queries — IPv6 resolution goes through the native channel instead.
• A rule set marks certain domains with no-resolve, intending to match by IP range only, but a config ordering issue makes the system resolve that domain before Clash gets a chance to intercept it.

▶Reproducible Steps to Detect a DNS Leak

No extra software needed — four steps, works on any platform:

1. Record a "clean" baseline first. Fully disable the proxy and any VPN, resolve a domain with a command-line tool, and note the resolver address returned — that's your ISP's native DNS exit.
2. Repeat the same lookup with Clash running. Use nslookup or dig on the same domain. If the resolver address matches the baseline exactly, that query never touched Clash — it went straight down the system's native path.
3. Confirm the traffic path with a packet capture tool. Use tcpdump or Wireshark to watch port 53 (and 853, which DoT uses) and see which interface the packets leave from. Traffic through the TUN adapter or a local loopback address (Clash's listening address) is safe; traffic going straight out a physical adapter to an external DNS IP is a leak.
4. Check Clash's own DNS logs. Set the log level to debug, or check the connection log in the dashboard, and confirm the resolution request for your target domain actually shows up there. If it doesn't appear, that query wasn't intercepted.

There's also a more direct browser-based check: open an online DNS leak test page that supports multi-node detection, and compare the resolver location before and after enabling the proxy. If the location still shows your local ISP's city after the proxy is on, that's a strong sign of a leak.

▶fake-ip vs redir-host: What Actually Differs

In Clash's dns block, enhanced-mode determines how resolution results interact with rule-based routing — it's the single most important field in leak-proof config.

fake-ip mode

When Clash receives an app's domain lookup request, it skips the real public-network query and instead hands back a "fake IP" pulled from a reserved virtual address pool (typically a range like 198.18.0.0/16 that never appears on the real internet). When the app connects to that fake IP, Clash looks up the corresponding domain the moment the tunnel is established, decides whether to route it direct or through a proxy node, and only then performs the real resolution. Throughout this process, anything observable at the system level is always the virtual address — the real public IP behind the target domain never gets exposed, and there's no reliance on the system's DNS exit. It's a natural fit for transparent proxying under TUN mode.

redir-host mode

Clash queries the upstream DNS server directly, gets back the real IP, hands it to the app, and logs that lookup so subsequent connections to that IP get routed by the rule table. This approach has two problems: first, once the real resolution result gets cached by the app or intercepted by some other process at the system level, there's still theoretically a chance of information exposure; second, for sites behind CDNs where one domain maps to many rotating IPs, matching rules by IP range easily misfires, hurting routing accuracy. redir-host suits older clients or deployments without virtual adapter support — it's generally not the recommended default for new configs.

The takeaway is straightforward: wherever TUN mode is available, go with fake-ip across the board — better leak protection and more accurate routing. Only switch to redir-host temporarily when you specifically need to keep an old rule set working or want to inspect raw resolution results.

▶Adjusting the dns Block Field by Field to Seal the Leaks

Once the mode is settled, here's a dns block you can check line by line — each entry maps to a specific leak risk:

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - tls://dns.rubyfish.cn:853
  nameserver-policy:
    "geosite:cn":
      - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
  ipv6: false

• enable / listen — first confirm the DNS service is actually enabled and listening on the given port. If the GUI toggle isn't switched on, writing it into the config file alone won't do anything.
• enhanced-mode: fake-ip — go with this by default per the previous section, paired with a fake-ip-range using a private range that won't collide with real public addresses.
• fake-ip-filter — LAN devices and local network services should be excluded from fake-IP assignment, otherwise direct connections on the local network will fail. This exclusion doesn't cause a leak, since it's local traffic to begin with.
• default-nameserver — used specifically to resolve the DoH/DoT domain names in nameserver and fallback below; must be raw IPs, or you get a deadlock where resolving an encrypted-DNS domain itself requires DNS.
• nameserver — use encrypted protocols (DoH or DoT) for upstream resolution, so this hop isn't logged in plaintext somewhere on the network path; by default these queries pass through Clash rather than the system's own network stack.
• nameserver-policy — assigns dedicated upstream resolvers to specific domain groups. A common pattern is fast local resolution for domestic domains and encrypted upstream for everything else, balancing speed with privacy.
• fallback / fallback-filter — automatically switches to a backup resolver when the default upstream's result is flagged as tampered or untrustworthy; geoip-code: CN checks whether the returned result falls in the expected region.
• ipv6 — if the system or router still keeps an active IPv6 path and it isn't handled here, IPv6 domain resolution will bypass fake-ip and go through the native channel — this is the leak point people overlook most often. Turn it off outright until you've set up dedicated IPv6 rules.

▶Additional Checks at the System and Browser Level

Once the config file is dialed in, there are a few more system-level settings — outside the dns block — worth confirming one by one, since they can cause leaks on their own:

1. Set the browser's secure DNS toggle to "follow system settings" everywhere, rather than pinning it to a fixed DoH provider — otherwise browser traffic will bypass Clash's DNS interception logic entirely.
2. Leave the OS network adapter's DNS setting empty or on automatic where possible. Don't manually fill in an ISP DNS address as a "backup" — some system policies will actually prioritize that backup address.
3. If a router or home gateway has DNS hijacking enabled, it might intercept and replace requests before an encrypted DNS query even leaves the device. In that case, verify on the client side that the encrypted protocol (DoH/DoT) actually established successfully rather than being silently downgraded to plaintext.
4. When switching between multiple users or network profiles, rerun the detection steps from the previous section — don't assume one config behaves the same across every network. Public Wi-Fi, corporate networks, and mobile data can each apply very different DNS hijacking policies.

Once you've worked through the checks above, you can be reasonably confident that the full DNS request path is routed through the tunnel. Leak-proof config isn't a one-time job — it's worth rerunning the four detection steps from the second section whenever you switch devices, change networks, or update the client. It's cheap to do, and it catches cases where routing "looks like it's working" but is actually leaking.