Windows UWP Apps Not Using Your Proxy? How to Remove Clash Loopback Restrictions

UWP Loopback Restrictions: Browser Works, Store Apps Don't

After enabling the system proxy in a Windows Clash client, your browser can reach websites, but Microsoft Store or some UWP apps keep loading. Don't rush to change your subscription. A working browser only proves that its own proxy path works—it doesn't mean sandboxed apps can connect to the same local port.

UWP apps typically run in an isolated AppContainer. By default, these apps are restricted from accessing loopback addresses on the local machine. Clash clients commonly listen for HTTP or mixed proxy traffic on 127.0.0.1, and the system proxy directs app requests to that address. If an app reads the system proxy setting but its sandbox can't connect to the loopback port, the request may fail before it reaches the mihomo core, so there may be no corresponding entry in the logs.

First, distinguish the three layers

• System proxy: Tells apps that honor the setting to send requests to the local proxy; it doesn't take over traffic from every program.
• Loopback exemption: Allows a specified AppContainer to access the loopback network. It doesn't configure a proxy for the app or change Clash rules.
• TUN mode: Uses a virtual network interface and routing to capture eligible traffic, without relying on each app to read the HTTP system proxy setting.

Before you start: Check the listening port, system proxy, and rule matches

First, check the actual listening port in your client. The examples below use mixed-port: 7890; this is only an example, not a default for every client. If the interface shows a mixed port of 7897, use 7897 in the commands that follow. Don't confuse the controller port with the proxy port: external-controller is for managing the core, not for receiving regular HTTP proxy requests.

1. Make sure your subscription is loaded, the client is running, and a working proxy group node is selected.
2. In Windows 11, go to Settings → Network & internet → Proxy and check that the address and port under Manual proxy setup match the current client. In Windows 10, go to Settings → Network & Internet → Proxy.
3. Leave TUN off for now and enable only the system proxy to avoid interference from two traffic-capture methods running at once.
4. Test the local port in PowerShell, then check the proxy path with an explicit proxy request.

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head https://www.microsoft.com/

TcpTestSucceeded: True only means the desktop process running PowerShell can establish a local TCP connection; it doesn't mean the UWP sandbox has been granted access. The second command checks whether the HTTP proxy can handle an HTTPS tunnel. An HTTP response header means this test path received a response, but check the client logs to see which proxy node handled the destination connection.

Check the Connections or Logs page for the destination domain and policy. If the app's request appears and matches DIRECT, check the rules before adding a loopback exemption. Rules are evaluated in order, so domain rules near the top take precedence over the final MATCH rule. A loopback setting won't turn a direct-connection rule into a proxy rule.

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

Some Windows Clash clients include a loopback exemption tool. Its location varies by client and version, so look in Settings for terms such as “UWP,” “Loopback Unlock,” or “Loopback.” Use this method only if the option is actually available. If you can't find it, that doesn't mean the core lacks proxy support—you can use the system command in the next section instead.

1. Open the built-in loopback tool. If Windows displays a User Account Control prompt, verify the program's source before approving it; changing exemptions usually requires administrator privileges.
2. Find the affected app in the list, such as Microsoft Store. Select only the apps you need to troubleshoot; there's no need to enable access for the entire list.
3. Click Save or Apply in the tool. If changes take effect immediately, follow the instructions shown in its interface.
4. Exit the target app completely, then reopen it. If it continues running in the background after you close its window, end the relevant process in Task Manager and try again.
5. Repeat the operation that failed and check the Clash connection log. Then use the query command in the next section to confirm that the exemption was actually added.

These tools manage Windows' loopback exemption list; they don't modify your subscription. If the app still fails after saving, first check that you selected the right package and fully restarted the app. Don't rely on a checked box in the interface as your only confirmation.

Method 2: Add or remove an exemption for a specific app with CheckNetIsolation

CheckNetIsolation.exe is a built-in Windows network isolation diagnostic tool. Use it when your client has no built-in option, you need to check the current exemption status, or you want to grant access to just one app. Run add and remove commands in an elevated PowerShell session for the signed-in user. If you enter credentials for a different administrator account, make sure the app you find belongs to the intended user.

1. Find the package family name

Search for PowerShell in the Start menu and select Run as administrator. First, look up the package identity for Microsoft Store:

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

The command's PackageFamilyName value is what you need for -n=. Don't use PackageFullName, which includes version and architecture details, or the display name from the Start menu. To find another app, list the packages for the current user and search by Name:

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

2. Add the exemption and check the result

The command below retrieves the Microsoft Store package family name automatically, avoiding typos from manual copying. If the package isn't found, it stops with an error instead of passing an empty argument:

