Clash DNS Leak Test and Prevention: Fake-IP and nameserver-policy Guide

How to Identify a DNS Leak: Resolution Path vs. Connection Route

Being able to open websites in Clash doesn't mean every DNS request follows the intended path. A browser may send connections through an HTTP proxy while querying the system resolver beforehand. Background apps may ignore system proxy settings, and Secure DNS in the browser may open its own DNS-over-HTTPS connection. When troubleshooting, track two things separately: which resolver receives the domain name, and which network route carries the DNS request.

Here, a “DNS leak” means a domain lookup that should use a specified resolution path is instead sent to the local network, an ISP, or another unintended resolver. Using a local resolver for domestic sites set to bypass the proxy is not a leak just because a test page reports a local IP address. Judge the result against your routing goals—not by whether a particular country appears in the results.

Before testing: keep the client, browser, and network conditions consistent

The examples below target the mihomo core. Clash Meta is its former name; older versions of the original Clash core and discontinued clients may not support every field. First, note the core name and version from the client's About or core information page, then export the current configuration. Record the client and core versions separately—“latest Clash” isn't specific enough.

1. Keep a way to roll back. Export your subscription config and local overrides. Note the original settings for system proxy, TUN, and browser Secure DNS.
2. Use consistent test conditions. Compare results on the same network, with the same node and browser. Pause other VPN and proxy tools during testing.
3. First rule out browser-level DNS. In Chrome, look under Settings → Privacy and security → Security for “Use secure DNS.” In Firefox, check Settings → Privacy & Security for “DNS over HTTPS.” Menu names may vary by version.
4. Make sure your changes persist. A subscription update may replace the original config file. Save changes through the client's local override or merge feature, then check the final runtime config.

Online DNS leak tests: compare results, not locations

Open DNSLeakTest, run the Standard test, then the Extended test. The test site uses random subdomains to observe which recursive resolvers query authoritative servers. Results therefore usually show the resolver's egress—not necessarily the server address in your system settings or the proxy node's address.

How to record the three test results

1. Baseline: Turn off traffic handling by the client, run a test, and record the resolver IP, its operator, and your current network.
2. System proxy: Enable the client's system proxy, leave TUN off, and test again. If the results are unchanged, the test may still be using the original DNS path.
3. TUN: Enable the DNS and TUN settings below, test again, and record the same details. Check the DNS connection in the client's connection panel.

Run each test twice. If the results differ, check the cache, browser Secure DNS, and concurrent queries to multiple upstreams before switching nodes. Public resolvers may use anycast and distributed egress, so the country or city shown by a test site may be inaccurate. Focus on whether the resolver operator matches your expectations and whether disabling a DNS path changes the results.

Online tests only cover queries triggered by the browser; they can't prove that every app on your system is using the intended path. Run local queries too, and inspect traffic on the physical network adapter if needed. Don't upload full logs containing subscription links, visited domains, or access tokens to public forums.

Basic fake-ip setup: match domain names to connections

In Fake-IP mode, the app first receives a virtual address. The core then uses its mapping to recover the domain and match it against rules. This can reduce reliance on real DNS lookups before a connection is established, but it isn't encryption and doesn't automatically intercept every DNS request. If an app bypasses the core after receiving a virtual address, connections may time out.

The following is a config snippet to merge, not a complete subscription. Keep your existing proxy nodes, groups, and rules. If the runtime config already contains dns:, merge these fields under it; don't add a second top-level key with the same name at the end of the file.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "+.qq.com":
      - https://dns.alidns.com/dns-query

• listen limits the DNS service to port 1053 on the local machine. System DNS settings usually can't specify this port, so entering only 127.0.0.1 doesn't mean DNS is being intercepted.
• default-nameserver resolves the domain names of DNS servers themselves (bootstrap resolution); it's not the regular upstream for ordinary domains.
• proxy-server-nameserver provides a resolution path for proxy node domain names, helping prevent a circular dependency between resolving a node and connecting through the proxy.
• In nameserver-policy, +.qq.com matches the domain and its subdomains, sending them to the specified upstream. Other domains use nameserver unless another rule changes how they are resolved.
• fake-ip-filter makes matching domains return real DNS answers. It doesn't set them to bypass the proxy, and it doesn't guarantee that public DNS can resolve local network names.

This example temporarily disables AAAA responses to reduce variables during initial troubleshooting. It doesn't disable IPv6 in the operating system or prevent apps from using cached IPv6 addresses. If your network needs IPv6, restore it and verify IPv6 routing, DNS, and proxy handling end to end. Don't rely on a single toggle to hide a routing problem.

