Windows UWP Apps Can't Connect Through a Proxy: Remove Loopback Restrictions and Troubleshoot

First confirm that the issue is a UWP loopback restriction

When Windows shows that a browser can connect through Clash Verge but Microsoft Store, Xbox, Photos, Mail, or another Store app cannot get online, a common cause is an AppContainer loopback access restriction. Here, “loopback” means an app accessing a local address such as 127.0.0.1, localhost, or an IPv6 loopback address. After Clash Verge enables the system proxy, Windows typically points the proxy server to a port listening on the local machine. The app must connect to that local port first, after which the mihomo core forwards traffic according to its rules.

Traditional desktop programs can usually access a local proxy port directly, while packaged apps running inside the AppContainer sandbox may face additional restrictions. If the target app has no loopback exemption, it may be unable to connect to Clash's local HTTP, SOCKS, or Mixed listener. The result is not necessarily that every program loses connectivity at once: individual Store apps may fail to load, show a blank sign-in screen, refresh continuously, or report that the network is unavailable.

However, a Store app being unable to connect does not automatically mean a loopback restriction. Before confirming the cause, look for this combination of symptoms:

• Clash Verge has an imported, working configuration, and the current configuration and policy groups are enabled.
• Edge, Firefox, or another desktop program can access the target website normally through the same system proxy.
• The affected app can connect directly after the system proxy is disabled, or its error state changes when the system proxy is toggled.
• When the affected app is opened, Clash Verge's connection log contains no corresponding request, suggesting that the traffic never reached the local proxy port.
• The problem is limited to one or a few packaged apps rather than all programs and domains failing at the same time.

Understand the connection path between the system proxy, AppContainer, and the local port

Before troubleshooting, break the connection path into stages. When Clash Verge enables the system proxy, it writes the proxy address to Windows. The exact port depends on the current settings; a common value is 127.0.0.1:7890, though another HTTP or Mixed port may be used. Apps that support system proxy settings read this value and send network requests to the mihomo listener on the local machine.

1. The app reads the Windows system proxy settings.
2. The app attempts to connect to the Clash listener on 127.0.0.1.
3. mihomo receives the request and selects direct access, rejection, or a specified policy group based on the domain, IP, process, or rule set.
4. The selected node or direct-access route establishes the external connection, and the response returns to the app along the original path.

UWP and some MSIX-packaged apps use the AppContainer security boundary. This boundary restricts access to local network resources to prevent sandboxed apps from freely probing or calling local services. Because the system proxy is located at a local address, an app may read the proxy settings successfully but still be blocked at the second step. A loopback exemption allows a specified package to access the local loopback interface; it does not change Clash rules for the app or restore a node that is unavailable.

It is also important to distinguish between “UWP app,” “app installed from the Store,” and “every modern-interface app.” Microsoft Store includes both AppContainer apps and traditional desktop programs distributed through the Store. The latter may not be subject to the same loopback restriction. Identify the target by its package identity and actual network behavior, not merely by its installation source.

Basic checks before removing the restriction

Before modifying the loopback exemption list, verify Clash Verge's local proxy status. This prevents an incorrect port, stale system proxy setting, or disabled configuration from being mistaken for an AppContainer restriction.

Verify the Clash Verge listener port

Open Clash Verge's settings and check the HTTP, SOCKS, or Mixed port, confirming that the core is running normally. Then open Windows Settings → Network & internet → Proxy and check whether the manual proxy address matches the listener value currently used by Clash Verge. If Clash Verge changed its port while Windows still retains the old address, every app that reads the system proxy settings may fail to connect.

Do not let multiple proxy programs use the same port. During a port conflict, Clash Verge may fail to start its listener, or the system proxy may actually point to another program. Exit the conflicting program first, change the port, and toggle the system proxy off and on again.

Check the configuration and policy group status

Confirm that the current subscription has been updated and selected, and that commonly used policy groups contain an available node. Start by visiting a site that clearly requires a proxy in a desktop browser, then check Clash Verge's connection log. If the browser request appears and completes, the local listener, basic rules, and at least one outbound route are broadly working.

Determine whether the target app actually uses the system proxy

Some apps use their own networking stack and may ignore the Windows system proxy; some system components use WinHTTP settings instead of the current user's Internet proxy settings. A loopback exemption only permits local access; it does not change which proxy interface the app chooses. If the app neither reads the system proxy nor has its traffic captured by TUN, adding an exemption may still produce no traffic in Clash.

