Microsoft Store Apps Not Using a Proxy: 3 Ways to Fix the UWP Loopback Restriction

First, check whether it’s a UWP loopback restriction or a proxy issue

If your browser connects but Microsoft Store or another Store app keeps loading, a UWP loopback restriction is a common place to start troubleshooting. Clash’s system proxy typically points to a local address, such as 127.0.0.1:7890. Apps running in the isolated AppContainer environment can’t access local loopback services by default, unlike regular desktop programs, so they may be unable to connect to the proxy.

But “installed from the Store” doesn’t necessarily mean “subject to the same UWP restriction.” Microsoft Store also distributes traditional desktop programs, and packaged desktop apps may handle networking differently. The loopback exemption methods in this guide are primarily for apps restricted by AppContainer network isolation; not every failed Store download is caused by this issue.

Run these three basic checks first

1. Check the proxy port. In the client’s port settings, find the HTTP or mixed port. This guide uses 7890 as an example. If your actual port is 7897, use 7897 in the tests below too.
2. Check the Windows proxy address. In Windows 11, go to Settings → Network & internet → Proxy → Manual proxy setup → Edit, and confirm the address and port match the client. When using the client’s system proxy toggle, let the client manage these settings to avoid them repeatedly overwriting each other.
3. Make sure the proxy can reach the internet. Open the target service in a browser and check the request in Clash’s connections or logs panel. If the browser also fails, check your subscription, selected node, and routing rules first—don’t start by adding loopback exemptions in bulk.

In PowerShell, use these two commands to check the local port and an explicit HTTP proxy separately. The address in the second command tests an HTTP port or a mixed port that supports HTTP; it won’t work with a SOCKS-only port.

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/

Choosing a method: start with a loopback exemption for individual apps

The first two methods change Windows’ loopback exemption list: the graphical tool makes apps easy to select, while the command line lets you confirm package names and undo changes precisely. The third method uses TUN to capture network traffic without relying on apps connecting to a local HTTP proxy. It provides an alternative traffic path; it does not grant apps loopback access.

Try one of the first two methods to start. If the app still fails after adding an exemption, check whether it reads the system proxy, whether the target domain is routed directly, and whether TUN is needed. Change one thing at a time and keep logs from before and after each change.

Method 1: Use your client’s built-in UWP loopback tool

Some Windows clients include a loopback exemption tool, which may be labeled “UWP Loopback,” “UWP Loopback” or “Loopback Exemption.” Its location varies between clients and versions, so don’t assume every Clash client has the same menu. If you can’t find this option in Settings, use the built-in Windows commands in the next section.

1. Keep Clash running, make sure the system proxy is enabled, and note the current listening port.
2. Look for a UWP or Loopback option in the client’s settings and open the tool. If Windows asks for administrator permission, confirm the program’s source before allowing it.
3. Find the app you want to configure, such as Microsoft Store. If the list shows both display names and package IDs, verify the package ID instead of relying on a similar-looking icon.
4. Select only the apps that need to use the local proxy, then click the tool’s Save or Apply button. The button name depends on the tool.
5. Fully close the target app and reopen it. If it’s still running in the background, end its task in Task Manager before testing again.

Can’t find the app in the list?

First, make sure the app is installed for your current Windows account, not just another account. If it’s still missing after refreshing the list, use PowerShell to find its package name. Traditional Win32 apps may not be managed by this tool at all; selecting a package with a similar name won’t fix that.

Method 2: Add and remove exemptions precisely with CheckNetIsolation

Windows 10 and Windows 11 include CheckNetIsolation.exe, so there’s no need to install a separate loopback tool. Open Start, search for PowerShell, then right-click it and select Run as administrator. The commands below look up Microsoft Store installed for the current user; you don’t need to search packages for all users first.

Step 1: Find the PackageFamilyName

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

A common Microsoft Store package family name is Microsoft.WindowsStore_8wekyb3d8bbwe, but use the value returned by your PC. The command needs the PackageFamilyName, not the PackageFullName, which includes the version and processor architecture.

To find another app, list the packages installed for the current user, then filter by name. This command sorts the results to make the app easier to find:

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

Step 2: Check the current list and add the target package

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

-s displays existing exemptions, -a adds one, and -n specifies the package family name. Run the query again to confirm the target package appears in the list. A successful command only confirms that the permission was set; restart the app and verify its requests next.

