Troubleshooting 8-minute read

Windows UWP Apps Not Working with Clash Proxy: Remove Loopback Restrictions and Troubleshoot Connectivity

Learn why UWP apps are isolated from loopback access, how to remove the restriction, and how to check proxy ports and app coverage when connectivity still fails.

When using Clash or a mihomo-based client on Windows, browsers can often access the proxy normally while Microsoft Store apps, Xbox components, Photos, Mail, and other UWP apps still appear offline. This is often mistaken for an expired subscription, but the problem may occur before the app reaches the local proxy port: Windows app containers are restricted from connecting freely to services running on 127.0.0.1 or localhost.

Here, “loopback” refers to the path a device uses to access its own network interface. Clash HTTP, SOCKS, and mixed ports commonly listen on a local address. Traditional desktop programs can connect directly, while UWP apps must also pass AppContainer network isolation rules. After granting the affected app loopback access, check the system proxy, port, and rule mode to pinpoint the failing step.

1. How UWP loopback restrictions usually appear

UWP apps run in app containers, with separate identities and permission boundaries. System proxy settings can tell an app to send requests to a proxy, but access to a local listening address is also governed by network isolation rules. Clash running normally does not mean every app has permission to access the local proxy.

Common symptoms include Microsoft Store opening while app downloads remain stuck; Xbox, game launchers, or Weather reporting that services are unavailable; account sync failing in Windows Settings; and browsers working through Clash while apps installed from the Store still show no network. Changing Clash’s mixed port to a LAN address may alter some requests, but it is not the preferred fix because it introduces additional variables such as listening scope, firewall rules, and LAN exposure.

UWP apps must also be distinguished from regular desktop apps. Identical app names do not imply identical network behavior. For example, a Microsoft Store version may run in an app container, while an installer downloaded from the vendor’s website may be a Win32 desktop program. The former is more likely to be affected by loopback isolation; the latter can usually use the system proxy or access local ports directly.

2. Check Clash listening addresses and ports first

Before removing loopback restrictions, confirm that the client actually exposes a working local proxy endpoint. Interface labels vary between Clash clients, but the core settings usually include an HTTP port, a SOCKS port, and a mixed port. A mixed port accepts both HTTP and SOCKS requests, making it useful when the system proxy provides only one entry.

  1. Open the Clash client’s Settings or General page and note the currently enabled HTTP, SOCKS, or mixed port.
  2. Confirm that the listening address is a local loopback address such as 127.0.0.1, and make sure no other program is using the port.
  3. In Windows, open “Settings → Network & Internet → Proxy” and check that the manual proxy points to the same address and port.
  4. Watch the Clash connections or logs page for requests when the UWP app starts.

If the system proxy is set to an HTTP port but the SOCKS port was entered instead, some apps will immediately report a connection error. Conversely, system components that support only HTTP proxies cannot use a SOCKS port as a regular HTTP proxy. Use the actual value shown in the client or configuration file rather than a default copied from another device.

Also check whether another program is controlling the system proxy. VPNs, network accelerators, packet-capture tools, and enterprise policies can all modify Windows proxy settings. If Clash logs contain no requests from the UWP app at all, the problem most likely lies with the proxy entry point, app permissions, or system proxy selection. If requests already appear, continue by checking rule matches and node responses.

3. Remove loopback access restrictions with Windows tools

Windows provides the CheckNetIsolation command to manage network-isolation exceptions for app containers. The key is finding the target app’s Package Family Name, not the name shown by its desktop shortcut. If the package name is incorrect, the command may fail or grant access to a different app with a similar name.

Method 1: Use a graphical loopback exemption tool

You can use a loopback exemption manager for Windows from a trusted source, select the apps that need network access, and apply the settings. The tool usually lists app names and package identifiers. Select the target app, save the changes, then fully exit and reopen it. The package identity generally remains after an app update, but installing versions from different distribution channels still requires verifying the actual package identifier.

A graphical tool is useful if you are not comfortable with the command line, but verify the download source, documentation, and target app name before using it. Loopback exemptions are local network-permission settings. Grant access only to apps that genuinely need to connect to a local proxy; do not allow every app in the list by default.

Method 2: Use PowerShell or Command Prompt

Open PowerShell or Command Prompt with standard user permissions, then list the current loopback exemptions:

CheckNetIsolation LoopbackExempt -s

After identifying the target app’s Package Family Name, add an exemption using this format:

CheckNetIsolation LoopbackExempt -a -n=AppPackageFamilyName

