When Clash is "on" but traffic still looks direct
You did the obvious things: imported a subscription, picked a node, and flipped System Proxy in your Mihomo-based client. The tray icon looks happy. Then you open Microsoft Edge or Google Chrome, visit an IP checker, and your residential ISP still stares back. Worse, the Microsoft Store or another packaged app downloads updates as if nothing changed. Nothing is "broken" in the sense of a crash—yet the behavior violates your mental model of what "system proxy" should mean.
On Windows 11, Clash Windows 11 system proxy not working complaints usually fall into three buckets that stack rather than exclude one another: the operating system never received the proxy table you think it did, Chromium is honoring a different policy path than the Settings UI, or a UWP process is blocked from talking to 127.0.0.1 because of UWP loopback rules. This article gives you a single ordered checklist so you stop random toggling and start collecting evidence.
If you have not installed a current GUI yet, grab a build from our Clash download page first; the steps below assume Clash Verge Rev, FlClash, or another Mihomo front-end that can manage the Windows proxy switch.
127.0.0.1:7890. If you already migrated to TUN, many of the symptoms disappear because traffic is captured before applications get to debate proxy APIs—but readers hitting this page are often explicitly trying to avoid TUN on locked-down laptops.
Why system proxy is not a universal remote control
Windows exposes proxy settings through several channels. Consumer documentation flattens them into a friendly toggle, yet applications consult different APIs. Win32 desktop programs often read the same WinINET catalog your browser uses when set to "system default," but games, custom updaters, and many command-line tools open raw sockets without asking. Universal Windows Platform (UWP) apps add another twist: for security, they are sandboxed and forbidden from connecting to loopback addresses unless explicitly exempted. That single restriction explains a huge share of "Store apps never use Clash" reports when your inbound listener lives on localhost.
Clash itself, through Mihomo, can publish a mixed port and push proxy settings when you enable system proxy mode. If any other VPN or corporate agent also writes proxy keys, the last writer wins. Antivirus suites that "inspect HTTPS" sometimes install their own filtering proxies and revert your changes silently. Understanding that ecosystem prevents you from blaming the YAML when the OS never stabilized the intended configuration.
Step 1: Prove Windows actually holds the proxy
Before you touch browser flags, confirm the foundation. Open Settings → Network & internet → Proxy. Under Manual proxy setup, verify that Use a proxy server is on and that the address and port match what your client displays—commonly 127.0.0.1 with the mixed or HTTP port from your profile. If the switch is off or points at a stale port after you changed the YAML, your client failed to register the update or another program cleared it.
Next, validate that Clash is listening where the UI claims. A quick PowerShell check is Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue (replace the port with yours). You expect to see Listen on the loopback interface. If nothing is listening, the dashboard can still show "running" while the proxy service failed to bind—classic when the port is occupied by an abandoned process.
Finally, scan for conflicts. Another VPN that installs a filter driver may leave its helper service running even after you "quit" the app. Corporate Zero Trust clients sometimes reapply direct access policies minutes after reboot. Pausing those tools temporarily is not superstition; it is isolation. If manual proxy settings stick only when the third-party agent is disabled, you have found the real owner of the network stack.
netsh winhttp import patterns, keep Clash and those imports aligned or you will see "browser OK, updater weird" splits. Document anything your employer mandates.
Step 2: Edge and Chrome still ignoring the proxy
Assume Step 1 passed: Windows shows the correct manual proxy and the port listens. Chromium-based browsers can still detour. Start with the simplest variable: extensions. A privacy extension, an ad blocker with its own VPN feature, or a legacy "proxy switcher" can override system settings per tab. Launch an InPrivate or Guest window with extensions disabled. If behavior changes, uninstall or reconfigure the extension rather than chasing Clash.
Next, inspect Secure DNS. When the browser resolves names through DNS-over-HTTPS to a public resolver, you can get confusing signals on leak tests even though TCP exits through Clash. That is not quite "proxy ignored," but it feels identical in casual testing. Temporarily set DNS to plain system default while you validate routing, then restore hardening once the tunnel is trustworthy.
Chrome and Edge also respect managed policies. On managed PCs, ProxyMode or ProxyServer policies can pin a configuration that ignores user-level changes. Visiting edge://policy or chrome://policy reveals whether your organization owns the decision. If a policy enforces direct access, no consumer proxy client can negotiate around it without admin cooperation.
For users who run multiple browser profiles, remember each profile can set manual proxy overrides independent of the OS. Open the operating-system proxy section inside the browser’s settings page and confirm it says use system settings, not a fixed direct mode left over from testing.
Quick sanity tests
- Second browser: If Firefox is installed, compare behavior; Firefox has its own networking stack and helps isolate Chromium-specific issues.
- Command-line probe:
curl https://api.ipify.orgin PowerShell respects WinINET in many setups; ifcurlshows the exit IP you expect while the browser does not, keep digging inside Chromium. - Logging: Enable verbose Mihomo logs briefly and watch whether new connections arrive when you refresh a tab. No log lines mean traffic never reached Clash.
Step 3: UWP, Microsoft Store, and loopback isolation
Now the distinctive Windows issue. Many Clash setups expose inbound listeners on 127.0.0.1. UWP applications—including the Microsoft Store and various inbox applets—run inside an AppContainer that blocks loopback by default. From their perspective the proxy is unreachable even though Win32 Chrome happily talks to localhost. This is the heart of UWP loopback proxy troubleshooting: you must explicitly exempt the packaged app or move the capture layer below the sandbox with TUN.
Microsoft ships the CheckNetIsolation utility for this purpose. Administrators use it to allow specific packages to access loopback for development; proxy users borrow the same mechanism. The workflow is: identify the app’s package family name, then add a loopback exemption. PowerShell makes listing names straightforward—for example, Get-AppxPackage *WindowsStore* surfaces the family name tied to the Store experience.
Once you have the SID or family name, you can add an exemption. The canonical pattern uses CheckNetIsolation LoopbackExempt -a -n="Your.PackageFamilyName_xxxxxxxx". After adding, restart the app completely—not merely minimize—to ensure the new capability is picked up. You can audit existing exemptions with CheckNetIsolation LoopbackExempt -s to confirm your entry persisted across reboots.
Some third-party Clash-related tools advertise "UWP helper" behaviors; treat them as convenience wrappers around the same underlying Windows facility. If a helper fails, manual CheckNetIsolation remains the ground truth.
Step 4: Confirm your rules are not sending you "DIRECT"
When the infrastructure works, misrouting still happens inside Mihomo. A domain can match a DIRECT rule earlier than you remember because GEOIP or domain-suffix lists updated. Open the client’s connection log or a live dashboard and watch the rule name attached to the failing site. If it says DIRECT while you expected a proxy outbound, edit the profile or subscription rather than reinstalling Windows.
DNS mode interacts here. In fake-ip setups, some leak tests look odd until you understand which resolver answered first. Pair system proxy testing with a simple rule you control—like sending a known overseas domain through a named policy group—to verify semantics independent of DNS noise.
For a deeper tour of how ordered rules compete, see our article on Clash rule routing and domestic versus overseas paths; it complements this checklist once connectivity itself is reliable.
When to switch from system proxy to TUN mode
If you exempted UWP, stabilized Chromium, and still see stubborn binaries ignore proxies, you have hit the wall of voluntary proxy compliance. At that point TUN mode is the structured upgrade: it attaches a virtual adapter so flows are classified before user-mode apps debate WinINET. It is more moving parts, but it ends the whack-a-mole feeling for many gamers and developer tools.
Our dedicated guide Clash TUN mode explained walks through Windows driver prompts, DNS hijack alignment, and rollback strategy. Read it before you enable TUN on hardware you need for work tomorrow morning.
Closing: make the symptom reproducible, then fix once
Intermittent proxy failures invite superstition: you reboot, it works, you never learn why. A better habit is writing down three fields—OS proxy table, listener port, and UWP exemption state—whenever something breaks. In most homes and small offices, Clash on Windows 11 behaves predictably once those layers agree.
Compared with ad hoc SOCKS injectors, a maintained Mihomo client plus a clean profile gives you logging, policy groups, and update channels in one place. Pair that with the loopback knowledge above and the usual Chromium hygiene, and the classic "browser still direct" story shrinks to a short checklist instead of a weekend lost to forum threads.
When you are ready to standardize on a release that tracks upstream security fixes, download Clash for free from our official page and experience the difference for yourself.