Troubleshooting 9-minute read

Windows Store Apps Can't Connect Through a Proxy: Fix UWP Loopback Access

Learn why UWP apps are blocked from accessing localhost by default, how to grant loopback access with CheckNetIsolation or a GUI tool, and when to use TUN mode instead.

First, check whether only Store apps are affected

After you enable the system proxy in Clash Verge, your browser can access websites, but a Store app keeps spinning, fails to sign in, or says it's offline. This may be related to AppContainer loopback isolation. Don't start by changing your subscription; first check whether the app can reach the local proxy listener, such as 127.0.0.1:7897.

However, an app being “installed from Microsoft Store” doesn't mean it runs in the UWP sandbox. The Store also distributes regular desktop apps, packaged Win32 apps, and other types of software. Loopback exemptions mainly apply to processes restricted by AppContainer network isolation; they aren't a universal fix for every Store app connectivity issue.

  • Browser also fails: Check the proxy port, node connectivity, whether your subscription loaded, and whether the system proxy address is correct.
  • Only one sandboxed app fails: Confirm its package identity, then try granting loopback access to that app alone.
  • Works again when the system proxy is off: The issue is related to the proxy path, but you'll still need to distinguish loopback restrictions from an app that doesn't support proxies or a remote service refusing the connection.
  • Still fails with the proxy off: Check the system clock, app service status, account sign-in, and local network. A loopback exemption usually isn't the first thing to try.

How UWP loopback isolation relates to the system proxy

The system proxy provides an address to apps that honor that setting; it doesn't automatically route every process's network traffic. Proxy clients typically listen on a local HTTP or mixed-proxy port. An app connects to that local port first, then the core uses its rules to choose between a direct connection and a proxy node.

For AppContainer apps subject to network isolation, access to localhost is restricted by default. So even if the proxy core and browser work, the app may fail at the first step: connecting to the local proxy. “Loopback” means connecting to the same computer, such as IPv4 127.0.0.1 or IPv6 ::1—not to a remote node.

What a loopback exemption can and can't do

  • A loopback exemption lets the AppContainer for a specified package access local loopback services. It can help when this restriction blocks a connection to a local proxy.
  • It doesn't configure a proxy address for the app or force every networking library to use the Windows system proxy.
  • It won't fix an expired subscription, DNS errors, node timeouts, certificate errors, or an app's own regional restrictions.
  • It doesn't change Clash or mihomo routing rules. Whether traffic goes direct or through a proxy after access is allowed still depends on the active configuration and policy groups.

Don't change the listener address to 0.0.0.0 or disable Windows Firewall to work around loopback restrictions. That exposes the local service more broadly without addressing the app's isolation boundary.

Grant an exemption for one app with CheckNetIsolation

1. Confirm the local proxy is working

On Windows 11, go to Settings → Network & internet → Proxy → Manual proxy setup and check the address and port. On Windows 10, go to Settings → Network & Internet → Proxy. If the client manages the system proxy, check its listener port first to avoid the two settings overwriting each other.

Open PowerShell and test the listener, then make an HTTPS request using an explicitly specified proxy:

Test-NetConnection -ComputerName 127.0.0.1 -Port 7897
curl.exe --proxy http://127.0.0.1:7897 --head --connect-timeout 10 https://www.microsoft.com/

TcpTestSucceeded : True only means the TCP port is reachable; it doesn't guarantee that the node or website is accessible. The second command uses a 10-second connection timeout. An HTTP response means that request received a response at the application layer. If the connection is refused, fix the port or start the core before adding an exemption.

2. Find the app's PackageFamilyName

Search for PowerShell in the Start menu and select “Run as administrator.” This example uses the Microsoft Store package. First, look up the package identity installed for the current user:

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

The command requires a PackageFamilyName, not the app's display name or its version- and architecture-specific PackageFullName. A common Microsoft Store package family name is Microsoft.WindowsStore_8wekyb3d8bbwe, but verify the actual query result before running the command.

For another app, list the packages for the current user and search by Name. Don't grant exemptions to every result just because its display name looks similar:

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

If the query returns no results, first check that the app is installed for the current account and isn't a regular desktop app. If you elevated PowerShell using a different administrator account, the package list for the current user may also differ. A missing result doesn't necessarily mean the package is corrupted.

3. Add the exemption and verify the list

Run these commands in an elevated terminal. The first adds one package; the second displays the current exemption list:

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

