Microsoft Store Apps Not Using Your Proxy? Fix UWP Loopback Restrictions with CheckNetIsolation

First, check whether only sandboxed apps are affected

If your browser works but Microsoft Store or a UWP app says it’s offline, the proxy node may not be the problem. When the Windows system proxy points to 127.0.0.1:7890 and the app runs in an AppContainer, check whether it’s blocked from connecting to the local loopback address. The request may never reach the Clash core, so changing proxy rules or repeatedly updating subscriptions usually won’t help.

This guide covers troubleshooting local HTTP proxies and mixed ports on Windows 10 and Windows 11. 7890 is only an example; use the port shown in your client’s settings. Clash for Mac is the site’s brand, but run the commands below in Windows—not in a macOS terminal.

Both your browser and the affected app fail: First check that your subscription loaded, the proxy group is set to a working node, and the local port is listening.
Your browser works, but a specific UWP app fails: A loopback restriction is worth checking, but rule out an issue with the app’s own services too.
The client logs a request from the app: The request has reached the client. Check the matching rule, outbound connection, and any connection errors.
Only part of a download or sign-in fails: The issue may involve a background service, another package, or a different network stack. Don’t assume it’s caused by one app’s loopback permissions.

Why AppContainer apps can’t reach a local proxy

A typical system-proxy request works like this: the app reads the system proxy settings and sends an HTTP request or an HTTPS CONNECT request to a local proxy port. The core then routes it directly or through a proxy node according to its rules. 127.0.0.1 is the IPv4 loopback address for this Windows machine, not a remote node.

AppContainer provides an isolated environment for apps. By default, network isolation policies generally prevent apps inside it from connecting directly to local loopback services. Even if the proxy process is listening and a regular desktop browser can connect, a sandboxed app may be blocked before it ever reaches the proxy.

What a loopback exemption changes

The LoopbackExempt subcommand of CheckNetIsolation.exe manages loopback exemptions. Adding a package removes this loopback restriction for its AppContainer. It won’t turn on the system proxy, import a subscription, select a proxy group, or grant the app any other network capabilities it needs.

Setting	What it does	Checks it doesn’t replace
System proxy	Provides a proxy address and port to apps that honor the setting	Whether the app reads the setting and the port is listening
Loopback exemption	Removes the loopback access restriction for a specific AppContainer	Proxy protocol, routing rules, and node availability
TUN mode	Routes matching IP traffic through a virtual network adapter	Routing, DNS, permissions, and other network filtering policies

Turning on “Allow LAN” usually won’t fix this. That setting mainly changes which interfaces the proxy listens on. Accepting connections from your LAN doesn’t grant AppContainer loopback access—and it can expose the port to more devices.

Check the proxy address and listening port first

Open your client settings and find the mixed port or HTTP proxy port. Note the actual value; don’t use a SOCKS-only port as the HTTP proxy port.
On Windows 11, go to Settings → Network & internet → Proxy → Manual proxy setup → Set up under “Use a proxy server.” On Windows 10, check the Manual proxy setup section on the Proxy page.
Check the address and port—for example, 127.0.0.1 and 7890. Also make sure “System Proxy” is enabled in the client.
Temporarily close other proxy apps so they don’t keep overwriting the system proxy. For initial troubleshooting, use just one traffic entry point.

Run these commands in PowerShell to check the local TCP port and make a request through the explicitly specified proxy:

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890

curl.exe --proxy http://127.0.0.1:7890 --head --max-time 20 https://www.microsoft.com/

TcpTestSucceeded : True only confirms that the TCP connection succeeded; it does not prove the proxy protocol, TLS, or remote node is working. The second command explicitly uses an HTTP proxy and waits up to 20 seconds. Change the port if your setup uses a different one. curl.exe avoids parameter differences caused by the similarly named Windows PowerShell alias.

These commands run in a regular desktop process and can’t confirm that a UWP app has loopback access. They’re useful for verifying the proxy endpoint first, so a typo in the port isn’t mistaken for an isolation issue.

Method 1: Use the loopback tool included with your client

Some Windows clients include a UWP loopback helper. In older versions of Clash for Windows, a common path was General → UWP Loopback → Launch Helper. This is specific to that client; it’s not a standard menu in every Clash or mihomo GUI client. You don’t need to switch to an outdated client just to use this tool.

Make sure the client’s local proxy port is working, then open the loopback helper.
If Windows shows a User Account Control prompt, verify the program’s source before granting permission. Changing loopback exemptions usually requires administrator privileges.
Find the app you’re troubleshooting in the list. Check its name and package details, and select only the apps that need to use the local proxy.
Click the tool’s Save or Apply button. Some tools label it Save Changes; follow the wording in the current interface.
Fully exit the app, then reopen it and repeat the action that failed. Closing its window may not stop background processes.

If the app isn’t listed, first make sure it’s installed for the current Windows user. Don’t select another package just because its name looks similar, and avoid granting exemptions to every app at once. If you don’t have a helper tool, use the system commands in the next section; you can still review and undo the changes.

