Windows UWP Apps Not Using Your Proxy? Fix Local Connections with a Loopback Exemption

First, check whether this is a loopback restriction

If your browser works but a Windows app keeps showing a network error, don't switch subscriptions just yet. With the system proxy enabled, Clash clients typically direct apps to a local proxy port, such as 127.0.0.1:7890. Some UWP apps running in an AppContainer are subject to network isolation and can't access this local endpoint the way a standard desktop app can.

A loopback exemption addresses one specific issue: whether an app can connect to a proxy on your PC. It won't import a subscription, fix dead nodes, or automatically route the app through the proxy. Check that the symptoms below match before changing the exemption list.

• The Clash core is running, and your browser can reach the target site through the same system proxy.
• The system proxy points to 127.0.0.1 or localhost, and its port matches the one configured in the client.
• Only one AppContainer app is affected, rather than all your software losing network access.
• After reopening the affected app and making a request, nothing appears for it on the client's Connections page. Treat this as a troubleshooting clue, not proof on its own.

How 127.0.0.1, the system proxy, and AppContainer work

127.0.0.1 is the IPv4 loopback address, pointing to this PC; its IPv6 equivalent is ::1. Clash can listen on a loopback interface for an HTTP or mixed proxy port so apps on the same PC can connect to it. When the system proxy is enabled, only apps that honor Windows proxy settings will try to connect.

AppContainer gives an app an isolated network boundary. By default, ordinary UWP apps can't freely access local loopback services. Network isolation can block a connection even when the proxy port is open. A loopback exemption allows a specific app package to use this kind of local connection; it doesn't grant unrestricted network access.

Don't change the listen address to 0.0.0.0 or enable “Allow connections from LAN” just to fix a loopback issue. This changes who can reach the proxy; it doesn't remove the app sandbox restriction. If only this PC needs access, keep the proxy bound to loopback.

Check the proxy port and Windows settings

Check both port settings

1. Open “Settings” in the client and look for “Port,” “Mixed Port,” or mixed-port. Labels vary by client; use the value in the active configuration.
2. In Windows 11, go to “Settings” → “Network & internet” → “Proxy” → “Manual proxy setup” → “Edit” next to “Use a proxy server.” In Windows 10, go to “Settings” → “Network & Internet” → “Proxy.”
3. Make sure the address and port match. If the client's mixed port is 7897 but the system proxy still uses 7890, correct the port before investigating UWP.

7890 and 7897 are common examples, not fixed defaults for every client. The HTTP system proxy must point to a listener that supports HTTP. Don't enter a SOCKS-only port in the HTTP proxy field.

Check the local listener with PowerShell

This example assumes the active port is 7890. Start the client, then run this in PowerShell:

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890

Check the output for TcpTestSucceeded. A value of True means this PowerShell process can establish a TCP connection; it doesn't mean a UWP app has permission or that a remote node is working. If the value is False, check that the core is running, the port is correct, and local security software isn't blocking the listener.

Method 1: Use the client's loopback exemption tool

Some clients include a graphical tool for managing loopback exemptions. For example, the discontinued Clash for Windows had a helper in older versions under “Settings” → “UWP Loopback” → “Launch Helper.” This is a reference for the legacy client, not a menu shared by Clash Verge Rev or other mihomo clients.

1. Close the affected app first so it won't keep using an old connection. End it from the background as well before testing again.
2. Open the loopback exemption tool in the client. If Windows User Account Control prompts you, verify the tool's source before granting permission.
3. Find the affected app in the list. Its display name may differ from its Store listing; check the package name if needed.
4. Select only the apps that need to access the local proxy, then click “Save Changes” or the tool's save button.
5. Restart the app, refresh its content or sign in, and watch the client's Connections and Logs pages.

If the app isn't listed, first make sure it's installed for the current Windows user. A tool launched under a different administrator account may show a different set of apps. Don't mistake an account mismatch for a subscription or node problem.

Method 2: Add an exemption with CheckNetIsolation

List existing exemptions and identify the app package

Search the Start menu for “Windows PowerShell,” then select “Run as administrator.” These commands work on Windows 10 and Windows 11. Organization policies may restrict changes on managed devices; follow your organization's device management requirements.

CheckNetIsolation.exe LoopbackExempt -s

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

