Clash DNS Leak Test and Fix: How to Check for Leaks and Configure DNS Protection

What Counts as a DNS Leak?

A DNS leak occurs when domain lookups take a different route than intended. For example, you may expect all public domain names to be resolved through your proxy, but your local router may instead forward the queries to your ISP's DNS servers. A changed web-facing IP address doesn't mean DNS queries followed the same route: an app may first use the system resolver, then pass the resulting IP address to the proxy.

Define your goal before judging the results. This guide covers two distinct goals: routing all system DNS queries through the Clash core and using a specified encrypted DNS service, or also routing the connection to the upstream DNS server through the proxy. The first allows encrypted DNS connections to go direct; the second does not. A single “test passed” result can't verify both.

• System proxy: Affects only apps that follow the system proxy settings; it doesn't automatically capture all UDP queries.
• TUN: Uses a virtual network interface to capture IP traffic that matches its routing conditions, but exclusions, permissions, and other VPNs can affect what gets routed.
• fake-ip: Returns a mapped address to apps so the core can retain the domain name; it is not a DNS encryption protocol.
• DoH / DoT: Encrypts the connection to a DNS resolver, but that connection can go direct or through a proxy.

Establish a Baseline: Record Both Your Egress IP and DNS Resolvers

Keep Test Conditions Consistent

1. Record the client, core version, operating system, network interface in use, and whether any other VPNs are running.
2. Close other proxy apps and temporarily turn off the browser's “Secure DNS” setting to avoid mixing two DNS resolution paths. Re-enable it later and test it separately.
3. Record your public IP and DNS test results with the proxy off, with only the system proxy enabled, and with TUN enabled.
4. Before each test, clear the system and browser caches, then start a fresh test. Use a newly generated test domain rather than querying the same cached domain again.

Open https://www.dnsleaktest.com/ or https://browserleaks.com/dns in your browser. These external testing services can access your current IP address and test query information. The results generally show the egress IP used when a recursive resolver queries authoritative servers; they can't, on their own, prove which transport protocol was used between your app and the resolver.

Seeing multiple DNS IP addresses isn't enough to prove a leak. Public DNS services may use multiple egress IPs, and multiple configured upstreams may take part in a query. Focus on whether the resolvers are expected and whether queries bypass the proxy route you intended to use.

System Checks: Interface DNS, Caches, and Port 53

Windows: Check Every Interface, Not Just Wi-Fi

Run these commands in PowerShell. The first shows DNS settings for each interface, the second clears the cache, and the third makes a query. Check every active interface, including Ethernet, Wi-Fi, and virtual adapters.

Get-DnsClientServerAddress
Clear-DnsClientCache
Resolve-DnsName example.com -Type A

A successful Resolve-DnsName command means only that it returned an answer; it doesn't prove that a proxy was used. The default server shown by nslookup example.com also isn't necessarily the final upstream after transparent DNS interception. Check core logs, routing, and traffic on the physical interface together.

macOS and Linux: Identify the Local DNS Stub

# macOS: Show DNS settings for each scope
scutil --dns
# macOS: Flush the system DNS cache
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux systems using systemd-resolved
resolvectl status
resolvectl flush-caches
resolvectl query example.com

On Linux, if /etc/resolv.conf points to 127.0.0.53, it usually means systemd-resolved is providing a local stub; it doesn't mean the upstream resolver is also on your machine. Check DNS Servers and DNS Domain for each link in resolvectl status. On distributions without systemd-resolved, use the relevant network management tool.

Capture Traffic on the Physical Interface

In Wireshark, start with the display filter dns || tcp.port == 853 to find standard DNS and common DoT connections. On macOS or Linux, you can also use the command below; replace en0 with the name of your active network interface.

sudo tcpdump -ni en0 '(udp port 53 or tcp port 53 or tcp port 853)'

If you see unencrypted public-domain DNS queries on the physical interface going to your router or ISP, trace their source. DoH usually uses port 443, so the filter above can't rule it out. Queries seen on a TUN virtual interface may be traffic captured before routing; don't assume they were sent over the physical network.

mihomo Configuration: TUN, fake-ip, and DNS Hijacking

The snippets below are meant to be merged into an existing configuration, not used as a complete subscription. Keep your existing proxies, proxy-groups, and rules. If tun or dns already exists, edit that section to avoid duplicate YAML keys. Use your client's override or merge feature to persist the changes and prevent a subscription update from overwriting them.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

What the Key Fields Actually Do

• auto-route: true: Sets up automatic routing for TUN. Desktop clients usually need administrator privileges or service mode.
• strict-route: true: Tightens routing behavior. On Windows, it can help prevent DNS from bypassing the tunnel on multi-homed systems, but may affect virtual machines, local networks, or other VPNs. Behavior varies across operating systems.
• dns-hijack: Sends TCP/UDP port 53 DNS traffic entering TUN to the core's resolver. It doesn't cover arbitrary HTTPS requests or automatically detect every app's built-in DoH.
• listen: 127.0.0.1:1053: Listens on port 1053 at the local loopback address only. System DNS settings usually can't specify a non-standard port, so you can't enter “127.0.0.1:1053” directly in the system DNS address field.
• ipv6: false: Controls how the built-in DNS handles AAAA queries. It doesn't disable IPv6 system-wide or act as an IPv6 leak protection switch.
• proxy-server-nameserver: Resolves proxy node hostnames, avoiding a circular dependency where connecting to a node requires resolving its hostname through that same node.

