Clash DNS Configuration Explained: Fixing Pollution & Leaks

A lot of people install Clash and find that some sites still won't load — and it turns out the problem isn't the proxy node at all, it's DNS. If a domain resolves to the wrong IP in the first place, no amount of proxying will save you. This article walks through how to configure Clash's DNS module properly, closing off both the pollution and leak problems for good.

Why DNS needs special handling

Under normal browsing, your browser asks a DNS server "what's the IP for this domain?" and then connects to whatever IP comes back. Two things can go wrong here:

• DNS pollution: when a query for certain domains goes through your ISP's default DNS, a forged IP comes back, and the connection fails or times out.
• DNS leaks: your traffic goes through the proxy, but the DNS lookup itself is still sent in plaintext over your local network — broadcasting exactly which sites you're visiting.

That's why Clash has a built-in DNS module: once enabled, every DNS query on the device passes through Clash first, and Clash decides which server handles the resolution and whether that resolution should go through the proxy.

fake-ip vs. redir-host

enhanced-mode has two possible values, and they determine how Clash answers the system's DNS queries:

Bottom line: use fake-ip by default. If you run into an incompatible app, just exclude it with fake-ip-filter instead of switching the whole setup back to redir-host:

dns:
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "+.stun.*.*"
    - "+.battle.net"       # game launchers often need real IP
    - "time.windows.com"

How nameserver and fallback split the work

This is the part of DNS configuration people get wrong most often. The correct mental model is:

• nameserver: your primary resolver group — well-known, reliable DNS providers that resolve most everyday domains quickly and accurately.
• fallback: your backup resolver group — encrypted DNS providers (DoH/DoT) that step in specifically for domains that might be getting poisoned.

Both groups are queried concurrently. When the result matches a condition in fallback-filter (for example, the resolved IP falls outside an expected region), Clash uses the fallback result instead, sidestepping the pollution:

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1                          # Cloudflare
    - 8.8.8.8                          # Google
  fallback:
    - https://1.1.1.1/dns-query       # Cloudflare DoH
    - https://dns.google/dns-query    # Google DoH
  fallback-filter:
    geoip: true
    geoip-code: US
    ipcidr:
      - 240.0.0.0/4                   # bogus IPs returned by poisoning

Here's the effect of this setup: everyday domains resolve instantly through your primary nameservers; the moment a resolution for a sensitive domain looks suspicious, Clash automatically falls back to the encrypted DNS result instead — pollution is blocked, and nothing leaks out in plaintext.

How to verify it's actually working

1. Open the "Logs" tab in the dashboard and set the level to debug — you'll see exactly which server handled each DNS query.
2. Run a leak test at dnsleaktest.com: the DNS servers it reports should match what you configured under fallback (or your proxy node's DNS), not your local ISP's servers.
3. Use nslookup on a domain known to be affected by pollution — if you get back a fake IP starting with 198.18, fake-ip is working as expected.

What to watch for when proxying an entire network

If you're running Clash on a router or NAS to transparently proxy every device on your network, getting DNS right matters even more — because there's no "let the client resolve it locally" fallback anymore; every device's DNS lookups have to pass through Clash. Two tips for this setup:

• Bind listen to your LAN interface: by default Clash only listens on 127.0.0.1, so other devices' DNS requests can't reach it at all. Change it to 0.0.0.0:53 and set your router's DHCP gateway to also act as the DNS server.
• Whitelist smart TVs and game consoles separately: these devices often have rigid network validation logic and will simply refuse to connect if the DNS result doesn't match the location they expect. When that happens, add the device's domains to fake-ip-filter rather than disabling fake-ip for the whole network.

One more thing worth mentioning: a lot of people default to 8.8.8.8 as their primary DNS just because it's simple and well-known. But depending on your network, reaching Google's DNS servers can itself be slow or roundabout, making it a poor choice as your primary resolver. Stick with the division of labor above: nameserver handles everyday resolution, and fallback is reserved for encrypted DNS duty.

Two common misconceptions

Let's clear up two misunderstandings beginners often have, so you don't go down the wrong path:

1. "Once fake-ip is on, I can never see the real IP again." Not true — fake-ip only changes the IP visible at the system level. Clash still resolves the real address internally when the connection is established, and you can see the actual destination IP in the logs and the connections page. It won't get in the way of troubleshooting.
2. "The more complex the DNS config, the more secure it is." Actually the opposite — two or three entries each under nameserver and fallback are plenty. Piling on more servers just slows down the first lookup, since Clash has to wait for all of them to respond concurrently. Simple and clear beats "big and comprehensive" every time.

Copy this DNS configuration into your config.yaml, reload it, and you can consider both pollution and leaks pretty much solved.

How this connects to rule-based routing: DNS feeds into decisions too

If your rule set uses GEOIP matching, the DNS resolution result directly affects whether that routing decision is accurate — if the IP is resolved incorrectly, GEOIP will misjudge the country too, potentially sending a local site through the proxy or letting a site that should be proxied go direct. That's exactly why it matters to get DNS right before fine-tuning rules: no matter how carefully you write the rules on top, they won't hold up on a shaky foundation. If a particular site's routing behavior doesn't match what you expect, it's often worth checking whether the DNS resolution itself is the culprit before you start rewriting rules.

Summary

This article really comes down to one idea: make sure each domain takes the path it's supposed to, and don't let DNS be the thing holding you back. To recap the key takeaways: default to fake-ip, and exclude incompatible apps with a filter list rather than reverting the whole setup; let nameserver handle everyday resolution and fallback handle domains that might be poisoned, with each doing its own job and staying out of the other's way; and after any change, clear your cache, reload, and verify — all three steps, every time. Keep these principles in mind and you'll be able to put together a solid DNS setup quickly no matter what device or client you switch to next, instead of starting from scratch every time.

If you're new to Clash, start by copying the complete example in this article and running it as-is. Once you've confirmed it's stable, fine-tune the specific servers under nameserver and fallback to match your own network. Get it working first, then optimize — that's a lot less stressful than chasing a perfect setup from day one.