The Complete Clash DNS Guide: Fake-IP, DNS Tampering & Self-Hosted Resolution

Why DNS Is the Usual Culprit Behind Broken Routing

Plenty of people spend ages tweaking rules only to find a site still goes through the wrong line, and their first instinct is "the rule must be wrong" — but the real cause is often a step earlier: DNS resolution.

Rule-based routing depends on first knowing whether a domain/IP should go through the proxy, and that decision has two possible inputs: the domain itself (DOMAIN, DOMAIN-SUFFIX, etc. rules) and the resolved IP (IP-CIDR, GEOIP, etc. rules). If DNS resolution goes wrong at this step, every IP-based decision downstream gets it wrong too:

• DNS tampering / hijacking: some networks return incorrect or unreachable IPs for specific domains — most often seen with domains that are blocked or restricted on that network.
• ISP DNS returning the "nearest" result: an IP returned for CDN acceleration purposes may not be the endpoint you actually meant to connect to, which can throw off GEOIP-based decisions.
• Local hosts file / cache poisoning: a stale or incorrect record cached at the OS or router level — restarting your client won't help here, since the problem isn't in Clash at all.

Fake-IP vs. Redir-Host: Weighing the Two Modes

Clash's dns.enhanced-mode setting determines the underlying resolution behavior, and each mode has its own trade-offs:

Neither is universally "better." A common rule of thumb: prefer fake-ip for desktop clients running in TUN mode; if a specific app misbehaves, exclude just its domain in fake-ip-filter rather than switching the whole mode.

Fighting Tampering With Encrypted DNS: DoH and DoT

A traditional DNS query is plaintext UDP traffic on port 53, which is easy for network equipment in the middle to inspect and tamper with — one of the most common causes of DNS tampering. The fix is to wrap the DNS query inside an encrypted channel:

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 9.9.9.9
    - 208.67.222.222
  fallback:
    - https://1.1.1.1/dns-query
    - tls://8.8.8.8
  fallback-filter:
    geoip: true
    geoip-code: US

The idea, same as in the Advanced Configuration guide: use a fast plain DNS in nameserver for speed on everyday resolution, and an encrypted DNS in fallback for accuracy; fallback-filter decides when it's time to fall back. Set geoip-code to your own country/region code — fallback-filter uses it to spot results that don't look right for your location and switch to the encrypted resolver instead.

Per-Domain Resolution: nameserver-policy

Sometimes a blanket "primary vs. fallback" split isn't granular enough — you want to point specific domains at a dedicated DNS server, like a corporate domain that only resolves correctly through the internal company DNS. That's exactly what nameserver-policy is for:

dns:
  nameserver-policy:
    'geosite:private': '9.9.9.9'
    '+.internal.company.com': '10.0.0.1'
    '+.google.com': 'https://1.1.1.1/dns-query'

nameserver-policy takes priority over the global nameserver / fallback settings — think of it as an "exception list" for specific domains, which is exactly what you want for corporate intranets, self-hosted services, or anything else with its own resolution requirements.

How to Verify Resolution Is Correct

"It feels slow / won't connect" isn't enough to tell whether the problem is DNS or something else — the more reliable approach is to check the actual resolved address directly:

• The Dashboard: almost every Clash client's dashboard shows the actual destination IP for each connection — the most direct way to check, no extra tools needed.
• Command-line tools: use nslookup domain on Windows, or dig domain / nslookup domain on macOS/Linux, and compare the resolved IP for the same domain with Clash on versus off.
• A quirk of Fake-IP mode: under this mode, an OS-level nslookup will return a fake IP (usually in the 198.18.0.0/16 range) — that's expected and doesn't mean resolution failed; the core only does the real resolution once a connection is actually made.

Should You Self-Host a DNS Server?

For most people, a public encrypted DNS (like 1.1.1.1 or 8.8.8.8) is already enough to solve tampering issues — there's no need to run your own. But if you're managing a home gateway or router that needs to serve resolution to multiple devices consistently, a self-hosted DNS (paired with something like AdGuard Home or dnsmasq) makes more sense:

• Ad-filtering and split resolution can be centralized at the gateway level instead of configured per device
• You can define custom local hostnames (friendly names for devices on your LAN), and point Clash's nameserver-policy at your self-hosted DNS for them
• You get request logs and stats, making it easier to spot which device or domain is behaving oddly

If you're just using this on a single machine day-to-day, configuring Clash's built-in DNS module with nameserver / fallback is already plenty — self-hosting is really an advanced option for gateway-level setups.

A 3-Step DNS Troubleshooting Checklist

1. Open the connection details in the Dashboard to confirm which IP the problematic connection actually resolved to — is it "resolved wrong" or "resolved fine but the rule didn't match"?
2. Temporarily flip enhanced-mode from fake-ip to redir-host (or vice versa) as a comparison test to narrow down the cause.
3. Double-check whether fallback-filter.geoip is enabled and whether geoip-code is actually set to your own region — this is the detail people miss most often.

If you've checked all of the above and still can't pin it down, take a look at the connection troubleshooting checklist in the FAQ, or go through the full config again against the DNS section of the Advanced Configuration guide.