Why you can still see a "DNS leak" with Clash running

People often conflate three different problems: the browser shows the proxy exit IP, yet a DNS leak test lists your ISP; a site loads but matches the wrong rule; or a command-line tool resolves differently from Chrome. Each symptom has different root causes, but they all point to the same architectural truth: routing and resolution are two pipelines. Clash Meta (Mihomo) can own both, yet only when your profile, client mode, and operating system resolver agree on who answers port 53 (and who handles encrypted DNS).

A classic DNS leak happens when hostname lookups still go to resolvers outside your policy path—often your ISP or a public resolver reached directly—while TCP or UDP traffic rides the tunnel. The observer at that resolver learns which names you looked up even if the bytes later exit from Tokyo. Clash reduces that risk by centralizing DNS inside the core with the dns: block, optional enhanced mode (fake-ip or redir-host), and—when you use TUN—dns-hijack so stray UDP/53 queries do not bypass the engine. If any layer still resolves around the core, leak tests will keep complaining no matter how green your proxy indicator looks.

This article stays practical: we map the knobs you actually see in YAML and GUIs, then give reproducible verification steps so you are not swapping DNS servers at random. If you are new to installers, grab a stable build from our Clash download page first, import a working subscription, and return here once basic connectivity works.

fake-ip versus redir-host: pick the right mental model

Mihomo exposes DNS enhanced mode as either fake-ip or redir-host. They are not two speeds of the same feature; they change what the client learns at lookup time, which in turn changes how domain-based rules and sniffing interact with the connection.

fake-ip answers many queries with addresses carved from a private range (commonly 198.18.0.0/15 in templates). Applications connect to that placeholder; the core completes the real resolution on a path aligned with your rules, often with the help of sniffing for TLS and QUIC. The upside is snappy domain routing and fewer races between IP-CIDR rules and CDN churn. The downside is compatibility: anything that requires the true record up front—some LAN discovery flows, certain captive portals, or split-horizon corporate hosts—may misbehave unless you add exceptions via fake-ip-filter, domain policies, or dedicated nameserver-policy routes.

redir-host behaves closer to a traditional stub resolver: answers reflect upstream results (subject to your DNS routing), which keeps semantics intuitive for local services. The trade-off is that you must keep nameserver, fallback, and your rules: section mutually consistent. If a domain resolves to a domestic IP while your rule set sends the TCP flow overseas—or the opposite—you will chase ghosts in the policy UI even though the YAML "looks fine" line by line.

ℹ️
Works with TUN: If you already followed our TUN mode guide, keep dns-hijack and the dns: block in sync. Hijack moves stray resolver traffic into the core; mismatched DNS mode still yields split-brain symptoms.

Steering queries with nameserver-policy and related knobs

Once you understand fake-ip versus redir-host, the next failure mode is over-broad recursion: every hostname races to the same resolver pair, even when some domains should never leave your LAN or should always hit a provider-specific path. Mihomo-style cores address that with nameserver-policy maps that pin suffixes or exact names to dedicated upstreams, and with auxiliary fields such as proxy-server-nameserver (when your core version exposes it) so proxy endpoints themselves resolve through a channel that will not create bootstrapping loops.

Use policies when you can name the exception: corporate *.intranet.example to an internal forwarder, a streaming origin that breaks when resolved overseas, or a SaaS API that pins certificates to specific edge POPs. Keep the list short and documented; giant policy tables become another undebuggable mini-profile. When in doubt, log a failing hostname, add the narrowest policy, and retest with the same three verification steps—do not blanket-switch enhanced mode because one stubborn client misreads fake-ip.

How to think about nameserver, fallback, and filters

Exact keys evolve between Mihomo releases, so treat the following as a pattern language you will align with the current wiki—not a paste-and-forget blob. In most profiles, nameserver lists the resolvers you want to try first for general browsing, while fallback holds alternatives when your fallback-filter says the first answers are untrusted or geographically wrong for your intent. A common pattern is to keep domestic-friendly resolvers in nameserver and let fallback carry neutral anycast resolvers when GEOIP or response characteristics fail a filter.

