Clash DNS Leak Tests and Fixes: Resolution Paths and Leak-Proof Configuration

DNS leaks and the Clash resolution path

When you visit a website, the application usually sends the domain name to a DNS resolver first, then connects to the returned IP address. Proxy rules determine whether the subsequent connection uses a direct route or a proxy, but DNS queries do not necessarily follow the same path automatically. If web traffic goes through a proxy while the domain query is still sent to a local router, an ISP resolver, or another unexpected server, this is what is commonly called a DNS leak.

A “leak” must be judged against the intended design. Having a local DNS resolver handle domains that should connect directly in mainland China is not necessarily a problem. The real concerns are whether domains meant to be resolved on the proxy side are exposed to the local network, whether responses are being improperly rewritten, and whether an application bypasses Clash’s DNS module. The goal is not for a test page to show one fixed address, but for the resolution path to match the rule design.

A typical path can be divided into four layers: the application issues a query, the operating system selects a DNS server, Clash or mihomo receives and processes the query, and the upstream resolver returns a result. Enabling a system proxy only affects connections that follow HTTP or SOCKS proxy settings; it usually does not intercept DNS requests sent by the operating system to UDP port 53. With TUN enabled, the client can capture more system traffic, but DNS hijacking is still required to redirect ordinary UDP/TCP DNS queries to the built-in resolver.

Browsers may also enable DNS over HTTPS, or DoH. This wraps DNS inside an HTTPS connection and sends it to a service selected by the browser. Because this traffic uses port 443, ordinary port 53 hijacking cannot identify it, creating a separate resolution path. Troubleshooting must therefore cover Clash, the operating system, and the browser—not just the DNS switch in the client panel.

Layered DNS egress testing: browser, system, and logs

Before testing, record the current mode: whether the system proxy is enabled, whether TUN is active, whether Clash DNS is enabled, and whether secure DNS is enabled in the browser. Then test in three states: Clash fully disabled, system proxy enabled only, and TUN enabled. Comparing results is more useful than relying on a single screenshot, because caches, network changes, and public DNS routing can all affect the outcome.

Step 1: Test the actual browsing environment

1. Close every browser window and restart the browser to prevent existing connections and memory caches from affecting the results.
2. Visit a trusted DNS testing page, run both the basic and extended tests, and record the resolver IP, network provider, and region.
3. Change Clash’s system proxy or TUN state, run the test again, and compare whether the resolver changes.
4. Review the browser’s Secure DNS, Use secure DNS, or DNS over HTTPS setting and check whether it specifies a separate provider.

Test pages typically generate random subdomains to see which resolver queries the authoritative DNS server. This shows the egress used when that page triggered a query; it does not mean every application uses the same resolution path. Browser extensions, enterprise policies, system caches, and transparent proxies on the network can also change the result, so confirm it with system commands and Clash logs.

Step 2: Check the DNS used by the operating system

On Windows, view the network adapter’s DNS servers in PowerShell and actively query a domain that is not cached:

Get-DnsClientServerAddress
Resolve-DnsName example.com

On macOS, view the current resolver list and system resolution results:

scutil --dns
dscacheutil -q host -a name example.com

On Linux distributions using systemd-resolved, run:

resolvectl status
resolvectl query example.com

The DNS server shown in command output may be a loopback address on the local machine, a LAN gateway, or a virtual address assigned by TUN. Seeing a local address does not mean the query stopped there; confirm which upstream mihomo ultimately selected. Conversely, if the system clearly sends queries straight to the router while no corresponding entry appears in the Clash logs, the request likely never reached the Clash DNS module.

Step 3: Trace the query path through logs

Temporarily raise the client’s log level enough to observe DNS activity, then query a domain you have not visited before. Check for domain resolution, rule matches, upstream connections, or retry failures. Restore the usual log level afterward so extensive debug output does not consume storage over time.

If the logs contain no query records at all, first check the system DNS, TUN DNS hijacking, and browser DoH. If queries are logged but the upstream connection uses an unexpected DIRECT or proxy policy, inspect how the resolver address itself is matched by the rules. If the issue appears only on the first visit and then disappears, also consider the separate DNS caches maintained by the system, browser, and Clash.

