1 Symptoms: rules look fine, the browser does not care
The complaint is familiar in community threads: “Clash is on, FakeIP is on, but this tab still uses my home IP or the wrong country.” Sometimes only Chromium-based browsers misbehave while a command-line curl test through the same machine respects the policy group. Other times, switching to Firefox or Safari suddenly “fixes” routing without any YAML change. Those patterns point away from a bad DOMAIN-SUFFIX line and toward a separate resolver inside the process that is drawing the page.
When Chrome secure DNS or Edge secure DNS is set to use a public DoH provider (or “with your current service provider” in modes that still upgrade to encrypted DNS where available), the browser may not send name queries through the operating system stub resolver that Clash or Mihomo intercepts. Instead, the HTTP client built into Chromium negotiates DNS over HTTPS with a known endpoint, obtains real remote IP addresses, and opens connections accordingly. If your Clash profile relies on FakeIP to map hostnames to internal addresses and then route by domain on the first packet, a browser that already resolved the true IP has partially skipped that contract. The result is traffic that appears direct, rule tests that look inconsistent, and endless frustration in log analysis.
None of this implies that DoH in the browser is “wrong” in absolute terms—it is a privacy and integrity feature for ordinary users. For people who orchestrate split routing with a local proxy, it is a layer that must be aligned or disabled so one resolver does not override another. A maintained desktop client from our download page remains the right place to get installers; keep upstream GitHub for source and issues, not as the only install path.
2 How the resolver chain breaks when Chromium uses DoH
In a classic Clash setup with FakeIP, the core expects the applications on the host to query DNS in a way that ultimately reaches Mihomo’s listener—often on 127.0.0.1 with redir-host or fake-ip range addresses returned so connections can be tied back to a domain and matched against rules. The operating system, DHCP, and sometimes router DNS settings cooperate when nothing tries to be clever. A Chromium build with secure DNS enabled is clever: it can ship its own list of DoH providers and speak HTTPS directly to them, so the name resolution never hits the local stub the way a legacy resolver would.
That is not the same as “DNS leak” in the sense of an ISP seeing queries—often the opposite, because the query goes to Cloudflare, Google, or another public recursive. The problem for Clash users is competition for authority: the browser and the core disagree about which address belongs to a hostname, and which path packets should take. DNS 抢解析 in community language captures this tug-of-war: whichever resolver answers first and is trusted by the app wins for that socket. You wanted Mihomo to be the single source of truth; the browser’s DoH is a second source.
Why FakeIP makes the clash visible
FakeIP is powerful because it centralizes name-to-route mapping, but it assumes cooperative clients. When a browser already holds a real A/AAAA record from a remote DoH server, the connection may bypass the address range where your tun or redirect logic hooks in, or the domain information may be missing from the first handshake in the way your stack expects. Misaligned TLS may follow: not always an obvious certificate error, but subtle symptoms like the wrong geolocation, CDN edge, or exit node in speed tests. Aligning the browser with system DNS (and thus with Clash) removes that entire class of split-brain behavior.
rules blindly.
3 Not the same topic as “Meta DoH + FakeIP” inside the core
Our Meta core DNS leak prevention guide walks through DoH inside the Mihomo dns: block, default-nameserver, fallback-filter, and how to pair FakeIP with tun-level DNS hijack so the entire system cooperates. That article is the right map when the proxy should own DNS end to end. The present article addresses a different layer: Chromium can ignore your carefully tuned OS chain when its own secure DNS feature is on, so even a perfect dns section does not get a chance to run for that browser’s queries.
Think of it as two separate DoH conversations: one you configured in YAML for the core, and one the browser may open directly to a public resolver. Both can be “correct” in isolation and still produce nonsense together. Disabling the browser’s DoH is not a vote against encryption in general—it is a decision to let the resolvers you placed under Clash and Mihomo drive name resolution for that application. You can re-enable secure DNS later if you move to a design where the os resolver and core are no longer the authority for that traffic.
4 Google Chrome: turn off secure DNS
The UI labels move slightly between versions, but the intent is stable. Open Chrome settings, go to the Privacy and security section, and locate Security. Inside that page, find Use secure DNS and switch it off (or choose the explicit option that uses your current system provider without upgrading to a third-party DoH if your only goal is to stay on the same resolver the OS already uses—when in doubt, full off is the clearest test). On some channels the toggle lives under a “Advanced” subsection; search the settings field for secure DNS if the menu layout has shifted.
Chrome also exposes an internal utility page. Navigate to chrome://settings/security in the address bar for a direct path to the same controls. If you manage browsers through policy in an organization, BuiltInDnsClientEnabled and friends may override the UI; see the enterprise section below. After you change the option, fully restart the browser, then retry your failing site. A half-reloaded profile sometimes keeps old resolver caches warm longer than you expect, so a full quit matters for fair testing.
5 Microsoft Edge: turn off security DNS (DoH)
Edge shares Chromium’s engine but ships Microsoft-specific wording. Open Settings, then Privacy, search, and services, and scroll to Security. Find the control named along the lines of Use secure DNS to specify how to look up the network address for websites and set it to off, or to prefer the system resolver without an independent DoH path. Wording can read “Choose a service provider” when misconfigured—if you had picked a public provider, your traffic was never asking Windows stub DNS first.
You can open edge://settings/privacy to jump closer to the right panel. If Edge is signed in with work or school accounts, a mobile device management or enterprise policy can force secure DNS on; the toggle may be greyed out. In that case you need the administrator’s policy, not another registry hack from a random forum. After changes, close every Edge window including background apps from the system tray, then test again. Consistency with Clash matters more than any single vendor default.
6 Verify that Clash and FakeIP are back in charge
Start with a narrow checklist so you are not mixing five problems at once. First, confirm the desktop client is running in the mode you think—system proxy or TUN—and that no second VPN is reordering routes. Then, with Chrome and Edge both set to use normal system DNS, open a small mixed set of sites that were previously “wrong” and watch Mihomo or Clash Verge’s live log. You should see domain-based lines or IP ranges that line up with your rules and policy groups, not a sudden burst of direct connections to addresses you never mapped through FakeIP.
Second, use an external what is my IP or DNS leak page in the same browser. Compare the reported country and autonomous system to the exit you selected. If the page still shows your real ISP on a PROXY rule, bounce upstream: confirm the rule for that site’s DOMAIN-SUFFIX is above catch-alls, confirm sniffer and TLS settings if you are on exotic ports, and read the Meta Sniffer article for HTTPS hostname recovery when SNI and routing disagree. The difference is that sniffer issues persist across browsers, while secure DNS issues often disappear the moment you test in a non-Chromium client.
Third, flush local caches. On Windows, ipconfig /flushdns is a common companion; on macOS, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder is the traditional pair. Revisit the browser after a clean start. If you still see odd resolution, check for a browser extension that injects its own proxy or DNS—they can recreate the same class of problem outside the main settings screen.
7 TUN mode, extensions, and residual pitfalls
Enabling TUN in Clash Verge or Mihomo often makes misrouted traffic easier to see because more packets pass through the core, but TUN does not magically read the minds of built-in DoH clients inside the browser. Until the browser stops resolving independently, the address it connects to is still the one it obtained from a remote secure DNS server. That is why this article focuses on the browser switch first, then on tun and dns-hijack in the core DNS article as a broader hardening pass.
Password managers, “privacy” extensions, and some antivirus products ship nested proxies or their own DNS settings. If symptoms persist only on one machine profile, audit extensions with the same rigor you applied to Chrome secure DNS and Edge defaults. As a last resort, create a fresh browser profile with no extensions, default secure DNS off, and only the Clash system proxy in play—if that profile behaves, reintroduce your tools one at a time until the culprit reappears.
8 Phones, tablets, and the rest of the stack
This article is about Chrome and Edge on desktop. On Android, a parallel issue is the operating-system Private DNS (DoT) feature, which can pull the same “second resolver” trick on a different layer; FlClash and Mihomo users should address that in the device settings, not in the Chromium switch alone. iOS handles DNS differently again; the principle—one coherent resolver path through your Clash stack—remains, but the toggles are not the ones listed above. If you are debugging a mixed environment, document each platform separately instead of assuming one blog section fixes every form factor.
Also remember that split routing is a whole-stack contract: the subscription’s remote rules, your local rules overrides, DNS mode, and now the application’s resolver behavior must all tell the same story. Fixing browser DoH is often the cheapest win because it is a single obvious toggle, yet it is only one line in a longer checklist. Pair this read with the Mihomo DNS guide when you want the proxy itself to run encrypted resolvers in a way that does not fight your policies.
9 FAQ
- Is turning off secure DNS “less secure”? It can reduce transport privacy for raw DNS, but in your model Clash is the control plane. You can reintroduce encryption via Mihomo’s DoH toward resolvers you trust, without letting the browser open a second channel you did not configure.
- Will Firefox have the same issue? Firefox has its own DNS over HTTPS settings; if you use Firefox, check Network Settings and disable “Enable DNS over HTTPS” for the same reason, or point it to a resolver you manage through the proxy story.
- My organization forces Edge policies—what now? You need an IT exception or a split tunnel profile that the administrator supports. No end-user flag bypasses a managed policy for long, and you should not rely on unsafe workarounds on company hardware.
- Does this replace Sniffer for mistaken HTTPS routes? No. Sniffer and SNI fixes address a different class of error where TLS metadata does not match your domain rules. Use both articles when logs show hostname drift, not only IP drift from resolution.
- After disabling, sites load slowly once—then fine: Normal: cold DNS caches repopulate through the system path. Give it a minute before you declare failure.
10 Wrap-up
When Clash and FakeIP are configured but split routing still “does nothing” in the browser, suspect Chrome secure DNS and Edge secure DNS. DoH inside Chromium answers names without your system stub resolver, competes with Mihomo for authority, and produces the DNS 抢解析 class of issues power users name-check in support channels. Disabling that layer restores a single resolution path so your rules and policy groups can do their job. It complements—not replaces—the deeper Meta dns work in our leak prevention guide, which stays the reference for DoH and FakeIP on the core side. Among desktop clients, a polished GUI with readable logs makes this debugging loop far faster than editing blind—especially when the fix was a two-click browser setting all along. Compared with all-in-one “privacy” browser bundles, Clash on the Mihomo core keeps the rule graph visible, versionable in Git, and under your own review when resolver behavior changes again next year.
If you are standardizing a client for your own machines, our curated builds on the download page keep installers and release notes in one place; use GitHub for the license and code, not as the only front door for colleagues who need a working binary today. Once the browser’s secure DNS toggle is off and logs line up, you can return to tuning streaming rules, work-from-home access, and everything else that actually depends on split routing instead of fighting invisible DNS Competition.