Step 3: Use a variable for other apps to avoid mistyping package names

This example also uses Microsoft Store: save the query result first, then pass it to the command. For another app, confirm its exact Name in the list from the previous step before changing the filter. Don’t use the app’s display name as its package name.

$app = Get-AppxPackage -Name Microsoft.WindowsStore
if ($null -ne $app) {
    CheckNetIsolation.exe LoopbackExempt -a "-n=$($app.PackageFamilyName)"
} else {
    Write-Output "Microsoft Store package not found for the current user."
}

When removing an exemption, delete only the entry you added

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

-d removes the specified exemption. There’s no need to clear the entire list for a single troubleshooting session, which could affect other configured apps. If you get an access denied error, check that PowerShell is running as administrator. If a package can’t be found, check its installation status for the current user and its package family name again—don’t guess the identifier.

Method 3: Use TUN to capture traffic from apps that ignore the system proxy

If an app doesn’t read the Windows system proxy, adding a loopback exemption won’t automatically route its requests through Clash. In that case, consider a client and core with TUN support, such as a client based on mihomo. TUN uses a virtual network interface and routing to capture eligible IP traffic, so the app doesn’t have to connect directly to 127.0.0.1:7890.

1. Check the core and permissions. Confirm in the client’s core information that the active core supports TUN. If the client asks you to install service mode, follow its prompts and make sure the service is running. Some implementations require administrator privileges to start.
2. Set up a controlled test. Note the system proxy status, then temporarily turn off the system proxy and test with TUN enabled on its own. This makes it easier to tell which traffic path is working.
3. Enable routing and DNS capture. Check the client’s TUN settings for options related to auto-routing and DNS. Common fields in mihomo configuration include tun.enable, auto-route, and dns-hijack, but don’t assume every client will use a copied configuration snippet as-is.
4. Restart the target app and monitor its connections. Confirm the request appears in the client’s connection list, then check the matched rule, policy group, and actual exit.

TUN capture doesn’t mean all traffic goes through a proxy node. In Clash Rule mode, requests are still matched against rules: they may hit DIRECT or go through a proxy policy group. If Store-related domains are set to direct and the direct route on your network isn’t working, loading may still fail.

Still failing after adding an exemption? Use the logs to identify these four issues

1. No request appears at all

First, make sure the app is fully closed and restart it. Then check that the Windows system proxy still points to the client’s actual port. If the loopback list is correct and the browser’s explicit proxy test succeeds, but the app still generates no requests, it may not use the system proxy, or another component may be making the requests. Try TUN as a comparison instead of adding the same package again.

2. The request appears, but the rule matches DIRECT

This means the request has reached the core, so check your routing rules next. Inspect the target domain, rule type, and exit in the connection details. Microsoft Store sign-in, page content, and downloads may use different domains or system components; fixing one endpoint may not cover the entire download flow. Don’t assume background downloads use the same route just because the Store page opens.

3. The proxy connection times out or reports a DNS error

Check whether the selected node can reach the same destination, and look for domain resolution failures in the logs. With TUN, also confirm that DNS requests are being captured by the intended configuration. Internal corporate domains, DNS from other VPNs, and the client’s DNS settings may conflict. Test them one at a time; don’t change the resolver, node, and routing all at once.

4. The page opens, but the download is stuck

Downloads may involve system services or other processes. A loopback exemption for one app doesn’t mean every service on the PC uses the user’s proxy. Don’t change the global WinHTTP proxy or keep resetting the Store cache as a substitute for finding the network issue. First check whether new connections appear during the download and which process created them, then decide whether TUN or a rule change is needed.

Verify the result and roll back: keep the setup reproducible

• Test the app: Check startup, sign-in, content loading, and downloads separately. Getting one button to work doesn’t mean everything is fixed.
• Verify the proxy route: Check the rules and exit in the connection log. After testing, restore your usual Rule mode from any temporary test settings.
• Record your changes: Save the package family name, actual port, and added exemptions so you can migrate or remove them later.
• To roll back: Clear the corresponding checkbox in the graphical tool, or use LoopbackExempt -d to remove the specified package. If you tested TUN, restore your previous TUN and system proxy settings.

The quickest troubleshooting sequence is to verify the local proxy first, then add a loopback exemption for the restricted app. If the app doesn’t use the system proxy, consider TUN. This separates port, permission, routing, and rule issues, making it easier to pinpoint what fixed the problem.