Clash Meta (mihomo) DNS configuration and fake-ip

mihomo’s DNS module can receive queries centrally and select upstream resolvers according to the configuration. The example below is intended to clarify how the fields relate; in practice, merge it into your existing configuration and adjust it for your network, core version, and subscription rules. Save the original configuration first to avoid loading failures caused by YAML indentation or field compatibility issues.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
    - "+.local"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - tls://1.1.1.1
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

Understanding nameserver and default-nameserver

nameserver contains the primary upstream resolvers for ordinary domain queries. You can enter plain DNS, DoT, or DoH addresses. Encrypted DNS reduces the chance that the local network can directly read or modify queries, but the upstream provider can still process them, so choose a reliable service within your trust model.

default-nameserver mainly handles bootstrap resolution. For example, when a DoH upstream is written as a hostname, the core must first obtain the DoH host’s IP address before it can establish the encrypted connection. This field typically uses directly reachable IP addresses, avoiding the loop of needing the same DNS service to resolve the DNS service itself. Bootstrap queries may still use ordinary DNS, so choose stable addresses appropriate for the current network.

proxy-server-nameserver resolves proxy server hostnames. When a proxy node is specified by domain, its IP must be obtained before the proxy connection can be established. Configuring these queries separately reduces the chance of a loop between node resolution and ordinary rules. When using newer fields such as respect-rules, first confirm the current mihomo core version and client implementation; older cores may ignore the field or report a configuration error.

How fake-ip participates in rule matching

In fake-ip mode, Clash returns a temporary address from a reserved range to the application while keeping a mapping between the domain and fake IP. When the application connects to that address, the core can recover the original domain and continue matching domain rules. This allows requests to be intercepted earlier and reduces cases where an application uses its own resolved address for a direct connection.

198.18.0.0/15 is a reserved range commonly used for benchmarking, and the 198.18.0.1/16 in the example falls within it. Do not treat a fake-ip address as a website’s real IP, or use the result of pinging a fake IP to judge whether the remote server is healthy. The mapping remains valid only for the lifetime of the current core and its caches.

LAN device discovery, printers, casting, some games, and applications that depend on real IP addresses may not work well with fake-ip. Add the necessary domains to fake-ip-filter so they receive real resolution results. Do not expand the filter without limit, or many domains will return to real-IP resolution, weakening centralized interception and domain-rule matching.

TUN mode and DNS hijacking configuration

Enabling mihomo’s DNS service alone does not mean the system will send queries to it automatically. A client can point the system DNS to a local listening port, or hijack traditional DNS traffic inside TUN. A common desktop configuration is shown below:

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

dns-hijack redirects port 53 queries passing through TUN to the mihomo DNS module, covering the common case where an application specifies its own ordinary DNS server. It generally handles UDP 53 and TCP 53, but cannot automatically identify DoH sent over port 443, nor guarantee that every application using its own network stack, a special virtual adapter, or a kernel-level bypass enters TUN.

Enabling TUN on Windows often requires administrator privileges and a working virtual network adapter component. macOS establishes the tunnel through a system network extension or VPN configuration. Linux requires cooperation between TUN device permissions, routing tables, and firewall rules. Android and iOS clients generally use the system VPN interface to capture traffic, and typically only one primary VPN configuration can remain active at a time.

If domains become completely unresolvable after enabling TUN, first check that the TUN route was created, then check whether mihomo’s DNS listening port is already in use. Also confirm that the firewall is not blocking the core from reaching upstream DNS and that the proxy node hostname can be resolved through proxy-server-nameserver. If node resolution fails, the proxy tunnel cannot be established; when the configuration also requires the upstream DoH connection to use the proxy, this creates a startup loop.

When an enterprise VPN, game accelerator, virtual machine network, container network, or another proxy tool runs at the same time, several programs may compete over the default route and DNS settings. During troubleshooting, pause conflicting tools one at a time, verify the result with Clash running alone, and then decide the route priority. If stale DNS settings remain after frequent network changes, exit the client, restore automatic DNS on the system, and enable TUN again.

