Clash DNS Configuration Explained: nameserver, fallback & DNS Hijacking

Why DNS Is the Foundation of Traffic Routing

Most Clash rules match against domain names: DOMAIN, DOMAIN-SUFFIX, and GEOSITE all read the domain directly, while GEOIP and IP-CIDR rules need a domain resolved to an IP first before they can make a decision. In other words, half the answer to "should this connection go direct or through a proxy" is hidden in the DNS response.

If resolution is left to the system's default DNS and that path gets hijacked or poisoned by an ISP, Clash ends up working with a bad answer: a domestic site resolves to an overseas IP and gets routed through the proxy by mistake, or vice versa. An even sneakier case is when the query goes out as unencrypted UDP to an overseas server, gets intercepted along the way, and comes back with a result that has nothing to do with the actual target — at that point, routing decisions fall apart entirely.

This is why Clash ships with a built-in DNS server: once enabled, the system or the TUN interface routes all domain queries through Clash, which answers them centrally based on configured upstreams, policies, and cache. The enhanced-mode setting further decides how answers are given: redir-host returns the real resolved result, while fake-ip returns a placeholder address first and only looks up the actual domain once a real connection comes in, for rule matching.

The Configuration Skeleton: enable, listen, and enhanced-mode

The DNS module lives under the dns block in the config file. Here's the minimal working skeleton:

dns:
  enable: true
  listen: 0.0.0.0:53
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.localhost"
    - time.*.com
    - ntp.*.com
    - localhost.ptlogin2.qq.com

Field by field:

• enable: the master switch. When set to false, Clash doesn't listen for DNS at all — resolution goes back to the system, and any IP-based rule matching has to rely on whatever the system resolver returns.
• listen: the listening address and port. 0.0.0.0:53 takes over port 53 on every network interface on the machine, which requires elevated permissions; GUI clients usually handle this authorization and point system DNS here automatically.
• ipv6: whether to answer AAAA queries. Keep this false if your network has no IPv6 egress — it stops apps from trying an unreachable IPv6 address first.
• enhanced-mode: the enhanced mode, either fake-ip or redir-host — see the glossary card above for what each means.
• fake-ip-range: the pool of fake addresses, defaulting to 198.18.0.1/16. This range is reserved for benchmarking and shouldn't appear on any real network; if your LAN happens to use it already, pick a different range.
• fake-ip-filter: a whitelist exempt from fake-ip answers, resolved directly with a real lookup instead. LAN domains, NTP time servers, and some voice/gaming services that rely on STUN usually need to be listed here.

nameserver vs. fallback: Splitting the Work Between Upstreams

nameserver is the default list of upstreams. When a real resolution is needed, Clash queries every upstream in this list at once and takes whichever answer comes back first. It handles the vast majority of domains — especially domestic ones that need low latency and ISP-aware results — so it's typically set to DoH endpoints from local public DNS providers. Upstream entries support four formats: a bare IP (plain UDP), tls:// plus a domain (DoT), https:// plus a path (DoH), and dhcp:// plus an interface name (inherited from the system).

fallback is the legacy Clash comparison-upstream mechanism. It's queried at the same time as nameserver, but its result isn't used by default — Clash only switches to the fallback answer when the nameserver response fails the fallback-filter check. The idea behind it: domestic upstreams are fast but can be tampered with, overseas upstreams are slower but trustworthy, and the filter picks the better one. fallback-filter offers three criteria:

• geoip and geoip-code: if the country code of the IP returned by nameserver doesn't match the configured value (CN by default), the result is treated as suspect and fallback is used instead.
• ipcidr: if the returned IP falls within a listed range (such as the reserved 240.0.0.0/4 block), it's treated as poisoned.
• domain: domains on this list always use the fallback answer, no conditions attached.

Two things worth flagging. First, the fallback upstream needs to use an encrypted channel like DoH or DoT — if it's plain UDP too, its queries are just as exposed to hijacking, and the whole comparison mechanism becomes pointless. Second, mihomo (the Meta core) has already marked fallback and fallback-filter as deprecated, recommending nameserver-policy instead for explicit, domain-set-based routing — more on that below.

The Full Path of a Single DNS Query

