Clash UWP Loopback Exemption: Fix Microsoft Store Apps That Won’t Use Your Proxy

First, check whether loopback restrictions are the cause

If your browser can open websites through Clash but a Microsoft Store app won’t sign in, load lists, or retrieve content, AppContainer network isolation may be the reason. A typical connection path looks like this: the app reads the system proxy settings and tries to connect to 127.0.0.1:7890, but Windows blocks it before it reaches Clash’s listening port. Changing nodes or routing rules usually won’t affect this step.

UWP apps typically run in an AppContainer and can’t access local loopback services by default. A loopback exemption lets a specified app container access services on your PC; it doesn’t configure a proxy, select a node, or change DNS settings. The app still needs to use a network path that goes through Clash.

Check these three things first

• The Clash core is running, and a regular browser can reach the target service through the same proxy.
• You’re using the system proxy or the app’s own local proxy settings—not just leaving the client window open.
• The problem affects a specific app. If no apps can connect, check your subscription, nodes, ports, and network connection first.

These commands are for PowerShell on Windows 10 and Windows 11. The examples use port 7890, but always use the port in your active configuration. Don’t replace a working client listening port just because a guide uses this number.

Check the system proxy and Clash listening port

In Windows 11, go to Settings → Network & internet → Proxy. In Windows 10, go to Settings → Network & Internet → Proxy. Check that the manual proxy or setup script matches the client’s current settings. For a manual proxy on this PC, the address is commonly 127.0.0.1; the port should match Clash’s HTTP or mixed port.

# Configuration snippet: shows the listening port field only, not a complete configuration
mixed-port: 7890
allow-lan: false
mode: rule

mixed-port accepts both HTTP and SOCKS proxy connections. Windows manual proxy settings use an HTTP proxy endpoint, so don’t enter a port that only accepts SOCKS connections. If your configuration uses separate port and socks-port values, use the former.

In PowerShell, check whether the port is listening, then make a request through the proxy explicitly to rule out system proxy settings:

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

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

• No listening entry: Check that the core is running, the configuration loaded successfully, and the port number is correct.
• The port is listening, but the request times out: Check the node, rules, and target service in the Clash logs before trying a loopback exemption.
• The request gets an HTTP response: This desktop process completed a proxy request. Even if the response is a redirect or access denied, distinguish network connectivity from application permissions.

This curl.exe command doesn’t test UWP apps; it only verifies the local proxy connection. netsh winhttp show proxy shows the WinHTTP proxy configuration and isn’t a substitute for checking the user’s system proxy settings. Don’t reset the machine-wide WinHTTP settings to fix a single UWP app.

Method 1: Use the client’s loopback exemption tool

Some Windows Clash clients include a tool for managing loopback access. Its menu may be called “UWP Loopback Exemption,” “Loopback,” or “UWP Loopback.” Availability and location vary by client and version; don’t assume every mihomo client has the same menu. If you can’t find it, use the system commands in the next section—there’s no need to install another proxy client.

1. Save your current configuration and note the name of the app that’s having problems.
2. Find the loopback management option in the client settings and launch the tool. If User Account Control appears, verify the program’s source before granting permission.
3. Find the target app in the list and select it. Grant access only to apps that actually need to reach the local proxy.
4. Click the tool’s Save or Apply Changes button. Selecting an app without saving usually won’t add it to the system exemption list.
5. Fully quit the target app, reopen it, and repeat the same sign-in or loading action.

If the target app isn’t listed, first confirm it’s installed for the current Windows user. Some apps consist of multiple packages or separate components, and the display name may not match the package that actually makes network requests. Query the package identity in PowerShell rather than selecting every item with a similar name.

Method 2: Add an exemption with CheckNetIsolation

1. Find the PackageFamilyName

Run this command in PowerShell under the currently signed-in user. The Microsoft Store package is shown as an example of how to look up an identity; a loopback exemption won’t necessarily fix every download or sign-in issue with this app.

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

A common package family name is Microsoft.WindowsStore_8wekyb3d8bbwe, but use the value reported on your PC. For other apps, list the packages installed for the current user, then narrow down the results by Name:

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

PackageFamilyName is not the same as PackageFullName. The latter usually includes version and architecture details, so don’t pass it to the -n parameter below. Don’t copy the app’s installation directory path either. If the query returns no results, check the package name, installation user, and app type first.

