Windows Store Apps Not Using Your Proxy: UWP Loopback Exemption and CheckNetIsolation

First, identify the issue: loopback restriction or an app that isn't using the proxy

If your browser can access the internet through a Clash client but a Windows Store app keeps loading, that doesn't necessarily mean your subscription is broken. If the client listens for HTTP or mixed-proxy traffic on 127.0.0.1 and the app runs in a restricted AppContainer, the app may be unable to connect to that local proxy endpoint. In that case, a UWP loopback exemption is one setting worth checking.

However, Microsoft Store is a distribution channel, not an app runtime model. Traditional Win32 software, packaged desktop apps, and UWP apps from the Store don't all have the same network restrictions. A loopback exemption is relevant only when an AppContainer loopback restriction is involved; installing an app from the Store doesn't automatically mean it needs an exemption.

How UWP, AppContainer, and 127.0.0.1 work together

127.0.0.1 is the IPv4 loopback address; connections to it aren't sent to other devices on your local network. Clash GUI clients typically run the core locally and accept app requests through an HTTP, SOCKS, or mixed port. Windows system proxy settings can tell apps that honor them to send requests to this local endpoint.

AppContainer is Windows' app isolation mechanism. It restricts access to resources, including network access, based on an app's identity and capabilities. Even when a proxy service is running on the same computer, a restricted container may not be able to connect to it. The LoopbackExempt subcommand in CheckNetIsolation.exe manages these loopback exceptions.

How this differs from TUN mode

• System proxy route: The app reads the proxy settings, then connects to the local proxy port. A loopback restriction can block it at this step.
• TUN route: The client uses a virtual network interface and routing to capture matching IP traffic. Apps typically don't need to connect directly to an HTTP proxy port.
• Scope: TUN behavior also depends on routing, DNS, permissions, and app behavior. It's not another name for exempting every app from loopback restrictions.

For troubleshooting, start with one clearly defined traffic-capture method. For example, turn off TUN and test the system proxy and loopback access for a single app. Avoid changing proxy mode, DNS, rules, and exemptions all at once; even if connectivity returns, you won't know which change fixed it.

Before you start: check the proxy endpoint and establish a baseline

This guide uses 127.0.0.1:7890 as an example. Port 7890 is not standard across all clients; use the port shown in your current client settings and active configuration. In mihomo, mixed-port accepts both HTTP and SOCKS traffic. A standalone socks-port should not be entered as the Windows HTTP system proxy endpoint.

1. Check the HTTP or mixed port in the client settings, and make sure the core is running.
2. In Windows 11, go to Settings → Network & internet → Proxy → Manual proxy setup → Use a proxy server, then check the address and port. In Windows 10, find them under Settings → Network & internet → Proxy.
3. If the client manages these settings, change them using the client's controls to avoid conflicts between the Windows interface and the client.
4. Note the target app, the action that fails, and when it happened. This will help you find the corresponding entry in the connection list or logs.

In PowerShell, first check whether a TCP connection to the example port succeeds, then send an HTTPS request through the proxy explicitly:

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://www.microsoft.com/

TcpTestSucceeded : True only confirms that the port is reachable. The HTTP response can help determine whether the proxy connection was established. A remote response such as 403 doesn't mean the proxy port is broken. This example uses curl.exe to avoid argument differences caused by the curl alias in Windows PowerShell.

Both checks are initiated by a desktop process and don't prove that a UWP app has loopback access. If either baseline test fails, fix the listening port or upstream connection first instead of changing container permissions. Don't enable “Allow access to local network” or change the listening address to 0.0.0.0 for this purpose; widening the listening scope and adding a loopback exemption are separate things.

Command line: list, add, and remove loopback exemptions

1. Save the current list and find the exact package identity

Search for PowerShell in the Start menu and choose Run as administrator. If you elevate using credentials for a different administrator account, the package query may apply to that other user. First look up the package information in the account that owns the target app, then make the change in the elevated window.

CheckNetIsolation.exe LoopbackExempt -s

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

Use -s to list existing exemptions. Save the output or take a screenshot before adding one so you can tell whether the entry was already there. By default, Get-AppxPackage lists packages for the current user. Guessing a package name from its display name is error-prone; get the PackageFamilyName from the output instead.

For example, to look up the package identity for Microsoft Store itself, run:

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

A common result is the package family name Microsoft.WindowsStore_8wekyb3d8bbwe. This differs from PackageFullName, which includes details such as the version and architecture. Use the package family name with the -n parameter below. If the query returns nothing, first check that the app is installed for the current account. Don't construct the command by inserting the display name.

