Fix UWP and Microsoft Store Proxy Issues With Clash: Loopback and TUN Guide

How the problem shows up in real sessions

On desktop, most of your workflow uses Win32 apps: they honor the machine-wide proxy or the user-level WinINET string that Clash flips on when you click “Set system proxy.” Chrome, Edge, Visual Studio, and the terminal (after you export variables) can all see 127.0.0.1:7890 or whatever mixed port you configured. Universal Windows apps sit behind a stricter model: they are packaged, sandboxed, and subject to network capabilities declared in a manifest. One consequence that matters for proxy users is loopback restriction. Unless a package is allowed to use loopback, any attempt to open a socket to a loopback address can fail, even if the system proxy is technically set.

People describe the result in several ways, all of which can coexist on the same machine. The Microsoft Store never finishes downloads, or it loads blank pages in its embedded web stack while a browser is fine. A third-party UWP from the Store authenticates in the web but the native shell cannot refresh tokens. Some apps appear to ignore the proxy entirely and only work on expensive cellular tethering, which happens to bypass your split tunnel, or they suddenly work in Clash TUN mode but never in port-based system proxy mode. None of that proves your node is bad. It is often a Windows networking policy interacting with a localhost listener.

Separately, a few Store components talk to Windows Update and delivery-optimization services that use their own heuristics. This article is about the Clash side: getting traffic into your core so the ruleset can decide what goes DIRECT and what goes to your overseas group. If you want the baseline of installing a client, importing a subscription, and choosing between System Proxy and TUN, read the Clash for Windows setup walkthrough first, then return here for UWP-specific steps.

Why loopback blocks localhost proxies for UWP

Back when Microsoft pushed Universal apps, the platform goal was to keep untrusted app code from poking at services that might run on the same user session but outside the app container. A blanket ban on loopback traffic reduced cross-app probing. The trade-off is that legitimate scenarios also need to reach 127.0.0.1: a local HTTP proxy or a MITM debug tool, for example. Rather than re-open the sandboxes globally, Windows exposes a narrow escape hatch: you add an exemption for a package family name (PFN) so that that specific UWP may use loopback. That is exactly what the CheckNetIsolation tool manipulates; it is part of a larger networking isolation test stack that administrators and developers already reach for when debugging Store software.

Your Clash process binds a listener to localhost for mixed HTTP/SOCKS because that design keeps the footprint obvious and easy to turn off. When an exempted UWP can reach that port, the traffic becomes ordinary TCP from the app’s point of view, then Clash applies rules and forwards. Without exemption, the connection never reaches Clash at all, so your fancy Clash rules and domain-based policy groups never get a chance to run. The UI still shows a green “System Proxy” because Win32 components updated successfully; the failure is one layer up in the UWP process.

• Not a node problem when: Win32 clients share the same node and the issue is strictly Store apps or specific UWPs.
• Still not loopback when: the app uses rare networking APIs; then you will see failures even after exemption, and TUN is the better bet.
• Check proxy reset: if everything breaks after quitting Clash, walk through restoring the Windows proxy settings before you keep tuning UWP.

Find the right package family name (PFN)

Every exemption is keyed to a package family name string, not a friendly app title. You can look it up with Windows PowerShell or by inspecting appx manifests, but the fastest interactive path is PowerShell. Open it as a normal user (admin rights are not required to read metadata) and run a filtered version of Get-AppxPackage against the name you see in the Start menu, then copy the PackageFamilyName field exactly, character for character, including the publisher hash after the underscore.

For the official Microsoft Store client itself, the family name is widely documented; on stock builds you will typically see Microsoft.WindowsStore_8wekyb3d8bbwe. You should still verify on your system because side-loaded or enterprise repackaged line-of-business apps use different strings. The same process applies to Windows inbox apps that ship as UWPs, or Store games, each with their own package identity.

# Replace the wildcard with part of the app or publisher name
Get-AppxPackage *Store* | Select-Object Name, PackageFamilyName, InstallLocation
Get-AppxPackage *Zune*  | Select-Object Name, PackageFamilyName

When multiple rows appear, use the Name column to pick the one that matches what you start from the Start menu, then work only with that row’s PackageFamilyName. Typos in the PFN are the most common reason people believe CheckNetIsolation “does nothing.”

Grant loopback with CheckNetIsolation

CheckNetIsolation ships with Windows and lives under the System32 folder. It exposes several subcommands; the one you need is LoopbackExempt with the -a (add) flag and a -n value equal to the PFN. Run the console as an account that is allowed to change network isolation settings—normally Administrator for global machine policy, though many single-user home PCs meet that bar without extra fuss. If User Account Control blocks you, re-launch the shell elevated.

