Fix UWP Apps Ignoring Clash on Windows 11: Loopback Exemption Steps

How this fits next to other Windows 11 Clash guides on this site

If you have not walked through baseline install vocabulary yet, start with Clash Verge Rev on Windows 11: first install — system proxy vs TUN. That article explains why system proxy and TUN feel different on Win32 and already names UWP as a gray zone. Here we go deeper on the Windows-specific mechanism: network loopback isolation for packaged apps, which is orthogonal to “did I pick Singapore or Los Angeles in the selector?”

If your goal is sharing the PC’s Clash listener to a phone on the same Wi-Fi, that is a different firewall and bind-address story—read Windows 11: enable LAN proxy and firewall rules for Clash after you finish loopback troubleshooting, or you will chase two unrelated problems in parallel.

For the policy engine itself—rule order, fake-ip, GEOIP catches—keep the Clash tutorial open while you read logs; loopback fixes connectivity to your local proxy port, but it does not magically rewrite a profile that sends microsoft.com down an unintended path.

Why some UWP and Microsoft Store apps ignore “the system proxy that works in Edge”

On Windows 11, “system proxy” generally means the WinHTTP/WinINET settings your GUI client toggles when you click System Proxy. Classic desktop executables and many Chromium-based browsers consult those settings and can forward traffic to 127.0.0.1:PORT where Clash listens. Packaged UWP apps, including many experiences distributed through the Microsoft Store, run inside an app container model that historically blocked outbound connections to local loopback interfaces for security reasons—malware in one app should not probe another app’s localhost service. The net effect for proxy users is blunt: the app may ignore your proxy settings and be unable to reach a loopback-bound proxy even if it tried, until you explicitly exempt it.

Separately, some apps simply do not honor per-user proxy tables the way Win32 Chrome does; they implement custom stacks or rely on WebView2 with their own networking. That is why “flip TUN on” appears so often in forum threads: transparent capture bypasses the narrow “call WinINET for every socket” assumption. TUN is not always desirable—corporate VPNs, other tunnel products, and driver conflicts matter—so understanding loopback exemption gives you a precise tool when the only symptom is packaged apps versus browsers.

Symptoms that point to loopback isolation rather than a dead node

Before you touch exemptions, sanity-check the failure shape. Loopback isolation typically produces a narrow contrast: Edge or Chrome reaches foreign sites through Clash, latency tests in your client look fine, DNS inside the client is not empty, yet Microsoft Store pages spin, Xbox sign-in fails, or a first-party UWP client claims there is no connection. Command-line tools you launch from a classic shell may also work while Store apps fail, because they are not subject to the same container restrictions.

If everything is broken—including browsers—the first chapter is still “is the core running, is the system proxy toggle actually on, is the port correct,” not loopback. If foreign sites work in the browser but specific domains fail everywhere, suspect split routing rules, stale rule providers, or Secure DNS in the browser rather than packaged-app isolation. Use your client’s log view to see whether blocked Store traffic ever generates a matching line; silence can mean the app never reached the proxy listener at all.

Step 1 — Confirm Clash’s listener, system proxy alignment, and ports

Open your GUI, verify the mixed or HTTP port from the settings page, and compare it with Windows proxy settings under Settings → Network & internet → Proxy. Manual proxy entries must match the host and port your core actually binds—many templates still mention 7890 while your active build uses 7897 or another value. A wrong port looks like universal failure, not UWP-only failure, but users often notice Store apps first because they test the Store after browsing.

Ensure your client’s system proxy integration is enabled after reboots; some security products revert proxy changes when they detect “unauthorized” modifications. If policy-managed machines block user-level proxy writes, exemptions will not help until the enterprise allows the configuration path you need.

Step 2 — Decide whether you prefer TUN or loopback exemption

TUN transparent mode routes packets through the virtual adapter and often “just works” for stubborn binaries, including packaged apps that were never written to honor WinINET. It is a legitimate first-line fix when you accept driver-level capture and have no conflicting VPN. For the trade-offs—DNS coupling, fake-ip interactions, coexistence with other tunnels—read Clash TUN mode explained instead of enabling TUN purely as superstition.

Loopback exemption is narrower: it leaves global capture off but tells Windows that a specific packaged app may connect to loopback destinations, which includes your local Clash listener. That can be attractive when you want minimal surface area or when another product already owns the default-route slot. You can combine approaches during debugging—enable TUN temporarily to confirm the rest of your profile is healthy, then fall back to system proxy plus exemptions if that architecture fits your threat model.

Step 3 — Find the package family name you must exempt

Exemptions are keyed by package family name (PFN), not by the pretty title in the Start menu. On a standard desktop build, open PowerShell as your interactive user and list candidates with a substring filter. Examples vary by SKU, but the pattern is stable:

Get-AppxPackage *Microsoft.WindowsStore* | Select-Object Name, PackageFamilyName
Get-AppxPackage *Xbox* | Select-Object Name, PackageFamilyName

