Windows Store Apps Not Working with a Proxy? How to Enable UWP Loopback Access

First, check whether loopback access is the issue

If your browser loads websites through Clash but Microsoft Store keeps loading or reports a network error, one common cause is that the app cannot connect to your local proxy. In Windows 10 and Windows 11, apps subject to AppContainer network isolation cannot access local loopback services by default like regular desktop programs can. Even if your system proxy is set to 127.0.0.1, the app may still lack permission to connect.

Here, “loopback” means an app connecting to a service on the same computer, such as 127.0.0.1:7890. A loopback exemption lifts this restriction for selected app packages only. It does not start Clash, choose a proxy node, or configure the app’s proxy address.

Run these three checks first

1. Make sure the client works: Enable a valid configuration, select an available proxy, turn on the system proxy, then use a browser to reach the service. If the browser fails too, troubleshoot the configuration, node, or network first.
2. Check the local proxy endpoint: Find the client’s “Port” or “Mixed Port” setting. This guide uses 7890 as an example; your port may differ. Set the HTTP proxy to an HTTP port or an HTTP-compatible mixed port, not a SOCKS-only port.
3. Keep the test conditions simple: Test with the system proxy and temporarily disable other VPNs and proxy clients. If TUN is enabled, turn it off temporarily to distinguish between traffic paths. On a work-managed device, do not change network settings required by your organization.

In Windows 11, go to Settings → Network & internet → Proxy → Use a proxy server → Edit to check the address and port. In Windows 10, check the manual proxy settings under Settings → Network & Internet → Proxy. If the client manages these settings, correct the port in the client to prevent it from being overwritten the next time you toggle the proxy.

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

Some Windows Clash clients include a tool for managing app loopback access, often labeled “UWP Loopback Exemption,” “UWP Tool,” or “Loopback.” This is a client interface feature, not a universal YAML option in Clash or the mihomo core. The location varies by client and version. If you can’t find the tool, use the Windows command-line method below.

1. Open the client’s Settings and look for a tool labeled “UWP” or “Loopback Exemption.” Older versions of Clash for Windows had a “Launch” button under “General” → “UWP Loopback.” This is just a reference for the old interface; there’s no need to install an outdated client.
2. When you launch the tool, check the Windows User Account Control prompt and allow it to modify the loopback list with administrator privileges. If your account lacks the required permissions, ask your device administrator for help.
3. Find Microsoft Store in the app list and select only the app you need to troubleshoot. If the tool has a save button, click “Save Changes” (or its equivalent) rather than just selecting the app and closing the window.
4. Fully exit the app and reopen it, then repeat the action that failed. If it is still running in the background, use Task Manager to end processes confirmed to belong to that app, then try again.

Avoid selecting every app just to save time. An exemption allows selected apps to connect to local services, so grant access only where needed. If the target app is missing from the list, first check that it’s installed for the current Windows user, then use PowerShell to look up its package identifier. Don’t guess a package name based on its display name.

Method 2: Add an exemption with CheckNetIsolation

CheckNetIsolation.exe is included with Windows and requires no additional installation. Run the commands below in an elevated PowerShell session or a PowerShell tab in Windows Terminal. Check the current list, add the exemption, then check the list again to confirm the change took effect.

1. Find the app package installed for the current user

Right-click the Start button and select “Terminal (Admin)” or “Windows PowerShell (Admin).” Run this command to find the Microsoft Store package family name:

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

The standard Microsoft Store package usually returns Microsoft.WindowsStore_8wekyb3d8bbwe. Use the returned PackageFamilyName, not the PackageFullName, which includes the version and architecture. The package family name identifies the app family and does not need to be updated with each app version.

To find another app, list the packages installed for the current user, then identify it by name:

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

2. Check the current list and add Microsoft Store

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

• -s: Lists current loopback exemptions so you can check the list before and after making a change.
• -a: Adds an entry. Provide the actual app package family name after -n.
• Even if the command reports success, run the final list query to confirm the entry is present, then reopen the app and test again.

If you get “Access denied” while adding the exemption, check that the terminal is running with administrator privileges. For package name or parameter errors, verify the query result and use straight English quotes and hyphens. Don’t paste curly quotes from formatted web pages into commands or use the app’s display name in place of its package family name.

3. Remove an exemption when it’s no longer needed

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

-d removes the specified entry. If you’re testing an app, remove its exemption afterward if you no longer need it. Leave other apps’ exemptions intact; don’t clear the entire list to troubleshoot one Store error.

Check the traffic: proxy connection or a DIRECT rule?

Successfully adding an exemption only confirms that the isolation setting changed. It does not mean every request will go through a proxy node. Return to the client’s Connections page, trigger the Store to load again, and check for the relevant domain, connection entry, and final policy. If needed, temporarily increase the log level on the Logs page, reproduce the issue once, then restore it to avoid generating excessive diagnostic data.

Clash and mihomo rules are generally evaluated from top to bottom, and the matched rule determines the policy. Once an app reaches the local proxy, a DIRECT match still connects directly to the destination. That’s different from the app never reaching the proxy. Don’t switch to Global mode indefinitely to fix one app, or overwrite all the rules in your subscription.

TUN, WinHTTP, and the system proxy are different things

TUN is not the same as a loopback exemption

The system proxy is mainly used by apps that honor that setting. TUN mode uses a virtual network adapter and routing to capture eligible traffic. In mihomo clients, TUN also involves service permissions, automatic routing, and DNS settings. If an app reconnects after you enable TUN, its traffic path has changed; that does not mean the loopback list was fixed automatically.

You can use TUN to test a different traffic path, but change only one setting at a time. If the system proxy points to a local loopback address, an isolated app may still need an exemption to access it. Enabling TUN alone is not guaranteed to fix every UWP issue.

Don’t apply the system proxy to every service

Some Windows services use WinHTTP, whose proxy settings are separate from the current user’s system proxy. Use this read-only command to check the status. However, “Direct access” alone does not prove the configuration is wrong, nor does it confirm that the Store uses this network path:

netsh winhttp show proxy

Don’t treat bulk WinHTTP changes, network resets, or disabling the firewall as required steps for a loopback exemption. These changes can affect system services, work-managed devices, and other software. Investigate them separately once you’ve identified the cause of the issue.

Final checks if it still doesn’t work

• Check service status: Make sure the Windows date, time, and time zone are correct. Check your account sign-in status and whether the destination service is available. A “network error” in the app doesn’t necessarily mean the local proxy is at fault.
• Reset the Store cache: If only the Microsoft Store is having trouble, press Win + R, run wsreset.exe, and try again. This clears the Store cache; it won’t replace a loopback exemption or fix an unavailable proxy node.
• Check whether the app is still supported: Support for the classic Windows Mail and Calendar apps ended on December 31, 2024. As of this article’s date, problems with the old clients can’t be attributed solely to loopback restrictions. Check whether you’re using the legacy Mail app or the new Outlook, then troubleshoot the relevant product.
• Keep only essential diagnostic details: Note your Windows version, client name, local port, app package family name, error code, and when the issue occurred. Remove subscription links, tokens, and account details before sharing logs.

Recommended order: confirm that the proxy works in a regular app, check the system proxy endpoint, add an exemption for the specific app, restart it, then use connection records to check the rules and proxy node. Each step tests a specific part of the setup, helping you address common UWP loopback restrictions without confusing them with Store cache issues, service networking, or discontinued apps.