---

The Symptom: Regular Apps Proxy Fine, Store Apps Don't

After enabling the system proxy for Clash or the mihomo core on Windows — or even after turning on TUN mode — most desktop apps (browsers, command-line tools, traditional exe programs) route outbound traffic through your proxy rules just fine. But some apps installed from the Microsoft Store — certain mail clients, store-distributed versions of some browsers, UWP-packaged cross-platform chat apps — show a classic "proxy isn't taking effect" symptom: sites that work over a direct connection load fine, but anything requiring the proxy times out or throws a network error, even though the system proxy settings correctly point to the local port.

It's easy to go down the wrong troubleshooting path here. Most people's first instinct is to suspect a dead subscription node, a crashed core, or a misconfigured rule, and they'll restart the client and re-import the subscription over and over with zero results. The real reason is much simpler: the problem isn't on the proxy service side at all. Windows applies a separate isolation layer to UWP (Universal Windows Platform) apps that's independent of how normal processes work, and by default it cuts off UWP apps' loopback communication with 127.0.0.1 / localhost — which happens to be exactly how nearly all local proxy clients (including the Clash family of cores) expose their HTTP/SOCKS5 proxy ports.

Why It Happens: UWP Sandboxing and Loopback Isolation

To understand this restriction, you first need to know that UWP apps run completely differently from traditional Win32 programs. UWP apps run inside a sandbox called AppContainer, and Microsoft assigns each UWP app its own security identifier (SID), strictly controlling which network resources it can reach through a mechanism called Network Isolation. The design intent behind this is security: it prevents store apps from freely accessing services on the local network or on other local ports without explicitly declaring the need to, reducing the risk of lateral movement and data leakage.

One key rule in the network isolation policy: UWP apps are blocked by default from reaching any service on the same machine that's listening on a loopback address (127.0.0.1 or ::1), unless that service is itself packaged and running as a UWP app. This explains why the problem only shows up in store apps — traditional desktop programs aren't constrained by AppContainer and can freely connect to any local port, while UWP apps get every outbound connection attempt blocked at this isolation check before it even reaches the network layer, no matter how correctly the system proxy is configured. This shows up especially clearly when the target is a local proxy port like 127.0.0.1:7890.

It's worth noting this restriction has nothing to do with whether your proxy software has "allow LAN connections" turned on, or whether it's listening on 0.0.0.0 versus 127.0.0.1 — even if the proxy is listening on all interfaces, loopback requests from a UWP app still get blocked by the system-level isolation policy. This is OS-level behavior, and there's no setting in the client's config file that can work around it.

First, Confirm It's Actually the Loopback Restriction

Before you go fixing anything, it's worth doing two quick checks so you don't misdiagnose the problem:

1. Confirm the affected app is actually a store app. Right-click the app's icon in the Start menu — if you see an "Advanced options" entry alongside "Uninstall," that usually means it's a UWP app; traditional Win32 programs generally go straight to an uninstall entry. You can also check the source label in Settings under "Apps & features."
2. Confirm the proxy service itself is working correctly. Manually test the same proxy port with a browser or command-line tool — for example, use curl with the proxy explicitly set to hit an address that requires the proxy to load. If a traditional program like this can get out fine, you can rule out the proxy config or the node itself, and the issue is squarely pointing at UWP network isolation.

If both checks line up, you can be fairly confident the connection failure is caused by the loopback restriction, and the next step is simply to grant a loopback exemption for that specific UWP app.

Fix 1: Lifting the Restriction via CheckNetIsolation

Windows ships with a built-in command-line tool, CheckNetIsolation.exe, specifically for managing the AppContainer network isolation allowlist. This is the official, standard fix, and it doesn't require installing any extra software.

Step 1: Find the App's Package Family Name

Open PowerShell as administrator and run the following command to list all UWP apps currently installed on the system along with their package names:

Get-AppxPackage | Select-Object Name, PackageFamilyName

Find the entry for your target app in the returned list and note its PackageFamilyName field, which looks something like 12345Publisher.AppName_abcdefghijk1m. This exact string is required for the next command — you can't substitute the app's display name.

Step 2: Add the Loopback Exemption

Close PowerShell and open Command Prompt (cmd) as administrator, then run:

CheckNetIsolation.exe LoopbackExempt -a -n="12345Publisher.AppName_abcdefghijk1m"