Copy the PackageFamilyName exactly—case, underscores, and publisher hash suffix included. If you sideloaded an app from your own pipeline, the PFN still appears in Get-AppxPackage output for that install. When multiple packages share a similar display name, prefer the PFN tied to the failing binary you can correlate via Task Manager → Details and the App history or startup entries, or temporarily uninstall duplicates to reduce ambiguity.

For unpackaged Win32 apps, CheckNetIsolation loopback commands are not the right lever; those binaries should already be able to reach 127.0.0.1 unless a separate firewall rule blocks them. Keep the problem statement focused on Microsoft Store / UWP / packaged desktop bridges such as certain WebView2 hosts where the runtime is still app-container mediated in your configuration.

Step 4 — Grant loopback exemption with CheckNetIsolation

CheckNetIsolation.exe ships with Windows and exists for exactly this class of networking policy work. Run commands from an elevated console when the tool requires administrator rights on your build; on many systems, registering an exemption for another user’s packages is unnecessary if you only manage your own profile, but elevation avoids “access denied” surprises on stricter images.

To add an exemption for one PFN, use the LoopbackExempt verb with -a (add) and -n= (name). Replace the placeholder with your copied PFN:

CheckNetIsolation.exe LoopbackExempt -a -n=Microsoft.WindowsStore_8wekyb3d8bbwe

The sample suffix 8wekyb3d8bbwe is not guaranteed to match your machine; always paste the PFN PowerShell printed for your install. After adding, restart the affected app completely—suspend/resume is not enough for some hosts—and retest Store catalog pages or app sign-in flows.

To list current exemptions for troubleshooting:

CheckNetIsolation.exe LoopbackExempt -c

To remove a mistaken entry, replace -a with -d (delete) while keeping the same -n=PFN argument. Document what you added; loopback exemptions are easy to forget six months later when auditing a laptop.

Some third-party “loopback managers” are thin GUIs over the same APIs. They can save time if you trust the vendor, but the built-in executable keeps the workflow transparent and scriptable for power users maintaining multiple PCs.

Step 5 — Re-verify split routing and DNS after connectivity returns

Once the packaged app can reach Clash, your normal policy story resumes. Microsoft properties fan out across many hostnames and CDNs; a minimal profile might still send some Microsoft endpoints DIRECT because of a catch-all rule or outdated GEOIP assumptions. Open the log pane, reproduce the Store action, and confirm which rule matched each hostname. If you expected a proxy hop but saw DIRECT, adjust ordering—narrow DOMAIN / DOMAIN-SUFFIX lines ahead of broad GEOIP,CN or provider blocks—and reload providers on a schedule so stale lists do not masquerade as “Store broken again.”

DNS still matters: profiles that use fake-ip expect resolver behavior aligned with the profile docs. Browsers with Secure DNS can produce “browser-only” anomalies, but Store stacks have their own resolver paths. If you bounce between system proxy and TUN during experiments, re-check that DNS mode and TUN helper state still match your template after each reboot.

Enterprise, kiosk, and security baselines

Managed organizations sometimes deploy baseline policies that forbid loopback exemptions outright or reset them during compliance sweeps. If exemptions vanish overnight, investigate MDM or security suite scripts before blaming Clash updates. Conversely, indiscriminately exempting every packaged app defeats the isolation model—prefer the smallest PFN set that restores the workflows you need, and remove exemptions when you retire an app.

Document the business reason for each exemption; security reviewers respond better to “Store catalog access via corporate split routing” than to unexplained CheckNetIsolation history.

When nothing changes after an exemption

First, confirm the PFN belongs to the process that actually owns the network failure—some “Store” experiences are hybrid hosts that spawn differently on Windows 11 feature updates. Second, confirm you are not mixing HTTP and SOCKS ports: a loopback path to the wrong listener still fails. Third, search for parallel tools that strip proxy settings (other VPNs, “game booster” filters, or TLS inspection). Fourth, re-run the exemption command under the same user context that launches the app; fast-user switching and separate admin sessions trip people more often than we like to admit.

If TUN immediately fixes the symptom while system proxy plus exemption does not, you are likely looking at an app that never respected WinHTTP for its primary data path; keep TUN or accept per-app limitations per your threat model.

Closing: narrow Windows networking fixes, clearer Clash outcomes

UWP and Microsoft Store quirks on Windows 11 are frustrating because they look like proxy failures from ten years ago—yet the modern root cause is often loopback isolation, not mystic YAML. Pair CheckNetIsolation exemptions with honest port checks, deliberate TUN choices, and log-driven split routing reviews, and the classic “browser works, Store does not” shape collapses into a short checklist instead of random forum tweaks.

When you are ready to standardize on a maintained desktop build across platforms, use this site’s download page as the primary installer path—Download Clash for free and experience the difference.