$store = Get-AppxPackage -Name Microsoft.WindowsStore
if ($null -eq $store) {
    Write-Error "Microsoft.WindowsStore package not found for the current user."
} else {
    CheckNetIsolation.exe LoopbackExempt -a "-n=$($store.PackageFamilyName)"
}
CheckNetIsolation.exe LoopbackExempt -s

-a adds an exemption, and -s lists the current exemptions. The output may show a package name or its AppContainer SID. To look up an SID, run Get-AppContainerProfile -Name *. After adding the exemption, exit Microsoft Store completely, reopen it, and try the original operation again.

3. Remove the exemption you added

$store = Get-AppxPackage -Name Microsoft.WindowsStore
if ($null -ne $store) {
    CheckNetIsolation.exe LoopbackExempt -d "-n=$($store.PackageFamilyName)"
}
CheckNetIsolation.exe LoopbackExempt -s

-d removes the specified entry. To roll back, remove only the change you made; don't clear all exemptions, as that could affect other apps. If an app is reinstalled, its package identity changes, or Windows is reset, check the current status again rather than relying on a previous successful command.

Method 3: Use TUN to capture traffic from apps that ignore the system proxy

If the target app doesn't read the system proxy setting, a loopback exemption won't make it connect to 127.0.0.1:7890 automatically. Consider using a client with mihomo TUN support: the app connects to the actual destination, and the virtual network interface captures its traffic. This changes how traffic reaches the core; it doesn't remove all Windows network isolation policies.

1. Turn off the system proxy first to prevent the app from continuing to connect to the local proxy port.
2. Follow the client's instructions to install or start its service mode, then enable TUN mode. Creating a virtual interface and setting routes in Windows usually requires appropriate permissions.
3. Temporarily exit other VPNs or virtual network adapter proxies. Keep a record of your existing settings, and don't delete system routes outright.
4. Fully restart the target app, then check its destination address, matched rule, and proxy group on the Connections page.
5. If no connection appears, continue troubleshooting TUN routes, DNS, and the app's network permissions. If a connection is logged, investigate the matched rule.

For users who manage mihomo configuration directly, here are some common TUN fields. Merge them into your existing configuration rather than replacing the entire subscription. If your client generates TUN settings in its interface, use that instead to avoid conflicts with runtime overrides and manual settings.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-route automatically sets traffic routes, while auto-detect-interface identifies the outbound interface. The dns-hijack setting applies to matching traditional DNS traffic; it doesn't capture all encrypted DNS. Also confirm that your existing dns configuration works and that your client and core support the selected network stack.

TUN isn't a universal fix for every Store app issue. AppContainer capabilities, organizational policies, an app's own proxy implementation, and background service behavior can still affect connectivity. If an app continues to connect explicitly to a local HTTP proxy, loopback restrictions may still apply. That's why it's important to turn off the system proxy and restart the app when testing TUN.

Choosing a method: Start with the narrowest change, then verify

First confirm that the local port is reachable, then add a loopback exemption for one target app. If no requests from the app reach the core, test TUN separately. Change only one setting at a time; otherwise, even if the connection starts working, it will be hard to tell which change fixed it.

Still can't connect? Continue troubleshooting based on what appears in the logs

No connection logged

• Make sure the app was fully restarted and that you changed the package used by the current user.
• Check whether the system proxy port changed after restarting the client, or whether another proxy program overwrote the Windows settings.
• Company- or school-managed devices may restrict loopback exemptions, virtual network adapters, or route changes. Follow your organization's device management policies.

Connection logged, but matched DIRECT

Loopback access is no longer the main suspect. Check the matched rule type, rule content, and selected policy group to confirm whether the domain should connect directly or through a proxy. Microsoft Store pages, sign-in, and downloads may use different domains and background services. Don't force every Microsoft domain to use the same policy just to fix one failure.

Proxy is working, but sign-in or downloads still fail

Identify exactly where the failure occurs: opening the Store homepage, signing in, retrieving a download URL, or downloading and installing the package. A working homepage doesn't mean downloads use the same network path. Next, check node connectivity, DNS results, system time, and certificate errors. Don't treat netsh winhttp reset proxy as a universal fix: WinHTTP settings and the current user's system proxy are separate configurations.

After troubleshooting, keep only the individual exemptions you need and revert temporary changes. If you only need one app that reads the system proxy to access the local proxy, a loopback exemption is usually easier to verify than leaving TUN enabled system-wide. If multiple programs ignore the system proxy, assess how TUN may affect system-wide routing and DNS.