The sequence is straightforward: add an exemption, restart the Store or UWP app, then watch whether it can now reach the proxy listener in Clash’s log panel. Clash for Windows and forks usually show a live connection list with a process or source when available; a sudden burst of new flows right after the app retry is a good sign. If you need to back out, the tool supports deletion with -d for the same PFN string.

CheckNetIsolation.exe LoopbackExempt -a -n=Microsoft.WindowsStore_8wekyb3d8bbwe
REM Replace the PFN with your Get-AppxPackage result for other apps.
CheckNetIsolation.exe LoopbackExempt -a -n=YourApp_friendlypfnfrompowershell

To review which exemptions already exist, run CheckNetIsolation.exe /? in an elevated session and use the LoopbackExempt subcommand your build documents for listing; Microsoft has adjusted switches across feature updates, so avoid memorizing a single letter. Storing a small text file in your own notes with the exact -a -n= commands you used makes rollback easier, especially if you manage several Store games and productivity UWPs the same way.

After you add exemptions, re-open the Microsoft Store completely—sometimes a residual WebView session caches failure—and trigger a download. If the client still resists, confirm Clash is listening on the same interface your policy describes (127.0.0.1 versus a LAN IP for Clash allow-lan scenarios). A mismatch there looks similar to a missing exemption even though the root cause is different.

When TUN is simpler than loopback

TUN mode installs a virtual network adapter and routes eligible IP traffic through the Clash or Mihomo core before it leaves the machine. UWP and Win32 no longer have to honor a localhost proxy as a first hop; the kernel has already steered the packet. That is why people say “TUN fixed my Store” even without touching CheckNetIsolation: the isolation rule that blocked loopback simply stops mattering for those flows, because the capture point is not 127.0.0.1 inside the app’s sandbox. You still need Core support for the adapter on your SKU, a compatible driver package (Wintun is common in modern Clash clients), and usually elevation at install or first start.

Practical workflow: if you are already comfortable with TUN for games, enable it for Rule mode, confirm DNS behavior matches your profile (fake-ip versus redir host), and retest the Store before you invest time in per-PFN exemptions. Many users run TUN all day; others keep TUN for stubborn apps only, because a kernel filter can interact with other VPN software or certain enterprise security agents. The trade-offs mirror what we already discussed for Splitting Steam and Epic with process rules in TUN: the interception layer is powerful, so know what else runs network filters on the same Windows image.

Inside Clash Meta or Mihomo, TUN is usually a YAML stanza plus a user-space toggle. Turn on the adapter, watch for an IP on the TUN interface, and verify the tray menu shows Rule or Global as you expect. If you get “connected in the client but not in the Store” in TUN, pivot to DNS, fake-ip, and leak troubleshooting because you have likely left the UWP world and re-entered classic resolver problems.

System proxy, PAC, and what UWP actually reads

Not every UWP uses the same code path. Some apps embed a Chromium-based WebView and inherit pieces of the system proxy configuration; others go straight to OS networking APIs. That is why a blanket statement like “UWP always ignores the system proxy” is imprecise. A more useful mental model: if a particular app must use a 127.0.0.1 listener and if the sandbox blocks loopback, the pair fails. If the app dials a remote proxy host on your LAN (for example, when you set LAN mixed port with allow-lan and point another device at the PC’s address), the loopback ban does not apply the same way because the target is not loopback. Some lab setups intentionally avoid localhost for that reason, at the cost of firewall rules.

PAC files and automatic configuration add another wrinkle. Clash can publish a local PAC to steer domains; browsers pick it up quickly, while a minority of UWPs do not. When you are debugging, keep one axis constant: either pure manual proxy, or pure TUN, or pure exemption plus manual proxy—never all three in flux on the same afternoon.

More than the Store: related packages and Store games

The Microsoft Store is only one UWP. Download pipelines sometimes involve App Installer (Microsoft.DesktopAppInstaller_…), Delivery Optimization background traffic, and per-title executables for Store-distributed games, each with its own package family name. When a game launcher opens but the patcher never moves past zero percent, open PowerShell, search Get-AppxPackage *PublisherOrGameName*, and add loopback for the PFN that actually makes the network call you see in Clash logs, not the splash screen you guess from the icon. One title may register multiple packages for DLC and networking helpers; a single wrong exemption is harmless, but a missing one leaves you chasing DNS again.

