Advanced Config 2026-07-19 9 min read

Clash DNS Config Explained: nameserver, fallback & Anti-Hijack Params

The dns block in a Clash config file decides which path domain resolution takes, whether it can be tampered with, and whether it can work alongside rule-based routing. This article breaks down the roles of nameserver and fallback, the differences between fake-ip and redir-host resolution modes, and the purpose of common anti-hijack parameters, with ready-to-use config snippets and verification steps.

Why Clash handles DNS on its own

In a typical setup, a device sends a domain query to whatever DNS server the OS or router is configured with, gets back an IP, and connects to that IP. If this DNS request isn't itself routed through the proxy, your ISP or any intermediate network device can see exactly which domain you're querying — or worse, return a falsified result. That's what's commonly called DNS pollution or DNS hijacking. Rule-based routing also depends on accurate domain data: if the IP behind a domain can't be trusted, decisions made from rules like DOMAIN-SUFFIX or GEOIP become unreliable too.

Clash and Clash Meta (the mihomo core) build a dedicated DNS module into the config file, letting domain resolution be managed inside the proxy stack instead of being left entirely to system network settings. This module is controlled by the dns field as a whole, with nameserver, fallback, and enhanced-mode as the three core options. Getting these right together is what keeps resolution both fast and free from pollution or hijacking.

Whether the DNS block takes effect — and to what extent — depends on the specific client implementation. Check what level of dns field support your client (Clash Verge Rev, FlClash, the mihomo core, etc.) actually has before copying a config as-is.

nameserver vs fallback: what each set of servers actually does

Clash's DNS block usually lists two separate groups of server addresses, under nameserver and fallback. These aren't a simple primary/backup pair — they're two channels handling different jobs.

nameserver: the default resolution channel

nameserver is the first channel used for everyday resolution. The servers listed here handle the vast majority of domain requests, including the results used for rule matching itself. If you're mainland-China-based, this is usually filled with ISP DNS or public DNS services (such as 223.5.5.5, 119.29.29.29), keeping resolution for domestic sites fast without any unnecessary round-trip through the proxy.

fallback: the backup channel for domains outside the region

fallback is a backup channel. Paired with fallback-filter, the typical flow is: resolve with nameserver first, then check whether the returned IP falls inside the country code specified in fallback-filter.geoip-code (usually CN). If it doesn't fall inside that range, the domain is likely a site outside the region that should go through the proxy — so it gets re-resolved using the servers listed under fallback (such as 1.1.1.1, 8.8.8.8), avoiding the slow or inaccurate results you'd get resolving foreign domains through a domestic DNS server.

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.8.8:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

default-nameserver is a more fundamental channel, dedicated to resolving the DNS server addresses in nameserver and fallback when they're written as domain names (for example, certain DoH addresses written that way). It must be filled with plain IPs — it can't rely on a resolution chain that hasn't been established yet to resolve itself.

fake-ip vs redir-host: which resolution mode to pick

enhanced-mode decides how the domain info Clash resolves gets passed on to the proxy and rule-matching modules. The common values are fake-ip and redir-host, and they work very differently.

fake-ip mode

In fake-ip mode, Clash doesn't hand the real IP behind a domain straight to the application. Instead, it returns a virtual IP from a private address range first. When the app connects using that fake IP, the traffic goes into Clash, which internally maps the fake IP back to the original domain and then decides the real exit node and destination based on rules. The upside is fast resolution and seamless pairing with TUN mode for a fully transparent proxy setup — this is basically the default choice for desktop clients and routers today. The downside is that some apps with a hard dependency on real IPs (services that validate a direct-connect IP, LAN device discovery, etc.) can misbehave. Usually you'll need to set direct-connect rules for the affected domains or IP ranges, or add those domains to the fake-ip-filter exclusion list so they skip fake-IP handling.

redir-host mode

redir-host mode is the older approach: Clash resolves the domain to a real IP and hands that straight to the application, and proxy decisions rely on the Host header or SNI info the app sends when connecting. This mode is more compatible and avoids the quirks that fake IPs can cause, but resolution and forwarding are less efficient than fake-ip, and accuracy drops for protocols that don't carry clear domain info (some purely IP-based apps, for instance). Mainstream Clash Meta / mihomo core clients now treat fake-ip as the recommended default — redir-host is mostly kept around for legacy configs or specific compatibility edge cases.

After switching enhanced-mode, restart the client or reload the config. Some implementations don't clear the resolution cache automatically, so you might see stale results from the old mode for a short while after switching.

Understanding and configuring anti-hijack DNS parameters

Beyond the basic nameserver/fallback split, Clash's DNS block also offers a few parameters specifically aimed at fighting DNS hijacking and improving resolution security. Understanding them helps when troubleshooting the "pages won't load even though the proxy is clearly working" kind of problem.

