Clash DNS Configuration and Leak Prevention Guide

Where DNS Resolution Sits in the Proxy Chain

Proxy software only handles connections that have already been established, while domain resolution happens before a connection is opened. If DNS requests go through the system's default resolver instead of Clash's built-in DNS module, two problems arise: first, local DNS requests are sent directly to your ISP's or local network's resolver, exposing which domains you've visited — this is what's known as a DNS leak. Second, domain-based rules such as DOMAIN and DOMAIN-SUFFIX in the rule engine may fail to match the correct target, because the IP the client receives doesn't line up with the domain the rules expect, causing routing errors.

Both Clash and Clash Meta (the mihomo core) provide a dedicated dns configuration block that takes over the client's domain resolution process instead of relying on the system's hosts file or the DNS configured in system network settings. The core fields of this module include enhanced-mode (resolution mode), nameserver (upstream DNS), fallback (backup DNS), and whether fake-ip-related filter rules are enabled. Understanding what each of these fields does is the prerequisite for diagnosing routing issues and DNS leaks.

Choosing Between fake-ip and redir-host

Clash's enhanced-mode supports two values, and their working principles and use cases differ significantly — picking the wrong mode is the root cause of many routing errors and connection failures.

fake-ip mode

When the client queries a domain, the DNS module doesn't actually resolve it. Instead, it assigns a fictitious IP from a predefined address block (for example 198.18.0.1/16) and returns that to the system. The application connects using this fake IP, and when Clash establishes the TCP/UDP connection, it reverse-looks-up the original domain from the fake IP and hands it to the rule engine to decide which proxy route to use — the actual domain resolution only happens at this stage. The advantage of this approach is that no real browsing records are leaked to any upstream DNS, and rule matching is more precise since the rule engine works with the original domain rather than a resolved IP. The downside is that it depends on a fake-IP-to-domain mapping table; some services that strictly validate client IPs, LAN device discovery protocols, and scenarios that need genuinely resolved results (such as multi-threaded speed testing in some download managers) may misbehave. You'll need to use fake-ip-filter to exclude these domains from fake-IP handling and fall back to real resolution.

redir-host mode

In this mode, the DNS module directly resolves domains into real IPs using the configured upstream servers and returns them to the system, so the client receives an actual address. Historically, this was used alongside early transparent proxy setups (iptables REDIRECT, TPROXY), where the proxy server needed to reconstruct the target domain from the Host header or SNI to match rules, because transparent proxies intercept IP connections without knowing the domain. Its limitations are equally clear: since the real resolution goes through Clash's configured upstream DNS, a poorly chosen upstream can return an IP that doesn't match the actual nearest node, which is unfriendly to multi-route CDN services. Also, because the client receives the real IP directly, some detection mechanisms that identify proxies based on IP ranges can spot the proxy traffic more easily.

Overall, the mainstream approach today is to default to fake-ip, and only use fake-ip-filter for localized exceptions in the rare cases that genuinely need real IPs, rather than switching wholesale to redir-host. redir-host is better suited to older transparent proxy chains without domain-sniffing capability; ordinary users running TUN mode or system proxy mode almost never need it.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'
    - 'time.*.com'
    - 'ntp.*.com'

Principles for Choosing Upstream DNS Servers

The nameserver field determines which server ultimately resolves a domain, while fallback serves as a backup resolution source, usually paired with the geographic check in fallback-filter. Here are a few principles to keep in mind when choosing upstream DNS:

• Prefer encrypted protocols. Plain UDP port 53 queries are easy for intermediate network nodes to observe or even tamper with. Where possible, configure DoH (DNS over HTTPS) or DoT (DNS over TLS), in the formats https://domain/dns-query and tls://domain:853 respectively.
• Separate resolution paths for domestic and international sites. If you're in mainland China, sites hosted there should resolve through a mainland public DNS to preserve resolution speed and CDN proximity, while sites outside China should resolve through overseas or encrypted DNS, avoiding a situation where mainland resolution results point to nodes that don't apply. This is usually handled via nameserver-policy routing by domain suffix, or by checking whether the resolved result falls within a specific country's IP range using fallback-filter.geoip.
• Avoid mismatches between your proxy node's region and the resolver's region. If every domain is resolved through an overseas DNS, sites hosted in mainland China may resolve to nodes that make access slower or trigger frequent CAPTCHAs.
• Keep at least one fallback. If the primary DNS is unreachable or times out, a fallback ensures resolution isn't interrupted. It's best to use a different provider or protocol for the primary and backup so they don't fail at the same time.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.pub/dns-query
    - tls://223.5.5.5:853
  fallback:
    - https://1.1.1.1/dns-query
    - tls://8.8.4.4:853
  fallback-filter:
    geoip: true
    geoip-code: CN
  nameserver-policy:
    'geosite:cn': 'https://doh.pub/dns-query'
    'geosite:geolocation-!cn': 'https://1.1.1.1/dns-query'