Fallback filtering: choosing an answer doesn't stop queries from being sent

It's easy to mistake fallback for “contact the backup server only if the primary times out.” In common configurations, the primary upstream and fallback may be queried in parallel, with filters determining which set of answers to use. As a result, multiple services may see queries for the same domain. This doesn't prove that queries are restricted to a single resolver.

The standalone example below prioritizes addresses in mainland China. If you use this approach, merge these fields under the same dns: key. It serves a different purpose from the single-upstream setup above; verify the basic setup first before adding fallback.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

This example uses GeoIP conditions to assess the primary DNS answers. Answers that don't meet the CN condition, or fall within the listed address ranges, trigger use of the fallback results. The actual behavior depends on the geographic data and core implementation; IP geolocation isn't a measure of domain trustworthiness. International CDNs, enterprise services, and delayed data updates can all produce unexpected choices.

If you only need specified resolvers for a few known domains, nameserver-policy is easier to verify than broadening fallback filters. Don't assume domains matched by a dedicated resolver policy still use the default primary-upstream and fallback behavior. Check the documentation and query logs for your version.

TUN DNS hijacking: catch queries that bypass the system proxy

The system proxy mainly serves apps that honor proxy settings; it doesn't mean system DNS is being intercepted. TUN receives traffic through a virtual network adapter and passes matching DNS requests to the core's DNS module. You can merge the snippet below with the basic DNS config, but creating a virtual adapter still depends on system permissions, the client's service, and platform support.

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

any:53 matches UDP 53 requests entering TUN; the second entry adds TCP 53. These aren't system firewall rules—only traffic that actually enters the core's handling path can be processed. Multiple network adapters, virtual machines, containers, other VPNs, and platform-specific routing can all affect this.

Other DNS paths beyond port 53

• DoH: Usually uses HTTPS on port 443, so it can't be identified as traditional DNS traffic by hijacking port 53 alone. Manage Secure DNS in the app or route its connections explicitly.
• DoT: Usually uses TCP port 853. Private DNS on mobile devices may use this path, so check it separately.
• Local network discovery: mDNS commonly uses UDP port 5353 and isn't covered by the regular DNS hijacking described here. Test printers, casting devices, and local name discovery separately.

If the whole machine loses internet access after enabling this, turn off TUN first to restore connectivity, then check administrator permissions or service mode, the default outbound adapter, and routing conflicts. Don't enable TUN in multiple clients at once. To resolve a port conflict, don't expose the DNS service on 0.0.0.0; changing the listen address also affects access control on your local network.

Verify and finalize: config, traffic handling, and subscription updates

First, check port 1053 and the Fake-IP response

Run these commands on a system with dig installed. Specifying the port lets you test the core's DNS directly, regardless of whether the operating system has switched resolvers. If the tool isn't installed, use the client's DNS diagnostics. Standard nslookup uses port 53 by default.

dig @127.0.0.1 -p 1053 www.wikipedia.org A
dig @127.0.0.1 -p 1053 www.qq.com A
dig @1.1.1.1 www.wikipedia.org A

The first two commands test the core's DNS directly. With the example Fake-IP config, an unfiltered A query usually returns a mapped address in the 198.18.0.0/16 range; this doesn't show which real upstream was used. The third command may also be intercepted by the core if TUN is enabled and port 53 hijacking is working. Even if the tool reports 1.1.1.1 as the server, that doesn't prove the request actually reached that address.

Then check the physical network adapter and live connections

For further verification, select the active network adapter in Wireshark and filter with udp.port == 53 || tcp.port == 53 || tcp.port == 853. Check for unexpected plaintext queries leaving the physical adapter during testing. This filter doesn't cover DoH, and seeing no port 53 traffic doesn't prove every query uses the proxy. Use client logs and the connection panel to confirm the egress route for encrypted upstream connections.

1. Clear old caches. On Windows, run ipconfig /flushdns. On Linux with systemd-resolved, run resolvectl flush-caches. Then restart the test browser to avoid interference from existing connections.
2. Run the online test again. Keep the same node and browser settings, then compare the resolver operator and results with the baseline.
3. Retest your actual use cases. Check websites in mainland China and elsewhere, corporate intranet services, and local network devices. Make sure dedicated DNS policies haven't broken internal name resolution.
4. Verify persistence. Update the subscription and restart the client. Check that dns, tun, and policy fields are still present in the runtime config.