1. Why DNS still misbehaves with Clash on
People install a forwarder expecting one clean resolver path. In practice, Clash-family cores sit between applications and the wider network: they may answer locally under fake-ip, forward to multiple upstreams, retry with fallback when answers look poisoned, and consult different lists depending on geosite, domain suffix, or custom policy tables. If any hop is slow, blocked on your current Wi-Fi, or returns an address that trips fallback-filter heuristics, the user experience is “random slowdowns” or “this one domain is wrong again,” even though the proxy nodes themselves are healthy.
Another confusion is symptom mimicry. TLS handshake timeouts, endless redirects, and partial page loads can come from routing, certificate, or QUIC issues—but they can also originate from a resolver that handed you a wrong CDN edge or a captive-portal sinkhole. Treat DNS as its own workstream. Our fake-ip troubleshooting guide covers compatibility lists and sniffer interactions; this article focuses on the resolver graph itself so the two documents stack cleanly.
2. Mental model: nameserver versus fallback
Think of nameserver entries as your first-line pool. They should be fast on your typical network, tolerate laptop sleep and captive portals reasonable well, and align with the geographic reality you want most lookups to assume. Think of fallback as a second opinion that wakes up when primaries return answers that look poisoned, belong to reserved ranges, or otherwise trip the rules encoded under fallback-filter.
The important detail is ordering and classification, not “more resolvers equals better.” A long, exotic chain slows every cold query. An overly aggressive fallback-filter may never trust a legitimate answer from a regional resolver, forcing constant cross-region trips. A too-loose filter duplicates work without improving security. You calibrate against what you actually see in logs: which upstream answered, how long it took, and whether the address set matches what a clean network returns for the same name.
| Field | Role in plain language |
|---|---|
nameserver |
Primary upstreams Clash tries first; optimize for latency and everyday reachability from your home or office uplink. |
fallback |
Secondary upstreams used when primaries return suspicious results—depends on fallback-filter logic in your core build. |
fallback-filter |
Rules that label an answer “bad” (for example unexpected geography codes or reserved IP ranges); tune carefully to avoid thrashing. |
nameserver-policy |
Per-domain or per-category overrides: send *.cn domestic queries to mainland-friendly DoH, and keep offshore lists on neutral resolvers, or the inverse if your threat model differs. |
3. Step 1 — Logging and hijack sanity before YAML churn
Before editing ten lines, confirm whether the pain is local hijack. Some ISPs intercept port-53 UDP, rewrite DoH hostnames, or inject answers only on certain Wi-Fi networks. Symptoms that follow the network rather than the domain are your clue. On a phone hotspot, if poisoned answers vanish, suspect the terrestrial ISP path—not your Singapore exit node.
Turn on verbose DNS logging in your GUI if available, or watch the core log while you reproduce one failing hostname. Note the elapsed milliseconds, the upstream label Clash attached to the query, and whether the result jumped between address families. Save one clean trace per symptom class. That discipline prevents the classic failure mode where you merge a “perfect” profile from a forum thread, but it assumes DoH endpoints you cannot actually reach on your employer Wi-Fi.
4. Step 2 — Primary nameservers you can actually reach
Pick two or three primary transports you understand: plain UDP/TCP to a recursive, DoH, or DoT. Mixing families is fine if your client supports them; duplicating seven identical providers is not. Prioritize successful handshake times from your real locations—home ethernet, tethering, and any VPN-within-VPN stacks you routinely run.
If primaries frequently time out, Clash keeps retrying while applications show spinners. That feels exactly like “Clash DNS is slow,” even if later hops would have worked. Fix reachability first, then consider filter tuning. For mixed corporate environments, keep at least one primary that uses standard port-443 DoH because odd ports and exotic recursive IPs are common block targets.
dns:
enable: true
# Listen address varies by GUI; confirm against Mihomo docs
nameserver:
- https://cloudflare-dns.com/dns-query
- tls://dns.google
- dhcp://systemThe snippet above is illustrative: substitute providers that match your compliance needs, and verify keys such as dhcp://system against the exact core you ship. Some bundles prefer default-nameserver for bootstrap queries—read your release notes rather than assuming field-for-field parity across forks.
5. Step 3 — Fallback chain and filters that match your threat model
Add fallback servers that are independent of your primaries: different operator, different region, different transport where possible. The goal is not infinite redundancy—it is a trustworthy second opinion when primaries lie or return sinkholes. If your primaries and fallbacks ultimately recurse through the same conglomerate, you gain little.
fallback-filter should reflect what you consider poisoned. Many templates enable GeoIP-based checks or reserved IP-CIDR lists. That helps against obvious hijacks, but on global CDNs the “right” answer might legitimately look foreign relative to your physical seat. If you aggressively mark those answers bad, you force constant fallback chatter and inflate latency. When in doubt, loosen filters gradually while watching logs, rather than importing a maximal rule set you did not author.
fallback:
- https://dns.google/dns-query
- https://1.1.1.1/dns-query
fallback-filter:
geoip: true
geoip-code: CN
ipcidr:
- 240.0.0.0/4
- 0.0.0.0/32Geo-related fields differ by version; treat the YAML as a conversation starter with your core’s current documentation. Always reload the profile or restart the embedded DNS listener after edits so you are not fooled by stale cache entries in the forwarder or the downstream operating system stub.
6. Step 4 — nameserver-policy for split domestic and international resolution
When your rules send mainland domains DIRECT and overseas brands PROXY, DNS should usually anticipate the same split. If every query first hits an offshore recursive, you may receive CDN coordinates optimized for exits abroad—then your DIRECT path chases addresses that make sense for Los Angeles, not for your city. Conversely, forcing all lookups through a narrow domestic recursive can miscolor offshore brands that share infrastructure with local edges.
nameserver-policy (sometimes paired with rule providers such as geosite) lets you attach resolvers to suffix lists or categories. Keep policies short and intentional: a giant imported spreadsheet is brittle on every subscription refresh. Prefer a concise domestic block, a concise global block, and a default pool for everything else. Align the policy table with the same domains you already tag in rules: so routing and resolution tell a single story.
nameserver-policy:
geosite:cn: https://doh.pub/dns-query
geosite:geolocation-!cn: https://dns.cloudflare.com/dns-query
'+.corp.example': tls://[email protected]Replace domains, transports, and list names with ones valid for your deployment. Corporate internal zones are typical examples of why split-brain DNS matters: the public internet will never know those names, so a blind offshore recursive is the wrong tool entirely. For Windows plus WSL quirks where localhost forwarding interacts with resolver choice, pair this section with our WSL2 and Windows DNS walkthrough so DHCP-supplied servers and systemd-resolved do not fight your YAML.
7. fake-ip and where the answer truly comes from
fake-ip mode is excellent for perceived speed: many queries receive an immediate synthetic address from fake-ip-range, while the real routing decision unfolds when connections materialize. That convenience means application-visible DNS answers are not always literal A/AAAA records from the public internet. Debugging “wrong IP in browser devtools” therefore requires you to ask whether the hostname is filtered for real resolution via fake-ip-filter and whether policy still aligns when the stack later resolves through proxy exits.
If certain domains need faithful public answers—LAN names, finicky SSO portals, some game services—expand fake-ip-filter deliberately rather than flipping enhanced mode globally. The compatibility story intersects with resolver policy: filtered names bypass the synthetic shortcut and interrogate your nameserver/fallback graph like traditional stubs. Treat fake-ip as a performance layer on top of the resolver design you build in earlier steps, not a replacement for it.
8. DIRECT versus PROXY and which network carries DNS
A subtle point many profiles gloss over is where the upstream DNS query leaves after policy picks DIRECT or PROXY. When you send TCP through a remote node, some stacks also hairpin DNS across that tunnel; others keep DNS local depending on tun, redir, or eBPF capture settings. If domestic DIRECT web traffic still resolves via an offshore recursive, you can see “correct” rules yet odd latency or occasional miscaching because the resolver’s view of edgenodes does not match the ISP path your packets take.
Align guidelines: match resolver geography to the expected egress for the domain class. For DIRECT domestic traffic, prefer resolvers that behave well on your ISP uplink. For PROXY traffic, consider resolvers reachable through the tunnel—or at least resolvers that model global routing the same way your nodes do. If you need a rigorous leak-oriented second opinion on browser-visible DNS, read our WebRTC and DNS leak checklist; it complements this resolver tuning without duplicating the fake-ip deep dive.
9. Verification without cargo-cult tweaks
After each YAML iteration, run a tiny verification loop:
- Pick one failing hostname and one “known good” control hostname from each region you care about.
- Reload DNS in the client, clear only if necessary—avoid unnecessary full OS cache flushes unless you are isolating OS-level stubs.
- Read the forwarder log: which server label answered, how long it took, whether fallback engaged, and whether the answer set is stable across two consecutive queries.
- Compare against an independent tool on a clean network path (for example secure DoH from another device) to distinguish resolver bias from true routing issues.
- Re-run your application test with the same outbound mode you intend to ship; changing nodes mid-test invalidates DNS conclusions.
Document outcomes in a single table: timestamp, hostname, mode (fake-ip on/off), primary server, whether fallback fired, and observed latency bucket. Future you—and anyone helping on a forum—will immediately see whether the latest tweak addressed resolver graph behavior or merely masked a flaky cafeteria access point for an hour.
10. Summary
Slow or poisoned Clash DNS is usually an ordered workflow problem, not magical malware on every exit node. Start from reachable primaries, add a thoughtful fallback chain with a fallback-filter you understand, then layer nameserver-policy so domestic and international destinations each consult resolvers that match how you route them. Keep fake-ip compatibility lists maintained for picky domains, and always ask whether DIRECT versus PROXY implies a different natural resolver vantage point.
Maintaining that structure beats endlessly reshuffling subscription lines. If you want a broader YAML baseline before you specialize DNS, skim our configuration documentation next—then return here when logs show resolver names rather than policy misses.
Clash-family cores expose more DNS knobs than most clients; used deliberately, they eliminate the brittle guesswork that passes for “optimization” in copy-paste profiles.