Windows Store Apps Not Using Your Proxy? How to Remove UWP Loopback Restrictions

First, check whether only one Store app is failing while your browser works

Leave your Clash client running. Make sure your subscription is enabled and a node connects, then open the affected app. If your browser can access the internet through the system proxy but a UWP app reports that it’s offline, times out during sign-in, or won’t refresh, check for a loopback restriction. Don’t start by changing subscriptions or DNS, or by exempting every app.

This guide covers troubleshooting on Windows 10 and Windows 11 with a local HTTP proxy. Client menus vary, but Windows includes CheckNetIsolation.exe for the underlying operation. The port 7890 is an example, not a default for every client. Check your current configuration before proceeding.

Start with these three checks

Make sure the system proxy is enabled in your client. In Windows 11, go to Settings → Network & internet → Proxy → Manual proxy setup and check that the proxy server points to a local address, such as 127.0.0.1:7890. In Windows 10, go to Settings → Network & Internet → Proxy.
Confirm that the port is an HTTP port or a mixed-port. A SOCKS5-only port cannot be used directly as the manual HTTP proxy port in Windows.
Open your client’s connections list or logs, then refresh the affected app. Note the time, whether a connection appears, which rule it matches, and any connection errors.

UWP loopback restrictions: why a local proxy may still be unreachable

Loopback access lets an app connect to a network service on the same computer, such as 127.0.0.1 or the IPv6 address ::1. Clash and the Clash Meta (mihomo) core typically listen on a local proxy port. Desktop apps send requests to that port, and the core routes them directly or through a proxy node according to your rules.

UWP apps commonly run in the AppContainer sandbox, which enforces network isolation. Even when an app can read the system proxy settings, it may be blocked from connecting to a proxy listening on the local machine. So having the system proxy enabled and being able to connect to the local proxy are two separate requirements. The app may show an error or try another network path, depending on its own behavior; don’t assume it always bypasses the proxy.

Typical proxy path:
App → 127.0.0.1:7890 → Clash / mihomo → rule-based routing → destination service

Where access may be blocked:
AppContainer app → local loopback port blocked → request never reaches the proxy core

Adding a loopback exemption lets a specified app bypass this loopback isolation restriction. It doesn’t configure a proxy for the app or guarantee that the app will use the system proxy. In this guide, “remove the restriction” means exempting the app from the restriction: the operation adds an exemption, rather than deleting one.

This is different from rule mode: Rules decide where requests go after they reach the core; they can’t fix sandbox restrictions that prevent requests from reaching it.
This is different from a subscription: A subscription provides nodes, proxy groups, or rules. It doesn’t change Windows app isolation settings.
This is different from allow-lan: allow-lan lets devices on your local network access the proxy. You don’t need to enable LAN access to troubleshoot loopback issues in a local UWP app.

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

Look in your client’s settings or tools for an option named “UWP Loopback,” “Loopback Exemption,” or “Loopback.” Some versions open a separate utility; others don’t include this feature. Don’t install an outdated, unsupported client just to find a similarly named button. If you can’t find the option, use the Windows command in the next section.

Select the affected app and save

Keep the affected app installed, then close it before making changes so it doesn’t keep using an existing connection.
Open the client’s loopback tool. If User Account Control appears, verify the program’s source before granting administrator access.
Find the affected app in the list. Check its display name and package details, and select only apps that need access to the local proxy.
Click “Save,” “Apply,” or the equivalent button in the tool. Selecting an app without saving usually won’t change the system settings.
Restart the affected app, perform a specific network action, and check the client’s connections list.

If the app doesn’t appear in the list, first make sure it’s installed for the currently signed-in Windows user, then reopen the tool. Some tools don’t fully list newer app versions or packages belonging to other accounts. In that case, look up the actual package family name instead of selecting a similarly named entry.

Method 2: Add an exemption for a specific package with CheckNetIsolation

Right-click Start and select “Terminal (Admin).” On Windows 10, you may see “Windows PowerShell (Admin)” instead. The commands below for querying package details require PowerShell. Administrator access is needed to change the exemption list, but be mindful of the signed-in user when querying it: if you launch the terminal using another administrator’s credentials, the app list may belong to that account, not the one you were using.

Step 1: Record the existing exemption list

CheckNetIsolation.exe LoopbackExempt -s

Use -s to list current loopback exemptions. Save the output so you can check whether the target package was already listed. It may include app names and security identifiers. Don’t clear the list just because it’s long; other software may rely on existing entries.

Step 2: Find the app’s package family name

Run the following command in PowerShell to list app package names and package family names for the current user. If the list is long, use the second command to filter by the app’s actual name. Microsoft Store is used as an example; loopback restrictions aren’t the cause of every Store network issue.

Get-AppxPackage | Select-Object Name, PackageFamilyName

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

The -n parameter requires a PackageFamilyName, not the app’s Start menu name or its version- and architecture-specific PackageFullName. A common Microsoft Store package family name is Microsoft.WindowsStore_8wekyb3d8bbwe, but verify it against the results on your PC.

Step 3: Add an exemption only for the package you found

The PowerShell code below looks up Microsoft Store first and stops if it can’t find it, so it won’t continue with an empty value. For another app, replace the lookup name with the actual Name confirmed in the list above. Don’t treat this example as a fix for every app.

$pkg = Get-AppxPackage -Name Microsoft.WindowsStore
if ($null -eq $pkg) {
    throw "Microsoft.WindowsStore was not found for the current user. Check the app name and signed-in account."
}
CheckNetIsolation.exe LoopbackExempt -a "-n=$($pkg.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s