The idea behind this example is: default to a mainland-encrypted DNS, switch to an overseas DNS when a domain matches the international category (via a geosite ruleset), and use fallback-filter as a safety net that checks whether the resolved IP falls within a mainland address range, to avoid misclassification if the domain category list hasn't been updated recently. This combination generally balances fast access to mainland sites with correct routing for international sites.

Verifying That DNS Requests Aren't Bypassing the Proxy

Once the DNS module is configured, you need practical ways to confirm requests are actually going through Clash rather than the system's default resolver. Here are some common methods.

Method 1: Check the client's connection log

Most Clash GUI clients (Clash Verge, Mihomo Party, FlClash, and others) have a connection log or active connections panel, and under normal circumstances every connection routed through the proxy will show its target domain rather than a bare IP. If you see a lot of entries showing only an IP with no domain, it usually means the domain information was already lost before reaching the proxy engine — typically because the system proxy doesn't cover the app making the request, or the app uses a direct-connect method that bypasses the system proxy settings. For this kind of traffic, it's best to switch to TUN mode so everything is taken over uniformly.

Method 2: Capture packets to check for leaked plaintext DNS traffic

Use a packet capture tool (such as Wireshark or the command-line tcpdump) to filter UDP port 53 and common DoH ports, and check whether queries are being sent from your local network interface to servers other than Clash's configured upstream. If, with the proxy enabled, you still capture query records addressed to the ISP DNS configured in your system network settings, that indicates a bypass leak — check whether the system proxy covers UDP traffic, or whether you need to switch to TUN mode to take over all network-layer traffic.

Method 3: Compare resolution results directly from the command line

In a terminal, resolve the same domain once using the system's default resolver and once by explicitly specifying Clash's configured upstream server, then compare whether the returned IPs match and whether the response time is consistent with the expected path.

# Using the system's default resolver
nslookup example.com

# Force a specific server and compare the result
nslookup example.com 223.5.5.5

If fake-ip is enabled and you query a domain using a built-in system tool, you should get back an address within the fake-ip-range rather than a real public IP. This is expected behavior indicating the fake-IP mechanism is working — it doesn't mean resolution has failed.

Method 4: Use an online DNS leak test page

Visit a dedicated DNS leak test website in your browser; the page will list the servers that actually handled the resolution requests. Under normal conditions, only your configured upstream DNS or the corresponding encrypted resolver nodes should appear. If your local ISP's resolver shows up in the list, some traffic is bypassing the proxy and querying directly. Go back and check the scope of your system proxy, whether TUN mode is enabled, or whether the browser itself has an independent DoH setting that's conflicting with Clash's DNS module.

Common Configuration Problems and How to Diagnose Them

Most real-world DNS-related issues fall into the following categories, and going through them one by one usually pinpoints the problem quickly.

1. Rule-based routing matches incorrectly. In most cases this is because redir-host is being used, or fake-ip isn't enabled, so the rule engine receives a resolved IP instead of the original domain, causing domain-based rules to fail. Switching back to fake-ip usually fixes this.
2. LAN devices can't discover or reach each other. This is a typical side effect of fake-ip mode. Add LAN-related domains (such as *.lan or your router's admin domain) to fake-ip-filter so these requests use real resolution instead of a fake IP.
3. Sites in mainland China become slow or trigger extra verification. This usually means mainland domains are being resolved through an overseas DNS and returning an unsuitable IP. Check whether the region logic in nameserver-policy or fallback-filter is configured correctly.
4. Resolution consistently times out. Check whether the configured upstream DNS server itself is reachable — encrypted protocols (DoH/DoT) can be interfered with on some networks. Try switching to a plain UDP server first to see if it's a protocol-level issue before deciding whether to keep the encrypted configuration.
5. UDP-based apps (games, video calls) behave oddly under system proxy mode. System proxy usually only takes over TCP traffic, so UDP requests — including some DNS queries — may not be covered. For these scenarios, it's best to use TUN mode directly, so all protocol traffic and resolution requests are handled uniformly at the network layer.

Once you've chosen the right DNS mode and set up region-based upstream routing, cross-checking with connection logs, packet captures, and online leak tests will confirm that resolution isn't bypassing the proxy, and that the rule engine is getting accurate domain information for routing decisions.