DNS Leak Prevention

DNS Basics

Before understanding DNS leaks, it helps to quickly review how DNS works. DNS (Domain Name System) is the internet's "phone book." When you type www.google.com into a browser and press Enter, your device doesn't inherently know which server's IP address that domain maps to — it first queries a DNS server: "What is the IP for www.google.com?" Only after the DNS server returns an IP address does your device initiate the actual connection.

In a traditional configuration, this DNS query is sent in plain text to the DNS server designated by your Internet Service Provider (ISP). This means your ISP — and anyone else who can monitor your network traffic — can keep a complete log of every domain you've queried, even if you ultimately access those sites through a proxy. The DNS query itself has already leaked your browsing intent.

DNS over HTTPS (DoH) and DNS over TLS (DoT) are two standard methods for encrypting DNS queries, preventing ISPs from eavesdropping on DNS requests in transit. But encrypted DNS alone is not enough — in a proxy setup, you also need to ensure DNS requests travel through the proxy tunnel rather than bypassing the proxy and going directly to an external DNS server.

What Is a DNS Leak

A DNS leak occurs when you have a proxy enabled and website content travels through the proxy tunnel, but DNS queries are not routed through the proxy — instead they go directly to your ISP's DNS servers, or even to a third-party public DNS server (like 8.8.8.8), exposing your domain lookup history outside the proxy's protection.

In Clash's traditional operating mode (Redir-Host mode), DNS leaks are a structural problem:

When you visit www.google.com, the operating system first queries a local DNS server for the real IP address. Once the IP is returned, Clash decides whether to use a direct or proxied connection based on that IP. The problem is that this DNS query happens before Clash processes the connection, using the system's default DNS server (typically your ISP's server) — the entire query completely bypasses the proxy. Even if you ultimately access Google through the proxy, the fact that you visited Google has already been logged by your ISP's DNS server.

A more serious situation occurs in "global proxy" configurations: some users configure a public DNS (such as 8.8.8.8) without routing it through the proxy. This DNS request travels unprotected to a remote server, can still be logged along the way, and adds extra latency — a lose-lose scenario.

The Risks

Privacy exposure: The most immediate consequence of a DNS leak is a privacy breach. Even if connection content is encrypted, DNS queries alone reveal which websites you've visited to third parties. Your ISP, network administrators, and even the Wi-Fi operator at a coffee shop can all log this information.

Degraded accuracy: When DNS queries bypass the proxy, third-party DNS servers (like 8.8.8.8) return resolution results optimized for your real, local exit IP rather than for the region where your proxy exits. This can result in your connection being routed to a geographically suboptimal server, actually slowing things down.

Inconsistent access: Some networks apply DNS-level filtering or hijacking to specific domains — returning an incorrect IP so the connection fails outright. If DNS requests don't go through the proxy, even a perfectly working proxy node may be unable to reach certain sites because the lookup itself was tampered with before the proxy ever got involved.

Fake-IP Leak Prevention

Clash's Fake-IP mode is the optimal solution for completely eliminating DNS leaks, and is widely used as the recommended configuration by the Mihomo core.

Fake-IP works very differently from traditional DNS mode: when an application makes a DNS query, Clash's built-in DNS server immediately returns a "fake" internal IP address (from a reserved address range such as 198.18.0.0/15), without actually sending a DNS request to any external server. The application uses this fake IP to initiate a TCP/UDP connection; Clash intercepts this connection at the connection layer, reverse-maps the fake IP back to the original domain name, and then decides what to do based on rules:

If the rules determine that the domain needs to be proxied, Clash sends the "domain + port" directly through the proxy tunnel to the proxy server, which performs the actual DNS resolution at the proxy's end — meaning the lookup happens close to the exit node, unaffected by any local network filtering.

If the rules determine that the domain should connect directly (an everyday, non-proxied domain), Clash performs a real DNS resolution for that domain, querying the local nameserver specified in the configuration file (e.g., 1.1.1.1) — fast and accurate.