Remove UWP app restrictions with a loopback exemption

Some Clash Verge versions or Windows helper tools provide a UWP loopback management screen. If the current client settings include an option such as “UWP Loopback,” “Loopback,” or “Remove loopback restrictions,” use that interface first to review the app package list and select only apps that genuinely need to access the local proxy. Menu locations can vary between versions, so do not search mechanically for a fixed menu based on an old screenshot.

If the client has no such option, use Windows' built-in CheckNetIsolation.exe to manage the exemption list. You must identify the app's Package Family Name accurately. It is not the app name shown in the Start menu or the installation directory name.

Step 1: Find the app's package family name

Open PowerShell as an administrator and list the packaged apps installed for the current user together with their package family names:

Get-AppxPackage | Select-Object Name, PackageFamilyName

If the list is long, filter it by name. For example, to search for packages related to Microsoft Store:

Get-AppxPackage -Name "*WindowsStore*" |
  Select-Object Name, PackageFamilyName

The PackageFamilyName in the command output is the value required for the next steps. A common Microsoft Store package family name is Microsoft.WindowsStore_8wekyb3d8bbwe, but other apps must use the result returned by the local system. Similar names may belong to the main app, a runtime component, or an extension package, so do not guess from the name.

Step 2: Add a loopback exemption for the specified app

In the administrator terminal, run the following command, replacing the example value with the target app's actual package family name:

CheckNetIsolation.exe LoopbackExempt -a -n="PackageFamilyName"

For example, to add an exemption for the Microsoft Store package found above, run:

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

-a adds an entry, while -n specifies the package family name. Afterward, fully close the target app, including any process that may still be running in the background, and reopen it for testing. Simply minimizing the window is usually not enough to establish a completely new network session.

Step 3: View the current exemption list

Use the following command to verify that the entry has been written:

CheckNetIsolation.exe LoopbackExempt -s

The output lists app packages that have loopback exemptions. If the target package is already present, there is no need to add it again. Repeating the add command generally cannot fix rule, DNS, or node problems and may distract from the actual troubleshooting path.

Step 4: Remove an exemption when it is no longer needed

If the target app no longer uses the local proxy or you need to restore the previous state, use -d to remove the specified entry:

CheckNetIsolation.exe LoopbackExempt -d -n="PackageFamilyName"

Run -s again after removal to verify the list, then restart the app. Keep the exemption list as narrow as possible: allow loopback access only for packages that need the local proxy instead of modifying every app at once.

Verification sequence after adding an exemption

A successful command only means that Windows accepted the setting; it does not confirm that the entire proxy path is working. Verify the chain in this order: app process, local connection, rule matching, and upstream route.

1. Restart the app: Confirm in Task Manager that the old process has ended, then open the target app. If necessary, sign out of the current Windows user, but a full computer restart is usually not required immediately.
2. Watch the Clash connection log: Open the Connections or Logs page in Clash Verge, then refresh the app. If the target domain or a request from the relevant process appears, the traffic has reached the core.
3. Check the rule result: See which rule and policy group handled the request. If it matched REJECT, an incorrect direct rule, or an unavailable policy, revise the configuration or switch policies instead of continuing to troubleshoot loopback access.
4. Test multiple entry points: The Store home page, search, image resources, account sign-in, and download services may use different domains. A working home page does not mean every interface has recovered.
5. Compare the system proxy states: Test with the proxy enabled and disabled while keeping all other conditions unchanged, confirming that the behavior is actually related to the proxy path.

If Clash Verge starts showing requests after the exemption is added but the app still reports a failure, the problem has moved from “cannot access the local port” to a later stage. Focus on the error type in the logs. For example, a DNS timeout calls for checking the nameserver, DNS hijacking, and network reachability; a connection timeout calls for checking the node and route; a TLS error may involve the system clock, certificate environment, or an intermediate link.

Microsoft Store page content, app authorization, and download tasks may be handled by different system services. Adding a loopback exemption for the Store's main package may restore page browsing while the download queue remains affected by Windows Update, Delivery Optimization, account status, or service policies. Investigate these symptoms separately rather than treating every Store error as a loopback problem in one package.

Should you switch to TUN mode if the system proxy still does not work?

