Windows UWP Apps Not Working with Clash: How to Remove Loopback Restrictions

Why loopback restrictions affect only some Windows apps

A loopback address points back to the current computer. Once Clash starts a local proxy port, an app first connects to that local port; the proxy core then selects DIRECT, REJECT, or a proxy policy group according to the rules. From the app's perspective, the first connection is to a local proxy service, not directly to the destination website.

UWP apps and some AppContainer-isolated components have their own network capability boundaries. By default, Windows restricts these containers from accessing the local loopback interface to reduce unauthorized communication between isolated apps and local services. Although the system proxy records the local proxy address, it does not automatically grant loopback access to every AppContainer app. Therefore, seeing the proxy enabled in Settings does not mean every Store app can connect to Clash's listening port.

Common symptoms

• Microsoft Store, online features in Calculator, weather apps, or other Store apps report that they cannot connect.
• Win32 programs such as Chrome, Firefox, and traditional desktop clients can access the internet normally.
• When the affected app refreshes, its requests to the destination domain do not appear in the Clash log.
• The app may reconnect directly when the system proxy is disabled, then fail again after the proxy is enabled.
• The same app works normally on another computer where loopback exemptions have already been configured.

Not every app installed from the Microsoft Store is necessarily affected. Some Store packages are simply packaged traditional desktop programs, while others use different networking components. Base troubleshooting on the app's package identity, actual logs, and connection behavior rather than its installation source alone.

Check the Clash listener and system proxy before making changes

A loopback exemption only fixes the permission issue that prevents an AppContainer from reaching the local proxy port. If Clash is not running, the port does not match, or the system proxy points to an old port, adding an exemption will not restore connectivity. Complete these basic checks in order first.

1. Confirm that the proxy core is running. Open the Clash GUI client currently in use and verify that the configuration is loaded and that the proxy node or policy group can complete a latency test.
2. Confirm that the system proxy is enabled. The “System Proxy” switch in the client should be on. If you use manual settings, the Windows proxy address must match the HTTP or mixed-port shown by the client.
3. Confirm that no other process is using the port. If the client repeatedly fails to start or the log reports a listening error, close the process occupying the port or choose another port first.
4. Watch the connection log. Open a webpage in a desktop browser that works normally and confirm that Clash records the connection. Then operate the affected app and check whether new requests appear.
5. Temporarily rule out the configuration rules. If requests from the affected app already appear in the log, the problem is more likely related to rule matching, the policy group, DNS, or the node—not loopback restrictions.

You can inspect the current user's Internet proxy settings in PowerShell. This command is read-only and does not change anything:

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" |
  Select-Object ProxyEnable, ProxyServer, AutoConfigURL

When ProxyEnable is enabled and ProxyServer points to a local address, the manual system proxy has been set. Some clients may use a PAC script, so check AutoConfigURL as well. Windows WinHTTP proxy settings are separate from the current user's Internet proxy; do not judge whether the Clash system proxy is working solely from netsh winhttp show proxy.

Identify the UWP app's package family name

CheckNetIsolation requires the Package Family Name, not the display name shown in the Start menu and not the Package Full Name with its complete version number. Using the wrong field may prevent the command from applying to the target app.

Query it with PowerShell

Using Windows Calculator as an example, open PowerShell and run:

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

The output's PackageFamilyName may look like Microsoft.WindowsCalculator_8wekyb3d8bbwe. Values differ by app, so use the result returned on your computer. If you do not know the package name, list the apps installed for the current user and sort them by name:

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

When many apps are installed, narrow the results with part of the name. For example, to find Microsoft Store:

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

Avoid confusing the two package identifiers

If the computer has multiple Windows users, run the query from the account that actually runs the app. Some packages are installed only for a specific user, so the apps found from an administrator account may not exactly match those in the everyday account.

Add a loopback exemption with CheckNetIsolation

Once the target app and Clash's basic connectivity are confirmed, use Windows' built-in CheckNetIsolation.exe to manage AppContainer loopback exemptions. Close the target app first, then open PowerShell or Windows Terminal as an administrator.

Grant access to a single app

The following PowerShell command retrieves the Calculator package and passes the Package Family Name found on this computer to the system tool:

$pkg = Get-AppxPackage -Name "*WindowsCalculator*"
CheckNetIsolation.exe LoopbackExempt -a -n="$($pkg.PackageFamilyName)"

If the query returns multiple packages, do not run the command against all of them immediately. Inspect each Name and PackageFamilyName, confirm the target, and then add it. You can also place a verified Package Family Name directly in the command:

CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.WindowsCalculator_8wekyb3d8bbwe"

-a adds an exemption, while the value after -n is the Package Family Name. When the command finishes, fully exit and reopen the target app. Closing its window may not stop the background process, so confirm in Task Manager that the app has stopped.

View the current exemption list

CheckNetIsolation.exe LoopbackExempt -s

The list confirms whether the exemption was written and can reveal settings left behind by earlier troubleshooting. Its output may use system identifiers rather than the Start menu name, so cross-check it against the PowerShell query results.