Throughout this process, no DNS queries leak to the system's default DNS server, and there are no unencrypted third-party DNS requests — this is the fundamental advantage of Fake-IP.

Mihomo DNS Configuration

The following is a Mihomo DNS configuration suitable for most scenarios, enabling Fake-IP and properly handling the split between local and proxied traffic:

dns:
  enable: true
  listen: 0.0.0.0:53        # Listen on local port 53
  enhanced-mode: fake-ip    # Enable Fake-IP mode
  fake-ip-range: 198.18.0.1/16

  # Fake-IP filter list: these domains skip Fake-IP and get real DNS resolution
  # Ensures system services like NTP and Apple Push Notifications are unaffected
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.localhost"
    - "time.*.com"
    - "time.*.gov"
    - "ntp.*.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

  # nameserver used for everyday, non-proxied domains
  # Prefer DoH/DoT encrypted queries
  nameserver:
    - https://cloudflare-dns.com/dns-query   # Cloudflare DoH
    - https://dns.google/dns-query           # Google DoH
    - 1.1.1.1                                # Cloudflare DNS (fallback)
    - 8.8.8.8                                # Google DNS (fallback)

  # For resolving the proxy server's own hostname (needs direct resolution)
  proxy-server-nameserver:
    - https://cloudflare-dns.com/dns-query
    - 1.1.1.1

The key points of this configuration: the Fake-IP filter list preserves real DNS resolution for common system service domains, preventing NTP time sync, mDNS, and other local services from being disrupted by Fake-IP; everyday nameservers use DoH encrypted queries to prevent ISP DNS hijacking; the proxy server's own domain uses a reliable direct DNS lookup so its address isn't affected by any DNS interference.

Verify Your Protection

After completing the configuration, use the following steps to verify that DNS leaks have been eliminated:

Method 1: Use an online leak test. Visit dnsleaktest.com or ipleak.net and click "Extended Test." After the test completes, the page will show which DNS servers handled your queries. If only DNS servers from your proxy node's region appear, there is no leak. If your home ISP's DNS servers (Comcast, BT, Spectrum, or similar) show up instead, a leak exists and you need to review your configuration.

Method 2: Command-line verification. Run the following commands in a terminal and observe which server responds:

# Query a foreign domain and observe the SERVER field
nslookup google.com

# Or use dig for more detailed output
dig google.com

If SERVER shows 127.0.0.1#53 (Clash's local DNS), the system DNS is pointing to Clash and Fake-IP is working correctly. If it shows 192.168.x.x (router DNS) or an ISP IP, the system DNS is not correctly pointed to Clash — check whether TUN mode is enabled or whether the DNS listener is working properly.

Common Misconceptions

Misconception 1: "Switching to 8.8.8.8 prevents leaks." Setting your system DNS to Google's 8.8.8.8 or Cloudflare's 1.1.1.1 does not prevent DNS leaks — it may actually make things worse. These queries still travel in plain text directly to a third-party server, bypassing your proxy entirely and adding extra latency. The key to leak prevention is routing DNS queries through Clash, not choosing a particular DNS server.

Misconception 2: "Enabling a proxy automatically routes DNS through it." In traditional system proxy mode, DNS queries are completely independent of the proxy and will not automatically go through it. Only when Clash has DNS listening enabled (enable: true) and the system DNS is pointed to Clash (done automatically via TUN mode, or by manually setting system DNS to 127.0.0.1) will DNS be managed by Clash.

Misconception 3: "Fake-IP mode routes all traffic through the proxy." Fake-IP only changes how DNS resolution works — traffic routing decisions are still governed by the rule set. With a GEOIP,US,DIRECT-style rule configured (or the equivalent for your own country), everyday local traffic still connects directly even with Fake-IP enabled, with no impact on local website speeds.

In summary: using Clash Plus with TUN mode enabled and Fake-IP DNS configured is currently the most complete DNS leak protection solution. The three work together to make your proxy truly seamless, secure, and leak-free.