Here, -a means add, -n is followed by the package family name, and -s displays the list. Entries may appear as SIDs or include package names, depending on the system. If you see “Access is denied,” make sure the terminal is elevated. If there's a name-related error, check the field you copied.

Save your work, fully exit the app, then reopen it from the Start menu. If it still has a background process, you can end the process you have confirmed belongs to the app in Task Manager and try again. Don't terminate system processes if you're unsure what they do.

4. Keep the change easy to undo

After testing, remove only the entry you added if you no longer need the permission:

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

-d means delete. Record the date, package, and test results. Don't clear all existing exemptions, as that could disrupt local connections already configured for other apps.

GUI tools: select the target package, not every package

If your current client has a “UWP Loopback Exemption” option, it may open a GUI management tool. The option varies across clients, forks, and versions, so don't assume a button from an older client is also available in Clash Verge Rev. If you can't find it, use the Windows command above—no extra tool is needed.

Common GUI options include Fiddler Classic's WinConfig and AppContainer Loopback Exemption Utility. If the tool is already installed and trusted on your system, you can use it to manage loopback permissions. This only uses its exemption management feature; you don't need to enable HTTPS decryption or install a packet-capture root certificate.

  1. Open the loopback exemption tool as an administrator and wait for it to list the app packages on your PC.
  2. Find the target by app name and package identity. If the name is unclear, verify it in PowerShell first.
  3. Select only the app that needs to access the local proxy, then click the tool's save button, such as Save Changes.
  4. Run CheckNetIsolation.exe LoopbackExempt -s to verify the exemption, then restart the app and test again.

Switch to TUN for apps that ignore the system proxy

If the loopback exemption is active but the app doesn't read the system proxy at all, changing the exemption list won't make it use an HTTP proxy. Consider mihomo's TUN mode instead: it uses a virtual network interface and routing to capture eligible IP traffic, then passes it through the rules.

TUN captures traffic differently from an app connecting directly to a local HTTP proxy, so it's often used for traffic from apps that ignore the system proxy. However, it isn't a universal fix for UWP network isolation. App permissions, firewall rules, routing, and DNS settings can still affect the outcome.

  1. Note the current system proxy, TUN, DNS, and policy group settings so you can restore them if needed.
  2. In Clash Verge Rev, make sure service mode is available before enabling TUN. The service installation and settings options vary by version. Installing the service for the first time may require administrator approval.
  3. To isolate the traffic path during testing, turn off the system proxy and leave only TUN enabled. Don't run another VPN or proxy client at the same time.
  4. Repeat the same action in the same app, then check the client's connection log, destination domain, and matched rule—not just whether the tray icon is lit.

If enabling TUN also stops your browser from resolving domain names, check DNS and routing first instead of adding more loopback exemptions. Auto-routing can conflict with a company VPN, virtual machine network, or other tunnel. Stop testing and restore the original settings before checking each item individually. TUN also doesn't force all app traffic through one node: a DIRECT rule may still send the destination directly.

Still failing after an exemption? Troubleshoot each connection stage

Symptom Check first Next step
Local port test fails Whether the core is running and the port matches Confirm the actual listener port, then test again
A curl request using the proxy also fails Node, DNS, rules, and remote connection Fix the proxy path first; don't add the exemption again
Exemption is present, but the app has no connection log entries Package identity, app proxy support, and background processes Fully exit the app and test again; compare with TUN if needed
Connection is logged, but sign-in fails Matched policy, server response, and account status Check the specific domain and error code

No connection log entry doesn't prove that loopback isolation is the cause. The app may not have sent a request, may be using cached data, or may use a traffic path the client doesn't capture. Conversely, if the destination domain appears and the expected policy matches, focus on DNS results, the node's exit, and the server response.

Don't treat netsh winhttp import proxy source=ie as a UWP loopback fix. It imports WinHTTP proxy settings; it doesn't change AppContainer loopback permissions or guarantee a change to the network stack used by the target app. Only handle WinHTTP separately after confirming that a specific service uses it and understanding the impact.

For a reproducible report, record at least the Windows version, client and core versions, app package family name, proxy listener port, system proxy and TUN states, and the exact steps that trigger the error. Use winver to check the Windows version, then change one variable at a time. This is usually more useful than switching nodes, changing DNS, and enabling TUN all at once. For rules and traffic capture settings, see the configuration reference. For basic connection issues, see troubleshooting.

Download ClashChoose your system and installer