Windows Store Apps Not Using the Clash Proxy? Remove the UWP Loopback Restriction with CheckNetIsolation

Browser works, Store app doesn’t: check for a loopback restriction first

With the Clash system proxy enabled on Windows, a browser may reach a website while Microsoft Store or another UWP app reports that there’s no network connection. This difference can stem from AppContainer network isolation. The system proxy usually points to a local address, such as 127.0.0.1:7890. Windows may block an isolated app from connecting to that address before the request ever reaches the Clash core.

However, an app installed from the Store doesn’t necessarily run in the UWP sandbox. Microsoft Store also distributes traditional desktop programs, and MSIX packages can contain fully trusted desktop apps. Confirm how the app runs before applying a loopback exemption. Ignoring the system proxy, using the wrong proxy port, or a sign-in service outage can cause similar symptoms.

Check these three signs together

• A desktop browser can reach the same service: This suggests the current node and basic proxy path may be working. But if the browser uses its own proxy extension, that doesn’t confirm the system proxy is active.
• No connection appears when you use the affected app: Open Clash’s Connections or Logs view, then refresh the app. No entry may mean Windows blocked the connection before it reached Clash—or that the app doesn’t use the system proxy at all.
• The system proxy points to localhost: Check whether the address is 127.0.0.1, localhost, or the IPv6 loopback address ::1, and make sure the port matches the one the core is actually listening on.

How the UWP sandbox handles connections to 127.0.0.1

A loopback address refers to the local computer, not a remote server. A typical connection path is “app → local HTTP proxy port → Clash or mihomo core → rule-selected outbound.” System proxy settings tell apps that honor them where to connect; they don’t remove the network isolation applied to those apps.

UWP apps typically run in an AppContainer. Windows restricts these apps from accessing local loopback services by default, maintaining an isolation boundary between apps and local services. Even when the proxy is running, an app may be unable to connect to 127.0.0.1:7890. CheckNetIsolation LoopbackExempt lets you grant a loopback exemption to a specific app package so it can access local services.

An exemption doesn’t force an app to use a proxy outbound. Once a connection reaches the core, it may match DIRECT or be blocked by REJECT. Loopback restrictions and routing rules operate at different layers, so troubleshoot access first, then check the outbound route.

Check the system proxy and listening port first

1. Keep the Clash client and core running, and make sure a configuration with a working node is enabled.
2. In Windows 11, go to Settings → Network & internet → Proxy → Manual proxy setup, then select Set up under Use a proxy server. In Windows 10, go to Settings → Network & Internet → Proxy; the toggles are arranged differently.
3. Check the address and port set when the client enabled the system proxy. For a local proxy, the address is usually 127.0.0.1, and the port should match the active HTTP or mixed port.
4. In PowerShell, test whether a TCP connection to that port succeeds before adding an app exemption.

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
netstat -ano | findstr ":7890"

TcpTestSucceeded : True means the current PowerShell process can connect to the port. It does not mean UWP apps are allowed to access it or that the proxy can reach its outbound destination. The netstat output should show a matching LISTENING entry; other connection states don’t prove that the core is listening.

Method 1: Grant an exemption to a specific app with CheckNetIsolation

This example uses Microsoft Store. In the affected Windows user session, open Start, search for PowerShell, and select Run as administrator. If you elevate by entering another administrator’s credentials, the user context changes, so the default Get-AppxPackage results may no longer refer to the affected user. Confirm which user you’re querying first.

1. Find the app’s package family name

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

To add an exemption, use PackageFamilyName, not the display name or the PackageFullName that includes the version and architecture. A common Microsoft Store package family name is Microsoft.WindowsStore_8wekyb3d8bbwe, but use the result from your own machine.

To troubleshoot another app, list the packages installed for the current user and filter by app name. The name shown in the app’s interface may differ from its package name, so don’t infer the package family name from the app’s icon or label.

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

2. Add the exemption and verify it

The command below retrieves the package name from the installed Microsoft Store package, avoiding manual entry. If the package isn’t found, the script stops instead of running a command with an empty argument.

$store = Get-AppxPackage -Name Microsoft.WindowsStore
if (-not $store) {
  throw "Microsoft.WindowsStore package not found for the current user"
}
CheckNetIsolation.exe LoopbackExempt -a "-n=$($store.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s

• -a: Adds a loopback exemption for the specified package.
• -n=: Specifies the app by package family name.
• -s: Lists the current loopback exemptions.