1. The app makes a query

   System DNS points to Clash's listening address, or the query is intercepted at the network layer by the TUN interface — either way, it lands in Clash's built-in DNS server.

2. fake-ip check

   If enhanced-mode is set to fake-ip and the domain isn't on the exemption list, Clash immediately returns a 198.18.x.x fake address and records the mapping; domains on the list go through real resolution instead.

3. Connection arrives, domain gets looked up

   The app connects to the fake address, Clash looks up the original domain behind it, matches it against the rules first, and decides whether to go direct or send it to a specific proxy node.

4. Real resolution when an IP is actually needed

   When a GEOIP or IP-CIDR rule is hit, or the target needs a direct connection, Clash first checks nameserver-policy for a dedicated upstream; if there's no match, it falls back to querying nameserver concurrently.

5. Poisoning check and final answer

   Legacy Clash uses fallback-filter to vet the nameserver result, switching to the fallback answer if it fails; the final result gets cached, so identical queries afterward are served straight from cache.

nameserver-policy and proxy-server-nameserver

nameserver-policy assigns dedicated upstreams by domain or domain set, and takes priority over nameserver. mihomo supports referencing domain sets with a geosite: prefix, so one line can route an entire group of domains to a specific upstream — this is exactly why it replaces fallback: the routing logic is explicit up front, instead of relying on after-the-fact result checking.

proxy-server-nameserver is dedicated to resolving proxy server domains. If a subscription's node address is a domain name, it needs to be resolved to an IP before a proxy connection can even be established; using a regular upstream that itself goes through the proxy creates a circular dependency. This field must point to an upstream reachable directly, without a proxy. default-nameserver, meanwhile, is the bootstrap upstream: the DoH/DoT upstreams in your config are themselves domains, so a set of plain-UDP upstreams is needed first just to resolve those.

dns:
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
      - https://doh.pub/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query
      - https://dns.google/dns-query
    "+.corp.example.com":
      - 10.0.0.2

In this example, domestic domain sets go through Alibaba's and Tencent's DoH, overseas sets go through Cloudflare's and Google's DoH, and internal company domains point to an internal DNS server; nameserver serves as the default exit for anything that doesn't match a policy. Since the queries to overseas DoH upstreams themselves go out through the proxy, that path is already trustworthy — no need for the after-the-fact comparison that fallback relies on.

Leaks, Hijacking, and Poisoning: Fixing Three Common Failures

DNS Leak

Browsers' built-in secure DNS (on by default in Chrome and Edge) bypasses system DNS and fires off DoH queries directly, so Clash never sees the domain — it can only match rules by IP, and routing accuracy drops noticeably. The fix is either turning off the browser's secure DNS setting, or enabling TUN mode so Clash intercepts all traffic at the network layer, guaranteeing that whoever the browser tries to query, it goes through Clash first.

Port 53 Hijacking

Plain UDP port 53 queries can be intercepted by any device along the path, and overseas UDP upstreams queried this way almost always get intercepted on mainland Chinese networks. Every upstream configured for cross-border queries should use DoH or DoT — nameserver should never contain a plain-UDP address pointing overseas.

Result Poisoning

In fake-ip mode, domains routed through the proxy never need a real resolution at all, so poisoned results have no way to enter the decision path; domains that need a direct connection go through domestic DoH upstreams, where poisoning is unlikely. If a specific domain still resolves oddly, check whether it needs adding to fake-ip-filter, then check the client logs to see which upstream actually answered that query.

Reference Configuration and Checklist

Pulling everything together, here's a ready-to-use mihomo-style DNS configuration:

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - time.*.com
    - ntp.*.com
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  nameserver-policy:
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query
      - https://dns.google/dns-query

Check through this list before enabling:

• enable is set to true, and the listen port isn't already in use by another service;
• System DNS already points to Clash, or TUN mode is enabled;
• nameserver uses domestic DoH, and every overseas upstream goes through an encrypted channel;
• proxy-server-nameserver is configured and reachable directly, so node domains resolve normally;
• fake-ip-filter includes LAN and time-server domains;
• Client logs show no persistent DNS timeout entries.

Once DNS is configured correctly, rule-based routing finally has a solid foundation to build on. Custom rules and policy group design going forward can all be built on top of this clean resolution baseline.