Chrome Won't Use Clash on Windows? Disable QUIC and Fix System Proxy

Why “Clash on” still leaves Chrome inconsistent on Windows

Chromium-derived browsers—including stable Chrome, many enterprise builds, and several Electron shells—implement their own scheduler on top of what the OS exposes. On Windows, that means layering Network Service processes, QUIC-capable sockets, asynchronous DNS stubs, certificate verification, and third-party interception hooks beside whatever your GUI wrote into LAN settings. Mihomo dashboards may report healthy inbounds while UDP sessions or encrypted DNS lookups never traverse the same choke points as TCP CONNECT through your localhost HTTP proxy listener.

Meanwhile, administrators often mix metaphors: TUN adapters capture naive applications at the forwarding plane, whereas explicit proxies expect apps to voluntarily issue CONNECT to 127.0.0.1. Chromium can do both, sometimes in parallel per origin, depending on whether HTTP/3 is negotiated or whether fallback to HTTP/2 over TLS resumes through the proxy pathway. Complaints that sound like “half the Internet obeys Clash” frequently collapse into two checks: Kill QUIC-induced UDP shortcuts, then prove whether DNS-informed routing aligns with transport routing afterward.

Step 1 — Establish ground truth for system proxy on Windows

Before touching flags, reconcile three independent surfaces that all claim to influence outbound HTTP on Windows: the per-user LAN dialog behind Internet Options, WinHTTP defaults used by assorted services (not necessarily Chrome), and what your Mihomo-compatible client asserts after you tap “Set System Proxy.” Open the classic proxy dialog (inetcpl.cpl → Connections → LAN settings) while your client is supposedly engaged: Use a proxy server for your LAN should point at 127.0.0.1 with the mixed port shown in Yukino, Verge Rev, or your bare Mihomo YAML—typically 7890 depending on customization.

Next, elevate Command Prompt or PowerShell and run netsh winhttp show proxy. Administrators sometimes expect these values to match automatically; WinHTTP retains its own import story from legacy IE settings and differs from sockets-level decisions inside browsers. Misaligned WinHTTP does not excuse Chromium misrouting outright, yet troubleshooting teams compare both because ancillary updaters rely on whichever store you forgot to normalize. If you rely on TUN instead of manual proxies, record that clearly: default routes through the tunnel adapter should appear in route print or PowerShell Get-NetRoute without conflicting metrics that send select prefixes around your Mihomo NIC.

Pair this groundwork with our general Clash troubleshooting guide: many false alarms stem from forgetting that rule mode, outbound tag selection, and policy groups still decide what happens once traffic enters Mihomo—even after proxy discovery stops lying.

Step 2 — Chromium’s own proxy switch under Chrome settings

Open chrome://settings/system and inspect “Open your computer's proxy settings”. That shortcut deliberately opens the OS panel because Chromium prefers to defer canonical representation to the platform on desktop—unlike mobile profiles that sometimes embed per-app overrides. If you toggled an extension-based switcher in the past, uninstall or disable it before testing: extensions can pin destinations to direct sockets even when the OS points at Clash.

Also review chrome://settings/security adjacent privacy controls; while not the same as proxy UI, enterprise policies may force network behaviors through the component updater or safe-browsing endpoints that look like “random Google hosts” in logs. Note timestamps so you do not chase unrelated long-polling channels while debugging a primary site.

Step 3 — Disable QUIC so HTTP/3 stops bypassing your proxy path

QUIC carries an outsized share of confusion because it rides UDP with encryption approximating TLS while skipping many HTTP/1.1-era proxy assumptions. When an origin supports HTTP/3, Chromium may prefer that path; if your Clash setup only intercepts TCP flows through localhost HTTP CONNECT cleanly, QUIC datagrams can still egress toward the ISP—not because Mihomo broke, but because the browser chose a viable alternative stack that your policy never saw.

Apply the blunt instrument first—turn QUIC off—to validate the theory. Navigate to chrome://flags/#enable-quic (or search “QUIC” inside flags) and set Experimental QUIC protocol to Disabled. Relaunch Chrome when prompted. Alternatively, administrators who distribute shortcuts may append:

"C:\...\chrome.exe" --disable-quic

After relaunch, visit a heavy Google property or CDN-backed site that historically negotiated HTTP/3; use chrome://inspect/#devices adjacent tooling sparingly—or simply observe Mihomo verbose logs—for evidence that TLS over TCP dominates again. Symptoms like incorrect geolocation banners or split behavior between Gmail and youtube often stabilize once QUIC starvation forces HTTP/2 over the proxied conduit.

Once stable, decide whether you re-enable QUIC later under stricter UDP handling (for example Tun-driven capture covering UDP to the same thresholds as TCP—policy-dependent) or maintain QUIC disabled on machines where simplicity beats marginal latency wins.