After running the command, check that the list includes the target app’s name or its corresponding SID. A non-empty list alone doesn’t confirm that the app you just added is there. If access is denied, make sure the terminal is elevated. If the command reports an invalid argument or package name, look up the package family name again rather than repeatedly trying the full package name.

3. Restart the app and check its connections

Close and reopen the app, then repeat the action that failed. Some apps keep background processes running after their windows close. Check Task Manager to make sure the target process has exited; if needed, save your work and end the app’s process. You usually don’t need to restart the entire computer just to add an exemption.

Also check Clash’s connection log for the target domain, matched rule, policy group, and actual node. If the connection appears but the page still fails, check routing, DNS, regional service requirements, or sign-in status. Adding more app exemptions won’t fix those issues.

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

Some Windows GUI clients include a “UWP Loopback,” “Loopback,” or similar option. It manages the Windows loopback exemption list; it isn’t a generic YAML field in Clash configuration, and not every mihomo client includes this tool.

A common location in the legacy Clash for Windows 0.20.x interface is Settings → System → UWP Loopback → Launch Helper. This path is included only to help identify an existing installation, not as a recommendation for choosing a new client. In other clients, check the settings for your current version. If there’s no such option, use the system command above.

1. Launch the loopback tool and grant administrator permission when prompted.
2. Find the package for the app that needs to access the local proxy.
3. Select the app and save your changes. If the tool has a refresh button, refresh the list after installing a new app.
4. Run CheckNetIsolation.exe LoopbackExempt -s to verify the updated system list.
5. Restart the app and check whether its connections reach the core.

Revoke loopback exemptions and keep troubleshooting notes

If you no longer use a local system proxy, or added an exemption temporarily to confirm the cause, you can revoke it for the affected app alone. The example below uses Microsoft Store and the same package family name as before.

$store = Get-AppxPackage -Name Microsoft.WindowsStore
if (-not $store) {
  throw "Microsoft.WindowsStore package not found for the current user"
}
CheckNetIsolation.exe LoopbackExempt -d "-n=$($store.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s

-d removes the exemption for the specified package. List the exemptions again afterward to confirm it’s gone. Avoid clearing the entire list; other apps or development environments may rely on existing entries. If the target app has been uninstalled, use its saved package family name or the SID in the list to identify the old entry. An app query that returns no results can’t provide the name.

• Before making changes, note the target app’s package family name and whether it’s already on the exemption list.
• Record the current proxy address, port, and active client configuration name so you can tell an exemption change from a configuration change.
• After testing, keep any exemptions you still need and revoke temporary ones individually.

TUN mode as an alternative: route traffic instead of granting loopback access

If an app doesn’t use the system proxy, a loopback exemption alone won’t make it use Clash. A mihomo client with TUN support can route IP traffic through a virtual network interface, bringing some apps that normally connect directly into rule processing. This differs from an app connecting to a local HTTP proxy, so with suitable routing and DNS settings, it can avoid relying on the local proxy port.

TUN isn’t a universal fix for every UWP network issue. If an app still uses the system proxy and tries to connect to a restricted loopback address, enabling TUN alone may not change the result. To isolate the cause, record your original settings, turn off the system proxy, and test with TUN only. First confirm that the client is actually capturing the target app’s traffic.

Test TUN in this order

1. Check whether the core supports TUN. mihomo and older Clash cores have different capabilities, so don’t rely on the client’s name alone.
2. Install the required service or grant administrator permissions as directed by the client, then confirm that the virtual network interface was created successfully.
3. Make sure auto-route is enabled, and inspect the final configuration generated by the client. Don’t combine multiple TUN configuration snippets from unknown sources.
4. Check that DNS requests reach the core as expected. DNS hijacking, system DNS, and an app’s built-in encrypted DNS may take different paths.
5. Temporarily exit other VPNs or traffic-capture software to reduce default-route conflicts, then test the app again.

The choice is straightforward: if the app follows the system proxy and the issue is loopback isolation, start with an exemption for that app. If it bypasses the system proxy or needs broader traffic capture, consider TUN. After switching to TUN, check the matched rules too: capturing a connection doesn’t mean it will use a proxy node.

Common outcomes and what to check next

Troubleshoot in this order: confirm the core is running and the port is listening; verify the system proxy address; determine whether AppContainer loopback isolation affects the app; add an exemption for that app; then check the connection’s rule and outbound route. Change one thing at a time to distinguish Windows connectivity issues from problems with your subscription, node, DNS, or rules.

For more on configuration, see the rule-based routing guide and core reference. For basic setup, see the proxy connection guide.