Use encrypted DNS protocols

Plain udp:// DNS requests can still be tampered with or blocked by intermediate network devices. Switching the addresses under nameserver or fallback to the tls:// (DNS over TLS) or https:// (DNS over HTTPS) prefix routes the DNS request itself through an encrypted channel, cutting down the chance of it being hijacked or altered. https://1.1.1.1/dns-query and tls://8.8.8.8:853 are both common examples, and most mihomo core clients support these prefixes natively.

listen and intercepting LAN DNS requests

The dns.listen field specifies the local port Clash's built-in DNS service listens on (such as 0.0.0.0:1053). Combined with the DNS hijack switch in system proxy or TUN mode, this forces DNS requests from the device to be intercepted and handled by Clash instead of bypassing it and hitting the system-configured DNS server directly. If you notice a particular app's domain requests aren't going through the proxy rules at all, it's often because this interception step isn't working — the app is likely using a hard-coded DNS address that skips the system resolution entry point.

Fine-grained routing with nameserver-policy

For cases where specific domains need to be resolved with a special DNS server (say, an internal company domain that must use an internal DNS server rather than resolving incorrectly through public DNS), nameserver-policy lets you assign a resolver to specific domains or suffixes, taking priority over the global nameserver config:

dns:
  nameserver-policy:
    "geosite:cn":
      - 223.5.5.5
    "+.corp.internal":
      - 10.0.0.53

This kind of setup is common in hybrid work environments with both internal and external networks in play, preventing internal services from becoming unreachable due to resolution taking the wrong path.

Verifying the DNS config actually works

Don't rely on a vague "the page loads" as confirmation once the config is written. Work through the following checks instead.

Check the client's connection log or DNS query record: most GUI clients (Clash Verge Rev, for example) show real-time domain resolution requests in the "Connections" or "Logs" panel, letting you confirm the target domain actually went through Clash instead of bypassing it.
Verify the resolution result from the command line: run nslookup target-domain 127.0.0.1 -port=1053 in a terminal (swap in whatever port dns.listen is actually set to) and check whether it returns a fake IP or a real one, matching the enhanced-mode you expect.
Test routing behavior against known domestic and foreign sites: visit one clearly domestic site and one clearly non-domestic site, and check the rule logs to confirm the former went direct while the latter went through a proxy node, rather than both taking the same path.
Check for resolution leaks: some apps have their own built-in DNS logic that bypasses system settings. If you suspect an app is leaking real resolution requests, temporarily cut its network permission or use a firewall rule to isolate and inspect its DNS traffic to confirm whether it's actually being intercepted by Clash.

Setting	Role	Common values
nameserver	Default resolution channel, handles most requests	223.5.5.5, 119.29.29.29
fallback	Backup channel, paired with a filter for domains outside the region	tls://1.1.1.1:853
fallback-filter	Decides whether a result needs to fall back	geoip-code: CN
enhanced-mode	Sets fake-ip or redir-host resolution mode	fake-ip
nameserver-policy	Assigns a dedicated resolver to specific domains	Mapped by domain/suffix

Start from a mature client's built-in default DNS config as a baseline, confirm the basic rules work, then fine-tune fallback and nameserver-policy for your own network one step at a time — changing too many parameters at once makes troubleshooting much harder.

Common pitfalls and troubleshooting tips

A handful of mistakes tend to show up repeatedly in real-world configs. Knowing them ahead of time can save a lot of troubleshooting.

Treating fallback as the primary DNS: if fallback-filter is misconfigured or missing, every request might get judged as needing fallback, actually slowing down resolution for domestic sites. Check whether geoip-code is set correctly.
Mixing encrypted and unencrypted DNS without a consistent timeout policy: encrypted DNS requests usually take slightly longer than plain ones. If the client's timeout is set too tight, resolution can fail intermittently — try loosening the client's DNS timeout or trimming the fallback server list.
Ignoring IPv6's effect on resolution results: some networks have IPv6 enabled, and if Clash's ipv6 field doesn't match the actual network state, the type of IP returned may not line up with what's actually usable. Explicitly set ipv6: true or false based on your own network rather than leaving it blank.
Using IP-range rules while resolution runs in fake-ip mode: in fake-ip mode, apps only see the fake IP. If your rules rely heavily on real IP ranges (like GEOIP), check whether the client core resolves the fake IP back to a real one before rule matching — implementations differ on ordering here. If matching behaves oddly, try switching to redir-host temporarily to compare.

The DNS block doesn't need to be perfect on the first try. Get a basic nameserver + fallback + fake-ip combo running first, then add parameters one at a time as specific issues come up (an app can't connect, an internal service resolves incorrectly) — that's usually far easier to maintain than stacking every optional field up front.