The first command lists existing exemptions; the second lists app packages for the current user. Use PackageFamilyName when adding an exemption, not PackageFullName. A full package name usually includes version and architecture details, while the family name identifies packages in the same app family.

Add an exemption using an installed package

This example uses the package name Microsoft.WindowsCalculator to demonstrate how to find and grant an exemption; it doesn't mean Calculator needs a proxy. For troubleshooting, find the target app in the list above and replace the search name with its exact Name. The script proceeds only if it finds a single package, preventing mistakes caused by an empty or ambiguous result.

$packages = @(Get-AppxPackage -Name 'Microsoft.WindowsCalculator')

if ($packages.Count -eq 1) {
    $family = $packages[0].PackageFamilyName
    Write-Output "Preparing to add loopback exemption for: $family"
    CheckNetIsolation.exe LoopbackExempt -a "-n=$family"
} else {
    Write-Warning 'Could not find a unique app package. Check the current user and package name.'
}

LoopbackExempt -a adds an exemption; pass the package family name after -n=. Once the command completes, run the query again. Don't assume it worked just because the terminal showed no obvious error:

CheckNetIsolation.exe LoopbackExempt -s

Make sure the target package family appears in the list, then close and reopen the app. If the command fails, keep the full error message. Insufficient permissions, a missing app package identity, and device policy restrictions each require a different fix; switching proxy nodes repeatedly usually won't help.

Verify the result: troubleshoot loopback, rules, and nodes separately

After adding the exemption, keep the proxy port and node unchanged and test the same app with the same action. Change one variable at a time to pinpoint what fixed the issue. Check the results in this order:

1. Check the exemption list. Run CheckNetIsolation.exe LoopbackExempt -s and confirm the target package is still listed.
2. Check whether the request reaches the core. Open “Connections” in the Clash client, then refresh the app. Some connections may not show a readable process name, so check the target domain, address, and time of the request.
3. Check which rule matched. If the request appears, see whether it uses DIRECT or a proxy group. If the app still can't connect, check the policy, node, DNS, and target service status.
4. Check the error logs. Connection timeouts, DNS lookup failures, and remote connection refusals shouldn't all be blamed on UWP loopback restrictions.

Exemption added, but no requests appear. Why?

The app may not use the Windows system proxy, may send requests from a helper process, or may not use a UWP network path affected by this restriction. A loopback exemption won't configure a proxy for any of these cases. Check whether the app has its own proxy settings, then decide whether TUN mode is appropriate.

Can TUN mode replace a loopback exemption?

In mihomo clients, TUN mode can route traffic through a virtual network adapter and send some apps that don't support the system proxy through the core. This may change how an app connects if it originally used direct sockets. But an app that reads the system proxy and tries to connect to a local port may still hit a loopback restriction. Enabling TUN isn't a universal fix.

Before testing TUN, make sure the client has any required service mode or administrator permissions, and note the original setting. Don't change the system proxy, TUN, DNS mode, and rules at the same time. Other VPNs, virtual adapters, and security software on Windows can also affect routing; compare them one at a time rather than disabling the firewall outright.

Remove loopback exemptions and maintain them

You can remove an exemption when an app no longer needs access to the local proxy or when you added it only to test a suspected issue. The example below uses the Calculator package; in practice, look up the package you originally added.

$packages = @(Get-AppxPackage -Name 'Microsoft.WindowsCalculator')

if ($packages.Count -eq 1) {
    $family = $packages[0].PackageFamilyName
    CheckNetIsolation.exe LoopbackExempt -d "-n=$family"
} else {
    Write-Warning 'Could not find a unique app package. Check the item you want to remove.'
}

CheckNetIsolation.exe LoopbackExempt -s

-d removes only the specified entry. Don't clear the entire list to remove one app; other apps may rely on local services. If the app has been uninstalled and its package can no longer be found, check the saved exemption list to confirm its identity, then remove that package family specifically.

• Routine updates usually keep the same package family, so you don't need to add the exemption again each time. Check it again after reinstalling, switching distribution channels, or changing Windows users.
• Record the affected app, actual proxy port, behavior before and after the exemption, and error type in the client logs to make the issue easier to reproduce.
• Before sharing logs, remove subscription URLs, access tokens, and other account details. You don't need to share a full subscription link to troubleshoot a loopback restriction.