Clash DNS Configuration Explained: Fixing Pollution and Leaks

Why DNS Configuration Matters So Much

A lot of people install Clash, import a subscription, and assume they're all set — only to find some sites won't load, traffic that's clearly going through the proxy still gets identified as a domestic IP, or the reverse: domestic sites get resolved to a foreign address. Nine times out of ten, the problem is in the DNS step, not the proxy node itself.

Before your browser can visit a URL, it first has to resolve the domain into an IP address — that's the DNS query. If your ISP tampers with this step, it doesn't matter how well you configure the proxy afterward, because your device already got handed the wrong IP to begin with. There are two common ways this "tampering" shows up:

• DNS pollutionYour ISP or a device in the middle forges the DNS response, pointing you to the wrong IP (like an unreachable address, or a redirect to an ad page).
• DNS leakEven though your traffic goes through the proxy, the DNS query itself is still sent directly to your local ISP, so a full record of which sites you visited leaks out — making the proxy pointless.

Comparing the Three DNS Resolution Modes

The Clash DNS module supports a few different modes of operation, and understanding the difference between them is the key to getting DNS right.

The earliest mode. Clash queries the upstream DNS server directly for the real IP, then decides whether to proxy or connect directly based on the rules. It's simple and straightforward, but the downside is that domain-based routing can fail — once you have the real IP in hand, if that IP range isn't matched by any rule, the direct connection can fail, and it isn't precise when it comes to IP-range rules like GEOIP.

Instead of returning the real IP directly, Clash first hands the client a virtual private IP (like 198.18.0.1). Only once an actual connection is initiated does Clash match against the rules by domain name to decide whether to proxy or go direct — and only then does it query the real upstream for the actual IP. This "route first, resolve later" approach means domain-based rules always take priority, which is why this is the most recommended mode today.

Some applications (like certain local-network device discovery tools, or internal corporate systems) can't work with a virtual IP and need the real IP to function properly. In that case you can use fake-ip-filter to exclude those domains from virtual-IP assignment, so they always get resolved to their real address.

# Core DNS module config
dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - '+.market.xiaomi.com'
  nameserver:
    - 223.5.5.5       # Alibaba DNS, for domestic domains
    - 119.29.29.29    # Tencent DNS, same purpose
  fallback:
    - tls://8.8.4.4:853     # DoT, for overseas domains
    - tls://1.1.1.1:853
  fallback-filter:
    geoip: true
    geoip-code: CN

How to Choose Between nameserver and fallback

This is where beginners most often trip up. Both nameserver and fallback are "lists of upstream DNS servers," but they serve completely different purposes:

• nameserver: the servers used by default first — typically fast DNS servers that are reachable normally from domestic ISPs (Alibaba 223.5.5.5, Tencent 119.29.29.29, 114 DNS, etc.).
• fallback: when fallback-filter decides a query result "doesn't look like a domestic address," Clash re-queries using the servers listed here instead — typically encrypted DoH/DoT DNS (like Google or Cloudflare), to avoid pollution.

Combined with fallback-filter.geoip: true, Clash queries nameserver first, and if the resolved IP isn't in the country/region specified by geoip-code (e.g. not CN), it automatically switches to fallback and re-queries — achieving automatic routing where "domestic domains use domestic DNS, overseas domains use encrypted DNS" without you having to maintain a domain list by hand.

Verifying and Troubleshooting

• nslookup / dig testRun nslookup google.com in a terminal. If it returns an address in the 198.18.x.x range, fake-ip is working correctly (this is expected behavior, not a bug).
• DNS leak testRun the extended test at dnsleaktest.com and confirm the DNS server location it reports matches your proxy node's location, not your local ISP.
• Dashboard logsSwitch the log level to debug on the "Logs" page of the dashboard. Visiting a site normally will show the detailed DNS query and rule-matching process, making it easy to see exactly which rule fired.