Microsoft Store Apps Not Using Clash? Fix the UWP Loopback Restriction

First, distinguish system proxy settings, app sandboxing, and proxy rules

Your browser can access the internet through Clash, but a Microsoft Store app keeps reporting connection errors. The UWP loopback restriction may be the cause. A typical setup has the system proxy enabled, pointing to 127.0.0.1:7890, while the app runs inside a restricted AppContainer sandbox. Windows network isolation can block the app from connecting to the local proxy before the request ever reaches the Clash core.

UWP stands for Universal Windows Platform; AppContainer is Windows' app isolation mechanism. A loopback address points to the local computer, such as IPv4 127.0.0.1 or IPv6 ::1. A loopback exemption lets a specified app container access local network services. It does not disable the Windows Firewall.

Being installed from the Microsoft Store does not necessarily make an app a UWP app. The Store also distributes traditional Win32 desktop programs and packaged desktop apps. Check the app package, how it runs, and its connection logs rather than assuming every Store app connection problem is caused by the loopback restriction.

What each mechanism does

• System proxy: Provides an HTTP proxy address to apps that read Windows proxy settings. It does not automatically route every program's TCP and UDP traffic.
• Loopback exemption: Lets a specified app container connect to a local proxy. The app still has to use that proxy setting.
• Rule mode: Once traffic reaches Clash or mihomo, rules determine whether it goes direct or through a proxy. Rules cannot fix sandbox restrictions that block a request before it reaches the core.

If your browser works, that only confirms one proxy path is available; it does not prove the target app can reach the same local port. Likewise, seeing an app in the client's connection list does not mean its traffic went through a remote node. Check the matched rule and actual exit route.

Before you start: check the port, system proxy, and connection logs

First, confirm which local listening port the client uses. This guide uses mixed-port: 7890, which shares a port for HTTP and SOCKS5. If your actual configuration uses 7897, use that value in every address and command below. Do not confuse the external controller port with the proxy port, and do not enable allow-lan just to let a local app connect.

1. In Windows 11, open Settings → Network & internet → Proxy and check the address and port under Manual proxy setup. In Windows 10, go to Settings → Network & Internet → Proxy → Use a proxy server. If you use a PAC script, check the proxy address it returns rather than adding a manual proxy on top of it.
2. Make sure the client core is running, the selected node is available, and note whether the client is in Rule or Global mode.
3. Open the client's connection list or logs, then trigger a clear network request in the target app, such as refreshing its content. Note whether there is no connection entry or an entry appears but fails.
4. Use only one traffic interception method at a time. When troubleshooting the system proxy, note your current TUN settings and turn TUN off temporarily so you can tell which route is active.

In PowerShell, check whether the port is listening and test the HTTP proxy directly. The second command below only fetches response headers from a sample website to verify the port and basic proxy path; it does not confirm that the target app has loopback access.

Get-NetTCPConnection -State Listen -LocalPort 7890
curl.exe --proxy http://127.0.0.1:7890 --head https://example.com/

If nothing is listening on the port, fix the client startup or configuration first. If a request sent explicitly through the proxy also fails, check the node, authentication, and rules. Repeatedly adding app exemptions will not make a port start listening.

Method 1: Add an exemption for one app with CheckNetIsolation

CheckNetIsolation.exe is a built-in Windows tool for managing network isolation. Add an exemption only for apps that genuinely need to access a local proxy, and save the current list before making changes. Run the commands below in an elevated PowerShell window. App package queries normally apply to the currently signed-in user, so if you elevate using a different administrator account, you may not see the original user's apps.

Step 1: Check existing exemptions and app packages

CheckNetIsolation.exe LoopbackExempt -s

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

-s displays the current exemption list. PackageFamilyName is the package family name, usually made up of the package name and publisher ID. It differs from PackageFullName, which includes details such as the version and architecture. Pass the package family name to -n; do not use the app's display name.

Step 2: Identify the right package and add it

The example below uses the Microsoft Store app, whose package name is Microsoft.WindowsStore. If another app is affected, find its Name in the list from the previous step and update the query. Do not exempt the Store itself just because the app was downloaded from the Store.

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

if (@($pkg).Count -eq 1) {
    CheckNetIsolation.exe LoopbackExempt -a "-n=$($pkg.PackageFamilyName)"
} else {
    Write-Warning "No unique app package found. Check the current user and package name."
}

CheckNetIsolation.exe LoopbackExempt -s

-a adds an exemption, and the package family name follows -n= with no space. After the command succeeds, use -s to confirm the entry is present. Then fully close the target app, including any background processes, and reopen it before testing. Minimizing the window usually is not enough.

Step 3: Remove an individual exemption if needed

When an app no longer needs access to local services, use the same app package variable to remove its entry. The command below leaves other apps' settings untouched. Do not clear the entire exemption list to remove one app.

