Windows Store Apps Not Working with Clash: How to Fix UWP Loopback Restrictions

First, confirm that UWP loopback restrictions are the problem

Typical symptoms include browsers, Git, and messaging apps working through Clash while Microsoft Store remains stuck on “Try again,” images load incompletely, or app downloads stay on “Acquiring license” for a long time. Xbox, Photos, Mail, and other Store apps on the same PC may also fail to connect. In Clash’s connections panel, browser traffic appears, but the affected Store app generates no connections.

This difference is usually not caused by node speed. Traditional Win32 programs can connect directly to a local listening address, while UWP and Store apps using the AppContainer isolation model are restricted from loopback access by default. Clash’s system proxy usually points to a local address such as 127.0.0.1:7890. To use that proxy, the app must first reach the local loopback interface. If Windows blocks the connection at this layer, the request never reaches Clash and naturally does not appear in the connection log.

Three quick checks

1. Clash is running, the active configuration has at least one working node, and websites open normally in your browser.
2. The client’s system proxy is enabled, and the Windows proxy address points to 127.0.0.1 with the same port Clash is actually listening on.
3. When Microsoft Store fails to refresh, no corresponding request appears on Clash’s “Connections” or “Logs” page.

If all three conditions are true, continue by configuring Loopback Exempt—that is, granting selected apps permission to access the local loopback interface. This only changes whether an AppContainer may connect to a local address; it does not replace proxy rules or select a node automatically. Traffic is still governed by Clash’s current rule mode, proxy groups, and DNS settings.

Why loopback restrictions block the local Clash port

Windows Store apps typically run inside isolated containers with an application identity. The system assigns network capabilities based on that package identity and restricts the container from directly accessing local loopback addresses. The goal is to isolate apps from local services and prevent them from freely probing ports running on 127.0.0.1.

Clash’s HTTP, SOCKS, or mixed-port listener is precisely such a local service. A common configuration sets the mixed port to 7890:

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

After system proxy is enabled, Windows sends requests from apps that support system proxies to 127.0.0.1:7890. Regular desktop programs can establish this local connection; a restricted AppContainer may be rejected before reaching the port. As a result, Microsoft Store may fail to load even when node latency is only 45 ms, and Clash logs may show no complete proxy handshake.

Loopback exemption addresses only whether the app can connect to the local proxy. It does not fix expired subscriptions, incorrect proxy groups, misclassified rules, or timeouts on remote nodes. During troubleshooting, break the path into “app → local Clash port → proxy rules → node → target service” to avoid repeatedly changing nodes without addressing the actual blocking point.

Use the Clash client’s built-in UWP Loopback tool

Some Windows GUI clients provide a UWP Loopback management entry; underneath, they still call Windows’ loopback exemption mechanism. Menu names vary slightly by client and version. Common paths include “Settings” → “System Settings” → “UWP Loopback” or “General” → “UWP Loopback” → “Launch Tool.” Older versions of Clash for Windows often place the entry on the General page, where the button may be labeled UWP Loopback.

GUI steps

1. First close Microsoft Store, Xbox, and any other apps you want to configure so old connections do not remain active.
2. Open the Clash client, confirm that system proxy is enabled, and note the mixed-port or HTTP port under “Settings” → “Port Settings.”
3. Go to “Settings” → “System Settings” → “UWP Loopback.” If the client requests administrator permission, approve it to continue.
4. Wait for the tool to enumerate app packages, then find Microsoft Store in the list. Its package identity usually contains Microsoft.WindowsStore.
5. Select Microsoft Store. If Xbox, Photos, or another Store app has the same problem, select each affected app as needed.
6. Click “Save,” “Apply,” or “Save Changes,” and wait for the tool to confirm that the settings are complete.
7. Reopen Microsoft Store, open any app details page, refresh it, and watch Clash’s connections panel.

