Clash TUN Mode and DNS Leak Prevention: Advanced Setup Guide

Why TUN Mode Does Not Automatically Prevent DNS Leaks

Clash TUN mode creates a virtual network interface and captures traffic that might otherwise bypass the system proxy. In Mihomo-based clients, such as Clash Verge Rev, the TUN interface can route many TCP and UDP connections into the core, where rules select an outbound. That is a useful foundation for system-wide proxying, but it does not by itself guarantee that every DNS query follows the same path.

DNS resolution is a separate part of the connection process. An app may ask the operating system to resolve a hostname before opening a socket; a browser may use its own encrypted DNS service; or an application may connect directly to a known IP address and never make a DNS request at all. Meanwhile, Mihomo may need to resolve proxy-server hostnames before it can establish an outbound connection. These requests have different origins and purposes, so a single “TUN on” switch cannot make them all behave identically.

A DNS leak, in practical terms, is a query that reaches a resolver outside the path you intended. For example, your browser connection may go through a proxy while a DNS request still goes to the router or an ISP resolver. This can produce inconsistent results: a site may resolve to a local or filtered address, a connection may use a different IP than expected, or a DNS test may show the network resolver even though the proxy appears connected.

It helps to separate three questions when diagnosing the setup:

• Is the query captured? TUN DNS hijacking can redirect conventional DNS traffic, commonly UDP or TCP port 53, into Mihomo. It cannot automatically intercept every app-specific encrypted DNS connection.
• Which resolver handles it? Mihomo’s dns section determines how captured and core-originated queries are resolved, including whether Fake-IP is used and which upstream nameserver applies.
• How does the resolver connection leave the device? DNS requests to an upstream resolver may be direct or may follow proxy rules, depending on the configuration and the Mihomo version.

Those distinctions matter because “the query is captured” and “the query is encrypted or proxied” are not interchangeable. DNS hijacking can bring a classic port-53 request into Mihomo, but the selected upstream and its outbound route still determine where that request goes next. Similarly, a test website reporting a resolver address is evidence about the resolver path, not proof that every application on the device behaves the same way.

How TUN, Fake-IP, and Nameservers Work Together

A reliable setup is a collection of compatible settings rather than one magic option. The tun section controls traffic capture and routing behavior. The dns section controls Mihomo’s resolver, response mode, and upstreams. Rules and DNS policies then determine how particular destinations are handled. If one layer is missing or conflicts with another, TUN can appear active while DNS still takes an unexpected route.

TUN capture and DNS hijacking

With auto-route enabled, Mihomo can install routes that direct traffic through the TUN interface. auto-detect-interface helps the core identify the active network interface on supported systems. strict-route is intended to reduce bypasses by applying stricter routing behavior, but its effects and available options can differ by operating system and core version. Check your client’s Mihomo version and platform-specific documentation before assuming a setting is supported or has identical behavior everywhere.

The dns-hijack entry any:53 asks the TUN stack to redirect conventional DNS requests on port 53 to Mihomo’s DNS handling. This is useful for applications that send standard DNS to a configured system resolver. It does not mean that every DNS protocol is intercepted: DoH typically travels over HTTPS, while DoT commonly uses a dedicated encrypted connection. Those flows may look like ordinary application traffic unless you manage them through application settings, firewall policy, or explicit routing rules.

Fake-IP, nameserver-policy, and respect-rules

In fake-ip mode, Mihomo can return a synthetic address for a hostname and keep the hostname-to-address association inside the core. When the app later connects to that address, Mihomo can recover the original hostname and apply domain rules. This is particularly useful when rules depend on domain names, but it can expose compatibility problems with software that expects real DNS answers, performs unusual address checks, or keeps stale DNS caches.

nameserver-policy selects an upstream resolver for matching domains. It is useful when you want a specific resolver for a domain group rather than applying the same upstream to every lookup. The match patterns and supported rule syntax depend on the core’s current configuration format, so validate the profile after editing it. A policy that is too broad or placed incorrectly can send queries to an unexpected resolver even when the YAML parses successfully.

respect-rules tells Mihomo to resolve DNS connections according to routing rules rather than treating every resolver connection the same way. This can help align upstream DNS traffic with your proxy policy, but it is not a substitute for working rules or reachable bootstrap resolution. In particular, Mihomo may need to resolve the hostname of a proxy server before it can use that proxy. A suitable proxy-server-nameserver can provide a deliberate resolver for that bootstrap task and help avoid a circular dependency in which DNS needs a proxy that itself cannot be resolved.

These options address different stages. Fake-IP affects the answer returned to an application; nameserver policy chooses an upstream for a query; respect-rules affects the route taken by DNS connections; and DNS hijacking captures traditional port-53 traffic at the TUN layer. A working configuration considers all of them rather than assuming one setting covers the others.

Configure TUN and DNS in Mihomo

The following example is a starting point for a desktop Mihomo profile. It uses TUN capture, Fake-IP, encrypted upstream resolvers, a separate resolver for proxy-server hostnames, and a sample domain policy. Resolver URLs and policy entries are examples, not universal recommendations: use resolvers you trust and that are reachable from your network.

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
    - 9.9.9.9
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.quad9.net/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
  respect-rules: true

Before applying the example, check whether your client manages DNS or TUN options outside the profile. Some GUI clients expose these settings in their own controls, merge them with subscription YAML, or overwrite profile values during an update. If the client has a TUN toggle, enable it there as well as confirming the effective Mihomo configuration. Avoid maintaining competing copies of the same setting in multiple places unless you understand which source takes precedence.

