Windows UWP Apps Not Working with Clash Proxy? Why Loopback Restrictions Happen and How to Fix Them

First, confirm that the issue is caused by the UWP loopback restriction

A typical pattern is that browsers work normally through Clash, while Microsoft Store, Xbox, Photos, Mail, or other Store apps remain offline. The Microsoft account sign-in window may stay on its loading screen or show “Check your Internet connection.” After disabling Clash system proxy, those apps may work again through a direct connection.

This difference usually does not mean the proxy nodes are down. Traditional desktop programs can connect to a proxy port listening on the local machine, such as 127.0.0.1:7890. UWP apps running inside an AppContainer sandbox cannot access the local loopback address by default. Although the system proxy points to Clash, the app cannot complete the first-hop connection to the local proxy port.

Three signs that point to a loopback restriction

• Chrome, Firefox, and regular Win32 programs can access the internet, while only some Store apps fail.
• Clash system proxy is enabled, with the proxy address set to 127.0.0.1 and the common port 7890.
• When the failing app sends a request, no matching connection appears in Clash, and the logs show no domain match.

Rule out ordinary proxy problems first

1. Open the Clash client and confirm that the core is running, rather than failing to start or restarting repeatedly.
2. Go to “Settings” → “System Proxy” and confirm that the system proxy is enabled.
3. Check whether the current configuration provides an HTTP or Mixed listening port. With only a SOCKS listener, Windows system proxy cannot use it directly as a standard HTTP proxy.
4. Open a page in your browser that displays the public IP address and confirm that regular desktop programs are using the proxy.
5. Switch to another working node and test again to rule out a timeout on a single route.

Why UWP apps cannot connect directly to Clash on the local machine

UWP apps usually run inside an AppContainer isolation environment. Windows assigns each app a package identity, declared capabilities, and restricted network boundary. The loopback address 127.0.0.1 and IPv6 address ::1 point to the current computer, but sandboxed apps cannot use them by default to access a service provided by another local process.

Clash system proxy mode depends on a local listener. In a typical setup, Windows sends HTTP requests to 127.0.0.1:7890; Clash accepts the connection and then selects DIRECT, a proxy node, or another policy group according to its rules. When a UWP app connects to 127.0.0.1:7890, the Windows boundary blocks it, so rule matching never takes place.

mixed-port: 7890
allow-lan: false
mode: rule

The allow-lan: false setting controls whether other devices on the local network can access the listening port; it does not grant AppContainer loopback permission to UWP apps. Changing it to true cannot replace a loopback exemption and also expands LAN access. For local Store apps, change the Loopback Exempt status of the relevant app instead.

What a loopback exemption actually changes

An exemption adds the specified package to Windows’ loopback exception list, allowing it to connect to local services. It does not start Clash, choose a node for the app, or force all traffic through the proxy. The system proxy, Clash listening port, and rule mode must still be configured correctly.

Method 1: Allow apps individually with the client’s loopback tool

Some Windows Clash clients include a UWP Loopback tool. In the classic Clash for Windows interface, find it under “General” → “UWP Loopback.” Other maintained builds may place it under “Settings” → “Network” or “Tools”; the name usually contains “UWP,” “Loopback,” or “loopback.”

Steps in the graphical interface

1. Start Clash completely and confirm that the Mixed Port or HTTP Port is listening, commonly on 7890.
2. Open the loopback tool. If Windows asks for permission, verify the program’s source and allow it to apply the system configuration.
3. Wait for the tool to load installed AppContainer packages. The list usually shows both the app name and its Package Family Name.
4. Select only the apps experiencing network problems, such as Microsoft Store or Xbox. There is no need to select every package at once.
5. Click “Save Changes,” “Apply,” or the equivalent save button to write the exemption list to Windows.
6. Exit the failing app completely, then relaunch it from the Start menu. Minimizing the window may leave its old network process running.
7. Keep Clash system proxy enabled, then retry the sign-in, download, or page refresh.

Why adding apps one at a time is recommended

Allowing packages individually makes changes easier to undo and helps identify the package that is actually affected. Some system components call a separate identity service package only during account verification, so allowing just the foreground app may not fix sign-in. Watch which window shows the failure, then add the relevant Microsoft Account, Xbox Identity Provider, or system identity component.

After an app update, its Package Family Name usually remains stable, so routine version upgrades normally do not require repeating the setup. If the app is uninstalled and reinstalled, moved to another release channel, or assigned a new package identity, the old exemption may no longer match the installed package and should be checked again.

Method 2: Configure exemptions precisely with CheckNetIsolation

Without a graphical tool, use Windows’ built-in CheckNetIsolation.exe. The command-line method is useful for reviewing the current list, documenting changes, and handling packages whose names are displayed incorrectly by a tool. Search for “Terminal” from the Start menu and choose “Run as administrator.”

Step 1: Find the app’s package family name

Run the following command in PowerShell to list app names and Package Family Names:

Get-AppxPackage | Select-Object Name, PackageFamilyName

If the list is long, filter it by name. The example below searches for Microsoft Store:

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

