Windows Store Apps Not Using Clash Proxy? Fix UWP Loopback Restrictions

Why Browsers Can Use the Proxy but Store Apps Can't

Many users run into this the same way: the desktop browser and traditional exe programs connect through the proxy without any trouble — latency tests pass, rules match correctly — but any app installed from the Microsoft Store, whether it's a chat client, a reader, or certain game clients, reports a network error across the board, as if the proxy simply isn't active. After double-checking the system proxy settings and confirming the Clash client is running fine, the problem turns out to be how the app itself runs.

The vast majority of Microsoft Store apps use the UWP (Universal Windows Platform) architecture, which runs on a completely different mechanism from traditional Win32 desktop programs. UWP apps run inside a sandbox called AppContainer, with far fewer permissions than traditional programs — network access has to be explicitly declared through system "Capabilities" rather than being granted by default like Win32 programs get full network access on the machine. This sandbox design is meant to improve security, but a side effect is that it blocks apps from connecting to the local loopback address (127.0.0.1 or localhost) by default.

This directly breaks how Clash works. The Clash client opens a listening port on the local machine (commonly port 7890 for the system proxy), and setting a system-wide proxy essentially tells every program to forward its network requests to the loopback address 127.0.0.1:7890. Win32 programs can naturally access the loopback address, so browsers and chat apps forward traffic without issue. Because of sandbox isolation, UWP apps are blocked from taking that same path — the request never even goes out. The app either throws a network error outright or falls back to a raw direct connection: if the direct connection itself is blocked, it looks like a total connection failure; if the direct connection works but the target service enforces regional restrictions, it looks like "content just won't load" with no obvious error.

Removing the Restriction with the Built-in CheckNetIsolation Tool

Microsoft provides an official fix for this: the command-line tool CheckNetIsolation, which ships with both Windows 10 and 11 — no extra install needed. It can grant a single UWP app a "loopback exemption" (LoopbackExempt), effectively telling the sandbox: this app is allowed to reach the local loopback address.

1. Press the Win key, search for "Command Prompt," and right-click to select "Run as administrator." Administrator privileges are required, or the command will fail silently.
2. Run the following command to list all currently installed UWP apps along with their package names, and locate the PackageFamilyName for the app that's having trouble:

   CheckNetIsolation LoopbackExempt -s

3. Once you've confirmed the package name, run the exemption command, replacing PackageName with the full string found in the previous step:

   CheckNetIsolation LoopbackExempt -a -n="PackageName"

4. No error message means it succeeded. There's no need to restart the system, but it's recommended to fully close and reopen the UWP app so the new network permission takes effect.

If you can't find the exact package name right away, you can run one command to grant the loopback exemption to every installed UWP app at once — useful for quickly confirming this is indeed the cause during troubleshooting:

CheckNetIsolation LoopbackExempt -a -p=*

Once the issue is confirmed fixed, it's a good idea to narrow the exemption back down to just the one app, using the commands below, rather than leaving it open for every Store app long-term:

CheckNetIsolation LoopbackExempt -c
CheckNetIsolation LoopbackExempt -a -n="TargetAppPackageName"

Built-in Client Fix: Bypass the System Proxy Layer with TUN Mode

The command-line approach works precisely for a single app, but if several Store apps are affected at once, manually exempting each one gets tedious. A more convenient option is switching the Clash client to TUN mode (labeled "virtual adapter mode" or "enhanced mode" in some clients).

TUN mode works on a completely different principle from the system proxy setting. A system proxy relies on each app forwarding requests to a local loopback port — which depends on the app being willing to cooperate with the system proxy setting in the first place. TUN mode instead creates a virtual network adapter on the system, and the client intercepts and takes over all outbound traffic at the network layer. As long as a program uses the standard TCP/IP stack — whether it's Win32 or UWP — it gets captured and forwarded by this virtual adapter, no longer relying on the loopback path at all, which naturally sidesteps the UWP sandbox's restriction on loopback access.

The exact steps vary slightly by client interface, but the general flow is the same:

• Open the client's settings page and find the "Network Mode" or "Connection Mode" option.
• Switch the mode from "System Proxy" to "TUN" or "Virtual Adapter."
• The first time you enable it, extra authorization is usually required: a virtual adapter driver gets installed once, and the client needs to run with administrator privileges, which triggers a one-time driver installation confirmation prompt.
• Once switched successfully, the system proxy setting can stay at its default — no manual configuration needed — and both Store apps and regular desktop programs will use the same forwarding path.

Which Method to Choose, and How to Debug Common Errors

If only one or two Store apps are affected and everything else works fine, use CheckNetIsolation for a precise exemption — it's a small, targeted change that doesn't touch other network settings. If Store apps are broadly affected, or you'd rather settle on a more reliable forwarding method long-term, switching to TUN mode once solves the problem for good, and any newly installed Store apps won't need individual fixes going forward.

If the connection still doesn't work after trying the above, check things in this order:

1. Confirm the Command Prompt was actually run as administrator. Without admin rights, CheckNetIsolation may report success while not actually taking effect — this is the step most people overlook.
2. Run the -s parameter again to review the exemption list and confirm the target package name really appears there, rather than a typo having exempted a package that doesn't exist.
3. Confirm the Clash client's listening port matches the port set in the system proxy settings — removing the loopback restriction only clears the access path; a misconfigured port still won't connect.
4. If switching to TUN mode still doesn't change anything, check whether the client reports a failed virtual adapter driver installation, and try restarting the client or the system before enabling it again.
5. Some Store apps have their own independent network settings (common in certain reading and download apps), and you'll need to disable an option like "Direct connection only" inside the app itself.

Confirming the Proxy Is Actually Working

After removing the restriction, don't just check whether the app can load content — that can easily give a false impression that things are working when the traffic is actually still going direct. Cross-checking with the following three methods is more reliable:

• Compare IP location: Open an IP lookup page in the browser to record the region shown with a direct connection, then trigger a network request inside the Store app (such as refreshing a region-restricted page), and compare whether the behavior matches what you'd expect from the proxy node's region.
• Client connection logs: Open the Clash client's logs or connection panel while operating the Store app, and watch for new connection entries appearing — you can see the exact domain and which proxy node handled it, which is the most direct evidence available.
• Switch nodes and retest: Switch the proxy to a node in a different region and repeat the same action. If the content behavior in the Store app changes accordingly, that confirms the traffic is genuinely going through the proxy rather than hitting a direct-connection cache.

Of the three, the client connection log is the most conclusive, since it doesn't rely on feedback from the Store app's own interface — it confirms directly at the traffic-forwarding layer whether the request was actually taken over. If the app's connections never show up in the log at all, the loopback restriction or TUN mode configuration hasn't actually taken effect, and it's worth going through the troubleshooting steps above again.