Windows Store Apps Not Using the Clash Proxy: Fix UWP Loopback Restrictions

Learn why UWP network isolation blocks localhost connections, then remove the restriction for Store apps with a built-in client tool or the CheckNetIsolation command.

First, check whether loopback access is being blocked

Check for loopback restrictions first if your browser works but a Store app cannot connect. If websites also fail to load in your browser, check that a configuration is enabled, the selected node is working, and the proxy port is listening. A loopback exemption cannot fix an invalid subscription, incorrect password, or unreachable server.

UWP is an application platform in Windows. These apps typically run in an AppContainer, an isolated environment that restricts what they can access. Loopback means an app connecting to an address on the same device, such as 127.0.0.1 or ::1. Clash's local proxy often listens on one of these addresses, so an isolated app may be unable to connect even when the system proxy points to Clash.

However, being installed from the Microsoft Store does not necessarily make an app a UWP app. The Store also distributes traditional desktop apps and packaged desktop apps. Check the app type, proxy settings, and connection logs rather than assuming every Store app connectivity issue is caused by loopback restrictions.

What you observe Check first Next step
Both the browser and target app fail Core, port, node, and rules Verify the local proxy connection first
Browser works, isolated app fails, and Clash shows no matching connection Loopback restriction or app not using the system proxy Add an exemption for the target package and test again
Clash shows the app's request, but the connection times out Matched policy, node, DNS, and remote service Inspect connection details instead of repeatedly adding exemptions
Store interface works, but downloads fail Network path used by download services and background components Distinguish foreground traffic from background downloads

Before you start: check the system proxy and local port

Note the actual port before changing isolation settings. This guide uses 127.0.0.1:7890 as an example; it is not the default for every client. An HTTP port accepts HTTP proxy requests, while a mixed port typically accepts both HTTP and SOCKS requests. In Windows manual proxy settings, use a port that supports HTTP proxy connections—not a SOCKS-only port.

  1. Open the client, select a working configuration, and check the port settings or active configuration for the port and mixed-port fields. Use the settings currently in effect.
  2. Enable “System Proxy” in the client. In Windows 11, go to Settings → Network & internet → Proxy → Manual proxy setup → Edit, then check the address and port.
  3. In Windows 10, go to Settings → Network & Internet → Proxy and check “Use a proxy server.” The client may set these values automatically, so you do not need to change them manually just to inspect them.
  4. Test a known working HTTPS page in your browser, then check the client's Connections or Logs panel. If the browser uses a separate proxy extension, its success does not confirm that the Windows system proxy is working.

Check whether the port is listening

Run the following command in PowerShell. If the actual port is 7897, replace 7890 in the command with 7897. A listening entry means a process on this device is listening on that port; you still need to confirm that it belongs to the core you are using.

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890

TcpTestSucceeded : True only means the TCP connection was established successfully. It does not confirm that the remote website or node is working. PowerShell usually runs outside the target app's isolated environment, so this test also cannot prove that UWP has permission to access loopback.

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

If your client includes a UWP tool, start by selecting the specific app. Some Windows clients provide a loopback exemption screen labeled “UWP Loopback,” “Loopback,” or something similar. This is an optional feature of the graphical client, not a menu provided by the Clash or mihomo core.

For example, the “UWP Loopback” option was available on the General page in older versions of Clash for Windows 0.20.x. This path is only useful for identifying an existing installation; it does not apply to other clients. If your current client does not have the same option, use the Windows command in the next section.

  1. Open the UWP loopback tool. If Windows asks for permission, first make sure the request comes from the tool bundled with your current client, then allow it to run with elevated permissions.
  2. Find the target app in the list. Its listed name may differ slightly from its Start menu name; check the publisher and package name if needed.
  3. Select only the apps that need to use the local proxy, then click Save or Apply. Depending on the tool, the button may be labeled “Save Changes” or “Apply.”
  4. Fully exit the target app, make sure it is no longer running in the background, then reopen it and try an operation that requires a network connection.
  5. Open Clash's Connections or Logs panel and check for a new request to the target domain. Do not rely on cached content on the app's home screen to determine whether it worked.

Method 2: Add a loopback exemption with CheckNetIsolation

Windows includes CheckNetIsolation for viewing and changing the exemption list. The example below uses a Microsoft Store app package. Open PowerShell as an administrator under the target user's account. In Windows 11, you can also right-click Start and select “Terminal (Admin).” If you launch the terminal with credentials for a different administrator account, make sure the app package you find still belongs to the target user.

Step 1: Find the exact package family name