A common Microsoft Store package family name is Microsoft.WindowsStore_8wekyb3d8bbwe. Use the command output from the current PC as the source of truth; do not guess the package family name from the display name.

Step 2: View existing loopback exemptions

CheckNetIsolation.exe LoopbackExempt -s

The output lists AppContainers that already have loopback access. Running the query first avoids duplicate entries and records the original state before changes. If the target package is already listed, the problem is more likely that the system proxy is disabled, the port does not match, the app ignores the system proxy, or Clash rules are incorrect.

Step 3: Add the specified app

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

-a means add, and -n must be followed by the complete Package Family Name. After the command succeeds, run -s again to confirm that the target package is listed. Then terminate and reopen the app; a full computer restart is not necessary for a one-off change.

To undo the change, remove a single entry

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

-d removes the exemption for the specified package only. During troubleshooting, do not clear the entire list, because other local development tools or system apps may rely on existing exceptions. Keep the before-and-after query results so you can restore the previous state when troubleshooting is complete.

Verify that the exemption is actually working

A successful command only means that Windows accepted the configuration. You must also confirm that the app’s requests are reaching Clash. Watch the listening port, the app’s behavior, and Clash connection records together so a node switch or temporary network recovery is not mistaken for a successful exemption.

Check whether Clash is listening on the expected port

Run this in Windows Terminal:

netstat -ano | findstr :7890

Normally, you should see 127.0.0.1:7890, 0.0.0.0:7890, or the corresponding IPv6 address in LISTENING state. If the configuration uses mixed-port: 7891, the system proxy must also point to 7891. If the port numbers differ, the app will still fail even when loopback permission is correct.

Watch requests in the Clash connections panel

1. Clear or pause the old connections, and note the current time.
2. Relaunch the target UWP app.
3. Perform a repeatable action, such as refreshing the Store home page, searching for an app, or opening the account sign-in page.
4. Check the Connections panel for a new domain, destination IP, and matched rule.
5. If the request appears but times out, switch nodes or check the relevant policy group.

Six checks if the app remains offline after adding an exemption

1. The system proxy port does not match the Clash configuration

The Clash configuration may have changed from 7890 to 7897, while Windows proxy settings still use the old port. Go to “Settings” → “Network & internet” → “Proxy” and check the current manual proxy address; also compare it with the Mixed Port or HTTP Port shown by the client. If the client manages the system proxy automatically, turn it off and back on once.

2. Only the foreground app was allowed; identity components are still restricted

Microsoft account sign-in may call a separate identity broker, Xbox Identity Provider, or Windows Web Account Manager component. The Store home page may load while the sign-in button spins indefinitely, indicating that the core Store package is allowed but another package in the authentication flow is not. Test packages one at a time based on the window name and package list; do not repeatedly add the same Store package.

3. The app has not created a new network process

Closing the window does not always end a UWP background task. Open “Task Manager” → “Processes,” end the target app and related processes, then launch it from the Start menu. If the old state persists, sign out of the current Windows account and sign back in.

4. The app does not use the Windows system proxy

A loopback exemption only permits local access; it does not force an app to read the system proxy. Some apps use a custom network stack, hard-coded direct connections, or specialized UDP traffic that system proxy mode cannot cover. In the client, you can enable TUN mode based on the mihomo core so traffic enters the core through a virtual network interface.

The path is usually “Settings” → “TUN Mode.” After enabling it, confirm that the client has permission to create a virtual network adapter and check that the corresponding interface appears in Windows. TUN and system proxy use different traffic paths, so save the current configuration first and avoid changing the port, DNS, and rules at the same time.

5. DNS or rules send the request through the wrong route

Once the connection appears in the Clash panel, the loopback issue is essentially resolved. Next, check the matched rule and policy group. For example, an account domain may be sent to DIRECT even though the current network cannot reach it directly; or an abnormal DNS response may cause handshake failures, timeouts, or repeated retries. Adjust rules for the actual domain shown in the logs instead of adding more loopback entries.

6. Another program is using the port

If netstat shows that 7890 is occupied by another PID, Clash may not have bound the port successfully. Find the process by PID on Task Manager’s “Details” tab, or change mixed-port to an unused port such as 7897, reload the configuration, and update the system proxy accordingly.

Stable configuration recommendations

Keep only the packages you actually need. Record the target app’s Package Family Name, Clash listening port, and change date so you can restore the setup quickly after reinstalling Windows or switching clients. When an app is no longer needed, remove its entry with CheckNetIsolation.exe LoopbackExempt -d.

For everyday use, choose a fixed Mixed Port such as 7890 and let the client manage the system proxy. Do not change the core, subscription, DNS mode, port, and TUN settings all at once while troubleshooting. Change one thing at a time and confirm the result through an app restart, the connections panel, and the listening-port status.

The final test is straightforward: the target app can sign in or load content, the Clash connections panel shows the corresponding request, and the matched rule is the one you expect. Together, these confirm a complete path from the UWP app to the local proxy port, through the Clash core, and out to the remote destination.