Clash DNS Leak Test and Fix: Practical enhanced-mode and nameserver Configuration

First, identify what is being tested: your exit address is not your DNS resolver

When a browser opens a website, it usually sends the domain to a DNS resolver before connecting to the resulting IP address. Clash taking over web connections does not necessarily mean that DNS requests follow the same path. A common pattern is for the web exit to show a proxy node while the test page still lists the local broadband provider, the resolver supplied by the router, or a public DNS server configured in the operating system. During troubleshooting, record the connection exit and the domain-resolution path separately.

A DNS test page usually shows the resolver that performed the recursive lookup for the test domain, not the address your computer contacted directly. For example, the system may query the router at 192.168.1.1, which then forwards the request to the ISP; the result may show only the ISP's recursive server. With DoH, the page may show an anycast node, partner network, or city that differs from the actual proxy node. A city mismatch alone is therefore not proof of a problem. Also compare the provider name, autonomous system, query count, and results from repeated tests.

Set up three reproducible tests

1. Record your current public exit IP, network provider, and region. Temporarily quit Clash and run one baseline test.
2. Start Clash, but keep TUN disabled. Enable only the system proxy, then run the second test in a private window.
3. Enable the DNS hijack for TUN using this article's configuration, clear the caches, reconnect, and run the third test.

For each round, run one standard test and one extended test, and record the resolver count, organization names, and countries or regions. A single result can be affected by browser caches, test-site load, and DNS anycast routing. For a controlled record, run three rounds with 30 seconds between them. If the same provider resolver appears in all three rounds, the path issue is more clearly persistent than a one-off result.

Determine whether the leak comes from the system proxy, TUN, or browser DoH

The system proxy mainly handles traffic from applications that support HTTP or SOCKS proxies. Traditional UDP 53 DNS requests are usually outside its scope, so the operating system may still send packets to the DNS addresses configured on the network adapter. Clash's mixed port is commonly 7890; it is a proxy inbound port, not a system DNS port. Setting the system DNS to 127.0.0.1:7890 will not provide a working DNS service.

TUN takes over traffic at the network layer and can use dns-hijack to capture DNS requests sent to port 53, then pass them to mihomo's built-in DNS module. This provides more complete coverage for applications, game launchers, and some command-line tools that ignore system proxy settings. However, an application's own DoH or DoT connection still looks like ordinary HTTPS or TLS traffic, so hijacking port 53 alone cannot change its resolver choice.

Trace each request source

• Only the browser shows an abnormal result: Check the browser's “Secure DNS” setting. If it uses a custom DoH service, DNS requests may bypass the operating system's DNS, while the HTTPS connection itself still follows Clash rules.
• Every application shows the local provider: Check mihomo's dns.enable, the TUN status, and dns-hijack. Confirm that the active runtime configuration actually contains the updated DNS section.
• The problem appears with TUN off and clears with TUN on: This usually means the system proxy is not handling UDP 53, while TUN hijacking is working.
• Only IPv6 is affected: Check dns.ipv6, the system's IPv6 default route, and IPv6 reachability through the proxy node. Do not inspect only the IPv4 exit.
• Corporate domains or LAN devices cannot be reached: Internal domains may be sent to public resolvers. Use nameserver-policy or fake-ip-filter to preserve the local resolution path.

Menu labels differ between clients, but the troubleshooting goal is the same. In a desktop client that supports editing the original YAML, open the configuration text via “Profiles” → the menu beside the current profile → “Edit File.” After saving, also choose “Profiles” → the current profile → “Reload.” TUN is usually under “Settings” → “Clash Settings” → “TUN Mode.” If subscription updates overwrite the local file, save the DNS section through an override or merge configuration instead of permanently editing the subscription cache.

Configure enhanced-mode, nameserver, and bootstrap resolvers

The following example uses the mihomo v1.19.10 configuration structure. The key relationships are: default-nameserver resolves the DoH servers' own hostnames, nameserver handles ordinary domain lookups, proxy-server-nameserver can resolve proxy-server hostnames separately, and nameserver-policy assigns resolvers by domain or rule set. Bootstrap resolvers should use IP addresses so that resolving a DoH hostname does not depend on the same DoH service before it is available.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "time.*.com"
    - "ntp.*.com"

  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query

  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query

