Clash DNS Setup Guide: Fake-IP, DoH & DNS Pollution Fixes

Many people find Clash's DNS setup confusing at first: the core has its own DNS module, but the client also lets you pick "System Proxy" or "TUN" — so how does a domain actually get resolved? This article starts from the fundamentals and walks you through the dns section of your config.

Why a proxy tool needs to handle DNS at all

If domain resolution goes through your local ISP's DNS, the result can be tampered with or simply inaccurate — even if the traffic eventually gets routed through a proxy node — which can cause routing rules to misjudge a region (for example, a false match on GEOIP,US). That's why Clash has a built-in DNS module: it takes over resolution so both "resolving" and "forwarding" stay under its own control.

Two resolution modes: redir-host and fake-ip

This is the pair of concepts you need to understand before touching DNS config. The core difference: whether the IP the client receives is a real one.

Mode	Resolved Result	Best For
redir-host	Real public IP	Best compatibility — good for apps that need a real IP for validation
fake-ip	Virtual private-range IP	Fast resolution, avoids DNS leaks — the current mainstream recommendation

Using DoH / DoT to avoid upstream DNS tampering

If nameserver only points at plaintext UDP DNS (like 8.8.8.8), the request itself can still be intercepted or altered in transit. Encrypted DNS (DoH/DoT) wraps the query inside HTTPS/TLS, which significantly reduces the odds of tampering.

nameserver is your default resolver group; fallback only kicks in when the default result falls outside a given region (as judged by fallback-filter) — usually set to a fast, tamper-resistant overseas DNS.

nameserver-policy: pick DNS by domain

If you only want specific domains to use specific DNS (say, internal domains through a local resolver, everything else through encrypted DNS), use nameserver-policy:

What to watch for on dual-stack IPv4/IPv6 networks

If your local network has both IPv4 and IPv6, and your ISP's IPv6 egress quality is mediocre, this can actually slow things down — browsers try both protocols simultaneously via Happy Eyeballs, but Clash may not handle IPv6 resolution specially by default. Use the ipv6 field to explicitly control whether IPv6 results are resolved and used:

If your IPv6 egress is actually solid, feel free to keep it enabled and let fake-ip cover both IPv4/IPv6 results — the right call depends on your own speed tests, not on copying someone else's "universal config."

DNS vs. local hosts priority

In some cases (testing a self-hosted service, temporarily blocking a domain) you might want to edit the system hosts file directly. Note that once Clash takes over DNS (dns.enable: true), the core may never see your system hosts mappings, since resolution requests might not go through the system resolver at all. In that case, it's better to add a hosts section directly to your Clash config — same effect, with a clearer scope:

How DNS settings differ across GUI clients

Most GUI clients wrap the dns section into a "basic" and "advanced" toggle: basic mode only exposes a dropdown for "enhanced mode" (mapping to enhanced-mode), while advanced mode reveals fields like nameserver and fallback. If you can't find a particular field in the UI, you can generally still add it by directly editing the config file (sometimes labeled as a raw YAML editor) — the client won't ignore config it doesn't render a UI for.

How to troubleshoot resolution issues

1. Confirm the DNS module is enabled: if dns.enable is false, Clash doesn't take over resolution — the system handles it instead.
2. Check for a wrongly matched rule: some domain rules end up placed before DIRECT, causing traffic that should be proxied to resolve directly instead.
3. Suspect a fake-ip conflict: if LAN devices, printers, or game consoles show discovery issues, add the domain to fake-ip-filter first.
4. Cross-check with an external tool: run nslookup or use an online DNS-check tool with the proxy on and off, and compare the results.

Does mobile need separate tuning

Because phones switch frequently between Wi-Fi and mobile data, DNS caching behaves a bit more "sensitively" than on desktop: if a site resolves to a stale result right after switching networks, it's usually not a config problem — the system or client is just holding onto the previous resolution, and it clears once the cache expires or you restart the proxy service. Some mobile clients also throttle background reconnection to save battery, so if resolution misbehaves after a long period suspended, try fully quitting and reopening the client.

How does DNS behave differently under TUN mode

With TUN mode enabled, all system-level traffic (including DNS queries) is intercepted by a virtual network adapter — in theory this covers more ground than the traditional system-proxy mode, catching apps that don't respect system proxy settings (for example, apps with a custom DNS resolver built in). But that also means a DNS misconfiguration has a wider blast radius — it's best to get your dns config stable under system-proxy mode first, then switch to TUN to verify, rather than trial-and-erroring directly in TUN mode.

Summary

For everyday use, fake-ip plus an encrypted DNS upstream covers the vast majority of cases; fine-tuning fake-ip-filter or nameserver-policy is only needed for LAN discovery or protocol-specific edge cases. Once this logic clicks, issues like "speed test works but the page won't load" become easy to diagnose on your own.