If the command runs without an error, the exemption was added successfully — there's no extra success popup. This adds the specified app to the loopback exemption list, allowing it to reach services listening on the local machine's 127.0.0.1, including the HTTP/SOCKS5 port opened by your proxy client.

Checking and Reversing the Exemption

To see the current list of exempted apps, run:

CheckNetIsolation.exe LoopbackExempt -s

If you later need to revoke an app's exemption (say, to restore the default isolation state while debugging something else), just swap -a for -d:

CheckNetIsolation.exe LoopbackExempt -d -n="12345Publisher.AppName_abcdefghijk1m"

Worth noting: this exemption list doesn't sync across devices, and it isn't automatically preserved if you uninstall and reinstall the app — you'll need to run the add command again after a reinstall.

Fix 2: Using a GUI Tool

If you'd rather not type commands or worry about mistyping the package name, a graphical tool can do the same job. EnableLoopback, a small open-source tool that's fairly widely shared in Microsoft community circles, is essentially a UI wrapper around CheckNetIsolation.exe — it doesn't change the underlying mechanism at all, and the logic is identical to the command-line approach:

1. Run the tool as administrator. On launch, it automatically reads the full list of UWP apps currently installed on the system and shows the current loopback exemption status for each one.
2. Check the boxes for the apps you need to unrestrict (you can select multiple, letting you handle several affected store apps at once), then click "Modify" to apply the changes.
3. What the tool does under the hood is exactly equivalent to running the command manually — checking a box adds the exemption, unchecking it removes it, and you never have to remember or copy a package name.

For situations where you need to toggle exemptions frequently, or need to handle several apps at once, a GUI tool is more convenient than repeatedly typing commands. But for a one-off fix on a single app, the command line is usually faster and doesn't require downloading and installing a third-party tool.

Verifying the Fix Actually Worked

After setting up the exemption, verify it in the following order rather than relying on a vague impression like "the app seems to load faster now":

• Fully close and reopen the app. A UWP app's network session is usually established at launch, so exemption changes often don't take effect hot while the app is still running — you need to fully quit the process and relaunch it for the new isolation policy to apply.
• Access something that clearly requires the proxy to load. Avoid judging by the app's home screen, which may be showing locally cached content — pick a feature that must fetch live data over the network and is clearly within the scope of your proxy rules.
• Check the proxy client's connection log or active connections panel. If the client's interface shows a connection record originating from that app, the traffic really is flowing through the proxy chain. If there's nothing related in the log at all, the exemption didn't take effect, and you should double-check whether the package name was copied correctly and whether the command was run with administrator privileges.

One detail that's easy to overlook: some UWP apps can still be restricted even after loopback isolation is lifted, if they haven't declared the relevant network access capability in their app manifest. This mostly comes up with apps distributed through enterprise-custom channels and rarely with regular store apps — if things still don't work after lifting isolation, check the app's declared capabilities in its manifest.

Other Ways to Sidestep the Loopback Restriction

If you'd rather not go through this process app by app, or you're dealing with a large and constantly changing set of affected apps, there are two approaches that avoid the restriction at the root:

Switch to TUN Mode

As mentioned earlier, the loopback restriction specifically targets apps that actively connect to a local proxy port. If your client supports TUN mode, enabling it creates a virtual network adapter on the system, and traffic from every process — including UWP apps subject to isolation — gets intercepted and forwarded uniformly at the adapter level. Apps no longer need to connect to a proxy port on 127.0.0.1 themselves, so they're naturally unaffected by the loopback isolation policy. If you regularly run into store app connection issues, switching straight to TUN mode is often less hassle than adding exemptions one at a time.

Adjust Listening Address and Firewall Rules Alongside the System Proxy

In some scenarios you could also consider adjusting the system proxy's scope to cover a lower-level network configuration, but changes like this usually come with other compatibility trade-offs and aren't as direct as the two approaches above — this generally isn't the first option to reach for, and is worth considering only in special environments where neither TUN mode nor per-app exemptions are workable.

---

The loopback restriction is a security design built into Windows itself, not a flaw in the proxy client — understanding this saves a lot of time spent troubleshooting the wrong thing. When you hit the tell-tale symptom of "only store apps can't reach the proxy," lifting the exemption via the package name using either the CheckNetIsolation command or a GUI tool usually resolves it within a few minutes. If you're dealing with a lot of apps or don't want to maintain an allowlist, switching to TUN mode is the lower-maintenance long-term fix.