Why fake-ip helps with rule-based routing

With enhanced-mode: fake-ip enabled, mihomo first returns a reserved address in the 198.18.0.0/16 range to the application and stores the mapping between the domain and fake address. When the application connects to that address, the core can recover the original domain and match rules such as DOMAIN, DOMAIN-SUFFIX, and GEOSITE. This preserves domain information and reduces cases where an application uses the system-resolved IP directly, leaving only the destination IP for routing.

fake-ip does not permanently replace the real public address; it is an internal mapping mechanism used by the core. When the connection is ultimately established, the real destination is resolved and contacted according to policy. It works well for everyday configurations that rely on domain rules, but LAN discovery, printers, time synchronization, some game logins, and applications that validate IP literals may reject fake addresses, so they need to be added to the filter list.

When is redir-host a better fit?

enhanced-mode: redir-host returns the real resolution result to the application and is usually more immediately compatible, but its domain mapping and rule-matching behavior differ from fake-ip. If an older application repeatedly fails under fake-ip, first add its domain to the filter list. Switch temporarily to redir-host for comparison only when the problem is broad and the domains cannot be identified. After changing enhanced-mode, clear the DNS cache and create new connections; otherwise, old records can skew the result.

Add DNS hijacking and strict routing to TUN

Configuring only the dns section is not enough. Requests sent by the system to port 53 on other DNS servers must be redirected to the built-in DNS. mihomo's TUN configuration can use dns-hijack: any:53 to capture these requests. auto-route adds routes, while strict-route reduces the chance of traffic bypassing through another interface on some platforms. Each operating system requires the appropriate permissions; Windows usually needs administrator approval, while Linux needs permission to create TUN devices and modify routes.

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

any:53 handles common DNS requests. Adding tcp://any:53 also covers queries over TCP 53. TCP is used when a DNS response exceeds the capacity of UDP, the server requests a retry, or the application deliberately selects TCP. This does not automatically block the browser's built-in DoH, which uses port 443. To make all browser lookups follow Clash DNS, open the browser's “Settings” → “Privacy and security” → “Secure DNS,” choose the system provider, or disable the custom provider, then test again.

Listening ports and port conflicts

This example uses 0.0.0.0:1053 as mihomo's DNS listen address. Port 1053 is unprivileged, making local debugging easier. TUN hijacking sends port 53 requests into this module, so you normally do not need to enter a DNS address with a port in the system network settings. If another local DNS service is already listening on 1053, the core log will report a bind failure. On Windows, use netstat -ano | findstr :1053 to check what is using the port; on Linux, use ss -lntup | grep 1053 to inspect listening processes.

In a setup without TUN, where the system queries the local DNS service directly, the system generally accepts only the standard port 53. In that case, make the DNS service listen on 127.0.0.1:53 and verify permissions and conflicts. This approach depends on platform network settings and can be overwritten by network changes, VPN software, or DHCP updates. For desktop Clash Meta clients, TUN with DNS hijacking is usually easier to keep consistent.

Configure fake-ip-filter precisely to avoid LAN and special-protocol failures

Domains on the filter list bypass fake-ip responses and use real addresses instead. A list that is too short can break device discovery, LAN administration pages, or time synchronization; a list that is too broad makes many domains resolve to real IPs early and weakens domain-based mapping. Start by extracting specific domains from the failure log, adding the narrowest suffix or full domain first. Do not exclude an entire large top-level domain.

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "router.asus.com"
    - "time.windows.com"
    - "time.apple.com"
    - "stun.*"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"

*.lan and *.local mainly support home LANs and local discovery. Returning real addresses for time servers helps some system services that accept only direct UDP traffic. Connectivity-check domains can affect how the system decides whether it is “online.” Before adding entries, inspect the queried domains in the client log; the domains used for these checks vary across operating-system versions.

Which DNS should resolve LAN domains?

If a corporate or home domain can only be resolved by the router, use nameserver-policy to send the relevant suffix to the internal DNS. For example, if the router DNS is 192.168.1.1 and the internal domain is home.arpa, define a policy only for that suffix. Confirm that the address provides recursive resolution before using it, and do not keep using the private LAN address on public networks.

