Published by Clash Official Site. In Clash and Mihomo's rule-based routing system, DNS is often the most overlooked component — yet the most common culprit behind "some sites won't load," "slow resolution," or "rules not firing." Many users meticulously tune nodes and policy groups, only to find that DNS returns the wrong IP or takes the wrong resolution path, causing routing rules to miss their targets. This article systematically covers Clash DNS module configuration — from principles to practice — helping you build a stable, fast, and anti-spoofing resolution chain.
Why Clash Needs Its Own DNS Configuration
Your OS's default DNS is usually provided by your router or ISP. Those results may be subject to hijacking, cache poisoning, or cross-border resolution latency. As a local proxy core, Clash needs to know the real or virtual address of a target domain before traffic enters rule matching — otherwise DOMAIN, GEOSITE, and other rules can't fire correctly.
When DNS and the proxy chain are out of sync, common symptoms include: local sites being proxied by mistake, remote sites failing on direct connections, TLS handshake errors, or the browser hanging on "Resolving…" for a long time. Dedicating a proper DNS module in your advanced config is therefore a critical step toward a stable overall experience.
Think of the DNS module as the "upstream intelligence layer" of your routing rules — if the intel is wrong, no policy group can save you.
fake-ip vs redir-host: The Two Core Modes
Mihomo / Clash Meta supports two enhanced DNS modes. Understanding the difference is the prerequisite for correct configuration.
fake-ip Mode
The client assigns a virtual IP (usually from the 198.18.0.0/15 range) to each domain. When an app connects to that virtual IP, the core restores the real target from the domain name and matches rules accordingly. Advantages: prevents DNS leaks, reduces resolution wait time, improves TUN mode compatibility. Disadvantage: some apps that rely on real IPs (e.g., LAN device discovery, certain games) may behave unexpectedly.
redir-host Mode
DNS queries return real IPs; the core continues matching rules like GEOIP against those IPs. This is closer to traditional proxy behavior and is more compatible — but if upstream DNS is spoofed/hijacked, you may get wrong IPs, causing rules to miss. Typically requires a reliable remote DNS plus dns-hijack to work stably.
| Comparison | fake-ip | redir-host |
|---|---|---|
| Returned address | Virtual IP | Real IP |
| DNS leak protection | Strong | Needs extra config |
| TUN compatibility | Excellent | Good |
| App compatibility | Occasional issues | Generally better |
Split DNS: Different Servers for Different Destinations
An efficient setup routes different domains to different DNS servers. For domains you access locally (e.g., your ISP's services, local intranet), use a trusted public DNS like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google) for fast, accurate results. For domains that should be proxied, query a remote DNS through your proxy tunnel (e.g., tls://8.8.8.8:853 via proxy) to bypass DNS hijacking and get correct routing.
In your config file, use nameserver-policy to assign specific DNS servers to domains or domain groups. For example, route geosite:cn to a local DNS and geosite:geolocation-!cn to a proxied DNS. Combined with fallback and fallback-filter, the system automatically switches to a backup resolver when the primary returns a potentially hijacked IP — the most common anti-spoofing combination in practice.
Recommended Configuration Approach
- Enable
enhanced-mode: fake-ip(preferred for TUN users) or choose redir-host based on your scenario. - Set
nameserverto a trusted local DNS; setfallbackto a remote DNS reachable via proxy. - Use
nameserver-policyto fine-tune routing — avoid sending all queries through a remote DNS, which slows local site access. - Add LAN domains, NTP, and some local service domains to
fake-ip-filterto prevent virtual IPs from interfering with local traffic.
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- https://1.1.1.1/dns-query # Cloudflare DoH (or your local/ISP DNS)
- https://8.8.8.8/dns-query # Google DoH
fallback:
- tls://8.8.8.8:853 # Remote DNS via proxy tunnel
nameserver-policy:
"geosite:cn": [https://223.5.5.5/dns-query] # China domain list → local DNS (non-China users: replace with 1.1.1.1)
"geosite:geolocation-!cn": [tls://8.8.8.8:853]Common Issues & Troubleshooting
Local sites slow after enabling proxy: Check if all DNS queries are going through fallback. Use nameserver-policy to route local domains to a local DNS.
Some apps can't connect: Try adding the relevant domains to fake-ip-filter, or switch to redir-host for testing.
DOMAIN rule written but not firing: Confirm the DNS module is enabled and no wrong IP is interfering at query time. Check the logs for the actual matched target address.
Resolution timeout: Check whether your remote DNS needs a proxy to reach the internet. Ensure DNS query traffic can reach your proxy node; try switching to https or tls DNS type for better stability.
Summary
Clash DNS configuration isn't a one-size-fits-all copy-paste template — it should be tuned to your client mode (system proxy vs. TUN), your provider's line quality, and your common use cases. fake-ip suits users who want efficiency and leak prevention; redir-host suits environments that need maximum compatibility. Regardless of mode, split DNS resolution + reliable fallback are the foundation of a stable routing setup.
To get clients and core binaries, visit the official download page. For first-time setup, combine with the setup guide to complete subscription import and rule mode configuration.
Related Articles