Use -a to add an exemption. Check that the command succeeds, then use -s to confirm the package appears in the list. If you’ve verified the package family name on this PC, you can also run the command below directly. Administrator access is still required.

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

Step 4: Close the app and test again

Save your work and close the affected app. If needed, end any lingering process in Task Manager, then reopen the app and refresh its content. You usually don’t need to restart the whole PC. Keep the client running and the system proxy enabled, and use a node you’ve already confirmed works.

If you see “Access denied,” check that you’re using an administrator terminal. For an invalid parameter error, verify the hyphens and package family name, and make sure the command wasn’t split or truncated when copied. Organization policies may restrict changes on managed devices; ask your administrator instead of repeatedly disabling security features.

How to verify: port access, app traffic, and routing

A successful command only confirms that the exemption was submitted; it doesn’t prove that the app is using the proxy. Check these three layers separately, changing one condition at a time to identify what actually fixes the issue.

Check	What to do	What it tells you
Proxy port	Test the local TCP port 7890	Whether a service is listening and accepting connections on the port
App request	Refresh the app and check the connections list	Whether the request reached Clash or mihomo
Routing decision	Check the domain, matching rule, and proxy group	Whether the request ultimately goes direct or through a proxy

Run the following command in PowerShell. If your current configuration uses 7897, change the port to 7897 as well. TcpTestSucceeded : True means only that the TCP connection succeeded. It doesn’t prove that Clash is listening on the port or that UWP loopback access is working.

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890

You can also use Windows’ built-in curl.exe to explicitly specify an HTTP proxy and test an HTTPS request from a regular desktop process. Using the full curl.exe name avoids a same-name alias in some PowerShell versions.

curl.exe --head --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://www.microsoft.com/

An HTTP response means the command received a response from the server or an intermediary. Check the logs to understand the full result; this isn’t a direct test of the affected UWP app. The final check is to trigger a sign-in, refresh, or other action in the app and look for new connections at the same time. If background traffic makes this difficult, temporarily close other apps.

Exemptions added, but it still fails: troubleshoot by symptom

No request from the app appears in the connections list

First confirm that the app is actually affected by AppContainer loopback restrictions and that the exemption matches its currently installed package. Then check whether the app uses the system proxy. Some apps use their own networking stack; other requests may come from a system service or a different process. Exempting the package that owns the app’s interface won’t automatically change how other processes connect.

The manual proxy and PAC settings in Windows, and the WinHTTP proxy, are separate configuration paths. Don’t treat netsh winhttp import proxy source=ie as a universal fix. It changes a different set of proxy settings and may not affect the app in question.
Microsoft Store’s interface, account sign-in, and app downloads may use different components. If the interface loads, that doesn’t mean the download service uses the same network path; test each separately.
Clearing the Store cache or reinstalling an app addresses different issues. Neither replaces verification of a loopback exemption, and there’s no reason to try them first without evidence of a related error.

The request appears, but the rule result is DIRECT

This means the request reached the core. Check the rules and proxy group next instead of adding more exemptions. Review the connection’s domain, destination IP, matching rule, and actual route. If the service is assigned to DIRECT by your configuration, a loopback exemption won’t force it through a proxy.

You can briefly switch to Global mode as a comparison, but select an available proxy group in Global mode and restore your original rule mode when you’re done. Don’t replace your entire ruleset just because Global mode works; first identify the domain and the rule order affecting it.

The request uses the proxy, but sign-in still fails

Check the logs for DNS failures, connection timeouts, and TLS errors. Also check the account’s region, system time, and service status. A node that works for web browsing may not be accepted by the service you’re trying to reach. If you see a certificate error, don’t hide it by disabling certificate validation. Check the system time, certificate chain, and any HTTPS inspection software first.

Should you enable TUN mode?

TUN routes traffic that matches its routing conditions through a virtual network interface. It can help troubleshoot apps that don’t follow the system proxy, but it isn’t another name for adding a loopback exemption. Results still depend on the client, mihomo configuration, routing, DNS, and Windows network isolation policies. Enabling TUN doesn’t guarantee that every UWP request will work.

If you decide to test TUN, save your current configuration first, then install or enable the required service as directed by your client. Change one setting at a time and note how connections and routes behave before and after. Don’t change Fake-IP, rules, the system proxy, and the firewall all at once, or it’ll be hard to tell what made a difference. For related settings, see Advanced Setup.

Remove exemptions and maintain your settings

If an app no longer needs access to the local proxy, you can remove its exemption. The example below uses the verified Microsoft Store package family name; -d removes the specified entry. It won’t uninstall the app or delete your Clash configuration.

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

Don’t clear all exemptions just to remove one entry. App updates usually retain the same package family identity. After reinstalling, switching distribution channels, or using a different account, look up the package again rather than blindly re-adding the old name. If the system proxy port changes, update the proxy address in Windows too; a loopback exemption won’t update the port for you.

Your browser also fails: Check the client, listening port, subscription, and node connection first.
Only the sandboxed app fails, with no incoming connections: Check the app type, package family name, and loopback exemption.
An incoming connection is logged: Check the rules, DNS, proxy route, and destination service instead of attributing everything to UWP.

Use a consistent troubleshooting order: confirm the local proxy works, identify the target app, add an exemption if needed, restart the app, then check its connection and route. This helps resolve issues genuinely caused by local loopback restrictions without confusing them with rule routing, system service proxies, or account problems.