Step 4 — Align Secure DNS with your resolver stack

Secure DNS inside Chrome can query encrypted resolvers (DoH) selected by the browser or by security products, returning answers that disagree with the fake-ip map your config builds. The UI lives under chrome://settings/security → Advanced → Use secure DNS. For diagnosis, choose With your current service provider or explicitly turn the feature off temporarily so stub resolution patterns match what Mihomo expects from the OS stub—especially when your profile uses fake-ip mode that synthesizes addresses for domain rules.

Contrast this with Mozilla’s separate DoH story covered in our Firefox + Clash SOCKS5, TUN, and about:config companion: Firefox exposes different preference keys, while Chromium centralizes secure DNS under settings and enterprise policy. If you require DoH through the same exit as web traffic, align provider endpoints with the outbound you intend—otherwise EDNS client subnet hints or distant anycast answers may steer you to CDN nodes that do not match your tunnel’s geography even when TCP flows proxy correctly.

When Windows itself enables “DNS over HTTPS” in modern builds, stack the override mindfully: OS-level DoH, Chrome Secure DNS, and Mihomo DNS listeners can nest three competing stories. For narrow debugging windows, disable upper layers first, confirm rules fire, then reintroduce encryption where compliance allows.

Step 5 — TUN mode versus explicit system proxy for Chromium

TUN mode transparently diverts traffic at the IP layer, which often captures UDP associated with QUIC if the tunnel policy includes it—while classic “set system proxy” approaches depend on applications honoring WinINet-based configuration. Teams sometimes enable both “just in case,” then wonder why double NAT or redundant hops appear in logs. Pick a primary strategy for desktop Chrome:

• Proxy-first: Keep QUIC disabled, rely on LAN proxy toward your mixed port, and avoid TUN unless a stubborn binary refuses proxy awareness.
• TUN-first: Let the adapter own default routes; set Chrome to “direct” relative to proxy UI (no manual localhost override) so you do not stack explicit CONNECT on top of already-tunneled flows unless you truly intend to.

Deep policy details live in our Clash TUN mode guide; the salient point for this article is that Chromium reacts differently to each mode when HTTP/3 re-enters the picture—hence tying QUIC controls to whichever mode you standardize on.

Step 6 — Extensions, policies, and alternate profiles

Corporate .admx policies may pin proxy bypass lists or mandate secure DNS independently of your tray app. Inspect chrome://policy while logged into the affected profile—non-empty rows referencing ProxyMode, ProxyServer, DnsOverHttpsMode, or QuicAllowed warrant conversation with whoever owns the baseline image. Likewise, uninstall VPN-browser extensions marketed as privacy shields; many inject localMitM roots or SOCKS endpoints that overshadow Clash silently.

If suspicion remains, create a disposable profile (People → Add) with zero extensions copied over. Launch with a shortcut that includes none of your hardened flags besides the QUIC disable snippet—profile corruption rarely causes systematic UDP leaks yet occasionally preserves obsolete policy caches until reset.

Step 7 — Verify with Mihomo logs and naive tests

Turn on verbose connection logging briefly in your GUI or tail the Mihomo core log. Reproduce navigation to two classes of targets: text-only HTTPS pages that reliably negotiated QUIC before (now forced over TCP), and latency-sensitive streaming endpoints previously split across oddly matched CDNs.

1. Open a single tab to an IP check endpoint over HTTPS—note ASN and continent.
2. Toggle Secure DNS states (off vs Chrome-managed) and reload; correlate whether IP or CDN city shifts without altering Clash outbound choice.
3. Observe whether UDP entries disappear after QUIC disables while outbound tags align with GEO rules.
4. Contrast with a second Chromium channel (Canary vs Stable) sharing the same proxy settings shortcut—helps isolate regressions independent of Mihomo upgrades.

When logs stubbornly omit Chrome despite obvious traffic, escalate to antivirus: HTTPS scanning interstitials occasionally wrap localhost interception differently per browser binary; pause shields only briefly to compare.

What typically breaks first (narrow mental model)

Recap

Getting Chrome Windows to honor Clash is less about a secret checkbox and more about stacking evidence: Windows proxy tables that match your Mihomo mixed port, QUIC disabled while you validate, Secure DNS choices that do not fight fake-ip logic, and a deliberate choice between transparent TUN mode and explicit proxies. Once TCP-heavy flows and resolver answers line up, return to tuning policy groups and subscription health—the fun parts—without questioning whether the browser smuggled traffic around your listener on UDP.

Compared with closed appliances that hide per-flow telemetry, Mihomo-compatible clients reward methodical checks. If you want a single installer path with readable dashboards before you touch raw config again, prefer the curated distribution on this site rather than scattering vendor links.

→ Download Clash for free and experience the difference