$pkg = Get-AppxPackage -Name Microsoft.WindowsStore
if (@($pkg).Count -eq 1) {
    CheckNetIsolation.exe LoopbackExempt -d "-n=$($pkg.PackageFamilyName)"
}
CheckNetIsolation.exe LoopbackExempt -s

• Access denied: Make sure PowerShell is running as an administrator, and check whether the device is managed by an organization.
• No results: Check the package name, signed-in user, and installation status. The app may also be a traditional desktop app, which this query method does not cover.
• Added successfully, but it still fails: Check whether the app uses the system proxy and whether its connections reach the core. A success message alone does not mean network access is restored.

Method 2: Use the client's built-in loopback exemption tool

Some Windows clients include a UWP loopback exemption tool, labeled something like UWP Loopback, Loopback, or App Container Exemption. Its location varies by client and version, so check the settings and documentation for your version. Do not assume another client's menu path will be the same.

1. Look for a loopback-related tool in the client settings and grant administrator permission when prompted. If your client does not include one, use the Windows command-line method above.
2. Check the app name and package ID in the list. Select only apps that need to access the internet through a local proxy, then save or apply the change.
3. Close and reopen the target app, then check whether the client receives a new connection.
4. If needed, run CheckNetIsolation.exe LoopbackExempt -s to confirm that the exemption was added at the Windows level.

These tools usually just provide a graphical interface for the same Windows setting. They do not supply nodes, repair subscriptions, or change rules. If a tool shows only process names without clearly identifying the app package, verify the target carefully to avoid granting access to unrelated apps.

Prefer per-app permissions. Exempting every app broadens access to local services and makes later troubleshooting harder. If an app is reinstalled or its package identity changes, check the list again rather than assuming the old entry still applies.

Method 3: Route app traffic with mihomo TUN

If a program ignores the system proxy, a loopback exemption will not force it to use 127.0.0.1:7890. In that case, consider TUN mode: a virtual network interface and routing rules send traffic that would otherwise go directly to its destination through mihomo, which then selects an exit based on your rules. mihomo is the successor core to Clash Meta. Whether a client supports TUN depends on its bundled core and system services.

On Windows, TUN mode usually requires administrator privileges or a service installed and started by the client. Configure it through the client's controls first, then check whether the virtual interface was created, routes were set, and DNS handling started. Do not replace your entire subscription configuration without understanding what is already there.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

This is a mihomo TUN configuration snippet, not a complete, runnable configuration. auto-route sets up routes, while auto-detect-interface detects the outbound interface. dns-hijack passes matching regular DNS requests to the core's DNS module; a valid dns configuration is also required. any:53 does not intercept all encrypted DNS traffic over DoH or DoT.

Test TUN without running into the same loopback restriction

If the app still reads the system proxy and connects directly to a local loopback address, enabling TUN does not guarantee that it will bypass a connection blocked by the sandbox. To test TUN, note your current system proxy settings, temporarily turn off the system proxy, and let the app try to reach its destination normally so TUN can route the traffic. Then fully restart the app and check the actual connection. Apps that require an explicitly configured local proxy may still need a loopback exemption.

• First confirm that both a regular website and the target app can connect, then check their matched rules to make sure traffic is not going direct unexpectedly.
• If other VPNs, virtual network adapters, or enterprise security software are running, check for default route and interface conflicts. Avoid enabling multiple system-wide traffic interception methods at once.
• If domain lookups fail, troubleshoot DNS separately. TUN does not automatically make every DNS upstream reachable.
• When testing is done, restore your intended system proxy settings and check whether the new routes affect your local network, printers, or corporate intranet.

When to use each method

If only one app is affected, first verify its package identity and try a per-app exemption to keep changes minimal. Consider TUN if several programs that ignore the system proxy need traffic interception. On managed devices, follow your organization's policies; do not disable the firewall or remove security policies as a substitute for troubleshooting.

What to check if the app still cannot connect after adding an exemption

1. First, check whether the core received the request: If there is no entry, revisit the app's proxy behavior, whether it was restarted, its package identity, and TUN routing. Log filters may hide entries.
2. Next, check the matched rule: If the connection shows DIRECT, the current rules send it direct. Check the destination domain and rule order rather than adding more exemptions.
3. Then check the exit route and protocol: Sign-in, images, and media may use different domains; some features also use UDP. Loading a homepage in your browser does not prove that every service used by the app is reachable.
4. Finally, rule out account and service issues: An expired sign-in token, incorrect system time, regional service restrictions, or a server outage can also look like a connection failure. Do not respond by installing certificates from unknown sources or disabling certificate validation.

Change one variable at a time and record the before-and-after state: local port, system proxy, exemption list, TUN setting, and matched rule. Success means the app works and its traffic takes the expected route—not merely that a command ran successfully. For a refresher on importing configurations and Rule mode, see the Getting Started Guide. To find a client that supports the interception method you need, browse the downloads for your platform.