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

Typical symptoms include Clash running while the browser and traditional desktop apps work normally, but Microsoft Store, legacy Mail, Photos, Xbox, or other Store-installed apps connect directly, time out, or report that the network is unavailable. The proxy node and subscription are usually fine; the difference is Windows network isolation for AppContainer apps.

After most Clash GUI clients enable the system proxy, Windows is configured to use a local address such as the HTTP proxy 127.0.0.1:7890, or the same port configured as the mixed port. Standard Win32 programs can connect to this local listening address, but UWP apps isolated by AppContainer cannot access the local loopback interface by default, so their requests never reach the Clash core.

Narrow it down with four checks

  1. Confirm in the Clash client that the current configuration is enabled, then select a working policy.
  2. Open Settings or General and confirm that the system proxy is enabled.
  3. In Windows Settings → Network & internet → Proxy, confirm that the proxy address is 127.0.0.1 and that the port matches Clash’s current listening port.
  4. Test the desktop browser and the target Store app separately. A working browser alongside a failing target app is the typical pattern for loopback isolation.

The port is not always 7890. Clients using the mihomo core may use mixed-port: 7890, or the port may have been changed to 7891, 7897, or another available value. Use the port shown in the current configuration and the client’s settings page when diagnosing the issue.

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

Some Windows GUI clients include a loopback exemption manager. This is useful if you are unfamiliar with package family names or the command line. The tool still modifies Windows’ AppContainer loopback exemption list; rules already written to the system usually remain after the client exits.

Common entry points and workflow

Menu names vary slightly between clients. In classic Clash for Windows, the usual path is General → UWP Loopback → Launch Helper; other clients may place it under Settings → System Settings → UWP Loopback or Network Tools. Follow these steps:

  1. Close the UWP app being tested to prevent old connections and cached results from affecting the outcome.
  2. Start the Clash client normally and load a valid configuration.
  3. Open UWP Loopback or the loopback exemption tool. If Windows asks for permission, verify the program’s source and allow the management operation.
  4. Find the target app in the list, such as Microsoft Store, Xbox, or a specific Store app.
  5. Select the target app, then choose Save Changes or an equivalent button.
  6. Return to the client, confirm that the system proxy is still enabled, and restart the target app.

If the target app is not in the list

  • Launch the target app at least once first. Some packages appear only after registration is complete.
  • Confirm that the app came from Microsoft Store or was installed as an AppX or MSIX package. Ordinary Win32 programs do not need a UWP loopback exemption.
  • Restart the loopback tool so it reloads registered packages.
  • If the app is still not detected, use the PowerShell and CheckNetIsolation method below.

Some newer apps are installed from Microsoft Store but still run a regular desktop process internally; others include both a desktop process and AppContainer components. Being Store-installed does not automatically mean an app is affected by the loopback restriction, so check the actual process and test results.

Method 2: Add a precise exemption with CheckNetIsolation

CheckNetIsolation.exe is a Windows network-isolation management tool that can list, add, and remove AppContainer loopback exemptions. The command requires the target app’s Package Family Name, or PFN. A PFN is not the name shown in the Start menu or the installation directory.

Step 1: Find the app’s Package Family Name

Right-click the Start button and open Terminal (Admin) or Windows PowerShell (Admin). First, filter installed packages by app name. The following example searches for packages containing Xbox:

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

If you do not know the package name, list all AppX packages for the current user, then search for the target name in the terminal:

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

The output usually contains two columns. Copy the complete value under PackageFamilyName, such as the long string combining the name and publisher identifier. Do not copy PackageFullName, which usually also includes the version, architecture, and resource markers.

Step 2: Add the loopback exemption

Replace the example PFN in the command below with the value you found. The -a parameter adds an entry, and -n is followed by the package family name:

CheckNetIsolation LoopbackExempt -a -n="PackageFamilyName of the target app"

A successful command usually returns a completion message. Then list the current exemptions to confirm that the target package was added:

CheckNetIsolation LoopbackExempt -s

If the list is long, write the output to a text file first and search for the package family name:

CheckNetIsolation LoopbackExempt -s > "$env:TEMP\loopback-list.txt"
notepad "$env:TEMP\loopback-list.txt"

Step 3: Remove an exemption when needed

If the app no longer needs to connect to the local proxy, or the wrong package family name was added, use -d to remove the entry:

CheckNetIsolation LoopbackExempt -d -n="PackageFamilyName of the target app"

After removing it, run CheckNetIsolation LoopbackExempt -s again to confirm that the entry is gone. Changing exemptions usually does not require restarting Windows, but fully exit and reopen the target app so it creates a new connection.

Verify that requests actually reach Clash

