When people track down why "the rule looks right but the site still won't load," the root cause often turns out to be DNS. It doesn't matter how precise your rules are — if the domain resolves to the wrong IP in the first place, everything downstream falls apart. This article explains what DNS pollution and DNS leaks actually are, and how Clash addresses each one.
01What Is DNS Pollution
DNS pollution happens when, as you look up a domain's IP address, some device in the network path "answers first" with a wrong or blocked IP instead of the address the domain actually points to. The result: even if your proxy rules correctly decide the request should go through a proxy, the connection still fails or lands on the wrong page — because the IP itself was never right to begin with.
The Fix: Use a Trusted Upstream DNS
Configuring an encrypted DNS server (DoH/DoT) in config.yaml bypasses the plain-UDP DNS interference that network middleboxes rely on:
dns:
enable: true
nameserver:
- https://1.1.1.1/dns-query
- https://8.8.8.8/dns-query02What Is a DNS Leak
A DNS leak is when your actual traffic goes through the proxy, but the DNS lookup for that request bypasses the proxy entirely and goes straight out through your local network. Your ISP can then still see exactly which domains you're resolving, even though the proxy is protecting the traffic that comes after. The proxy is doing its job for the data itself — but not for the fact that you looked the domain up at all.
The Fix: Enable fake-ip Mode
fake-ip mode has the Clash core take over DNS resolution entirely: when an app looks up a domain, Clash first hands back a fictitious local IP, and the real resolution method and exit path only get decided once a connection is actually attempted, based on your rules. That way the DNS lookup itself is folded into Clash's routing pipeline instead of leaking out to your local network directly.
dns:
enable: true
mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "localhost.ptlogin2.qq.com"03nameserver-policy: Routing DNS Queries by Domain
Sometimes you want specific domains resolved by a specific DNS server — for example, resolving mainland China domains through a China-based DNS server to get faster CDN edge nodes, while resolving everything else through an overseas DNS to avoid pollution. nameserver-policy lets you assign resolvers per domain rule:
dns:
enable: true
nameserver-policy:
"geosite:cn": ["223.5.5.5", "119.29.29.29"]
nameserver:
- https://1.1.1.1/dns-queryIn the example above, anything matching geosite:cn (mainland China domain classification) resolves through those China-based DNS servers, while everything else falls back to the default nameserver list.
04Field Reference
| Field | What it does |
|---|---|
| enable | Whether Clash's built-in DNS server takes over resolution. Should generally be set to true. |
| mode | Resolution mode: fake-ip (recommended, prevents leaks) or redir-host (more compatible, but weaker leak protection). |
| nameserver | The default upstream DNS server list. Encrypted DoH/DoT servers are recommended. |
| nameserver-policy | Assigns a specific DNS server per domain rule, taking priority over the default nameserver. |
| fake-ip-filter | A list of domains excluded from fictitious IP resolution. |
05How to Verify Your DNS Configuration Is Working
Don't just guess after changing your config — a few simple checks will confirm whether DNS is actually behaving as intended:
- Check the client's connection log: most clients show the actual resolved address for every request in their "Logs" or "Connections" panel. If fake-ip is enabled, you should see domains resolving to fictitious addresses in the 198.18.x.x range — confirming fake-ip is active.
- Use an online DNS leak test: with the proxy on, visit a DNS leak test site. If the DNS server it reports matches your real location or ISP, your queries aren't going through the proxy — meaning there's a leak, and you need to double-check your fake-ip or nameserver-policy setup.
- Compare resolution results for different regions: visit a domain that should route directly and one that should route through a proxy, and check whether the actual exit node matches expectations. If it doesn't, your nameserver-policy domain classification probably isn't covering that domain — you likely need to add the matching geosite rule.
Most subscriptions already ship a usable DNS configuration, so there's rarely a need to write one from scratch. But if you're hitting "the rule is correct but it still won't connect," or you're worried about privacy leaking at the DNS layer, this is usually the section worth revisiting first.