Windows UWP Apps Not Using Your Proxy: Set Up or Remove Loopback Exemptions

Learn why Windows Store apps can’t access localhost by default, and how to grant UWP apps loopback access with a client tool or CheckNetIsolation.

Symptom: Your browser works, but one app can’t connect

Windows system proxy is enabled, and your browser can reach websites through the client, but a UWP app keeps showing a network error and no matching request appears in the client’s connection list. AppContainer network isolation may be the cause. The app tries to connect to a local proxy, such as 127.0.0.1:7890, but Windows blocks the connection before it reaches the mihomo core.

A loopback exemption addresses whether an isolated app can connect to a local service. It does not fix poor nodes, expired subscriptions, or proxy rules. Add an exemption only after identifying loopback access as the issue. Also, an app being distributed through the Microsoft Store does not necessarily make it a UWP app: traditional desktop and packaged Win32 apps may not be subject to the same restriction.

Loopback Addresses and AppContainer Network Isolation

127.0.0.1 is the IPv4 loopback address, and ::1 is the IPv6 loopback address. Traffic to either address stays on the current computer. The client binds an HTTP or mixed proxy port to a loopback address, and the app sends requests to that port for the mihomo core to match against rules and route outbound.

UWP apps typically run in an isolated AppContainer. Windows restricts these apps from accessing local loopback services, so an app may be unable to connect even when the system proxy points to localhost. The loopback exemption feature in CheckNetIsolation.exe can lift this restriction for a specific app container.

An exemption does not configure a proxy for the app or add network capabilities to its package manifest. If the app ignores the system proxy, uses its own networking components, or is restricted by an organization’s policies, address those issues separately.

Before You Start: Check the Proxy Port and Windows Settings

Check Which Port Is Listening

First, check the active configuration and port settings in your client. The 7890 port below is an example of a mixed port, not a universal default. If your port is 7897, use 7897 in both the commands and Windows settings that follow.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

This is a parameter example, not a complete configuration. Don’t use it to overwrite your existing subscription. To grant a local UWP app a loopback exemption, you don’t need to change the listening address to 0.0.0.0 or enable “Allow connections from the local network.” Remote subscription updates may also overwrite manually added parameters, so use your client’s persistent settings or override feature where possible.

Make Sure Windows Uses the Same Port

  1. In Windows 11, go to Settings → Network & internet → Proxy → Manual proxy setup → Set next to Use a proxy server. In Windows 10, go to Settings → Network & Internet → Proxy.
  2. Make sure the address and port match the ones used by your client. If the client manages the system proxy automatically, change it using the client’s controls to avoid the two settings overwriting each other.
  3. Run the following listener check in PowerShell. If it returns no results, start the core or correct the port before setting up an app exemption.
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/

Use curl.exe with an explicitly specified proxy to check whether the port can complete a request. An HTTP response confirms that this test connection was established; a timeout means you should check the node and logs. This command runs in a regular desktop process, so success does not prove that the UWP loopback restriction has been removed. The response alone also cannot confirm that traffic exited through the expected route.

Method 1: Use Your Client’s Built-In Loopback Exemption Tool

Some Windows clients include a loopback exemption tool. It may be labeled “UWP Loopback,” “Loopback,” or “Loopback Exemption.” The menu location varies by client and version, so don’t assume the path from an older release applies to every mihomo client.

If you’re using an older version of Clash for Windows, open the tool via General → UWP Loopback → Launch Helper. This client is no longer maintained; this path is provided only to help identify existing installations. Don’t install an old client just to access this menu. If your current client has no equivalent option, use the Windows command in the next section.

  1. Open the tool and approve an administrator prompt if required. Verify the publisher and program source; don’t run “fix” tools from unknown sources.
  2. Find the affected app in the app list and verify its package details. Don’t select an app based only on a similar display name.
  3. Select only the target app, then click the tool’s Save or Apply button. Selecting an app without saving usually does not add it to the exemption list.
  4. Fully exit and reopen the target app. If it keeps running in the background after the window closes, end its task in Task Manager before testing again.

A graphical tool typically just wraps the system exemption mechanism. After using it, verify the result independently with CheckNetIsolation.exe LoopbackExempt -s. If the app isn’t listed in the tool, first confirm that it’s installed for the current account and that it’s an app type covered by this feature.

