Windows UWP Apps Can’t Connect Through a Proxy: Remove Loopback Restrictions and Verify the Fix

First confirm that this is a UWP loopback issue

Do not change loopback exemptions just because the Microsoft Store will not open. Microsoft Store, Mail, some media apps, and other Store apps may fail because the system proxy is disabled, the Clash core is not running, rules are incorrect, DNS fails, account services are unavailable, or a Windows service is unhealthy. A loopback restriction explains one specific pattern: the app needs to connect through a local proxy, but its AppContainer prevents access to that locally listening address.

The most telling combination is this: a traditional desktop browser accesses the internet normally through Clash; Clash’s system proxy is enabled; the target UWP app reports no internet, loads indefinitely, or fails to connect; and after the system proxy is disabled, the app may recover direct access—or may still fail because of the network environment. Record the current mode, proxy port, and app name before making targeted changes.

Establish a baseline in this order

1. Confirm that the Clash client reports the core as running, rather than only showing that the interface process is open.
2. Use a regular desktop browser to open a working site and confirm that the system proxy path works for Win32 apps at minimum.
3. Search the Clash connection log for the target domain and check whether launching the UWP app creates a new connection.
4. Record the HTTP or mixed port in the client settings and confirm that the system proxy points to the same port.
5. Fully exit the target app and reopen it so that a background process does not continue reusing a connection from before the change.

If launching the target app produces no related requests at all in the Clash connection list while browser requests appear normally, the loopback restriction should be checked first. Conversely, if the request reaches Clash and clearly shows a rule match, DNS error, or node connection failure, the traffic has already passed through AppContainer to the local proxy; investigate rules, DNS, or the upstream node instead.

Why the system proxy works while the UWP app still fails

When Clash or mihomo runs on Windows, it usually listens on a local port. For example, a mixed port may listen on 127.0.0.1:7890 and accept both HTTP and SOCKS protocols; some clients configure separate HTTP and SOCKS ports. After the system proxy is enabled, Windows writes the proxy address to the current user’s network settings, and apps that use those settings send requests to the local Clash port.

For ordinary desktop programs, accessing 127.0.0.1 is standard local communication. UWP apps and some packaged apps may instead run inside an AppContainer sandbox. AppContainer places boundaries around network capabilities and local loopback access to prevent isolated apps from freely connecting to other services on the same device. As a result, the app may read the system proxy address but be unable to connect to it, causing the request to fail before it reaches the Clash core.

A loopback exemption does not force the app to use a proxy. It only allows the specified AppContainer to access the local loopback interface. Whether the app reads the system proxy, bypasses it, or uses UDP or QUIC still depends on the app and the Windows networking stack. After adding an exemption, verify the traffic path in the connection log rather than relying only on a temporary change in the app’s interface.

Remove the loopback restriction for the target app

Some Clash clients for Windows provide a “UWP loopback,” “Loopback,” or “Remove loopback restriction” tool. It usually invokes Windows’ loopback exemption mechanism and displays installed AppContainer apps. Select only apps that genuinely need to connect through the local proxy, such as the affected Microsoft Store or a specific Store app. Avoid selecting every item before confirming the scope.

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

1. Start the Clash client normally and confirm that the core has loaded the configuration successfully.
2. Open Settings, General Settings, or the service tools area and look for an entry named UWP, Loopback, or “loopback.”
3. Find the target program in the app list. The list may show the app name, package name, or package family name, so distinguish similar entries carefully.
4. Select the target program and save the change so Windows adds a loopback exemption for the corresponding package.
5. Close every window belonging to the target app, confirm in Task Manager that its background process has ended, and then restart the app.

Menu locations differ between clients, and some modern clients do not include a graphical loopback tool. The absence of such an entry does not mean the mihomo core lacks proxy support: loopback restrictions are a Windows AppContainer policy, not an option in the Clash rule engine. In that case, use Windows’ built-in commands to inspect and change the setting.

Method 2: Find the package family name with PowerShell

Open PowerShell and search by the app’s display name or package name to find its PackageFamilyName. The following command lists app packages installed for the current user along with their package family names:

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

If the list is long, filter it by keyword. For example, to find apps whose names contain Store:

Get-AppxPackage *Store* |
  Select-Object Name, PackageFamilyName

After finding the exact package family name, run the loopback exemption command in a terminal. Replace the example value with the actual PackageFamilyName returned by the query:

CheckNetIsolation.exe LoopbackExempt -a -n="PackageFamilyName of the target app"

The -a option adds an exemption. The value after -n must be the package family name—not the name shown in the Start menu or the installation directory name. A typo may cause the command to fail or modify the wrong package. Copy the complete value from the PowerShell output before running it.

View and revoke existing exemptions

To view the current loopback exemption list, run:

CheckNetIsolation.exe LoopbackExempt -s

If an exemption is no longer needed after testing, use the delete command to restore the app’s default restriction:

CheckNetIsolation.exe LoopbackExempt -d -n="PackageFamilyName of the target app"

Verify Everything from the Local Port to the Rule Match

Adding an exemption changes permissions only, so verification must proceed layer by layer. Keep Clash in rule mode temporarily, because rule mode shows domains, destination addresses, matched rules, and policy groups in the connection log, making it more useful than global mode for confirming that requests are routed as expected.

Step 1: Check the listening port