The app list may contain entries with similar display names. Check the package name or Package Family Name instead of relying on the icon alone. Microsoft Store commonly uses Microsoft.WindowsStore_8wekyb3d8bbwe; Windows App Installer usually uses Microsoft.DesktopAppInstaller_8wekyb3d8bbwe. They serve different purposes, so exempt the one you actually need.

A Windows restart is usually unnecessary after saving, but fully close and reopen the target app. If Microsoft Store retains its old state, end the corresponding process in Task Manager and launch it again. You can also press Win + R and run wsreset.exe to clear the Store cache; this handles cache and UI state, not loopback exemptions.

Use the command line when the client has no loopback tool

Windows includes CheckNetIsolation.exe for viewing, adding, and removing AppContainer loopback exemptions. The key to manual setup is obtaining the exact Package Family Name; the app’s display name cannot be used in its place.

Step 1: Find the Microsoft Store package family name

Open PowerShell as administrator and run:

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

A typical result looks like this, but use the output from your own PC:

Name              PackageFamilyName
----              -----------------
Microsoft.WindowsStore Microsoft.WindowsStore_8wekyb3d8bbwe

To find apps whose names contain Xbox, use:

Get-AppxPackage *Xbox* |
  Select-Object Name, PackageFamilyName

Step 2: Add the loopback exemption

After confirming the package family name, run this in an elevated terminal:

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

The -a parameter means add, and the value after -n must be the complete Package Family Name. After the command succeeds, close Microsoft Store and reopen it for testing.

Step 3: Check the current exemption list

CheckNetIsolation.exe LoopbackExempt -s

The output should include the package identity you just added. If the target is missing, the terminal may lack sufficient privileges, the package family name may be misspelled, or extra spaces may have been copied. Copy it again from the PowerShell query result and rerun the add command.

Remove the exemption when you need to revoke access

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

-d means delete. After making the change, run LoopbackExempt -s again to confirm that the target entry has been removed. Loopback exemptions are stored by app package identity. Updates usually do not change the package family name, but after uninstalling and reinstalling an app, migrating the system, or changing its package identity, check the list again.

How to confirm Microsoft Store is using Clash after exemption

Seeing the Store page recover is not enough to confirm the traffic path, because the content may have come from cache. A more reliable test combines app behavior, Clash connection records, and rule-match results.

Test 1: Watch the connections panel

1. Open the Clash client’s “Connections” page and clear any existing filters.
2. Fully close Microsoft Store, then open it again.
3. Open an app details page you have not viewed before, switch screenshots, or click “Check for updates.”
4. Check whether a new HTTPS connection appears in the panel. Its target domain may belong to Microsoft Store, licensing, content delivery, or account services.

If the request appears, the UWP app can at least reach the local Clash port. Next, check which rule and proxy group handled the connection. If it shows DIRECT, that is the rule result and does not mean the loopback exemption failed. If a specific domain should use the proxy, inspect the active rule set instead of repeatedly adding exemptions.

Test 2: Confirm the port matches the system proxy

In PowerShell, check the commonly used 7890 port:

Get-NetTCPConnection -LocalPort 7890 -State Listen

If there is no result, return to Clash “Settings” → “Port Settings” and check the actual mixed-port. Some configurations use 7897, 1080, or another port. In Windows “Settings” → “Network & Internet” → “Proxy,” the address and port must match the client’s current listening values. If a port conflict caused Clash to switch ports, the old system proxy settings can also make Store connections fail.

Test 3: Perform a repeatable Store action

• Open the Microsoft Store “Library” page and click “Get updates.”
• Choose a small app and check whether its download moves from “Waiting” to active progress.
• Check the Clash logs to confirm that repeated connection timeouts or DNS errors no longer occur.
• Switch the proxy-group node and refresh again to confirm that the new connection uses the currently selected policy.

One successful download only shows that the path worked at that moment. Test twice in a row, then test once more after closing and reopening Microsoft Store. This helps rule out cache, existing connections, and brief network recovery as false positives.

