Clash DNS Leak Test and Protection Setup: From Test Results to Rule Fixes

Start by defining what counts as a DNS bypass

Before connecting to a domain, a device usually needs to resolve it to an IP address. Clash can take over this step, or it may proxy only the TCP or UDP connection after resolution. If web traffic passes through the proxy while domain queries still go directly to DNS servers provided by the local network, the query path and application traffic have split. DNS test sites typically label this as a DNS leak.

However, seeing a local ISP, public DNS service, or resolver from another region in the test results does not necessarily mean the configuration has failed. Public DNS services often use anycast networks, so the same server address may terminate in different cities. A resolver may also forward queries to another egress node. The test page shows a recursive resolver or egress infrastructure, not necessarily the address entered in the configuration file.

A reliable diagnosis must answer three questions: Who receives the application's query, how does the Clash core reach its upstream resolver, and which proxy rule matches the resulting application connection? Looking only at the country, city, or server name shown on a test page cannot fully reconstruct this path.

Build a repeatable Clash DNS leak testing process

Before troubleshooting, lock down the test conditions. Do not repeatedly refresh the page while changing the configuration, node, and browser settings at the same time; it becomes difficult to tell which change affected the result. Keep a copy of the current configuration and record the core type, operating mode, system proxy status, TUN status, and browser Secure DNS status.

Step 1: Establish a baseline with the proxy disabled

Temporarily disable the system proxy and TUN, open the test page, and record the resolver names, count, and approximate locations. This set of results represents the network's normal DNS path. Then enable Clash and test again in a new private browser window. If the two results are identical, the system may still be using the original path, but confirm this against the cache and any DoH built into the application.

Step 2: Clear caches and use a fresh domain

The operating system, browser, Clash core, and upstream servers may all cache resolution results. Refreshing the same page may not generate a new DNS query. During testing, clear the operating system's DNS cache, quit and reopen the browser, and use a new random domain supplied by the testing tool. If the client offers a Clear DNS Cache or Restart Core function, run it after changing the configuration.

Step 3: Distinguish system proxy from TUN

The system proxy mainly affects applications that honor HTTP or SOCKS proxy settings. A normal UDP port 53 query does not automatically enter Clash just because the system proxy is enabled. TUN mode receives more traffic at the network layer and can hand traditional DNS queries to the core through DNS hijacking rules. The same configuration can therefore produce different test results in system-proxy and TUN modes.

Step 4: Review core logs and connection records

Open the client log during testing and search for the test domain, DNS, UDP, DoH, or rule-match entries. Logs may show a domain mapped to a fake IP, a query sent to a nameserver, or a connection matching a DIRECT or PROXY policy. This evidence is usually more direct than the geographic labels on a test page. If the test domain never appears in the log, the query probably did not enter the active core.

1. Keep one configuration file and one proxy node fixed.
2. Record the system proxy, TUN, IPv6, and browser Secure DNS states.
3. Run one test after clearing the caches.
4. Change only one option before the next test round.
5. Compare the core log, connection list, and test results.

Path differences between fake-ip and redir-host

Common Clash enhanced DNS modes include fake-ip and redir-host. Both allow the core to participate in domain resolution, but they work differently. Choose a mode based on rule matching, compatibility with LAN devices, and application behavior—not just on how many resolvers the test page displays.

fake-ip: Return a reserved address first, then restore the domain in the core

In fake-ip mode, Clash returns a mapped address from a dedicated address range. When the application connects to that address, the core looks up the original domain in its mapping table and selects a policy using domain rules. This reduces the chance that the system obtains the real destination IP before handing the connection to the proxy, and helps domain rules remain effective.

fake-ip does not mean that all DNS traffic is automatically intercepted. The application must still send its query to Clash's DNS listening port, or a TUN DNS hijacking rule must forward it to the core. If the browser connects directly to an external DoH service, the query is wrapped in HTTPS, so ordinary port 53 hijacking cannot inspect its DNS content.