Restored connectivity does not necessarily mean that requests are going through the current proxy. During verification, check the app’s behavior, Clash connection logs, and the system proxy status together so cached content is not mistaken for a successful fix.

Verification 1: Check Clash connection logs

  1. In the client, open Connections or the equivalent page.
  2. Clear the existing records, or note the current time.
  3. Fully close the target UWP app, reopen it, and trigger a network request.
  4. Check whether a new connection appears for a domain accessed by the app.
  5. Review the matched rule, policy group, and final node to confirm that the result matches your configuration.

If the target domain appears on the connections page, the request has reached the Clash core. If a connection exists but the page still will not open, check rule matching, DNS resolution, and node connectivity instead of repeatedly adding loopback exemptions.

Verification 2: Compare the system proxy toggle

Keep the target app fully closed. Test once with the Clash system proxy enabled, then once with it disabled. If a connection appears when enabled and disappears when disabled, while the app’s network behavior changes accordingly, the relationship is clear. Restore the original proxy setting when testing is complete.

Verification 3: Check the local listening port

In PowerShell, confirm that Clash is listening on the expected port. Assuming the mixed port is 7890, run:

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

The normal result shows the port in Listen state. If there is no result, the core is not listening on that port or the client is using another port. Even with a correct loopback exemption, the UWP app cannot connect to the proxy in that case.

Troubleshooting order when the exemption does not help

1. The system proxy port does not match Clash’s listening port

This is the most common follow-up issue. For example, the configuration specifies mixed-port: 7897 while the Windows proxy still points to 127.0.0.1:7890. Check the mixed port under the client’s Settings → Parameters, then verify the address and port under Windows Settings → Network & internet → Proxy.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

allow-lan controls whether devices on the local network can connect to Clash’s listening port; it does not fix the local UWP loopback restriction. Changing it to true solely for local app access is usually unnecessary.

2. The target app uses a different package

A single product may include a stable release, a beta, gaming service components, and a separate sign-in component. After exempting the main app, another AppX package may be the one actually making requests. Run Get-AppxPackage again, check related packages by product name, and verify each one against the Clash logs.

3. The app process did not fully exit

After you close the window, the app may remain running in the background. In Task Manager → Processes, end the corresponding task, wait five seconds, and start it again. If necessary, sign out of the current Windows user session so the AppContainer network state is rebuilt.

4. The rules send the request direct

A loopback fix only lets the request reach Clash; it does not change the rule result. If the connections page shows DIRECT, the domain or IP matched a direct-connection rule. Check the domain rules, rule-set order, and final match in the configuration instead of mixing a loopback issue with a proxy-rule issue.

5. DNS or TUN mode creates a second issue

After TUN mode is enabled, some clients take over more system traffic, but UWP behavior still depends on the client implementation, the Windows networking stack, and the current configuration. If system proxy mode works normally, switch to TUN for comparison. Do not change loopback, DNS, TUN, and rules at the same time, or it will be difficult to identify which change helped.

How loopback exemptions, the system proxy, and TUN relate

These three concepts operate at different layers. The system proxy tells programs that support proxy settings to send HTTP or HTTPS requests to a local port; a loopback exemption lets an isolated AppContainer access that local port; TUN mode uses a virtual network interface to take over a broader range of IP traffic.

  • System proxy: Best for browsers and apps that follow Windows proxy settings; a common target is 127.0.0.1:7890.
  • UWP loopback exemption: Resolves the problem of an AppContainer being unable to access the local proxy listening address; it does not select nodes or change rules.
  • TUN mode: Useful for programs that do not read system proxy settings and for broader traffic interception; it typically requires driver, service, or administrator support.

If only one or two UWP apps cannot use the enabled system proxy, start with precise loopback exemptions so the scope of change stays clear. Evaluate TUN mode only when many programs that ignore system proxy settings need to be routed. Before switching modes, keep the working configuration and record the mixed port, DNS, and rule mode for easy rollback.

Post-fix checklist

  • The Clash core is running and the configuration file loaded without errors.
  • The current node works, and the desktop browser can access the network with the same configuration.
  • The Windows system proxy address and mixed port match exactly.
  • The target UWP app’s Package Family Name has been added to the loopback exemptions.
  • The app was fully closed and restarted rather than reusing an old connection.
  • The Clash connections page shows domain requests generated by the target app.
  • The matched rule and policy are as expected; the request was not incorrectly assigned to DIRECT.
  • After testing, keep only the loopback exemptions that are actually needed.

After these checks, you can distinguish three types of failure: the app cannot connect to the local proxy; the request reaches Clash but the wrong rule is selected; or the node or DNS itself is unavailable. Verifying each link in order is more effective than repeatedly switching nodes or reinstalling the client.