Side-loaded or Developer Mode apps that you install with Add-AppxPackage also receive PFNs. The procedure is the same, though enterprise builds sometimes re-sign with an internal certificate and a hash you do not recognize at first glance. In those environments, Clash TUN is often the policy teams prefer, because it avoids maintaining a per-app exemption spreadsheet across hundreds of line-of-business UWPs, at the cost of a standardized driver-approval process on locked-down estates.

TUN setup details that matter on Windows 10 and 11

After you turn on TUN, traffic follows the route table the core manages. A healthy setup shows a Wintun-style adapter with a small RFC 1918 private address, Clash logging inbound connections, and Rule mode matching the hostnames you expect. If the adapter is missing, install or repair the driver that ships with your GUI, then restart the service. Windows 11 24H2 and later builds can be pickier about co-installed VPN clients; the symptom is a yellow warning in the tray or a silent failure to elevate. Uninstall the competing virtual NIC temporarily, or adjust its “split tunnel” so only one product owns default routes—otherwise the Store can flap between adapters.

IPv6 and QUIC introduce noise. If your ruleset is IPv4-first but the Store negotiates an IPv6 path, you might see success in the browser and stall in a helper process. A pragmatic fix inside Clash is to align the stack: enable IPv6 handling in the core if your node supports it, or disable IPv6 on the Windows NIC as a test (revert when done). Fake-ip and Microsoft domains together deserve attention here; when in doubt, follow the fake-ip troubleshooting guide before you declare loopback the culprit.

When the issue is not loopback (sanity tests)

Not every Store failure is sandbox-related. A corrupted cache, a Microsoft account sign-in hiccup, or regional Store policy can look like networking. Before you add exemptions, try the same update on a clean Wi-Fi without Clash at all; if it still fails, the root cause is upstream of proxies. If it only fails with Clash on, compare system proxy and TUN in two separate sessions, reboot between tests, and note whether the failure happens at TLS handshake, DNS resolution, or after the first megabyte. Handshake failures often point to Sniffer or custom CA interference; stalled mid-download points to throttling, CDN geo, or a dead rule group, not to loopback.

Terminal and Git flows are covered in the Clash terminal proxy article; those patterns assume Win32, so they are not substitutes for the UWP stack but help you verify that the node and subscription are not the problem first.

Compare approaches for Microsoft Store and UWP

How to verify the fix in Clash

After either path, confirmation should be empirical. In Clash for Windows, open the Connections or Log view and filter for the Microsoft Store’s background traffic—often over HTTPS to Microsoft’s CDNs. You should see policy matches instead of empty panels when the Store refreshes. If the log stays silent, traffic is not reaching the core, which points back to loopback, driver state, or a DNS failure upstream.

On the Windows side, Get-NetAdapter in PowerShell will show whether your TUN interface is “Up,” and ipconfig /all still helps when a virtual switch configuration collides with your expectations. If you are mixing multiple tunnel products, remove older adapters temporarily and retry with only Clash installed—generic advice, but it saves hours when one vendor’s filter sits above another’s.

FAQ

I exempted the Store PFN but it still will not update

Double-check the PFN after a major Windows feature upgrade, because some upgrades reinstall inbox apps. Then verify Clash is actually on Rule or Global and that a domain rule is not sending Microsoft CDN hostnames to a dead policy group. Finally, test TUN: if TUN works instantly, the remaining issue is almost certainly the localhost path, not the node.

TUN is worse for latency on the same machine

Small overhead is possible, but for Store traffic you usually care about reachability, not a fraction of a millisecond. If latency-sensitive games suffer, you can use process-first routing (see the Steam and Epic TUN article) to keep those executables on DIRECT while the Store still rides TUN, provided your Clash core and rules support it.

Is loopback exemption allowed?

You are using documented Windows tooling to adjust isolation on a machine you administer. It does not “hack” the Store; it restores a class of traffic that the sandbox was blocking. Follow your organization’s policy if the PC is not yours, because MDM can restrict both TUN and developer tools.

Checklist you can run in order

Use a client you can reason about

Whether you lean on CheckNetIsolation or TUN, the winning habit is the same: keep your Clash profile, adapter state, and Windows proxy switch obvious at a glance. The Microsoft Store is a high-churn, CDN-heavy client; give it a clean path to your core first, then fine-tune rule order for Microsoft domains if your provider’s bundle already tags them. When both paths are in place, UWP ceases to be the “mystery app that only works on mobile data” and returns to being just another set of connections you can read in the log.

Download Clash for free and get Windows Store traffic under control