Check the current mixed or HTTP port in the Clash client, then inspect the Windows system proxy. The ports must match. For example, if the client listens on 127.0.0.1:7890 while the system proxy still points to 127.0.0.1:7897, every app that reads the system proxy will connect to the wrong address. Stale ports are especially common after switching between Clash clients.

Also confirm that the listening address in the configuration has not been changed to a value intended only for another interface. For local apps, listening on the loopback address is usually sufficient. LAN sharing involves allow-lan, the listening address, and the firewall, and follows a separate configuration path; do not expose LAN access just to fix a single UWP app.

Step 2: Restart the target app

Many UWP apps keep background tasks running after their windows are closed. After changing the loopback exemption, end the corresponding process in Task Manager, or sign out of the current Windows account and sign back in. If the app keeps reusing an old connection, it can falsely appear that the setting was added but did not take effect.

Step 3: Watch Clash connections and logs

Reopen the app and trigger a clear network action, such as refreshing a page, checking for updates, or loading account information. Then review the Clash connection list:

• If the target domain appears and data transfers successfully, the loopback path, local port, and proxy entry point are connected.
• If the domain appears but the wrong rule is matched, adjust the rule order, rule-set references, or policy group.
• If a connection appears but the node handshake fails, test another available node in the policy group.
• If there are no requests at all, confirm whether the app uses the system proxy, whether the correct package received the exemption, and whether the app uses a protocol that this proxy entry point does not handle.

Step 4: Compare the toggle states

Keep all other conditions unchanged and test once with the system proxy enabled and once with it disabled. If the app fails when enabled, works with a direct connection when disabled, and never generates a request in Clash, the issue is usually still the local proxy entry point or loopback permission. If both states fail, check the app service, Windows networking, account status, and DNS instead of repeatedly adding exemptions.

Troubleshooting Steps When the Connection Still Fails After Removing the Loopback Restriction

If the target app is already on the exemption list but still cannot connect normally, continue checking from the proxy entry point onward. The following issues can resemble a loopback restriction but require different fixes.

A stale system proxy address or port

Windows may retain the previous client’s proxy port, especially after an abnormal exit, switching between portable and installed versions, or alternating between multiple proxy tools. Close other proxy software first, then let the current Clash client set the system proxy again. Do not rely only on the client toggle; verify the proxy address actually saved in Windows.

The app does not use the system proxy

Not every app follows the current user’s system proxy settings. Some implement their own networking stack, some use UDP or QUIC, and some background components send requests through a different service process. In such cases, an HTTP system proxy may not capture all traffic even when the loopback exemption is correct. You can test mihomo TUN mode, but first confirm that the client has the required permissions, the virtual network adapter is available, and you understand the DNS and routing changes.

TUN mode captures traffic at the network layer, which is different from having an app actively connect to the system proxy at 127.0.0.1. It is often used for apps that do not read the system proxy, but it does not guarantee a fix for every UWP issue. If there are still no requests after enabling TUN, check route exclusions, interface conflicts, security software policies, and the app’s own service status.

Rules send required requests to the wrong policy

Apps such as Microsoft Store may access content delivery, account, certificate, and update services at the same time. Seeing the main domain succeed does not mean every dependency request is working. Check failed or repeatedly retried domains in the connection log and verify the top-to-bottom rule order. Once Clash matches a rule, it does not check later rules, so an overly broad rule near the top can override a more precise rule below it.

During troubleshooting, temporarily switch to a confirmed working policy group for comparison, but do not use global proxy mode permanently to hide a rule problem. Once the specific domain and failure cause are clear, write the correction into the rule configuration and retain a final fallback rule.

DNS resolution and proxy connections are separate stages

If the log shows DNS resolution failures, unexpected addresses, or repeated timeouts, check the configured dns section, resolver reachability, and the Clash DNS listener. With fake-ip, also check whether the app has compatibility requirements for virtual addresses or specific domains. Do not skip the DNS layer just because the symptoms occur in a UWP app.

Port conflicts and a core that failed to load

An open client interface does not mean the proxy port is listening. Configuration syntax errors, an occupied port, or a failed core startup can leave the system proxy pointing to an address with no service. Check configuration loading results and listening errors in the client log, change to an unused port if necessary, and update the system proxy accordingly.

Enterprise policies or managed-device restrictions

Company and school devices, as well as Windows environments under centralized management, may use Group Policy, firewalls, or endpoint protection to restrict AppContainer access, local proxies, and network interfaces. A successful command does not mean a policy will not overwrite the setting later. Confirm the device-management requirements first and avoid repeatedly changing centrally controlled configuration.

Recovery test checklist

After making the changes, use the checklist below for a final confirmation. Each item maps to a specific layer, making future reproduction and rollback easier.

• The Clash or mihomo core started successfully, with no configuration parsing errors.
• The local HTTP or mixed port is listening and is not occupied by another program.
• The Windows system proxy address matches the current client port.
• The package family name for the target UWP app has been added to the loopback exemption list.
• The target app was fully terminated and restarted after the change.
• The Clash connection log shows a domain or destination address generated by the app.
• The request matched the expected rule and policy group, and the upstream node established a connection successfully.
• DNS queries do not time out repeatedly, and the results match the current configuration mode.
• After testing, revoke temporary changes that are no longer needed and record the final working settings.

A successful fix means more than “the page opens”: the target request should consistently reach Clash, match the expected rule, and complete its transfer. This layered verification distinguishes AppContainer permissions, the local proxy port, rules, DNS, and node issues, preventing repeated changes to the same setting.