Windows UWP Apps Not Working with Clash Proxy: 2 Ways to Remove Loopback Restrictions

First, check whether this is a UWP loopback restriction

If your browser works normally through Clash but Microsoft Store, Xbox, some mail, or streaming apps keep reporting connection failures, the issue is often not a dead proxy node but Windows AppContainer network isolation. UWP apps typically run inside an AppContainer sandbox and cannot freely connect to local loopback addresses such as 127.0.0.1 or localhost.

Clash, Clash Meta (now known as mihomo), and their graphical clients usually listen on a local proxy port. For example, the mixed port mixed-port: 7890 maps to 127.0.0.1:7890. With the system proxy enabled, regular desktop programs can connect to this address, while restricted Store apps may not—resulting in the familiar “websites work, Store apps are offline” split.

Typical signs of a loopback issue

• Edge, Firefox, or regular desktop software can access external sites through the proxy.
• Microsoft Store stays on the loading screen for a long time or says it cannot connect to the network.
• Xbox, Feedback Hub, legacy Mail, and other packaged apps fail to connect.
• The app connects directly when Clash system proxy is disabled, then fails again when it is enabled.
• Clash logs show no connection attempts from the affected app.

Check the local proxy port first

Open the client’s “Settings” → “Port Settings” or “Settings” → “Mihomo Configuration” and confirm whether the active port is HTTP, SOCKS, or mixed. A common value is 7890, but it may also be 7897, 7899, or a custom port. The address in Windows system proxy settings must match the port the client is listening on.

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

mixed-port means that one port accepts both HTTP and SOCKS connections. allow-lan controls whether devices on the local network can access the proxy; it is separate from local UWP loopback permission. Setting it to true does not replace a loopback exemption.

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

The built-in graphical tool is the easiest option for most users. It usually lists installed AppContainer apps and calls Windows system APIs to add loopback exemptions after you select them. Menu names vary slightly between clients, but the core workflow is the same.

Common menu paths

• Clash Verge Rev 2.x: Open “Settings” → “System Settings” and look for “UWP Loopback” or “Loopback”.
• Clients with the classic interface: Open “General” and click the launch button beside “UWP Loopback”.
• Some mihomo clients: Open “Settings” → “Network” and look for “Remove UWP Loopback Restriction”.

If your current client has no such entry, that does not mean the mihomo core lacks proxy support. Loopback exemptions are Windows permission settings, normally handled by a graphical tool or system command rather than a field in the proxy core’s configuration file.

Step-by-step

1. Keep the Clash client running and make sure the system proxy is enabled.
2. Open the client’s UWP loopback tool and wait for the app list to finish loading.
3. Find the app that needs proxy access, such as Microsoft Store or Xbox.
4. Select the target app; there is no need to select every entry at once.
5. Click “Save”, “Apply”, or “Remove Restriction”. Approve the permission prompt if Windows displays one.
6. Fully close the target app and open it again. Merely minimizing the window usually does not recreate its network process.

Which apps should you select?

Granting access only where needed makes troubleshooting easier than selecting everything. Start with the app that is failing, save the change, and test immediately. If Microsoft Store works but another app still fails, add an exemption for the second package. This shows which change fixed the issue and makes future rollback easier.

Method 2: Add a precise exemption with CheckNetIsolation

CheckNetIsolation is a built-in Windows command-line tool for viewing, adding, and removing AppContainer loopback exemptions. It is useful when the client has no built-in option, its graphical list fails to load, or you need a clear record of every change.

The key parameter is the Package Family Name, commonly abbreviated as PFN. It is not the app title shown in the Start menu or the installation directory name. If the package family name is wrong, the command may not affect the intended app.

Step 1: Find the package family name

Right-click the Start menu and open “Terminal (Administrator)” or “Windows PowerShell (Administrator)”. To query Microsoft Store, run:

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

The output commonly looks like this; the actual suffix depends on the publisher identifier:

Name                   PackageFamilyName
----                   -----------------
Microsoft.WindowsStore Microsoft.WindowsStore_8wekyb3d8bbwe

If you do not know the internal name, filter all packages by a title keyword:

Get-AppxPackage |
  Where-Object {
    $_.Name -like "*Store*" -or
    $_.PackageFamilyName -like "*Store*"
  } |
  Select-Object Name, PackageFamilyName

Step 2: Add the loopback exemption

After confirming the package family name, run this in an elevated terminal:

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

The LoopbackExempt parameter manages loopback exemptions, -a adds one, and the package family name follows -n. After the command completes, close Microsoft Store, confirm in Task Manager that its related processes have exited, and then launch it again.

Step 3: View the current exemption list

