First, check whether loopback restrictions are causing the problem
On Windows 10 or 11, if your browser works through Clash but a UWP app keeps failing to connect, check whether AppContainer network isolation is blocking it. Clash's system proxy usually points to a local address such as 127.0.0.1:7890. By default, apps running in an AppContainer can't access local loopback services like regular desktop programs can, so the connection may fail before traffic reaches the proxy core.
A loopback exemption lets a specified app access local loopback addresses. It does not bypass proxy rules, remove account restrictions, or automatically grant the app network capabilities. The exemption applies to an app package, not a subscription or proxy node. Not every app installed from the Microsoft Store is a UWP app; some packaged desktop apps run as full-trust processes, so don't determine an app's type by its installation source alone.
- This is likely the issue if: On the same PC and network, your browser works through the proxy, a specific AppContainer app fails, and you're using the local system proxy.
- Rule out a client issue first: If your browser can't connect either, check that the core is running, the port is listening, and the node is reachable.
- Rule out a service-side issue first: If errors affect only one account, download, or domain, also check your sign-in status, service availability, and connection logs.
Step 1: Check the system proxy and local port
In Windows 11, open Settings → Network & internet → Proxy → Manual proxy setup → Edit. In Windows 10, go to Settings → Network & internet → Proxy and find the manual proxy setup section. Make sure the proxy address and port match your client. If the client manages these settings through a System Proxy toggle, use that toggle to avoid conflicting settings.
The system proxy needs an HTTP proxy port or a mixed port that supports HTTP. Don't enter a SOCKS-only port here, and don't use the proxy core's controller port. The controller is for managing configuration and checking status; it doesn't forward HTTP proxy requests from apps.
Check the TCP listener in PowerShell
Test-NetConnection -ComputerName 127.0.0.1 -Port 7890Check the TcpTestSucceeded value in the output. True means only that a TCP connection to the port succeeded; it doesn't confirm that the node, DNS, or destination site is working. If the value is False, start the core or correct the port first. A loopback exemption can't fix a service that isn't listening.
You can also use Windows' built-in curl.exe to test the HTTP proxy path explicitly. This command has a 15-second timeout; it's an example for troubleshooting, not a test result. If the destination is unreachable, try an HTTPS address you know is accessible.
curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://www.microsoft.com/If the explicit proxy request succeeds but the target app still fails, check its loopback permissions next. Don't enable Allow connections from the local network just to let a UWP app reach a local proxy. That setting lets other devices connect to a listening service; it isn't the same as AppContainer loopback isolation on this PC.
Step 2: Find the package family name and note existing exemptions
CheckNetIsolation.exe is a Windows tool for managing network isolation. Use an elevated terminal to add or remove exemptions. When looking up an app, use the Windows account that runs it. If you elevate with a different administrator account, Get-AppxPackage may query that account instead, so the target package won't appear.
- Close the target app, including any background processes it may have left running.
- In PowerShell under the target user's account, run the query below to find the app.
- Right-click Start and choose Terminal (Admin) or Windows PowerShell (Admin), then approve the User Account Control prompt.
- Query the exemption list and save the output before making changes so you can compare and restore it later.
Get-AppxPackage |
Sort-Object Name |
Select-Object Name, PackageFamilyName
CheckNetIsolation.exe LoopbackExempt -sThe add command needs the PackageFamilyName, not the app's display name or its PackageFullName, which includes details such as version and architecture. A package family name typically consists of the app name, an underscore, and a publisher identifier. Don't try to construct it from the installation folder name.
Use Windows Calculator to illustrate the command
The example below uses Microsoft.WindowsCalculator to show how to find a package. Calculator doesn't need a proxy for basic calculations, so it's only an example of the command structure—not a test for fixing network access. For the actual app, replace the filter name with its Name from the list in the previous step.
Get-AppxPackage -Name Microsoft.WindowsCalculator |
Select-Object Name, PackageFamilyNameIf the query returns no results, check that the app is installed for the current account and that the name matches. The Store display name may differ from the internal package name, so you can start by browsing the full list. Don't use package family name commands for desktop apps installed with a regular installer that don't have a package identity.
Step 3: Add an exemption for one app with CheckNetIsolation
Once you've confirmed the app identity, run the add command in an elevated PowerShell window. The example still uses Calculator and retrieves its package family name with a variable to avoid copy-and-paste errors. The script requires exactly one match; if the target isn't unambiguous, it stops without making changes.
$apps = @(Get-AppxPackage -Name Microsoft.WindowsCalculator)
if ($apps.Count -ne 1) {
throw "No unique app package found. Check the current user and app name."
}
$pfn = $apps[0].PackageFamilyName
CheckNetIsolation.exe LoopbackExempt -a "-n=$pfn"
CheckNetIsolation.exe LoopbackExempt -sLoopbackExempt manages loopback exemptions, -a adds one, -n= takes a package family name, and -s displays the current list. The tool can also target an app by its AppContainer SID, but package family names are usually easier to look up in Windows and help avoid identity mix-ups.
- Check whether the add command reports an error. If access is denied, make sure the terminal is actually running as administrator.
- Check the
-soutput for the target name or its corresponding SID. A completed command doesn't by itself mean the app can connect again. - Reopen the target app and repeat the same network operation that failed before.
- Also check Clash's Connections page or logs to see whether the request reached the core, which rule group matched, and which outbound connection was selected.
Alternative: Use your client's UWP loopback tool
Some Windows GUI clients include a tool for managing loopback exemptions, but this isn't a universal setting in Clash or mihomo configuration files. Availability, button names, and location vary by client and version. If you can't find the tool, use the Windows command above; there's no need to add a supposed UWP switch to your YAML file.
How to find the option in the legacy Clash for Windows client
The discontinued Clash for Windows client included a General → UWP Loopback → Launch Helper option. If the client is already installed, select the target app in the helper window and click Save Changes. Approve any permission prompt from Windows. This describes an existing installation; it's not a reason to install or modify the legacy client.
- Find the target app in the tool's list and select only the app you need to fix.
- After saving, close and reopen the target app, then repeat the same network operation.
- In an elevated terminal, run
CheckNetIsolation.exe LoopbackExempt -sto check the actual system list. - For similar options in other clients, follow the interface for your installed version. Don't treat Service Mode, System Proxy, and loopback exemptions as the same feature.
GUI tools and command-line commands change the same kind of system exemption; neither improves the quality of your proxy nodes. If a helper won't open, shows an empty list, or fails to save, check the package identity and administrator permissions instead of repeatedly switching subscriptions.
Still can't connect after adding the exemption? Trace the request path
| What you see | What to check next |
|---|---|
| Can't connect to local port 7890 | Check the actual listening port, whether the core is running, and whether the port supports HTTP. |
| Browser works, but the target package isn't in the exemption list | Check the package family name, current user, command permissions, and any error output. |
| Exemption is listed, but the client shows no matching request | Check whether the app uses the system proxy and whether another package or background service is making the connection. |
| The request appears in the logs but matches DIRECT | Check the rule order, destination domain, and policy group. A loopback exemption doesn't force traffic through the proxy. |
| Request reaches the proxy, then times out or returns an error | Use the logs to check the node, DNS, destination site, and account status. Don't add the exemption again. |
Test Microsoft Store and Xbox features separately
Store page loads, account sign-in, and app downloads may use different components to make requests. Fixing one screen doesn't mean every background transfer uses the same package identity or proxy settings. Xbox features may also involve separate services, UDP traffic, and different network requirements. Record each failed action, its time, and the relevant logs. Don't assume one package exemption covers every component.
TUN mode is not a loopback exemption
mihomo's TUN mode uses a virtual network interface and routing to capture traffic. This is different from an app connecting directly to a local HTTP proxy. If an app doesn't use the system proxy, TUN may be another troubleshooting option, provided your client supports it and you configure the required permissions, routes, and DNS correctly. TUN doesn't automatically remove network restrictions for every AppContainer or guarantee compatibility with every UWP networking path.
When testing TUN, change one thing at a time and note the System Proxy toggle, TUN toggle, and target app status. Don't change DNS, rules, nodes, and the exemption list all at once; even if the issue goes away, you won't know what fixed it. See Key Terms for related concepts, or continue with the Cross-Platform Guide for platform settings.
Revert the change: Remove the exemption you added
Loopback exemptions are stored in Windows and aren't automatically removed when you exit Clash. To undo the test when it's no longer needed, the app uses a different network path, or you want to restore its previous isolation, use -d to remove the specific package. The example below uses Calculator as before; when reverting your own changes, specify the package you modified.
$apps = @(Get-AppxPackage -Name Microsoft.WindowsCalculator)
if ($apps.Count -ne 1) {
throw "No unique app package found. Use the package family name saved before the change to verify."
}
$pfn = $apps[0].PackageFamilyName
CheckNetIsolation.exe LoopbackExempt -d "-n=$pfn"
CheckNetIsolation.exe LoopbackExempt -sIf the app has been uninstalled, use the package family name you saved earlier rather than relying on the current Get-AppxPackage results. In a GUI tool, deselect the target app and save, then verify the change with the Windows command.
When you're done, restart the target app and check whether removing the exemption had the expected effect. If the app already had an exemption before you started, don't remove it just to clean up; the goal is to restore the original state. Keep a record confirming all four points: the local port is reachable, the target package exemption has been checked, the request path is visible in the logs, and the app's actual network operation succeeds. This helps distinguish a real fix from a one-off success.