Method 2: Add a Specific App with CheckNetIsolation

Open a Terminal as Administrator

Search for “Terminal” or “Windows PowerShell” in the Start menu, then select Run as administrator. The examples below use PowerShell syntax. If you authenticate as a different administrator account, check which user’s apps are being queried so you don’t mistake “not installed for this user” for “app not found.”

Find the PackageFamilyName

The -n argument for a loopback exemption takes the package family name, PackageFamilyName—not the desktop shortcut name or the version- and architecture-specific PackageFullName. First, list the packages installed for the current user:

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

The example below uses a Microsoft Store package to demonstrate filtering. To troubleshoot a different app, find its package in the list above and replace the filter. Don’t grant access to an unrelated app.

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

A common package family name is Microsoft.WindowsStore_8wekyb3d8bbwe, but use the value returned on your computer. If the query returns nothing, check the user scope and package name. Don’t guess based on a full package name found for another device online.

Add and Verify the Exemption

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

CheckNetIsolation.exe LoopbackExempt -s

-a adds an exemption, and -s lists existing exemptions. The output may include both the app container name and its SID; check that the target package is present. If access is denied, make sure the terminal is running as administrator. If the app container can’t be found, verify the package family name and installation status.

If you’ve identified the correct package with the query, you can pass it through a PowerShell variable to reduce copy-and-paste errors:

$app = Get-AppxPackage -Name Microsoft.WindowsStore
if ($null -ne $app) {
    CheckNetIsolation.exe LoopbackExempt -a "-n=$($app.PackageFamilyName)"
} else {
    Write-Output "The specified app package was not found for the current user."
}

Verify the Result: Separate Connectivity, Rules, and Routing

Keep the test conditions consistent: use the same network, configuration, and destination action. Open the client’s connection view, then refresh the page that fails in the app or try signing in. Don’t count cached content on the app’s home screen as a successful connection.

Observed resultLikely issue areaNext step
Target package is missing from the exemption listPermissions or package nameRerun the query and add the exemption from an elevated terminal
Target package is listed, but no connection appearsThe app isn’t using this proxy or hasn’t sent a requestRestart the app and check the system proxy and the app’s network settings
A connection appears with the DIRECT policyRule-based routingCheck the matched rule and confirm whether the traffic should use a proxy policy
The connection times out after entering a proxy policyNode, DNS, or destination networkCheck the core logs and the selected node’s status
The network request succeeds, but an account action still failsApp service or account regionCheck the service status, account, and error code

If the client shows process names, use them to identify the target app; otherwise, compare the request time and domain. If the logs show DNS, TLS, or authentication errors, troubleshoot that part of the connection rather than adding the same exemption again. Temporarily switching to Global mode can help determine whether rules are involved, but restore the original mode after testing.

How TUN Mode Relates to Loopback Exemptions

The system proxy gives a proxy address to apps that choose to use it. TUN mode instead captures matching traffic through a virtual network interface and routes. These are different ways of handling traffic. If an app ignores the system proxy, a loopback exemption won’t make it use a proxy automatically; consider the client’s TUN mode instead.

However, enabling TUN does not necessarily remove every AppContainer network restriction. If the app still connects directly to a restricted loopback port, that restriction must be addressed separately. TUN capture also depends on permissions, routes, DNS, interface exclusions, and interference from other VPN software.

Remove an Exemption and Maintain Your Setup

If the app no longer needs local proxy access, or you’ve confirmed that loopback isn’t the cause, you can remove the exemption you added. The example below uses the same package and removes only that exemption, leaving existing settings for other apps unchanged:

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

CheckNetIsolation.exe LoopbackExempt -s

-d deletes the specified exemption. List exemptions again afterward to confirm that the target entry is gone. Before troubleshooting, save the original list so you can distinguish the entry you add from settings already on the device.

Routine updates usually don’t require another exemption if the package family name stays the same. Query it again after reinstalling, changing distribution channels, or any change to the package identity. A minimal troubleshooting sequence is: confirm the port is available, identify the app type, exempt the target package, restart the app, then check connections and rules. Only investigate nodes, DNS, and account services further if connectivity works but the app still fails.

Download Clash