If it still cannot connect, troubleshoot in order

After adding a loopback exemption, the problem usually moves from “the app cannot reach the local port” to Clash itself or the upstream network. Do not keep selecting the same app; verify each layer in the order below.

1. Confirm the configuration and port are active

• The Clash client should show that it is running, and the configuration file should have loaded successfully.
• The system proxy address should be 127.0.0.1, with a port matching the mixed-port or HTTP port.
• If the configuration enables only a SOCKS port, do not use that port directly as the Windows HTTP system proxy.
• After editing YAML, check the indentation first, then reload the configuration in the client.

2. Check the rule mode and proxy group

Rule mode matches target domains one by one. Microsoft Store relies on multiple services for accounts, licensing, app metadata, and content delivery, so one domain cannot determine the overall result. Once requests appear in the connections panel, focus on the Rule, Chains, or proxy-group fields. If rules send some services to an unavailable node, the Store may show images while downloads fail.

For temporary diagnosis, switch the target proxy group to a confirmed working node with latency of about 50–150 ms, then retry the Store update. Global mode can provide a short comparison, but switch back to your normal rule mode afterward and continue identifying the specific rule.

3. Check DNS

When the connection has reached Clash but the logs show DNS resolution failures, timeouts, or unexpected addresses, inspect the DNS configuration. With the mihomo core, make sure dns.enable, the listen address, nameserver, and enhanced mode are compatible. If Fake-IP is enabled, ensure system traffic is actually handled by Clash; otherwise the app may use a different DNS path and produce mismatched resolution and connections.

4. Check the firewall and security policies

The local firewall may block Clash’s listening port or restrict the app container’s network access. First confirm that the Clash process and the core in use are allowed to run under the current network profile, then check for blocking rules targeting 127.0.0.1:7890 or the relevant process. Company-managed devices may enforce Microsoft Store, proxy, and AppContainer network policies through Group Policy, in which case local changes may be overwritten.

5. Distinguish system proxy mode from TUN mode

System proxy mode depends on apps actively reading Windows proxy settings, so UWP loopback exemptions are directly relevant to the local proxy port. TUN mode uses a virtual network interface to capture more traffic and is more effective for programs that ignore system proxy settings. After enabling mihomo TUN, some Store apps may no longer depend on the traditional 127.0.0.1 HTTP proxy path.

However, TUN is not a universal replacement for fixing loopback issues. It also involves administrator privileges, service mode, routing, DNS hijacking, and firewall compatibility. If only Microsoft Store is affected while other programs work reliably through the system proxy, add a Loopback Exempt for the target app first because it makes a smaller change. Consider TUN only when multiple types of programs ignore the system proxy or when you genuinely need to capture traffic such as UDP.

Common misconceptions and takeaways

Enabling the system proxy automatically removes UWP restrictions

The system proxy only tells an app where the proxy server is. Whether an AppContainer can access that local address is controlled separately by the loopback policy. Confirm both independently.

Using port 7890 is always correct

7890 is a common default, not a requirement. The configuration file, client overrides, or a port conflict may change the actual listening port. Use the current client interface and listening result as the source of truth.

Exempting Microsoft Store covers every Store app

Exemptions are recorded by package family name. Microsoft Store, App Installer, Xbox, and other apps generally have different package identities, so query and add each one according to the actual issue.

A connection appearing in Clash means the entire proxy path works

A connection only proves that the app reached the local proxy. It can still fail because of rule matching, DNS, node handshakes, remote-service restrictions, or network policies. Check the failed stage in the logs to decide what to investigate next.

A practical summary is: when regular desktop programs work but Store apps produce no Clash connection records, check UWP loopback exemptions; when records appear but requests fail, check the port, rules, DNS, and node; when multiple programs fail at once, return to Clash’s basic connection path and the local network. Following this order usually limits the issue to one clear layer.