Clash DNS Configuration Explained: How to Fill In nameserver, fallback, and DNS Hijacking

The dns section is the most confusing part of any Clash config. The same configuration can make one user's pages load instantly while another user stares at a spinner — and the difference usually isn't the proxy nodes, it's how nameserver, fallback, and dns-hijack work together. This article walks through the dns section in the order you write it, explaining what each field is for and when it actually takes effect.

Get the dns Section Right First: enable, listen, and enhanced-mode

The dns section isn't a set of toggles — it's the complete configuration for Clash's built-in DNS server. It does three jobs: receive queries, decide what address to return, and hand the result to the routing rules. Here's the minimal working form:

dns:
  enable: true
  listen: 127.0.0.1:53
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

enable controls whether the built-in DNS server runs. When it's off, all domain lookups in system proxy mode go to the system resolver, so GEOIP and IP-CIDR rules may see poisoned addresses and route incorrectly. When it's on, Clash becomes the resolver itself and the results are also used for rule matching.

listen sets the bind address and port. 127.0.0.1:53 only serves the local machine, which is fine for pure system proxy setups; 0.0.0.0:53 also serves LAN devices and queries hijacked by TUN, so it's the better choice for TUN mode. If port 53 is taken by another program, you can switch to 127.0.0.1:5353, but then the system DNS and proxy settings must point there too.

enhanced-mode is a choice between two modes: fake-ip returns fake addresses from a reserved range, while redir-host returns real addresses. This field has the biggest impact on rule matching, and we'll cover it in detail in section 4. For now, remember the takeaway: use fake-ip with TUN mode.

How nameserver and fallback Split the Work: One Primary Path, One Backup

nameserver is the primary resolution path. Every domain is sent there by default. fallback is the backup path: only when the nameserver result is judged untrustworthy does Clash run a second lookup, and the fallback result wins.

The logic in one sentence: if the IP returned by nameserver is in mainland China, the domain isn't poisoned, so use it directly; if it's an overseas address, suspect poisoning and re-resolve through fallback. That's why the two lists have clear roles — nameserver gets fast domestic DNS servers, fallback gets trustworthy overseas resolvers.

  nameserver:
    - 223.5.5.5
    - 119.29.29.29

  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query

• For nameserver, use domestic DNS over plain UDP — single-digit millisecond latency and nearby nodes for domestic CDN domains.
• For fallback, use DoH — trustworthy results and resistant to poisoning; 1.1.1.1 and 8.8.8.8 are written as IPs directly, so no extra bootstrap lookup is needed.
• Don't reverse it: putting overseas servers in nameserver and domestic ones in fallback. Every query would go through slow overseas resolution, and when correction is actually needed, fallback would still return a domestic result — the whole mechanism becomes pointless.
• Also, don't mix domestic DNS into the fallback list, or poisoned domains will still get wrong IPs.

fallback-filter Logic: geoip, ipcidr, and domain

fallback-filter decides when fallback triggers. It only looks at the nameserver result and consists of three conditions:

  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16
      - 127.0.0.0/8
    domain:
      - '+.google.com'
      - '+.youtube.com'

geoip and geoip-code are the main switch. geoip: true means the IP returned by nameserver is geolocated, and geoip-code: CN means "IPs in mainland China are trusted". If this condition matches, the nameserver result is used as-is.

ipcidr adds trusted IP ranges. Private addresses returned for internal domains have no country, so geoip would misclassify them as overseas and repeatedly trigger fallback. That's why you list 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 127.0.0.0/8 here. 240.0.0.0/4 is a reserved range from the original Clash docs example; keeping it does no harm.

domain is the exception list. Domains listed here skip the filter and go straight to fallback. In terms of syntax, +.google.com matches the apex domain plus all subdomains, while *.google.com matches subdomains only. Putting common overseas domains here saves one geoip check.

The full decision order is:

1. Domain matches the domain list → use the fallback result directly.
2. The IP returned by nameserver matches geoip-code (CN) → use the nameserver result.
3. The returned IP matches ipcidr → use the nameserver result.
4. If none of the above match (the IP is outside mainland China) → resolve again with fallback and use the fallback result.

