Clash DNS Configuration Explained: nameserver, fallback, and DNS Hijacking

Where the DNS block fits in Clash and what it does

In a Clash config file, the dns block is a module independent from proxies and rules. It doesn't decide which proxy node traffic uses — it handles exactly one thing: how domain names resolve into IP addresses. This step happens before rule matching — once Clash gets a domain, it needs to know the corresponding IP before it can evaluate GEOIP, IP-CIDR, and similar rules to decide routing. If the dns block is misconfigured, rule-based routing accuracy is directly affected. A typical symptom: a direct-connection rule is written, yet traffic still goes through the proxy, or vice versa.

The core fields in the dns block include enable (whether Clash handles DNS resolution itself), listen (the listening address, usually paired with TUN mode), enhanced-mode (fake-ip or redir-host), nameserver (the primary resolver list), fallback (the backup resolver list), and fallback-filter (rules that decide when fallback kicks in). These fields work together to form the complete resolution chain.

How nameserver and fallback divide labor

nameserver is the primary resolver list — Clash uses these servers to resolve domains first. fallback is the backup resolver list, only used when specific conditions are triggered. It's not simply "switch to fallback if nameserver fails."

Common nameserver setups

It's recommended to fill in servers with fast resolution speed and close geographic proximity from your ISP. A common combination mixes local public DNS with your carrier's DNS:

nameserver:
  - 223.5.5.5
  - 119.29.29.29
  - 114.114.114.114

What triggers fallback

fallback is usually filled with resolvers located outside your region or across networks, such as 1.1.1.1 or 8.8.8.8. It's not an unconditional backup — it works together with fallback-filter. Only when the result resolved via nameserver is judged "untrustworthy" (for example, falling outside the geoip range, or matching specific rules) does Clash switch to fallback and re-resolve. The point of this mechanism: local domains resolved via local DNS get the nearest CDN node, reducing latency, while domains that are censored or need proxy access get resolved via clean overseas DNS instead, avoiding incorrect results.

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
  domain:
    - +.google.com
    - +.facebook.com

The config above means: if the IP resolved via nameserver doesn't belong to mainland China (outside geoip-code: CN), or matches a domain in the domain list, the result is treated as untrustworthy, and Clash re-queries using the servers under fallback instead. This way, censored domains get correct results from overseas resolution, while local sites still use the fastest local DNS.

fake-ip vs redir-host: how the two enhanced modes differ

The enhanced-mode field determines how Clash handles DNS resolution results, with two options: fake-ip and redir-host. These two modes have different design goals and different use cases.

fake-ip mode

In fake-ip mode, Clash intercepts DNS query requests and doesn't return the real IP a domain maps to. Instead it returns a virtual IP from a reserved address range (198.18.0.0/16 by default). The application connects using this virtual IP, and as traffic passes through, Clash restores the virtual IP back to the real domain, hands it to the rule engine for routing decisions, and finally resolves the real IP for forwarding.

The advantage of this mode is faster resolution (no need to wait for a real DNS query every time), and rule matching can be done directly by domain rather than relying on IP, which is more accurate. When paired with TUN mode, fake-ip is nearly the standard choice. The downside is that some software with a strong dependency on IP addresses (certain game networking features, LAN discovery protocols) may misbehave after receiving a virtual IP, requiring those domains to be excluded individually in fake-ip-filter.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.0/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.stun.*.*"
    - "time.*.com"

redir-host mode

In redir-host mode, Clash queries nameserver/fallback for the real IP directly and returns it to the application, with no virtual address substitution. Rule matching depends on this real IP, or on the domain-to-IP mapping recorded during the query stage. This mode has better compatibility — applications rarely misbehave from receiving a "fake" address — but resolution overhead is higher, and rule matching is less precise than fake-ip in some complex scenarios.

Detecting and handling DNS hijacking

DNS hijacking refers to a resolution request being tampered with in transit by an intermediate node, returning an incorrect IP address, which redirects access to an ad page, an error page, or breaks connectivity outright. A common way to detect hijacking is resolving the same domain using different DNS servers and comparing the results — if your local ISP's DNS returns an IP that's noticeably different from a known public DNS, and access is behaving abnormally, hijacking or censorship is very likely.

In Clash's case, the fallback-filter mechanism itself is one way of dealing with DNS hijacking: it judges whether a result is trustworthy using geoip and domain lists, and re-queries with a different set of servers if it isn't. Beyond that, consider the following:

• Prefer nameserver addresses that support DoH (DNS over HTTPS) or DoT (DNS over TLS) to reduce the chance of plaintext queries being tampered with, in the format https://dns.server/dns-query or tls://dns.server:853.
• For domains known to be censored, you can specify the correct IP directly in the hosts block, bypassing the DNS query step entirely.
• Make sure the use-hosts field is enabled so the static mappings in hosts take effect and take priority over DNS queries.

dns:
  enable: true
  use-hosts: true
  nameserver:
    - https://223.5.5.5/dns-query
    - https://120.53.53.53/dns-query
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.4.4:853
  fallback-filter:
    geoip: true
    geoip-code: CN

hosts:
  example.local.test: 127.0.0.1

Note that DNS hijacking and proxy rule routing are two different layers of problems. If the proxy node itself works but a specific website consistently fails, check whether the issue is in DNS resolution first, rather than assuming the node or the rules are wrong. Conversely, if several DNS servers all return the same, correct result but access still fails, the problem is more likely in the proxy node or rule matching.

Anti-leak checklist and a full example

DNS leak refers to a domain resolution request that should have gone through the proxy instead bypassing Clash and going straight to the system's default DNS server, exposing the actual site being accessed. To avoid leaks, pay attention to the following:

1. Confirm that system-level proxy settings or TUN mode have correctly taken over traffic — don't enable proxying for only some apps while leaving the system-level DNS query channel uncovered.
2. The enable field in the dns block must be true, otherwise Clash won't intervene in resolution and all queries go through the system's default path.
3. It's recommended to explicitly set the listen field, e.g. 0.0.0.0:1053, and confirm that DNS requests at the OS or router level are correctly forwarded to this listening port rather than bypassing it via the system's built-in DNS client.
4. When TUN mode is enabled, confirm that the dns fake-ip or redir-host mode is consistent with TUN's stack configuration, to avoid two resolution logics conflicting and letting some requests slip through.
5. Use nameservers that support DoH/DoT to reduce the chance of your carrier observing or tampering with queries at the transport layer.

Below is a complete dns block example that combines all the points from this article, ready to drop directly into a config file — just adjust the specific nameserver and fallback addresses to match your actual nodes:

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  use-hosts: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.0/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.stun.*.*"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://223.5.5.5/dns-query
    - https://120.53.53.53/dns-query
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.4.4:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - +.google.com
      - +.github.io

The default-nameserver field deserves a separate note: it's used specifically to resolve the DoH server addresses written as domain names under nameserver and fallback (for example, 223.5.5.5/dns-query in the example above is already an IP, but if it were written as a domain-based DoH address instead, default-nameserver would need to resolve the DoH server's own IP first, before it can be used to query the actual user domain). This is an easily overlooked detail that affects whether the whole resolution chain actually works.