Method 2: Add an exemption for a specific package with CheckNetIsolation

1. Find the PackageFamilyName

In the Windows user session where the app is installed, open PowerShell. First, find the package family name for Microsoft Store as an example:

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

A common Store package family name is Microsoft.WindowsStore_8wekyb3d8bbwe, but use the output from your own PC. The command needs the PackageFamilyName. Don’t use the PackageFullName, which includes details such as the version and architecture, or the product ID from the Store page.

If you don’t know the package’s internal name, list the packages for the current user and identify it from the output:

Get-AppxPackage |
    Sort-Object Name |
    Select-Object Name, PackageFamilyName

If nothing is returned, first check that you’re signed in as the same user who installed the app. Elevating from a different administrator account can also change the context used to query packages. Don’t use -AllUsers as a default workaround, especially on a shared PC.

2. Check the current list and add an exemption

Right-click Start and choose “Terminal (Admin)” or “Windows PowerShell (Admin).” Check the current list first, then add an exemption for the package you’ve identified:

CheckNetIsolation.exe LoopbackExempt -s

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

CheckNetIsolation.exe LoopbackExempt -s

-s: Shows the current loopback exemption list.
-a: Adds an exemption.
-n: Specifies the package family name. For another app, use the exact name returned by the package query.

Save or copy the list before adding an exemption so you can tell which entries were already there. The list may show both names and SIDs; check the entry for the target package instead of relying only on a success message. If you see “Access denied,” make sure the terminal is running as administrator rather than repeatedly trying different package names.

3. Restart the app and retry the request

Exit the app, and if needed, end its process in Task Manager before reopening it. Keep the same proxy group, network, and test action—for example, refresh the Store home page—so you can compare behavior before and after the exemption. A full PC restart usually isn’t needed. Avoid resetting the network and changing DNS at the same time, or it’ll be harder to tell what fixed the issue.

Still not working? Follow the request path

No new connection appears in the client

First make sure the exemption applies to the package that actually makes the network request, then check the system proxy address, port, and bypass list. Some apps don’t use the system proxy; others hand downloads off to a background service. An exemption for the foreground app may not change how that service connects.

Don’t treat netsh winhttp set proxy as a universal fix for Store apps. WinHTTP proxy settings are separate from the current user’s system proxy settings. Changing them may affect system services without affecting the app you’re troubleshooting.

The client shows a connection, but it uses the wrong outbound

Check the destination domain, matched rule, and actual outbound on the Connections page. A loopback exemption doesn’t change rule priority; if the request matches DIRECT, it’ll still connect directly. Only after confirming that the request reaches the client is it useful to briefly compare rule mode with global mode. Restore the original outbound mode when testing is done.

Behavior changes when TUN is enabled

TUN mode can capture traffic from some apps that don’t use the system proxy, but it doesn’t disable Windows network isolation. If the app is still configured to connect to a local proxy, loopback restrictions may still apply. Test “system proxy on, TUN off” separately from the TUN setup recommended by your client, and note the difference. Don’t turn on both options and assume that identifies the cause.

Undo the change: remove only the entry you added

If the app no longer needs local proxy access, clear its selection in the same helper tool and save, or run the removal command in an administrator terminal. The example below uses Microsoft Store:

CheckNetIsolation.exe LoopbackExempt -d -n="Microsoft.WindowsStore_8wekyb3d8bbwe"

CheckNetIsolation.exe LoopbackExempt -s

-d removes the specified entry. Restart the app afterward, then check the list and test its behavior. Remove only the entry you added; leave exemptions that were already set by developer tools or other apps. Don’t clear the entire list to undo a change for one app.

Loopback exemptions and the system proxy setting are independent. Turning off the client’s system proxy won’t remove exemptions, and removing an exemption won’t reset Windows proxy settings. If you’re stopping the client, also check Settings → Network & internet → Proxy to make sure Windows isn’t still pointing to a local port that’s no longer listening.

Frequently asked questions

Will an app use the proxy after I add a loopback exemption?

Not necessarily. The exemption only removes the loopback access restriction for that AppContainer. The app still needs to use the local proxy address, the client must be listening on the right port, and a working configuration must be loaded. Whether traffic goes direct or through a proxy also depends on the outbound mode and matching rules.

Do I need to add it again after changing subscriptions or nodes?

Usually not. The exemption is tied to the package identity, not a node, subscription URL, or local port. You generally won’t need to add it again after an app update if its package family name hasn’t changed. If behavior changes after reinstalling the app, check its package identity and the exemption list again.

Does localhost behave differently from 127.0.0.1?

localhost may resolve to either an IPv4 or IPv6 loopback address. If the proxy listens only on 127.0.0.1 but the connection tries ::1, it can fail. For troubleshooting, check the listener using the explicit IPv4 address first—but this won’t bypass AppContainer isolation.

Should I add an exemption for every app at once?

No. Adding exemptions one app at a time makes it easier to verify the cause and undo changes. Keep the original list, note the target package family name, and change only what’s needed for safer, more reliable troubleshooting.