Verify the proxy, rules, and DNS after granting access

A successful loopback exemption only means the app can attempt to connect to the local proxy. It does not guarantee that the rest of the proxy path is correct. Verify the app, Clash logs, rule matching, and destination service step by step.

1. Restart the target app. Try signing in, refreshing, or loading content again, and note whether the error message changes.
2. Check the Clash log. If the target domain or connection entry now appears, the app can reach the local proxy port.
3. Inspect the matched rule. Confirm that the request enters the expected policy group instead of being blocked by REJECT, an incorrect domain rule, or an inappropriate DIRECT rule.
4. Switch to a working policy. Select a confirmed working node in the policy group so that a node failure is not confused with a loopback permission issue.
5. Check DNS. If the log shows a domain-resolution failure, inspect the Clash DNS configuration, system DNS, Fake IP compatibility, and whether the app uses a special resolution method.

If connection entries now appear but the app still reports a failure, temporarily switch to a simpler configuration for comparison. The goal is not to bypass routing permanently, but to determine whether the problem is in the rules or the app. Restore the original configuration afterward and adjust rules for the actual domains involved.

Some apps contact separate services for authentication, content delivery, telemetry, or certificate status. Allowing only the main domain may not be enough. Use the logs to identify the complete set of requests instead of guessing domains by name. For Windows services that need a direct connection, create explicit DIRECT rules; domains that need the proxy should go to the appropriate policy group.

System proxy vs. TUN mode

The system proxy depends on an app actively reading Windows proxy settings and connecting to the local HTTP or mixed port exposed by Clash. UWP loopback restrictions affect this connection stage. TUN mode takes over a broader range of traffic through a virtual network interface, so it may also cover apps that do not follow system proxy settings.

TUN is not a universal replacement for loopback troubleshooting. It also involves administrator privileges, a virtual adapter, routing, DNS interception, firewall rules, and compatibility with other VPN software. If the goal is simply to let a few UWP apps use the existing system proxy, a precise loopback exemption is usually easier to verify. If many apps ignore the system proxy and you understand the routing and DNS implications, consider TUN mode supported by the mihomo core.

Layered troubleshooting when connectivity still fails

Clash logs show no requests at all

Run the exemption-list command again and confirm that the target package is present. Then check whether the app belongs to a different package, whether an update changed its package identity, and whether the current user matches the account used to query the package information. Also verify that the system proxy really points to a loopback address and that the app has not bypassed the system proxy.

Requests appear in the log, but the connection times out

This usually means the loopback stage is working. Next, check node connectivity, policy-group selection, the destination port, and the network environment. A desktop browser can access the same service as a comparison, but remember that the browser and the app may contact different sets of domains.

The log shows DIRECT, followed by failure

Check the rule order. Clash matches rules in the order listed in the configuration, so a broad DIRECT rule may match before the intended target rule. Keep the rule meanings clear when editing, and make sure the list ends with a sensible final policy, such as a policy group for MATCH.

Still not working after enabling TUN

Check that TUN actually started, whether another VPN or security product rewrote the routing table, and whether DNS requests are entering the expected resolution path. Do not run multiple tools that create virtual network adapters at the same time. If disabling other network tools fixes the issue, routing priority or a driver conflict is the more likely cause.

Microsoft Store can browse but cannot download

The Store page and app-package downloads may use different services. In addition to checking Clash rules, verify the status of Windows Update, Background Intelligent Transfer Service, and related system services. A loopback exemption only affects a container's access to the local machine; it does not repair disabled system services, account authorization, or the Store cache.

Revoke loopback exemptions and restore settings

When an app no longer needs to use Clash, has been uninstalled, or troubleshooting shows that loopback is unrelated, revoke its exemption. Removing -d from the command means delete:

$pkg = Get-AppxPackage -Name "*WindowsCalculator*"
CheckNetIsolation.exe LoopbackExempt -d -n="$($pkg.PackageFamilyName)"

You can also use a verified Package Family Name:

CheckNetIsolation.exe LoopbackExempt -d -n="Microsoft.WindowsCalculator_8wekyb3d8bbwe"

Run CheckNetIsolation.exe LoopbackExempt -s again after revoking the exemption to confirm that the target entry is gone. Then restart the app and verify its network behavior. If you changed the system proxy, Clash port, DNS, rule mode, or TUN switch during troubleshooting, restore each item rather than only deleting the loopback exemption.

Troubleshooting details worth recording

• The target app name and Package Family Name.
• The Clash core, listening port, and proxy mode in use.
• The difference between the logs before and after adding the exemption.
• The matched rule and policy group for each request.
• Whether TUN, another VPN, or network-filtering software is enabled.
• The final fix and the command used to revoke it.

These notes help distinguish between “the app cannot reach the local proxy” and “the proxy received the request but the subsequent connection failed.” Check AppContainer and loopback permissions for the former; check rules, DNS, nodes, and the destination service for the latter. Tracing each layer of the connection is usually faster than repeatedly reinstalling the client or changing subscriptions.