Clash DNS Configuration: How It Works, Leaks & Best Practices

Why DNS Matters So Much

DNS (Domain Name System) is the internet's "phone book" – it translates human-readable domain names like example.com into IP addresses that machines understand. Every time you type a URL in your browser or open an app, the very first step is usually a DNS query. Only after obtaining the correct IP can the TCP connection and HTTPS handshake proceed.

In a proxy tool like Clash, DNS goes far beyond simple name resolution – it plays a direct role in routing decisions. Clash rules can match by domain name (DOMAIN), by IP range (IP-CIDR), or by geographic origin (GEOIP). If DNS returns incorrect results, the entire routing chain breaks down.

Misconfigured DNS typically causes two categories of problems:

• DNS leaks: Domains that should go through the proxy end up being resolved by your local or ISP DNS. This can expose your browsing intent and, due to DNS pollution, return wrong IPs – causing connection failures or bypassing the proxy entirely.
• Routing errors: IP-based rules (such as GEOIP,US,DIRECT) rely on accurate resolution. If a domain expected to route via proxy resolves to a CDN node in your country, it may be sent over a direct connection by mistake; conversely, a local domain resolving to an overseas IP wastes proxy bandwidth unnecessarily.

DNS configuration is therefore unavoidable when tuning Clash for optimal performance. Once you understand the underlying principles, you'll be able to explain common issues like "why did a particular site suddenly go direct?" or "why won't a streaming service load?" The sections below take you systematically from DNS pollution causes through resolution modes to a practical configuration.

DNS Pollution and Encrypted DNS

In unencrypted UDP/TCP DNS queries, requests travel in plain text, leaving them open to tampering by intermediate network devices. This is what is commonly called DNS pollution. A polluted domain may return an incorrect IP (often 0.0.0.0 or a placeholder address), making the site unreachable or directing you to the wrong server.

To combat pollution, Clash supports encrypted DNS protocols such as DoH (DNS over HTTPS) and DoT (DNS over TLS). With encryption in place, queries cannot easily be tampered with, making resolution results far more reliable. Clash's nameserver and fallback mechanism is built around the idea of "primary regional DNS for speed + encrypted fallback for reliability".

default-nameserver is used to resolve the DoH domain names listed under nameserver and fallback themselves (for example, looking up the IP of dns.google). It should be a reliable plain UDP DNS server, which avoids the classic chicken-and-egg bootstrapping problem.

Clash's Two Resolution Modes

redir-host

In redir-host mode, Clash first performs a real DNS lookup to obtain the actual IP address, then decides whether to use the proxy or a direct connection based on the rules. The logic is straightforward and easy to understand, and it works well when you need real IPs for GEOIP-based rules.

The drawbacks are significant, however: resolving overseas domains is prone to DNS pollution, returning wrong IPs; every new connection must wait for the DNS response, increasing first-packet latency; some applications cache DNS results internally, which can conflict with Clash's routing strategy.

fake-ip (Recommended)

In fake-ip mode, Clash assigns a "fake IP" from a reserved address range (default 198.18.0.0/16, an IANA-reserved block that does not conflict with real public IPs) to every domain being resolved. The application connects to that fake IP, Clash intercepts the connection locally, looks up the domain in its internal mapping table to decide proxy vs. direct, and then establishes the real connection.

The advantages are clear: applications get an immediate response without waiting for a real DNS reply; domain information stays inside Clash for more accurate routing; compatibility with streaming services and rule-based routing is better. fake-ip is the most widely used mode in the community today.

A Recommended Configuration

The following DNS configuration template has been validated by a large number of users and can be added directly to your Clash config file (adjust upstream DNS servers to suit your network environment):

A brief explanation of each field:

• nameserver: Primary DNS, used first. Choose a reliable encrypted DNS server in or close to your region for low-latency resolution.
• fallback: When the nameserver result is considered "untrusted" (e.g., GeoIP doesn't match your region), Clash re-resolves using fallback – typically a secondary encrypted DNS for more reliable results.
• fallback-filter.geoip: Enables GeoIP filtering; if the IP returned by nameserver does not belong to your configured region (geoip-code), fallback is triggered. Set this to your country code (e.g. US, JP, KR).
• fake-ip-filter: Excludes domains that should not receive fake IPs, such as LAN hostnames (*.lan) and certain local services that require real IPs.

Common Issues & Troubleshooting

Local/trusted sites are slow or unreachable

The fallback may be triggering incorrectly, causing local domains to be resolved by overseas DNS. Check that fallback-filter is configured correctly, or add explicit DOMAIN direct-connection rules before the fallback kicks in. You can also use nameserver-policy to pin specific domains to a dedicated DNS server.

Streaming service reports region unavailable

Some streaming platforms cross-check whether your DNS server and IP address match. Ensure that streaming-related domains are routed through the proxy and that DNS resolution for those domains is also handled on the proxy side. If necessary, configure dedicated rules for Netflix, Disney+, and similar services.

LAN devices cannot communicate with each other

fake-ip can interfere with mDNS and Bonjour LAN discovery protocols. Add *.local and *.lan to fake-ip-filter, or switch to redir-host for that subnet. If you have Chromecast, AirPlay, or similar devices at home, also add their related domains to the filter to ensure screen casting and device discovery work correctly.

IPv6 notes

If your network does not yet require IPv6, keep ipv6: false to prevent certain applications from preferring IPv6 and causing routing anomalies. If you have fully enabled IPv6, set it to true and configure nameserver-policy to assign dedicated resolution paths for IPv6 domains, ensuring both v4 and v6 traffic is routed correctly.

Verifying That Your Configuration Works

After completing the configuration, follow these steps to verify it:

1. Visit a DNS leak test site (such as dnsleaktest.com) and confirm that the DNS resolution exit matches your expectations. When the proxy is active, your local ISP's DNS servers should not be exposed.
2. Test both local/trusted sites (e.g., your ISP portal or a local news site) and proxy-routed sites, and confirm the former go direct while the latter go through the proxy at normal speeds.
3. Check the connection log in the Clash dashboard or log output to confirm domain-to-rule matching is working as intended.
4. Disable and re-enable the proxy, then verify that applications can still resolve correctly – this rules out stale DNS caches causing anomalies.

Summary

Proper DNS configuration is the foundation of a stable proxy experience. The recommended setup is fake-ip mode combined with a strategy of "primary regional DoH + encrypted fallback + GeoIP filtering" – this ensures reliable resolution while preventing leaks. When you encounter LAN or application-specific issues, use fake-ip-filter and nameserver-policy for fine-grained adjustments. Always test your configuration in practice after making changes, and continue to optimize based on your actual network environment. Once you have mastered DNS configuration, you will be able to independently diagnose most connection issues related to name resolution, laying a solid foundation for further work on rule-based routing and proxy group tuning.