fake-ip addresses commonly come from 198.18.0.0/16. Seeing one means the mapping mechanism was used; it doesn't mean the remote website's actual address is in a reserved range. If an app gets a fake-ip and then bypasses the core to connect directly, the connection may fail. Fix traffic capture rather than immediately expanding fake-ip-filter. Adding a domain to the filter list changes how its address is returned; it doesn't change the egress route for upstream DNS.

Route Upstream DNS Through a Proxy: Rules and Bootstrap Resolution

If you also want connections to upstream DNS servers for public domains to go through a proxy node, configure an additional DNS egress policy. In mihomo, respect-rules: true makes DNS upstream connections follow routing rules. When using it, configure proxy-server-nameserver to give proxy node hostnames a separate bootstrap resolution path.

The example assumes your existing configuration has a policy group named PROXY with a proxy node selected, not DIRECT. Add the first entry to the dns section from the previous snippet, then insert the rule near the top of your existing rules list. Don't replace your existing rules.

# Merge into the existing dns section
dns:
  respect-rules: true

# Merge into the existing rules list, before rules that may match first
rules:
  - IP-CIDR,1.1.1.1/32,PROXY,no-resolve

This rule routes connections to 1.1.1.1 through PROXY and may also affect other traffic to that IP. It covers only the example's IPv4 upstream; plan a new rule if you use a different DNS address. After saving, check the core's connection log to confirm the DNS upstream matches the intended policy. Seeing respect-rules in the configuration alone isn't enough.

Bootstrap resolution for proxy node hostnames still needs to be considered separately. Even if business domains are resolved through the proxy, the node hostname may be resolved directly during startup. If you also need to prevent direct DNS lookups at startup, use a stable node IP provided by your service provider or a controlled bootstrap mechanism, and keep any required TLS server name settings. Don't permanently hard-code an IP resolved temporarily, or the node may become unreachable when its address changes.

Prevent System DNS Fallback and Other Resolution Bypasses

Don't Confuse fallback with System DNS Fallback

Clash's fallback is another set of upstream resolvers in the core, with fallback-filter controlling how results are used; it is not the operating system's backup DNS. Removing it won't stop the system from sending queries to resolvers provided by DHCP. Conversely, adding more fallback addresses without a clear reason can expose queries to more DNS services.

• Check every upstream entry: In addition to nameserver, check default-nameserver, fallback, nameserver-policy, and direct-nameserver, and understand what each one does. Don't change just one list.
• Check all Windows interfaces: In Settings → Network & Internet, check DNS assignment for every currently active interface. On managed devices with Group Policy, ask your administrator to review policies such as “Turn off smart multi-homed name resolution” rather than changing enterprise network settings yourself.
• Check your browser: In Chrome, Settings → Privacy and security → Security → Use secure DNS may select a separate resolver. Turn it off while troubleshooting, then re-enable it and verify that its connection uses the expected egress route.
• Check Android: Search System settings for “Private DNS.” A specified Private DNS provider usually uses an encrypted connection, which port 53 hijacking won't automatically capture. Settings menus and VPN behavior vary by manufacturer.
• Check IPv6 and split routing: IPv6 DNS on the physical interface, TUN route exclusions, per-app bypass settings, and other VPNs can all create bypasses. Temporarily disabling an option can help isolate the cause; a long-term setup should cover all required IPv4 and IPv6 routes.

If you need a strict policy that stops resolution when the proxy is unavailable, first verify the DNS route, then use controlled routing or firewall rules to restrict direct egress while explicitly allowing node connections and essential network services. Enabling TUN alone doesn't provide a kill switch. For remote machines, corporate networks, and networks that require captive portal sign-in, make sure you have a recovery path first.

Retest Step by Step and Pinpoint the Problem

1. Confirm the configuration loaded: Apply it again and check for unknown fields, duplicate keys, or YAML indentation errors. Startup logs should show that TUN was established successfully.
2. Clear old results: Flush the system cache, fully quit the browser, and reopen it. Use a new test domain each time so cached results don't hide the actual route.
3. Test system resolution: First query using a system command, then run a browser DNS leak test. The results should make sense given your current configuration; a single test page showing a clean result isn't enough.
4. Verify upstream egress: Check DNS destinations, matched rules, and the final policy group selection in core connections and logs. If DNS should use a proxy, confirm it hasn't selected DIRECT.
5. Check the physical network: Capture TCP/UDP port 53 and any relevant encrypted DNS connections. Use process information to investigate unknown port 443 connections; not seeing unencrypted packets isn't conclusive proof.
6. Test after state changes: Repeat the tests after switching Wi-Fi, waking from sleep, changing nodes, and updating the subscription. Confirm that overrides remain in place and routes are re-established.
7. Check failure behavior: In a recoverable local environment, temporarily make the selected proxy unavailable. Confirm whether the system fails as expected or silently switches to another DNS route.

If No Websites Will Load

First determine whether the problem is a DNS timeout or a failed proxy connection. If logs show that the upstream DoH connection failed, check the egress policy for 1.1.1.1:443 and verify that the node is available. If the node hostname can't be resolved, check bootstrap resolution. If you get a fake-ip but the connection times out, check TUN routing, excluded processes, and conflicts with other VPNs. Change one thing at a time and keep the previous configuration so multiple changes don't hide the cause.