The command requires PackageFamilyName, also known as the package family name. This is not the desktop shortcut name or the PackageFullName, which includes the version and architecture. First, find the Store app packages installed for the current user:

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

A common result is the package family name Microsoft.WindowsStore_8wekyb3d8bbwe, but use the output from your own PC. To find an app other than the Store itself, search for part of its package name. For example, you can search for Xbox-related packages:

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

A wildcard search may return multiple results. Do not add every result to the list or mistake the display name for the package family name. If nothing is returned, check that the app is installed for the current user and that it is a package this method can identify.

Step 2: Add an exemption for the target package

The PowerShell code below finds the Microsoft Store package for the current user and adds it to the loopback exemption list. The null check prevents the command from continuing if the app is not installed. To work with another app, replace Microsoft.WindowsStore with its verified package name.

$package = Get-AppxPackage -Name Microsoft.WindowsStore

if ($null -eq $package) {
    throw "Microsoft.WindowsStore package not found for the current user."
}

$family = $package.PackageFamilyName
CheckNetIsolation.exe LoopbackExempt -a "-n=$family"

-a adds an exemption; -n is followed by the package family name. If you see an access denied message, first check whether the terminal is running with administrator privileges. Do not disable system security features to bypass the permission requirement.

Step 3: Check the list and restart the app

CheckNetIsolation.exe LoopbackExempt -s

Use -s to display the current exemption list. Check that it includes the target package family name; some entries may appear as security identifiers instead. After the command confirms the exemption was added, close and reopen the target app, then make a new network request. If needed, sign out and back in to ensure an old process is not still running.

How to verify the change and safely undo it

Check both the app's behavior and Clash connection logs. The best way to tell whether a setting worked is to compare the same action before and after the change, not just check whether the command succeeded. Keep the same node and configuration during testing, and avoid changing multiple variables at once.

  1. Note the symptom before making changes—for example, “Store search fails”—rather than simply writing “no internet.”
  2. Add a loopback exemption for the target package, then fully exit and reopen the app.
  3. Repeat the same search or refresh and check whether the app receives fresh results from the server.
  4. In Clash, check the connection, domain, and policy at the relevant time. In Rule mode, a match to DIRECT means the request was routed directly; it does not indicate that the loopback setting failed.

Remove an exemption by package when it is no longer needed

Use -d to remove an exemption. The example below uses Microsoft Store and looks up the package family name again, so it does not rely on a variable from a previous terminal session:

$package = Get-AppxPackage -Name Microsoft.WindowsStore

if ($null -eq $package) {
    throw "Microsoft.WindowsStore package not found for the current user."
}

$family = $package.PackageFamilyName
CheckNetIsolation.exe LoopbackExempt -d "-n=$family"
CheckNetIsolation.exe LoopbackExempt -s

Check the list again after removal to confirm the target entry is gone. Do not clear all exemptions just to undo a setting for one app; other apps, development environments, or debugging tools may rely on existing entries. If reinstalling an app changes its package family name, verify the new name rather than assuming the new installation is authorized because the old entry is still present.

Still not using the proxy after adding an exemption? Trace the traffic path

System proxy, Global mode, and TUN work at different layers

“Global mode” does not force every process to connect to Clash. It mainly determines how traffic that has already reached the core is routed. If an app is not using the system proxy at all, switching to Global mode will not make its traffic enter the core. First determine whether the request never arrived or arrived but took the wrong route.

TUN routes traffic through a virtual network interface. Clients that use mihomo can usually enable it in their settings, but whether it captures the target traffic also depends on routing, DNS, permissions, and exclusions. TUN is not another name for a loopback exemption and is not guaranteed to fix every Store app issue. Before testing TUN, save your current settings, change one thing at a time, and check the connection logs.

The foreground interface and background downloads may use different processes

Microsoft Store page requests and app downloads or updates may go through different components. Adding an exemption for the Store's foreground package does not mean background services will use the same user's system proxy. If the page opens but downloads still fail, check Windows download services, network errors, and actual connection records instead of repeatedly adding unrelated app packages.

Do not treat WinHTTP settings as a universal fix

Windows user proxy settings and WinHTTP proxy settings are not the same mechanism. Some programs and system services use the WinHTTP networking interface, so changing its proxy can affect other tasks. Use the read-only command below to inspect the current settings, but do not blindly import or overwrite them before confirming where the request comes from.

netsh winhttp show proxy

If the logs show the target request, check DNS resolution, matched rules, and node availability next. If there is no request at all, check whether the app uses its own proxy, connects through another process, and is actually an app type subject to loopback restrictions. For help identifying configuration fields, see the YAML Reference; for general connection issues, start with the FAQ.

Download Clash