The cost of this logic is that overseas domains may get an extra fallback query on every lookup, and the DoH TLS handshake raises first-packet latency. For latency-sensitive cases, you can use nameserver-policy to assign a specific resolver to individual domains and bypass the whole decision chain:

  nameserver-policy:
    '+.baidu.com': 223.5.5.5
    '+.taobao.com': 223.5.5.5
    '+.google.com': https://8.8.8.8/dns-query

DNS Hijacking in TUN Mode: Why It Must Be Paired with Fake-IP

TUN mode pulls all IP traffic into a virtual network interface, so you'd think DNS queries are captured too. But the system resolver may send queries to any DNS server — the router's address, the ISP's DNS, or an app's built-in DoH — and while that traffic does enter TUN, it doesn't necessarily pass through the built-in DNS.

dns-hijack closes that gap: it intercepts all UDP and TCP traffic to port 53 on the virtual interface and forces it to the built-in DNS.

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53

Hijacking solves the "do DNS queries reach the kernel" problem. Next you need to solve "does the domain name survive into the connection stage" — and that's what enhanced-mode handles.

In fake-ip mode, the built-in DNS returns fake addresses from the 198.18.0.0/16 reserved range and records the domain-to-fake-IP mapping in the kernel. When an app connects using the fake address, the traffic enters TUN and the kernel restores the original domain from the mapping before handing it to the rules. Rules like DOMAIN-SUFFIX and DOMAIN-KEYWORD keep working.

In redir-host mode, the built-in DNS returns real addresses. Apps connect to real IPs directly, so by the time traffic enters TUN there are only IP packets — no domain for the rules to match, leaving GEOIP and IP-CIDR as fallbacks. For CDN domains and anything needing precise routing, rules largely stop working. This mode is fine under system proxy, where the domain is carried in the HTTP CONNECT request; the problem only appears in TUN mode.

The takeaway: hijacking guarantees queries reach the kernel, and fake-ip guarantees the domain isn't lost. Without either one, you get the two extremes of "everything goes direct" or "everything goes through the proxy", and the logs make it hard to see why.

fake-ip has a companion field, fake-ip-filter, for domains that need real addresses. LAN devices, .lan and .local suffixes, and local service domains belong here — otherwise they get fake addresses and become unreachable.

A Complete Configuration You Can Use Right Away

Combining the fields above into a working config, here's the reasoning: nameserver uses fast domestic DNS; fallback uses overseas DoH so poisoned domains get corrected; fake-ip keeps domain rules working in TUN mode; dns-hijack uses any:53 to cover all DNS traffic.

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.ptlogin2.qq.com'
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  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
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16
      - 127.0.0.0/8
    domain:
      - '+.google.com'
      - '+.youtube.com'
      - '+.github.com'

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53

After deploying, checking these six spots is the standard DNS troubleshooting routine:

• default-nameserver can't be omitted. It resolves the DoH server's own domain; without it, domain-form DoH servers like doh.pub can't establish a connection. IP-form 1.1.1.1 is unaffected, but keeping it is always safer.
• For dns-hijack, write any:53, not 8.8.8.8:53. The latter only hijacks queries sent to that address, so it breaks as soon as the system DNS changes.
• Make sure fake-ip-filter excludes internal domains, or LAN devices will have connection problems.
• Don't use redir-host with TUN mode. Broken domain rules are the most common cause of "internet works but routing is all wrong".
• When port 53 is occupied, change listen to 127.0.0.1:5353 and update the system DNS too — don't change only half of it.
• After changing the config, check the dns output in the debug log first, then query the built-in DNS with dig or nslookup to confirm whether it returns fake or real addresses.

There's no universal DNS template, only a self-consistent logic: nameserver handles speed, fallback handles accuracy, fallback-filter decides when to switch, and fake-ip carries domain info to the rules. Walk through them in this order and most resolution issues can be traced to a specific field.