LAN names, printer discovery, network connectivity checks, and some gaming platforms may not work well with fake-ip. Add these domains to fake-ip-filter so the core returns real addresses. Keep the filter limited to confirmed issues; an overly broad list weakens fake-ip's domain mapping.

redir-host: Return real addresses while preserving domain handling

redir-host returns the real resolved address to the application. It is often more compatible with software that depends on real IP addresses, but resolution happens earlier and relies more heavily on upstream DNS reachability and responses. This mode was common in older Clash clients; mihomo still supports the related configuration, but newer setups should be tested against the client's capabilities and network environment.

Fix upstream DNS and rule paths

The configuration below explains each field's role; do not overwrite an existing subscription with it directly. Supported fields vary between Clash forks. The original Clash core typically supports basic enable, enhanced-mode, nameserver, fallback, and fake-ip-filter; features such as proxy-server-nameserver, direct-nameserver, nameserver-policy, and respect-rules are mainly found in newer mihomo cores.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

  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://dns.alidns.com/dns-query

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

  fake-ip-filter:
    - "*.lan"
    - "localhost"

default-nameserver handles startup resolution

Encrypted DNS endpoints usually contain a hostname, such as dns.alidns.com. The core must resolve that hostname before it can establish a DoH connection. default-nameserver mainly handles this initial resolution and may also help bootstrap proxy server hostnames. It is not the final upstream for every application domain, so nameserver must still be configured.

nameserver is the standard query entry point

nameserver defines the upstream servers used for normal domain queries. Listing multiple servers can improve availability, but it may also make multiple DNS infrastructures appear during testing. If the goal is to identify where requests originate, start with one stable upstream, confirm the path, and add backups afterward.

DoH and DoT can prevent traditional DNS messages from being sent in plaintext over the local link, but encryption alone does not determine whether a connection uses DIRECT or a proxy. If the upstream connection goes out directly, its egress is still the local network. To have it select an egress according to rules, confirm that the core supports and has enabled the relevant rule-following capability.

proxy-server-nameserver resolves node hostnames

Proxy servers in a subscription may use hostnames rather than fixed IP addresses. The core must resolve a node hostname before it can establish the proxy connection. If that resolution depends on the proxy that has not yet been established, a loop results. mihomo's proxy-server-nameserver explicitly handles this type of query; choose an upstream that is stable and directly reachable from the current network.

nameserver-policy selects only the resolver

nameserver-policy selects an upstream by domain or rule set—for example, sending private domains to the system resolver and region-specific domains to an appropriate resolver. It controls “which DNS server receives the query,” not “which final policy group handles the website connection.” Application traffic is still determined by domain, IP, rule-set, and fallback rules in rules.

The geosite example depends on the core having loaded the corresponding rule data. If the client lacks the rule set, uses an outdated data version, or references a nonexistent rule name, matching may not work as expected. In that case, first test with an explicit domain suffix, then check the rule data source and update time.

Handle fallback and filtering conditions carefully

Older configurations commonly use fallback together with geo-IP checks to choose between resolution results. If configured poorly, the normal and fallback upstreams may be queried at the same time, so the test page shows multiple DNS services. This may be concurrent querying rather than a bypass. After migrating to mihomo, consider using nameserver-policy to assign domains explicitly and reduce hard-to-explain concurrent results.

Handle DNS in the operating system, browser, and applications

A correct Clash core configuration does not mean every application will use it. DNS requests may come from the system resolver, browser Secure DNS, built-in application DoH, a virtual machine, a container, or another device on the LAN. Troubleshoot layer by layer according to the source of each request.

The system proxy does not intercept all DNS traffic

With the system proxy enabled, browsers generally send HTTP or HTTPS connections through the proxy, but system services and applications that ignore proxy settings may still connect directly. Traditional DNS queries are usually sent over UDP or TCP port 53 and do not naturally enter an HTTP proxy. If the client only enables the system proxy, expect some system-level queries to continue using the DNS configured on the network adapter.