Replace AppPackageFamilyName with the actual value; do not copy the example text literally. You can also use PowerShell to query installed app packages and filter the results by display name. For example:

Get-AppxPackage | Select-Object Name, PackageFamilyName

After adding the exemption, run CheckNetIsolation LoopbackExempt -s again to confirm that the entry appears. Then exit the target app and, if necessary, end its background process in Task Manager before launching it again. Closing the window does not always terminate a UWP app’s background instance, so perform a full exit first if restarting produces no change.

4. What to check if the app is still offline

If a UWP app remains offline after the loopback exemption takes effect, check in this order: app entry point, proxy port, client logs, then rules and nodes. This sequence first establishes whether the request reaches Clash before you change the configuration.

1. Confirm that the app uses the system proxy

Not every app follows Windows manual proxy settings. Some use the system WinINet proxy, others use WinHTTP, and some provide separate network options inside the app. Check the Windows proxy switch and address first, then look for proxy, network, or download settings in the app itself. If the app bypasses the system proxy completely, changing Clash’s HTTP port alone will have no effect.

2. Verify the port type and listening status

The system proxy usually requires an HTTP proxy endpoint. If the client has only a SOCKS port enabled, enable its mixed port or configure a compatible HTTP port. A port occupied by another service, a port that changes after the client restarts, or a mismatch between the configuration file and the active client profile can all cause seemingly intermittent connection failures.

3. Check the logs to see whether requests arrive

Launch the UWP app and refresh it once, then look for the relevant domain in Clash connection logs. If there is no entry at all, return to the app proxy entry point, loopback exemption, and firewall checks. If an entry shows rejection or a timeout, inspect the proxy group, node latency, and DNS result. If the entry shows a direct connection but the service is unreachable, the issue may be rule matching or the direct network itself.

4. Check rule mode and proxy groups

In Rule mode, requests are matched in the order defined by the configuration and then sent to the corresponding proxy group. Rules may route Microsoft services, sign-in services, updates, or static assets to different groups. For testing, temporarily switch to Global mode to determine whether rule-based routing is responsible. Restore the mode suited to everyday use afterward and refine the rules based on the logs instead of relying on Global mode permanently.

5. Check DNS, system time, and security policies

If the app can reach the proxy port but cannot resolve domains, check Clash DNS settings, system DNS, and whether the current network is blocking those queries. A significantly incorrect system clock can affect HTTPS connections and Microsoft Store authentication. Enterprise devices may also restrict app network access through Group Policy, proxy auto-configuration scripts, or security software; handle those settings according to the device-management rules.

5. When to consider TUN mode

TUN mode uses a virtual network interface to capture traffic at a lower level, allowing some programs that ignore system proxy settings to enter Clash’s processing path. It is useful when multiple apps, games, or system components need coverage, but enabling it involves virtual adapters, routing, DNS, and administrator permissions, which also makes troubleshooting more complex.

If the goal is only to let one UWP app access a local HTTP proxy, handle the loopback exemption and system proxy first. Consider TUN when multiple apps ignore the system proxy or an app has no proxy settings of its own. Before enabling it, record the current configuration, confirm which TUN implementation the client supports, and watch for conflicts with other VPNs, virtual adapters, or LAN-sharing software.

After enabling TUN, continue checking Clash logs and rule matches. Traffic entering TUN does not necessarily use a proxy node; rules may send it direct, reject it, or assign it to a proxy group. If LAN devices become unreachable, DNS loops occur, or the network disconnects, disable TUN first to confirm the scope, then inspect routing and DNS settings step by step.

6. A quick troubleshooting checklist

  • Can the browser access the internet normally through Clash, and does the client show that it is running?
  • Is the UWP app from the Microsoft Store, and does it run in an app-container environment?
  • Is the target app’s Package Family Name correct, and does it appear in the loopback exemption list?
  • Do the Windows system proxy address, port, and proxy type match Clash’s current listening settings?
  • Does the Clash connection log show the target domain when the app starts and refreshes?
  • After the request arrives, is it matched to a proxy, direct connection, or reject policy?
  • Are another VPN, proxy app, enterprise policy, or firewall changing the network path?
  • After confirming that the system proxy cannot cover the app, evaluate TUN mode and virtual-adapter options.

The key to this type of failure is not repeatedly replacing the subscription, but identifying which layer the request passes through. A UWP loopback exemption answers whether the app can reach the local proxy entry point; port settings determine which proxy service it connects to; rules and nodes determine how Clash forwards the request. Verify each layer in order to avoid changing permissions, proxy endpoints, and routing rules all at once.

Download Clash