2. Add an exemption for the target app only

The example below applies to Microsoft Store itself; it doesn't also grant access to other apps downloaded from the Store. Run it as written only if your query returns the same package identity. For other apps, use the package family name returned for each one.

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

After running the command, check that the matching identity appears in the list and that no error was reported. If access is denied, make sure the terminal is elevated. If the name or parameters are rejected, check the package identity and use straight English quotation marks. Once the entry is added, fully close and reopen the target app so it doesn't reuse the failed connection.

3. Remove the exemption you just added

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

Use -d to remove an exemption for a specific app. Remove only an entry you added for this test. If it was already present, don't delete it just to troubleshoot. Don't run a script that exempts every package or clear the entire list instead of removing a specific entry; developer tools and other apps may rely on existing entries.

GUI method: select the target app in the loopback exemptions list

Windows Settings doesn't have a universal checkbox for UWP loopback exemptions. If Fiddler Classic is installed, open the loopback exemption tool from its WinConfig toolbar button. In some versions, you can also open it from Tools → Win8 Loopback Exemptions. Although the menu still says Win8, it manages the same Windows AppContainer loopback settings.

1. First check the proxy port as described above and note the current system proxy settings.
2. In Fiddler Classic, clear File → Capture Traffic so the packet-capture proxy doesn't take over the traffic you're testing.
3. Open WinConfig, approve the administrator prompt, and wait for the app container list to load.
4. Select only the app you're troubleshooting, then click Save Changes. Don't use Exempt All to grant access in bulk.
5. Close WinConfig and Fiddler Classic. Check again that the system proxy still points to the actual port used by the Clash client, then launch the target app and test it.

To remove an exemption, reopen WinConfig, clear the entry you added, and save. The GUI and command line manage the same type of system setting; cross-check the list with CheckNetIsolation.exe LoopbackExempt -s. If Fiddler Classic isn't installed, use the built-in Windows command instead. There's no need to set up a packet-capture environment just for this step.

How to verify: compare app requests, rule matches, and results after removal

Seeing an app in the exemption list confirms that the setting was saved, not that the feature you need will work. Test the same action that failed—for example, refresh the Store page or load online content in the app—and check the client's connection log at the same time.

1. Keep test conditions consistent: Use the same subscription, proxy group, and rule mode. Close packet-capture tools and note the test time.
2. Restart the target app: If needed, end its process in Task Manager before reopening it. Closing the window alone may leave background processes running.
3. Check connections: In the client's Connections or Logs view, check the target domain, destination address, matched rule, and outbound policy. The interface labels vary by client.
4. Check the actual outcome: Distinguish between a request reaching the proxy and a successful sign-in or download. Server-side regional restrictions, account status, and certificate errors need separate investigation.
5. Compare with the exemption removed if needed: Remove only the entry added for this test, repeat the same action, then restore it if appropriate.

Some connections are initiated by system services or helper processes, so filtering by process name alone may not work. An app may also display a cached page, making a single successful launch weak evidence. Comparing the time, destination domain, and matched rule is more reliable than checking only whether content appears in the window.

If the connection appears in mihomo but matches DIRECT, the loopback stage is usually no longer the point of failure. Check which rule matched first, whether the rule set is up to date, and whether the proxy group uses the intended policy. Rule mode doesn't mean all traffic goes through the proxy, and adding an exemption doesn't change that.

What to check if it still doesn't work

The app is exempt, but no connection appears in the client

First make sure the exemption is for the package that actually makes the network request, not a similarly named launcher. Then check whether the app follows the Windows system proxy, has its own proxy setting, and has been restarted. A loopback exemption can't create a proxy route for an app that doesn't use the system proxy. You can test TUN capture separately while keeping the original configuration intact.

The client sees the connection, but the app still fails

Check the matched policy and connection errors first, then distinguish DNS resolution failures, upstream timeouts, TLS errors, and HTTP error responses. App downloads may use multiple domains; a working home page doesn't mean content delivery uses the same policy. Adjust the actual failing connection instead of routing every domain through the same outbound policy.

The app fails again after an update or reinstall

Routine app updates usually don't change the package family name, but switching distribution channels, installing a preview build, or moving to another Windows account can change the package identity. Run the package query and -s again to check the current environment. On managed business devices, ask your administrator about policy restrictions; don't turn off the firewall as a substitute for a targeted exemption.

The full diagnostic chain is: local proxy works → the app uses that endpoint → any required loopback access is allowed → the connection matches the expected rule → the request succeeds. Check each step in order to distinguish Windows container restrictions from client settings and remote service issues.