Browser DoH and application resolvers

Browsers such as Chrome, Edge, and Firefox can enable encrypted DNS independently. Some try to upgrade the system DNS automatically to the provider’s DoH service, while others let users choose a resolver manually. If that service differs from the Clash configuration, browser tests may show another DNS egress. This does not necessarily mean TUN has failed; the browser may simply be creating a separate HTTPS query connection.

To make the browser use Clash DNS consistently, disable custom Secure DNS in the browser so queries return to the operating system and are then handed to mihomo by system DNS or TUN hijacking. Another option is to keep browser DoH enabled and use Clash rules to decide whether connections to the DoH service go through the proxy or directly. In that setup, however, queries are processed by the remote DoH service, mihomo cannot directly see each query, and domain-based routing may depend on domain information carried by the browser’s subsequent connection.

Some applications bundle fixed DNS, DoH, or DoT settings, while antivirus and parental-control software may install local filtering resolvers. If only one application behaves abnormally, inspect its network settings, startup parameters, and system policies instead of repeatedly changing Clash’s upstream resolvers. Android’s Private DNS usually uses DoT; if it conflicts with the VPN client, temporarily set it to Automatic or turn it off for comparison. Choose the final setting based on your actual needs after testing.

Common DNS leaks and resolution failures: troubleshooting order

Test results still show the local ISP’s DNS

First confirm that browser Secure DNS is disabled, then check whether the system DNS points to the address managed by the client. If only the system proxy is enabled and TUN is not, system-level UDP DNS continuing to go to the router is common. For centralized interception, enable a compatible TUN setup with DNS hijacking and confirm that queries appear in the client logs.

LAN devices become unreachable after enabling fake-ip

Add LAN domain suffixes to fake-ip-filter, and confirm that LAN subnet rules appear before the fallback proxy rule. When accessing a NAS, router, or printer, first use its LAN address to verify basic connectivity. If the IP works but the domain does not, focus on whether the local domain is provided by the router’s DNS, mDNS, or an internal DNS server.

DoH upstream connection times out

Check whether the DoH hostname can be resolved through default-nameserver, then check whether its IP is being routed incorrectly. Some networks restrict particular public resolver services; blindly adding several unreachable upstreams only extends retry times. Keeping a small set of verified upstreams and configuring direct and proxied paths separately makes problems easier to isolate than stacking a long list of addresses.

The proxy node appears available, but websites report that domains cannot be resolved

A node connectivity test may use an existing IP or cached result, so it does not prove that the DNS path works. Check whether the node address is an IP or a hostname; if it is a hostname, confirm that proxy-server-nameserver works. Then query an ordinary domain and inspect the logs to distinguish among an unresolvable node hostname, an unreachable upstream DNS server, and a response rejected by the rules.

Tests show multiple resolvers

Multiple resolvers may come from an upstream service cluster, concurrent browser queries, fallback resolution, or system and browser paths operating at the same time. Do not judge the result as abnormal based on the count alone. Repeat the test with random domains, then disable browser DoH, fallback, and other network tools one at a time to identify which setting introduces the additional egress. If every resolver belongs to an expected upstream and the local network resolver is not handling proxy domains, the result may be by design.

The problem returns after a configuration update

A subscription update may overwrite the client’s DNS section or rename rule groups, causing existing nameserver-policy or upstream routing to stop working. Check whether the client uses the original subscription configuration, an override, or a merged configuration. DNS settings that must persist should be placed in the override mechanism supported by the client, and the final effective configuration should be verified after every update rather than checking only the subscription source file.

A complete investigation should form a closed loop: first decide which domains should resolve locally and which queries should be handled on the proxy side; use browser tests to observe the symptom, system commands to confirm the DNS target, and logs to verify that queries enter mihomo; then adjust fake-ip, upstream resolvers, TUN hijacking, and browser DoH. Change one variable at a time and test again so you can identify which configuration change fixed the issue.