Some clients automatically change the system DNS or install a network service when TUN is enabled. Avoid manually assigning different DNS servers to multiple network adapters at the same time, as this can create conflicts. First check the client documentation and runtime log to confirm whether it manages DNS settings, then decide whether manual changes are needed.

Browser Secure DNS can create an independent path

Modern browsers can connect directly to a specified DoH service. This appears as ordinary HTTPS traffic, may bypass the system resolver, and is not captured by dns-hijack: any:53. To test Clash's built-in DNS, temporarily set browser Secure DNS to follow the system, clear the browser DNS cache, and test again.

If browser DoH must remain enabled, treat it as a separate DNS solution. Check the proxy rules, egress path, and failure fallback behavior for the DoH service hostname instead of expecting Clash's fake-ip configuration to intercept queries inside the browser.

Check IPv6 separately

Disabling ipv6 in the Clash DNS configuration usually means the application will not receive AAAA results, but it does not automatically disable IPv6 networking in the operating system. An application may still use a cached IPv6 address or obtain AAAA records through its own resolver. If abnormal results occur only on IPv6 networks, check system IPv6, core IPv6 support, proxy node capability, and IPv6 paths in the rules separately.

Do not permanently disable IPv6 across the entire system just to make a test page display one result. A more reliable approach is to use a controlled test to confirm that IPv6 is actually responsible, then adjust the setup based on node and network support.

LAN devices and containers may not use the host resolver

Virtual machines, Docker containers, Android emulators, and LAN devices often have independent DNS settings. Even when Clash on the host correctly intercepts queries, these environments may still send requests to the router or an external server. To provide Clash DNS to other devices, also check the listening address, firewall, and LAN access permissions. Binding only to the loopback address will not allow other devices to connect.

Check DNS hijacking and route order in TUN mode

TUN mode can receive traffic that ignores the system proxy and is a common way to handle system-level DNS bypasses. In mihomo, dns-hijack can capture traditional port 53 queries and pass them to the built-in DNS module. The exact fields are also affected by client-generated configuration and runtime permissions.

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

auto-route automatically sets routes, while auto-detect-interface helps the core choose the current egress network adapter. If the device has wired and wireless networks, another VPN, or virtual adapters connected at once, auto-detection may select an unexpected interface. When DNS times out or the internet stops working entirely after enabling TUN, check the default route and interface changes instead of changing only nameserver.

any:53 mainly handles traditional DNS. It cannot decrypt external DoH, nor can it guarantee that QUIC, Private DNS, or application-built tunnels enter the built-in resolver. For these protocols, standardize DNS behavior in the application settings or control the relevant connections with domain and network policies.

After enabling TUN, confirm that Clash's own connections to upstream DNS are not mistakenly routed back into TUN, creating a loop. Mature clients usually handle this through core-process exclusions, routing marks, or an outbound interface. If the log repeatedly shows the same DNS query and eventually times out, check the client's service mode, core permissions, and exclusion rules.

Fix rules and configuration based on the test symptom

Final checklist

• The active profile matches the file currently being edited.
• The core type and version support the DNS fields in use.
• The test domain can be found in the core log.
• The applicable scope of the system proxy and TUN has been distinguished.
• The status of DoH built into the browser and applications has been confirmed.
• nameserver, fallback, and policy rules are not issuing redundant queries without a clear purpose.
• The node hostname has a separate, reachable startup resolution path.
• The core has been restarted and the relevant caches cleared after configuration changes.
• IPv4, IPv6, and LAN devices have been tested separately.

The goal of DNS protection is not to make every test page show one fixed name. It is to make the query path understandable and controllable, while keeping it consistent with proxy rules. First confirm that the request enters Clash, then identify which upstream the core selects, and finally check the egress policy for the upstream connection and application traffic. Following this order avoids repeated trial and error across multiple DNS fields.