Why Windows Store Apps Skip the Proxy: Fixing UWP Loopback Isolation

After you enable the Clash client's system proxy, browsers, terminal tools, and most desktop software route traffic through the proxy without any trouble. But Microsoft Store, the new Outlook, and some other Microsoft-native apps behave as if the proxy doesn't exist at all — connections fail, updates hang, sign-ins keep failing. If the system proxy is confirmed working for everything else, the problem is almost never your nodes or rules — it's Windows' platform-specific UWP loopback isolation mechanism.

Windows apps fall into two broad categories: traditional Win32 desktop programs (plain .exe files — most chat apps, browsers, and dev tools fall here), and modern apps built on the UWP (Universal Windows Platform) framework, which run inside an App Container. Microsoft Store, the built-in Mail and Calendar apps, the new Outlook, and some preinstalled camera and maps apps all run as UWP or similarly containerized apps.

System proxies — whether it's the HTTP/HTTPS system proxy configured by the Clash client, or TUN mode intercepting all traffic globally — apply to Win32 programs almost indiscriminately: as long as traffic goes through the system network stack, the proxy can intercept and forward it. But UWP apps run inside a restricted App Container, and for security isolation, they're blocked by default from accessing the local loopback address (127.0.0.1 and ::1). The Clash client's proxy listening port (mixed port defaults to 7890, or whatever the client UI shows) sits exactly on that loopback address — which is the root of the problem: the proxy isn't broken, these apps are simply blocked by the system from connecting to the local proxy port.

Common symptoms

• Microsoft Store can't search, downloads stall at 0%, or app updates spin indefinitely.
• The new Outlook (built on the One Outlook tech stack) still can't connect an account, or shows a network error at sign-in, even with a proxy configured.
• Some Xbox-related apps and built-in weather/news apps completely fail to refresh content once the proxy is on.
• Third-party apps distributed through Microsoft Store and packaged as MSIX/AppX can hit the same restriction.

Windows ships with a command-line tool, CheckNetIsolation.exe, specifically for managing App Container network isolation rules — including the loopback access allowlist. This method doesn't rely on any client feature, works reliably, and is the most basic and universal fix.

1. Open Command Prompt as administrator

   Search "Command Prompt" or "cmd" in the Start menu, right-click, and choose "Run as administrator." Changing loopback isolation rules requires admin rights — running it without will simply fail.

2. Check the current exemption list (optional)

   Run the following command first to see which apps are already exempted, so you don't add duplicates:

   CheckNetIsolation LoopbackExempt -sCopy

3. Add a loopback exemption for the target app

   For Microsoft Store, the Package Family Name is Microsoft.WindowsStore_8wekyb3d8bbwe. Run:

   CheckNetIsolation LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"Copy

   No error output means it succeeded. To exempt the new Outlook or another UWP app, look up its full package name with Get-AppxPackage first, then replace the value after -n=.

4. Find the package name for other apps

   Open PowerShell (again, as administrator) and run the following to list installed UWP apps and their package family names:

   Get-AppxPackage | Select Name, PackageFamilyNameCopy

   Find the target app's PackageFamilyName value in the output and paste it directly into the command from the previous step.

5. Restart the app to verify

   Fully close the target app (not just minimize it) and reopen it to confirm the proxy is now working. Loopback exemption changes usually take effect immediately — no system restart needed.

To revoke an app's exemption later, just swap -a (add) for -d (delete):

Manually finding package names and typing commands is a high bar for users who aren't comfortable with the command line, so many Clash clients on Windows bundle a graphical loopback exemption tool. It's essentially a wrapper around CheckNetIsolation, but skips the package-name lookup step.

• Look in the client's "System Settings" or "Network Settings" section for something labeled "UWP Loopback Exemption," "LoopbackExempt," or "Network Isolation Exception."
• Opening it usually auto-lists installed UWP/MSIX apps on the system — check the target app (Microsoft Store, the new Outlook, etc.) and apply. The tool assembles the full package name and calls the system command internally.
• Some clients offer a "one-click exempt common apps" button that pre-lists frequently affected apps like Store, Xbox, and Mail — handy if you don't want to check each one manually.

Why the built-in tool is sometimes less reliable than the command line

The GUI wrapper is convenient, but has two limitations: first, the app list depends on the client's own detection logic, so freshly installed apps or apps packaged in unusual ways may not show up; second, maintenance of this feature varies by client version, and some builds haven't kept the list updated with the latest system app naming. If the target app isn't in the list, or clicking exempt still doesn't work, falling back to the command line and manually finding the package name is the more reliable option.

It's worth distinguishing between system proxy mode and TUN mode here. System proxy mode writes an HTTP/HTTPS proxy address into the system network settings, and apps must actively read that setting and connect to the local loopback port — that connection attempt is exactly what loopback isolation blocks. So UWP apps are more likely to be affected in system proxy mode.

TUN mode, on the other hand, creates a virtual network adapter at the system level and intercepts all outbound traffic at the network layer (including traffic from inside a UWP app container), without relying on the app actively connecting to a local proxy port. In theory, this bypasses loopback isolation entirely. If you keep running into UWP proxy issues and your client supports TUN mode, try switching to it to see if the problem disappears. TUN mode does require extra virtual adapter driver permissions and has a slightly higher setup bar than system proxy mode — check your client's documentation on enabling TUN mode before troubleshooting further.

If you're seeing "some apps skip the proxy, most work fine," follow this order to avoid wasting time on the wrong leads:

1. Confirm the affected app type

   Check whether the misbehaving app comes from Microsoft Store or is packaged as UWP/MSIX. Ordinary .exe desktop programs are basically unaffected by loopback isolation, so don't chase this lead for them.

2. Verify exemption status via the command line

   Run CheckNetIsolation LoopbackExempt -s to view the current exemption list and confirm whether the target app is already on it — this avoids redundant actions or misdiagnosing the cause.

3. Fully restart the app after adding the exemption

   After changing loopback exemption rules, you must fully close and reopen the target app for it to take effect — just switching it to the background and back won't trigger a reload.

4. Still not working? Try TUN mode

   If you've confirmed the exemption was added and fully restarted the app, and the issue persists, switch to TUN mode as a test — this helps distinguish a leftover loopback isolation issue from an unrelated network configuration problem.

Loopback isolation is a security design at the Windows system level, with no direct connection to the kernel or subscription rules used by the Clash client — switching nodes or re-importing a subscription won't fix it if the affected app's loopback restriction hasn't been lifted. Once you understand this, the next time you see "only Store apps / the new Outlook won't use the proxy," you can go straight to UWP loopback isolation instead of repeatedly digging through rule configs.