# Illustrative only — confirm keys against your Mihomo version
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
    - tls://dns.google
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

Notice what this does not do: it does not magically stop leaks by itself. You still need the operating system to hand DNS work to Clash, which is why TUN plus hijack or a disciplined system-proxy setup matters. Pair DNS policy with nameserver-policy when specific suffixes must always hit a particular resolver—useful for corporate VPN names, certain streaming endpoints, or LAN segments that should never be dragged through an offshore recursive server.

When something breaks only under fake-ip, reach for fake-ip-filter (and related domain lists) before you disable enhanced mode wholesale. The filter is how you tell the core "these names need genuine records now," which stabilizes odd TLS clients and intranet hosts without giving up fake-ip for the rest of your traffic. If you need a broader tour of how GEOIP and rule order interact with these DNS choices, read our rule routing best-practices article alongside this page—the two topics are inseparable in real configs.

Tested verification: three layers you can repeat

Leak hunting is easier when you separate application behavior, OS resolver state, and core logs. Work top-down so you do not "fix" DNS in Chrome while PowerShell still uses a different path.

  1. Core logs first. Trigger a fresh request to a domain you control in rules—watch whether Mihomo logs a DNS event and a connection with the same host. If the browser shows traffic while the core stays silent, you are not in the same capture path (mixed TUN off, split tunnel, or a second VPN fighting for routes).
  2. Terminal resolver checks. On Windows, open PowerShell and run Resolve-DnsName example.com or use nslookup while Clash is in the state you are testing. On macOS, run scutil --dns and compare ordering before and after enabling TUN or changing hijack. If terminals ignore Clash while Safari is fine, you are seeing libc resolver differences, not a defective rule file.
  3. External leak pages with care. Pick reputable DNS leak testers, understand that WebRTC and split DNS can create confusing readouts in fake-ip mode, and run the test twice: once with browser secure DNS off, once with your intended long-term settings. If discrepancies vanish only when browser DoH is disabled, you have isolated a bypass—not a mystery leak.

When you need a second opinion on YAML fragments or client toggles, our documentation hub links to curated examples that track newer Mihomo fields; use them after you understand the flow described here so you do not fight version drift.

Browser secure DNS (DoH) and Clash together

Chrome and Edge can pin DNS-over-HTTPS to a public provider. That path may bypass the stub resolver chain Clash expects, which breaks the tidy story fake-ip tries to tell: domain rules may misfire, and leak tests will show resolver locations that do not match your policy groups. For debugging, turn secure DNS off temporarily and let Mihomo own recursion; once stable, either keep it off or align secure DNS with a design your core can reason about—never two competing masters without a plan.

Firefox offers a similar toggle; Safari leans on system resolvers more often but still inherits profiles from network extensions when VPN-style clients are active. Document what you changed so the next troubleshooting session does not become a coin flip.

FAQ

Does IPv6 cause leaks?

If IPv6 reaches the open internet while your policy only steers IPv4, you can see inconsistent exits and resolver paths. Temporarily disabling IPv6 on the interface you are testing—or ensuring your rules and TUN stack cover IPv6 end to end—removes an entire class of "works sometimes" bugs. Document the change; do not flip it blindly on production laptops without a rollback note.

How does this relate to split routing articles?

DNS chooses the IP; rules choose the outbound once the connection exists. If either stage is wrong, GEOIP-based shortcuts and domain exceptions will disagree with reality. Keep this page next to the domestic versus overseas routing guide when tuning providers: you are optimizing one pipeline, not two unrelated checklists.

Closing: alignment beats superstition

There is no single DNS address that guarantees privacy; safety comes from consistent ownership of resolution and transport. Fake-ip is a powerful accelerator for domain rules, redir-host is the conservative mirror, and nameserver plus fallback wiring is how you keep recursion honest when filters trip. Test with the same three-layer checklist whenever you change clients: logs, OS resolver state, and an external page you trust.

Compared with chasing random public DNS lists, aligning Mihomo with your capture mode usually produces calmer traces and fewer unexplained mismatches between IP checks and rule traces. When you want a maintained client build that tracks upstream Mihomo improvements, download Clash for free from our official page and experience the difference.