dns:
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1
    "+.corp.example":
      - 10.20.0.53

Internal DNS addresses should usually be handled as direct connections; otherwise, the query may be sent through a proxy node that cannot reach them. If the client supports configuration merging, place the LAN-only policy in a local override enabled only on the relevant network. When a laptop switches from an office network to a home network, check whether a private address such as 10.20.0.53 is still referenced, or every query may wait for a timeout.

Clear caches and verify the fix

After changing DNS settings, old connections and multiple layers of caching do not disappear immediately. The operating system, browser, applications, and mihomo core may all retain resolution results. Before verifying, reload the configuration, stop and restart TUN, then clear the system DNS cache. On Windows, run ipconfig /flushdns; on Linux with systemd-resolved, run resolvectl flush-caches; on macOS, run sudo dscacheutil -flushcache and restart mDNSResponder. Close every browser window and reopen it, or use a new private window.

A comparable test record

On Windows 11 24H2 with mihomo v1.19.10, a home broadband connection, and dual-stack IPv4/IPv6, the baseline extended test issued 20 queries and listed two local-provider recursive resolvers. With only the system proxy enabled, the web exit changed to the proxy node, but the same provider resolvers still handled all 20 queries. After enabling fake-ip, two DoH nameservers, TUN, and any:53 hijacking, three consecutive rounds showed only the public DNS networks specified in the configuration; the local provider resolvers no longer appeared.

These figures illustrate how to compare before and after, not a result every network should produce. Public DNS uses anycast, so a test page may show one to four edge nodes in different rounds. The fix can be considered effective when the organizations match the configured targets, no local resolution path is mixed in, and the web exit matches the routing expectations. If both resolver types appear, continue checking browser DoH, IPv6 routing, or a background application bypassing the system DNS.

Cross-check from the command line

Beyond browser-based testing, query mihomo's port 1053 directly to confirm that the built-in DNS is responding. On Windows, after installing a tool that supports specifying a port, run dig @127.0.0.1 -p 1053 example.com; the same command works on Linux and macOS. In fake-ip mode, an address within 198.18.0.0/16 is expected. If the request times out, check the listening port and core log before changing rule groups.

Then run a normal system lookup, such as nslookup example.com. When TUN hijacking is enabled, even if the server name shown by the command is still the router or the address in the system settings, the actual port 53 traffic may already have been captured by the core. The final assessment should combine the mihomo log, the test-site results, and before-and-after comparisons; do not rely only on the server shown on the first line of nslookup.

Common problems and fixes

All domains fail to resolve after configuration

• Check that YAML indentation uses spaces consistently, and that dns and tun are top-level sections.
• Confirm that default-nameserver uses directly reachable IP addresses rather than only DoH hostnames.
• Check whether the local network blocks the selected DoH service. If necessary, replace it with a resolver reachable from the current network.
• Check whether port 1053 is already in use, then search the client core log for dns, listen, and timeout.

Testing looks normal, but some applications cannot sign in

First find the domains accessed by the application in the log, then add them one at a time to fake-ip-filter for a narrow test. For STUN, LAN discovery, NTP, or connectivity checks, real-IP responses are often a better fit. If adding the full domain restores access, consider whether the same service suffix also needs to be covered. Do not filter every domain at the outset, or the test cannot reveal which request type is incompatible with fake-ip.

IPv4 works, but IPv6 still shows the local network

Confirm that the proxy node and selected DNS support the intended IPv6 behavior. If the current proxy path does not handle IPv6, temporarily set dns.ipv6 to false for comparison and see whether the test page stops returning AAAA results. Also check whether TUN covers the IPv6 default route. The long-term choice should follow the node's capabilities: either take over IPv6 fully or disable the path consistently in both the system and DNS, rather than changing only one switch.

The configuration reverts after a subscription update

Subscription files are generated remotely, so refreshing them replaces the local cache. Save DNS and TUN settings through the client's override, merge configuration, or script extension. The path is usually “Profiles” → the menu beside the current profile → “Override Settings.” Then choose “Profiles” → “Update” and reopen the configuration preview to confirm that enhanced-mode, nameserver, and dns-hijack are still present.