Clash on but Browsers Still Direct? Turn Off Secure DNS on Windows 2026

1. The Pattern: App Proxy Works, the Browser Disagrees

The scenario usually arrives as a one-line complaint: “Clash is on, but the browser is still direct.” In practice you might see a terminal tool or a smaller desktop program happily exiting through the node you picked, while every tab in Chrome or Edge still resolves names through a path that does not go through the policy you expect. That is not proof that the entire rule set is wrong. Chromium-based browsers can maintain their own secure DNS policy: they can send queries as DoH to Google Public DNS, Cloudflare, or another provider, over HTTPS, regardless of what ipconfig /all prints. When that happens, the “DNS half” of your split-tunnel design no longer lines up with the system proxy you enabled in the Clash client, and the site you load may appear to be “local” in geolocation or routing terms even if TCP traffic eventually rides the proxy for some connections.

Another angle is proxy not working as a user-visible label, when the real state is inconsistent DNS: one layer thinks the name resolves to a fake-ip pool (see routing and rules for the general model), the browser’s resolver believes something else, and the sniffer in mihomo cannot attach a clean SNI to a stable destination. Triage in the right order: first calm down DNS, then re-test the system proxy, then, only if needed, add tun or UWP workarounds such as Clash TUN and UWP loopback.

2. Google Chrome: Disable “Use secure DNS”

In recent stable Chrome builds, open Settings, go to Privacy and security, then Security. Find the block labeled with wording similar to Use secure DNS and switch it off. The exact label moves slightly with channel, but the intent is the same: you want the browser to inherit whatever resolver chain Windows (and then Clash) provides, not to ship name lookups out to a fixed DoH endpoint that ignores your Windows networking stack. If your organization enforces a policy through Google Admin templates, a managed Chrome may re-enable the feature on each restart; in that case you will need a matching policy change or a profile where you are allowed to opt out, because user toggles are not always sticky.

After the toggle, hard-restart Chrome—close all windows including background apps from the system tray, not just the last tab—then reload an IP or DNS test page. If the symptom was purely DoH skew, the delta should show up on the first fresh session. Keep extensions that inject their own proxy or “privacy” layers disabled during the test; a VPN-style extension and Clash on system proxy are a classic recipe for the UI saying “on” while the tab still does its own thing.

3. Microsoft Edge: Secure DNS and Enterprise Overrides

Edge shares the Chromium network stack but ships with Microsoft defaults. Open Settings, then Privacy, search, and services (or the closest equivalent on your build), and locate Security and Use secure DNS or the “Choose a service provider” list. For troubleshooting, set it to off or a mode that defers to the system resolver, not a locked provider such as a fixed Cloudflare or Google entry you cannot override. On domain-joined PCs, the enterprise may preconfigure secure DNS; if the toggle is gray, you are looking at a policy, not a failed Clash build.

Edge’s optional “follow device DNS” style wording is what you want while you prove the chain. Later, if you re-enable a provider, at least you will know that your Clash rules and the browser’s DoH both point at a coherent story. Remember that Edge also participates in the Windows secure DNS story: browser-only toggles are necessary but not always sufficient, which is why the next section covers the OS.

4. Windows 10 and 11: Encrypted DNS at the OS

Windows 11 exposes per-interface DNS and “encrypted” preferences under Settings > Network & internet. Pick your active connection (Wi-Fi or Ethernet), then Edit next to DNS server assignment, and prefer plain DHCP or a manual list that you understand—not an automatic DoH profile you never aligned with the tunnel. On Windows 10, the same concept exists with slightly different paths; the goal is to stop the OS from wrapping every lookup in a generic encrypted channel that your mihomo DNS block was not designed to interleave with.

This is the layer people skip because it feels like “the router’s job.” On a laptop that roams, though, a forgotten Wi-Fi profile can carry custom DNS, and a corporate NAC client can reapply encrypted DNS on every reconnect. You want one resolver story: either trust Clash to own DNS through tun, or set Windows to something predictable (often loopback to the Clash DNS port when your config expects it) that matches the YAML you imported. Mismatch here is a top cause of proxy not working symptoms that look like a bug in the core when they are not.