CheckNetIsolation.exe LoopbackExempt -s

If the target package name or security identifier appears in the list, the exemption was written successfully. If the command succeeds but the app still cannot connect, continue checking the system proxy port, Clash logs, and matched rules.

Remove the exemption when you need to roll it back

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

-d deletes an exemption. Restart the app after removing it. Windows updates or app reinstalls can change package registration; if the issue returns, query the PackageFamilyName again instead of reusing an old command.

Verify that app traffic is actually reaching Clash

An app loading again does not necessarily mean its traffic is using the proxy as intended. Some requests may bypass the proxy, and cached content can make a page appear normal. A more reliable check combines Clash connection logs, rule matches, and the exit address.

Watch live connections

1. Keep Clash in “Rule” mode.
2. Open the client’s “Connections” page.
3. Clear all filters and note the current connection count.
4. Fully close the target UWP app, reopen it, and refresh its content.
5. Check for new domain names, destination IPs, processes, or policy-group entries.

For example, after opening Microsoft Store, the Connections page should show requests related to Microsoft services along with the matched rule and final policy. Domains vary by Windows version, region, and account status, so do not rely on a single fixed domain as your only test.

Temporarily cross-check with Global mode

If the app still fails in Rule mode, briefly switch to “Global” mode and select a working node. If the app recovers in Global mode, the loopback connection is working and the remaining issue is more likely rule matching, DNS, or node reachability. Switch back to “Rule” mode after testing to avoid sending all traffic through one policy indefinitely.

Compare three outcomes

Five things to check if you still cannot connect

1. The system proxy port does not match mixed-port

Assume mihomo is listening on 127.0.0.1:7890 while the Windows system proxy still points to the old port 7897. Even with loopback permission, the app cannot connect. In Windows 11, open “Settings” → “Network & internet” → “Proxy” and check whether the manual proxy is being managed correctly by the client.

It is usually best not to enter a Windows proxy manually while also enabling the client’s system proxy switch. The two settings can fall out of sync after a restart or port change. Let the current client manage the proxy, and toggle the system proxy off and on once after changing the port.

2. The client did not start the core successfully

Check the client home page or logs to confirm that the mihomo core is running. If the logs show a port conflict, close the process using the port or change mixed-port from 7890 to another free port, then refresh the system proxy settings.

netstat -ano | findstr :7890

The last column of the command output is the process PID. Use the “Details” tab in Task Manager to locate it by PID. Do not terminate an unfamiliar system process; first confirm whether it belongs to another proxy client or a previous core instance that did not exit cleanly.

3. Rules send Microsoft services to an unavailable policy

A loopback exemption only determines whether an app can connect to the local proxy; it does not choose a proxy node for the app. Open the “Connections” page and see which policy group handled the request. If the group points to an unavailable node, a reject policy, or an incorrect direct route, the app can still fail to load.

For testing, manually choose a stable, low-latency node for the relevant policy group. A successful latency test only proves that the test address is reachable; it does not mean every Microsoft service is accessible. Judge the result together with the actual connection status.

4. DNS resolution is returning unexpected results

If the logs repeatedly show DNS timeouts, failed lookups, or an empty destination address, check dns.enable, upstream DNS servers, and the operating mode in the mihomo configuration. When TUN mode is enabled, also confirm that the client service mode or administrator permissions were installed correctly; otherwise DNS hijacking may not take effect.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

This configuration is only a structural example and should not be used to overwrite an existing subscription directly. A subscription may already define rules, fallback resolvers, and Fake-IP filter lists. Back up the original configuration before editing, and use the client’s override feature whenever possible.

5. The app process did not actually restart

A Store app may continue running in the background after its window is closed. Open Task Manager, end the relevant task on the “Processes” or “Details” tab, wait five seconds, and start it again. You can also sign out of Windows and sign back in so the AppContainer process reloads its permissions.

Frequently asked questions

Recommended troubleshooting order

1. Confirm that regular desktop programs can get online through Clash.
2. Confirm that the local listening port matches the Windows system proxy.
3. Use the client’s built-in tool to add a loopback exemption for the target UWP app.
4. If there is no graphical option, use PowerShell to find the package family name, then run CheckNetIsolation.
5. Fully terminate and restart the target app.
6. Watch requests, matched rules, and the final policy on Clash’s Connections page.
7. Only then check the node, DNS, TUN service, and port conflicts if the problem persists.

The key is to separate two issues: the loopback exemption determines whether the app can connect to the local proxy, while the Clash configuration determines how traffic is resolved, routed, and forwarded after it enters the proxy. Confirm that requests reach the logs first, then investigate rules and nodes for a more direct diagnosis.