How to Detect Clash DNS Leaks: Testing Methods & Leak-Proofing Guide

NT-03.1What a DNS Leak Is, and Why It Happens Even With the Proxy Connected

A DNS leak means traffic forwarding is going through the proxy, but the domain-to-IP lookup itself isn't — it's being sent straight to whatever DNS server your machine normally uses (typically one assigned by your ISP or home router). That means even though page content travels through the proxy, which domains you're visiting is still exposed on the local network. Inconsistent resolution results can also cause unstable connections or DNS tampering.

There are usually two root causes. First, in system-proxy mode, the OS only hands off application-layer HTTP/HTTPS traffic to the proxy — DNS requests travel over a separate UDP port 53 channel, and if the client doesn't specifically intercept that channel, the requests bypass the proxy entirely. Second, even when the client does handle DNS, if the nameserver entries in the dns config block still point to a local or ISP address, the results are still shaped by your local network environment. Whether requests go through the proxy at all, and where they actually resolve, are two separate things worth checking individually.

Both Clash and Clash Meta (mihomo) cores expose a dedicated dns config block, with enhanced-mode controlling how resolution requests get handled. Understanding this field is the starting point for diagnosing and fixing leaks.

NT-03.2Testing Steps: Confirm the Leak Before You Touch Any Config

Before changing any settings, run through a repeatable procedure to confirm whether a leak actually exists — don't just tweak parameters based on a hunch. These steps work on the client for any platform.

1. Disconnect the proxy and note your machine's current DNS server (check the DNS entry under your active network adapter in system network settings).
2. Connect the proxy, confirm the policy group has an active node selected, then open the client's log panel and filter by DNS or resolve to watch the resolution requests come through.
3. Visit a page that echoes back your request's source info, and compare the two results: does the resolver address shown match before and after enabling the proxy? If it still shows your ISP's DNS server with the proxy on, that's a leak.
4. Open the client's Connections panel and check the destination address of active connections — confirm the resolved IP actually falls within the expected proxy range, rather than resolving to something reachable directly on your local network.
5. Switch to TUN mode and repeat the steps above, then compare against the results from system-proxy mode to see whether the leak only shows up under one particular traffic-takeover method.

NT-03.3enhanced-mode: fake-ip vs. redir-host

The core field in the dns config block is enhanced-mode, which controls how the client folds domain resolution into its unified handling. The common values are fake-ip and redir-host.

Here's a working dns config example. The key is pointing nameserver at addresses that support encrypted transport, instead of sticking with your machine's default resolver:

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.market.xiaomi.com"
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback:
    - tls://8.8.4.4:853

nameserver is the primary resolver list — it's worth switching these entirely to DoH (DNS over HTTPS) or DoT (DNS over TLS) endpoints, so the lookup requests themselves are encrypted in transit and can't be sniffed in plaintext on the local network. The fallback list kicks in when results from the primary nameservers look tampered with, and should also use encrypted-protocol addresses.

NT-03.4LAN Access Breaking Due to a Misconfigured fake-ip-filter

A common side effect of enabling fake-ip is that hostname lookups for devices on your local network (router admin pages, NAS boxes, printers) also get swapped out for fake IPs, breaking access. The fake-ip-filter field lets you list domains that should skip the fake-IP logic and resolve to their real addresses instead:

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"

The +. prefix matches the domain and all its subdomains, and * is a wildcard. If a LAN device or a service that needs a precise exit IP (like an internal corporate system) stops working once the proxy is on, check first whether its domain needs to be added to this filter list — don't just disable fake-ip outright.

NT-03.5Diagnosing Differences Between System-Proxy Mode and TUN Mode

System-proxy mode only intercepts traffic from apps that actively read the system's proxy settings — some command-line tools, certain UDP traffic, and programs that ignore system proxy config entirely can send DNS requests that bypass the client altogether. This kind of leak can't be fixed by adjusting the dns config block alone; you need TUN mode, which lets a virtual network adapter take over all traffic at the network layer, DNS queries included.

After enabling TUN mode, check these two things too, so you don't end up with traffic captured but resolution still leaking:

• Confirm the dns-hijack field in the tun config block is enabled (typically set to 0.0.0.0:53 or any:53) — this is what intercepts all port-53 DNS requests at the network layer and hands them off to the built-in DNS service.
• On Windows and macOS, if the system still keeps the original adapter's DNS settings around, some programs may prefer the system resolver cache. After confirming TUN mode is active, flush your local DNS cache once before retesting.

For the actual steps to enable TUN mode and how it differs across platforms, see the dedicated write-up on virtual-adapter traffic takeover elsewhere on the site — not repeated here. Once dns-hijack and enhanced-mode are configured, repeat the test procedure from earlier in this guide until the resolver address stays consistent whether the proxy is on or off — that's a clean pass.

NT-03.6Double-Checking Things After a Config Change

Editing the dns config block has fairly broad impact, so it's worth reviewing in this order to avoid connection issues caused by a bad edit:

1. Make the change in a test environment or a spare config file first, and only apply it to your daily-use profile once you've confirmed it works — don't overwrite the subscription config you're actively relying on.
2. Double-check the format of each nameserver entry (DoH addresses need to be a full URL; DoT addresses need a tls:// prefix plus a port number).
3. Re-run the test procedure from earlier in this guide and note whether the resolver address actually changes.
4. Use it normally for a while and confirm LAN device access, internal corporate services, and similar cases are unaffected.

Troubleshooting a DNS leak really comes down to confirming whether domain resolution — not just traffic forwarding — is actually routed through the proxy. Once enhanced-mode, nameserver, and fake-ip-filter are all checked and aligned, most leak issues can be resolved at the config level.