Clash DNS Config Explained: nameserver, fallback & DNS Hijacking Breakdown

Why DNS Still Slows You Down Even After Your Proxy Is Set Up

When people first look at a Clash config file, they usually focus entirely on the proxies and rules sections — nodes and routing rules feel like the parts that actually "decide whether it works." But in real troubleshooting, a good chunk of "this site won't load," "it's still pulling a mainland CDN even with the proxy on," or "switching nodes made the page slower" issues actually trace back to a misconfigured dns section.

The reason is simple: proxy rules mostly match by domain, but every network request ultimately resolves to an IP address. If the domain resolution step is already poisoned or takes the wrong path, no amount of fine-tuned routing rules downstream can fix it. The core job of DNS config is making sure domains meant to go through the proxy resolve to their real IP, while domains meant to connect directly resolve to the nearest CDN IP — and neither path interferes with the other.

The Backbone of the DNS Section: What nameserver and fallback Actually Do

The DNS module structure in Clash and Clash Meta (mihomo core) is largely similar. The common fields break down into three layers:

• nameserver: the default list of resolvers most domains use.
• fallback: a backup list of resolvers used specifically when the nameserver result "looks wrong."
• fallback-filter: the rules that decide what counts as "wrong," determining when Clash should trust the fallback result instead of the nameserver result.

A minimal skeleton looks roughly like this:

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

default-nameserver is an easily overlooked field: it's used only to resolve the servers in nameserver and fallback when they're written as domain names (like DoH addresses). It must be a bare IP, otherwise you end up with a circular dependency — trying to resolve the address of the server that's supposed to do the resolving.

nameserver-policy: Routing Different Domains to Different DNS Servers

With only a single nameserver group, every domain gets resolved by the same set of servers — which isn't enough once you need explicit routing. nameserver-policy lets you assign a dedicated resolver per domain rule, using a syntax similar to routing rules:

dns:
  nameserver-policy:
    "geosite:cn":
      - 223.5.5.5
      - 119.29.29.29
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query
      - https://8.8.8.8/dns-query

What this config means: requests matching geosite:cn (the mainland China domain set) always resolve via the domestic DNS, naturally landing on the nearest CDN node. Requests matching the overseas domain set always resolve via an encrypted offshore DNS, avoiding any "helpful" tampering from a mainland ISP's DNS along the way. With this in place, mainland sites won't take a slow detour through overseas resolution, and overseas sites won't end up resolving to an unreachable IP because a domestic DNS handled them.

One thing to note: nameserver-policy takes priority over plain nameserver lookups — a match applies immediately, skipping the fallback logic entirely. That's the key difference from the fallback mechanism covered next: one is proactive routing, the other is after-the-fact correction.

What Exactly Does fallback-filter Filter, and What Triggers It

The fallback mechanism exists to handle domains that don't clearly belong to "domestic DNS" or "overseas DNS" — especially ones not covered by any nameserver-policy rule. Roughly, here's how it works:

1. The request goes out to both the nameserver group and the fallback group (simultaneously or in sequence);
2. Once an IP comes back from nameserver, it's checked against the conditions defined in fallback-filter;
3. If that IP matches geoip-code: CN (i.e., it's identified as a mainland China IP) or falls within an address range listed under ipcidr, the result is considered trustworthy and gets used as-is;
4. If it doesn't match — meaning the domain should really be an overseas site, yet nameserver returned a domestic IP or even an invalid address — Clash treats this as suspected DNS poisoning and switches to the resolution result from the fallback servers instead.

A common entry under ipcidr is 240.0.0.0/4, a reserved address block that some ISPs return as a fake address during DNS poisoning. Adding it to the filter list lets Clash spot poisoned results early. fallback-filter also supports a domain field, which forces specific domains straight to fallback via a whitelist — handy for sites that get poisoned repeatedly.

enhanced-mode: fake-ip vs. redir-host, Two Ways to Implement Hijacking

enhanced-mode determines how Clash "intercepts" domain requests before routing them by rule. The two common values behave very differently:

fake-ip mode

Clash takes over DNS requests locally and hands each domain a temporary fake IP from within the fake-ip-range block. When the application connects using that fake IP, Clash's core internally maps it back to the original domain, then performs the actual resolution and forwarding according to your rules. The upside: the resolution request never leaves the local machine and can't be intercepted by an ISP — this pairs best with TUN mode for the smoothest experience. The downside: a handful of scenarios that rely on a real IP for validation (like some LAN device discovery or direct P2P connections) may misbehave, requiring you to exclude the relevant domains via fake-ip-filter.

redir-host mode

In this mode, Clash resolves the domain to a real IP using the configured DNS servers first, then routes by IP or domain rule. It's more broadly compatible and avoids the "fake IP confuses the app" problem, but the resolution step involves a full DNS lookup, so it's slightly slower — and if your rule set also contains IP-range rules, mismatches between the resolved IP and the actual routing address can occasionally cause misrouting.

Unless you have a specific compatibility need, default to fake-ip when running TUN mode. If a particular LAN tool, game, or device-discovery feature breaks, add just that domain to fake-ip-filter rather than switching everything to redir-host and losing the overall experience.

A Ready-to-Use Config You Can Drop In

Putting all of the above together, the config below fits most common setups — direct connection for mainland traffic, proxy for everything overseas — and can replace the entire dns section of your config file:

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.stun.*.*"
    - "+.stun.*.*.*"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
  nameserver-policy:
    "geosite:cn":
      - 223.5.5.5
      - 119.29.29.29
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query
      - https://8.8.8.8/dns-query

The routing logic here works like this: check nameserver-policy first — if it matches, resolve with the assigned server immediately; if not, fall through to the default nameserver resolution, then let fallback-filter judge whether the result is trustworthy, switching to fallback only when it isn't. The whole process is handled locally via fake-ip, so queries never get intercepted by an ISP's DNS. If your subscription provider ships its own DNS optimization block, it's fine to keep the defaults first and swap in these fields one at a time instead of overwriting the whole section.

Troubleshooting Common Symptoms

If problems persist after setup, check these angles:

• Mainland sites load slowly: usually means nameserver-policy doesn't cover those domains, or your domestic DNS list only has one slow server — add two public DNS servers from different providers.
• A LAN tool stops working after enabling fake-ip: add the specific domain or IP range to fake-ip-filter instead of switching the whole setup to redir-host.
• Overseas sites still occasionally resolve to an invalid address: check whether ipcidr in fallback-filter covers the poisoned address ranges typical of your local ISP, and if needed, force that domain to fallback via fallback-filter.domain.
• Images or scripts fail to load after switching nodes: this usually isn't a DNS issue — it's routing rules splitting the main domain and its static-asset domains into different policy groups. Check whether your rule set covers all the domains that site actually uses.