TUN mode captures traffic at the virtual network interface layer and does not rely entirely on apps actively reading the Windows system proxy, so it can cover programs that ignore system proxy settings more effectively. For apps that cannot use a local HTTP proxy reliably, TUN is another troubleshooting path, but it is not a simple replacement toggle for a loopback exemption.

Before enabling TUN, confirm that the required Clash Verge service component and permissions are configured correctly, and record the original system proxy state. TUN involves routing, DNS hijacking, interface priority, and process-level traffic capture, so its scope is broader than a single UWP package. If one clearly identified AppContainer app cannot access the 127.0.0.1 proxy, a targeted loopback exemption is usually easier to verify and undo.

Situations where TUN may be worth considering include:

• The target app is confirmed not to read the Windows system proxy, and no connection records appear either before or after the system proxy is enabled.
• A game launcher, command-line program, or specific network component uses a protocol that ordinary HTTP proxying cannot cover.
• You want to handle more traffic from processes without explicit proxy support under the same rule set.

If enabling TUN makes local network devices unreachable, causes DNS errors, or creates a virtual adapter conflict, first check DNS, route exclusions, and interface settings in the Clash configuration. VPNs, virtual machine software, container networks, and other network filters can all change route priority. During troubleshooting, avoid repeatedly switching the system proxy, TUN, nodes, and DNS at the same time; otherwise it becomes difficult to identify the source of the failure.

Layered troubleshooting checklist when connection still fails

No requests appear in Clash Verge

First confirm that the correct package family name was selected, then use CheckNetIsolation.exe LoopbackExempt -s to verify that the exemption exists. Next, check the Windows system proxy address and port. If the app does not use the system proxy, briefly test TUN and see whether connection records begin to appear. No records usually means the problem occurs before the request reaches mihomo.

Requests appear in the log but are rejected by a rule

Check the matched domain, rule, and policy group. The rule set may classify certain Microsoft domains as direct, or a custom rule may reject them incorrectly. Record the exact domain and match result before making changes, and do not add an overly broad wildcard rule based only on the app name. Reload the configuration after changing rules and confirm that new connections use the expected policy.

The log shows a DNS failure

Confirm that the underlying system network can reach the DNS servers in the configuration, and check whether Clash DNS is enabled, the nameserver is reachable, and DNS hijacking conflicts with other network programs. If TUN is enabled, also check DNS capture on the virtual interface. DNS failures and loopback restrictions can both produce a blank page, but DNS problems usually leave a query error in the log.

Only sign-in, images, or downloads fail

This usually means the main request passed through the proxy, while subresources, account APIs, or download services use different domains and processes. Trigger each failing function separately while watching for new connections. Microsoft Store downloads also depend on related system services, disk space, time settings, and account authorization, so checking only the foreground app package is not enough.

Access still fails after the proxy is disabled

If the issue remains after disabling Clash Verge's system proxy and exiting the client, check Windows networking, the app cache, account sign-in, and system services. Start by finding the target app under Settings → Apps and using its available repair option; reset clears app data, so confirm the impact before proceeding. Also check that the system date, region, and network connection are correct.

Stale system proxy settings or a changed port

After Clash Verge exits unexpectedly, Windows may temporarily retain the previous proxy address. Restart the client and disable the system proxy normally, or verify the toggle in Windows proxy settings. If the port has changed, make sure Windows points to the new port and that it exactly matches the port mihomo is listening on.

Keep a record that can be reviewed after recovery

After resolving the issue, record the target app's display name, Package Family Name, Clash Verge listener port, system proxy or TUN mode in use, and the adjustment that ultimately worked. App updates usually do not change the same package family name, but reinstalling, switching to a preview build, or changing distribution channels can change the package identity, so the original exemption may not cover the new package.

If the same behavior returns, first run the exemption-list query, then watch the Clash connection log. Once you know whether the request reaches the local proxy, you can quickly distinguish an AppContainer loopback issue from a proxy-port, rule-configuration, or upstream-connection problem. Remove exemptions for apps that are no longer used to keep the configuration clear.

The complete troubleshooting logic is: confirm whether desktop apps work, determine whether the target package is sandboxed, check whether the request reaches mihomo, verify that the correct rule matches, and confirm that the outbound route works. Checking these layers in order is more effective than repeatedly switching nodes or reinstalling the app.