1. Confirm the core. Check the Mihomo version shown by the client and verify that it supports the fields you plan to use. A parser error or an ignored field is more likely with an older or different core.
2. Back up the profile. Save a copy of the current working YAML before editing. Change one group of settings at a time so that a regression can be traced to a specific change.
3. Set up TUN capture. Enable TUN and the platform’s required permissions in the client. On some systems, administrator privileges or permission approval are required before routes can be installed.
4. Configure DNS deliberately. Add the DNS settings, then review the effective profile for duplicate keys. YAML accepts only one value for a given key at the same level; duplicate blocks may be rejected or behave differently than intended.
5. Validate and restart. Use the client’s configuration check if available, apply the profile, and restart the core if the DNS listener or TUN interface does not update cleanly. Confirm that the client reports TUN as active rather than relying only on a saved toggle.
6. Test a known domain. Use a domain that should match a specific rule or DNS policy. Check the Mihomo logs and connection view to see whether the expected hostname, policy, and outbound appear.

The example sets ipv6: false as a conservative starting point for environments where IPv6 is not deliberately configured. This is not a general recommendation to disable IPv6 permanently. If you need IPv6, enable it only after verifying that the client, operating system, TUN stack, rules, and DNS upstreams handle IPv6 consistently. Otherwise, an IPv4-only test may pass while a real application chooses an IPv6 route that bypasses the path you intended.

The sample listen value is also environment-dependent. Desktop clients may integrate DNS handling without requiring you to expose a listener to the local network. Do not expose a resolver on all interfaces unless you need that behavior and have secured access to it. A local DNS listener should not become an unintended open resolver for other devices.

Verify the Route and Troubleshoot Leaks

Testing should cover both DNS resolution and the resulting connection. No single website or command can certify every application, but a short, repeatable check can reveal whether the main path behaves as expected. Start with the client logs, then compare them with operating-system and browser behavior.

On a desktop, try a lookup from a terminal, such as nslookup example.com or dig example.com, and compare the result with Mihomo’s DNS logs. These tools commonly use the operating system’s resolver path, but their exact behavior depends on the platform and command options. A successful lookup proves that a name resolved; it does not prove that an application’s later connection used the expected proxy group. Check the connection log as well and confirm that the hostname matched the intended rule.

For a second test, compare a normal command-line lookup with the browser’s secure DNS setting. Temporarily disable browser DoH only while diagnosing, then test again. If the query appears in Mihomo’s logs only after changing that browser setting, the browser was using a separate resolver path. Decide whether to keep browser DoH enabled and manage it deliberately, or to use the system resolver consistently; do not assume TUN port-53 interception controls HTTPS-based DNS.

Also test after changing networks. A laptop may behave differently on home Wi-Fi, a hotspot, or a corporate network because the active interface, IPv6 availability, DNS interception, and firewall rules change. If a problem appears only on one network, compare the operating system’s DNS server list and routes there before rewriting the entire Mihomo profile.

If DNS requests do not appear in Mihomo at all, first verify that TUN is active and that the operating system routes traffic through the virtual interface. Then check whether the application uses DoH or DoT. If requests appear but the wrong upstream is chosen, inspect policy patterns, YAML indentation, and the effective configuration after the client merges its settings. If DNS works but connections fail, look beyond DNS: a dead proxy node, a rule ordering issue, TLS validation, or a stale Fake-IP mapping can produce a similar symptom.

When Fake-IP causes an application problem, test the affected domain with an appropriate real-IP or fake-IP filter supported by your Mihomo version, rather than disabling Fake-IP globally as the first response. Some software embeds IP assumptions or does its own address validation, while other applications work normally with synthetic answers. Apply exceptions narrowly, verify the syntax against the current core, and retest domain-based routing after the change.

For IPv6, check more than the DNS answer. Confirm whether the system has an IPv6 address and default route, whether Mihomo DNS returns AAAA records, and whether the TUN stack and rules capture IPv6 connections. If your network or proxy setup does not support IPv6 reliably, a temporary IPv6-off test can help isolate the issue. If IPv6 is required, restore it and configure its DNS and routing path rather than treating a passing IPv4 test as proof that both address families are covered.

Frequently Asked Questions

Does enabling TUN stop every DNS leak?

No. TUN can capture traffic according to its routing and DNS-hijack configuration, but applications may use encrypted DNS, a custom resolver, or direct IP connections. TUN also does not decide by itself which upstream resolver Mihomo uses. Check the DNS settings, routing rules, client behavior, and application-specific secure DNS options separately.

Should I always use Fake-IP?

Not necessarily. Fake-IP is useful when you want Mihomo to retain hostname context for domain-based routing, but a small number of applications may expect real DNS answers or behave unusually with synthetic addresses. Start with the mode that suits your profile and test important apps. Use targeted exceptions when there is a reproducible compatibility problem.

What does respect-rules change?

It allows DNS connections to follow routing rules instead of assuming all upstream resolver traffic should use the same path. It does not create correct rules automatically, and it does not eliminate the need to resolve proxy-server hostnames. Review the effective rules and configure an appropriate bootstrap resolver where needed.

Can I keep browser DoH enabled?

Yes, if that is your preference, but treat it as a separate DNS path. Browser DoH usually travels as HTTPS traffic, so a port-53 DNS hijack does not necessarily capture it as a DNS request. Confirm how the browser connection is routed and whether its resolver choice is acceptable for your privacy and policy requirements.

Some proxy clients make TUN setup or rule editing easier, but their defaults may expose fewer details when DNS takes an unexpected route. Mihomo-based Clash clients offer configurable capture, DNS policies, logs, and rule-based routing in one workflow, which makes it easier to investigate each layer instead of guessing. If you want to test that approach on your device, you can Download Clash and apply the settings that fit your network.