5. Verify the Windows System Proxy Matches Clash

Open Settings > Network & internet > Proxy in modern Windows. When your client enables system proxy mode, you should see a manual or scripted entry pointing to 127.0.0.1 and the port you configured—very often the mixed-port value from the profile. If the toggle is off, or the address points at an old port from a previous install, Chrome will cheerfully go direct for traffic that is not using an extension or command-line --proxy-server override. The desktop GUI and the actual OS switch can disagree after a crash or an aborted elevation prompt, so a visual “connected” in the app is not a substitute for this screen.

From an elevated or normal Windows terminal, you can also inspect legacy WinHTTP settings if a component still references them, but the primary consumer of what most readers care about is the user session settings above. Re-run the Clash “set system proxy” action after you correct any port drift, then restart the browser. If you previously toggled a VPN product that rewrites the same area, power-cycle that product or uninstall its leftover filter driver when testing—two stacks fighting for 127.0.0.1 is another frequent reason people suspect secure DNS when the real issue is a hollow proxy pointer.

6. Clash DNS and Why It Can Fight the Browser

A typical mihomo profile includes a dns section with enable: true, upstream resolvers, and often fake-ip or redir-host style behavior. Fake-ip is powerful: applications receive synthetic addresses, and the core maps them back to hostnames. Chromium, however, may cache or reorder steps differently from, say, curl.exe on the same host. The practical takeaway for this article is not to rederive the entire Clash manual here; it is to ensure you are not simultaneously forcing DoH in the browser to a public resolver that bypasses the fake-ip path entirely, then wondering why the connection object in logs never matches the DOMAIN rules you hand-authored.

If, after you disable secure DNS in Chrome and Edge and in Windows, you still see split behavior, that is the moment to open the core log and look for a single first-hop error line—similar discipline to the subscription guide linked earlier, but for ordinary HTTPS sites. nameserver-policy can pin specific domains to a known-good resolver, but do not add policy noise until the browser and OS are no longer shipping DNS sideways through DoH.

7. When to Switch to TUN or UWP Exemptions

System proxy only wraps applications that respect the user proxy. Some store apps, games, and pieces of the Windows service stack will ignore it. TUN (often paired with a Wintun driver in maintained GUIs) routes at a different layer, which can finally pull stubborn traffic off the direct path. If, after the DNS and proxy verification above, the browser is still the odd one out, read the TUN and UWP note for Clash on the same machine: UWP container loopback and process rules are the next tier of the story, not the first lever for simple DoH drift.

Likewise, IPv6 on dual-stack links can make one browser test show an unexpected exit if only half the family is steered. If you run a tun profile, be explicit in your plan about IPv4 versus IPv6; a partial proxy not working symptom sometimes collapses to “IPv6 still leaves the house on the wrong NIC.”

8. A Five-Minute Verification Script

Walk this once with a notepad. First, in Chrome and Edge separately, confirm Use secure DNS is off. Second, in Windows network settings, confirm no surprise encrypted DoH policy on the interface you are actually using. Third, under the OS proxy page, align 127.0.0.1:<port> with the Clash mixed-port or the documented local HTTP port. Fourth, in the Clash app, re-apply the system proxy switch and look for errors in the last few log lines. Fifth, with only one browser open, run an IP and a simple DNS check site you trust, then close and reopen the browser completely before a second test—this clears transient caches that look like “still broken” when the chain is already fixed.

9. Closing Notes

Compared with the chaos of re-importing the same Clash profile until something sticks, a structured pass that stops secure DNS and DoH in Chrome, Edge, and Windows, then re-aligns the system proxy, is faster and more reproducible. The maintained clients in this ecosystem tend to be more stable and easier to follow than a pile of ad-hoc forks—especially when you are teaching your future self what “fixed” actually meant.

When you are ready to install or refresh a client from a single trusted place instead of hunting for scattered binaries, use our download center, work through the toggles in this article once more, and only then return to fine-grained rules with confidence. → Download Clash for free and experience the difference