2. Add the exemption from an elevated terminal and verify it

Right-click Start and select “Terminal (Admin)” or “Windows PowerShell (Admin).” If possible, elevate under the same account that owns the target app. If you launch the terminal with another administrator’s credentials, make sure the app package you find belongs to the right user.

CheckNetIsolation.exe LoopbackExempt -s

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

CheckNetIsolation.exe LoopbackExempt -s

-s lists current exemptions; -a adds the specified app. Run the first query to record the current state and the second to verify the change. The output may show both the app name and SID—check the target entry rather than relying on whether the command returned an error.

After adding the exemption, fully close and reopen the target app. If needed, confirm in Task Manager that its process has exited. You usually don’t need to restart Windows. If the app has a persistent background process, closing its window alone may not establish a new connection.

3. Remove a single exemption

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

CheckNetIsolation.exe LoopbackExempt -s

Use -d to revoke access for a specific app. Don’t clear all exemptions while troubleshooting; other development tools or local services may depend on existing entries. If you get an access denied error, make sure the terminal is elevated. On a device managed by organizational policy, ask your administrator to confirm what permissions are allowed.

Still not working? Troubleshoot each connection stage

Seeing the target app in the exemption list confirms that access was granted; it doesn’t prove the request went through the proxy. Open the connection log in Clash and retry the action. Change one thing at a time so you can pinpoint the cause—don’t switch nodes, enable TUN, and change DNS all at once.

The app doesn’t use the system proxy

A loopback exemption won’t force an app to read Windows proxy settings. If the app uses its own network stack, connects directly to remote servers, or sends requests through a system service, granting access to the foreground app may not affect the actual connection. A Store page that opens while downloads fail may also indicate that downloading uses a different service path.

The rule matched, but the egress isn’t what you need

If the connection appears in Clash, check which rule matched under mode: rule and which proxy group was ultimately selected. The server may return an error based on your egress region, account status, or request frequency; adding a loopback exemption won’t fix that. A successful node latency test also doesn’t guarantee that the target service will work.

Firewall, organizational policy, and network capabilities

Local firewall rules, endpoint security policies, or network capabilities declared by the app can still block connections. A loopback exemption doesn’t override every network restriction. Keep the specific error code, timestamp, and relevant logs, then check the policy for the individual process. Don’t turn off the entire firewall as a permanent fix.

When to use TUN and when to stick with the system proxy

If an app explicitly ignores the system proxy and you need Clash to handle its IP traffic, consider mihomo’s TUN mode. TUN routes traffic through a virtual network interface instead of relying on each app to connect to an HTTP proxy port. Its coverage still depends on routes, exclusion rules, DNS settings, and system permissions.

• Only a few AppContainer apps need access to the local proxy: Start with the system proxy and grant loopback exemptions only where needed to limit the impact.
• The app connects directly and ignores proxy settings: After verifying the basic configuration, test TUN separately and check the actual connection log.
• The system proxy is still enabled with TUN: The app may continue connecting to the local proxy, so loopback restrictions may still apply. Don’t assume enabling TUN always makes an exemption unnecessary.
• The device uses a corporate VPN or another virtual network adapter: Check for route and DNS conflicts first. Don’t enable multiple traffic capture mechanisms and hope for the best.

allow-lan: true is not a substitute for a loopback exemption. This setting allows other devices to connect to the proxy listener; it doesn’t grant local AppContainers access to loopback. Expanding the listening scope just to fix a UWP app creates additional access-control work.

Verify and maintain the exemption

1. Keep the LoopbackExempt -s output from before and after the change, and confirm that only the intended app was added.
2. Reopen the target app and test sign-in, content loading, and downloads—not just the launch screen.
3. In the Clash connection log, check the target domain, matched rule, and selected policy to confirm that traffic follows the expected path.
4. Undo any temporary global mode, DNS, or other unrelated changes made during troubleshooting, then test again.

Routine app updates usually don’t change the package family name, so you shouldn’t need to grant access again after every upgrade. If the app is uninstalled and reinstalled, installed from another source, moved to a different Windows account, or the system is rebuilt, look up the package identity and exemption list again.

Pinpoint the failing stage: Is the local port listening? Can the app access loopback? Does the request reach the core? Which policy handles it? What does the target service return? Working through these steps in order helps separate AppContainer permission issues from subscription, node, DNS, and service problems.