Windows Lab · · Approx. 10 min read

Clash TUN On but UWP Still Bypasses? Fix Loopback Exemption and Process Rules on Windows

You enabled Clash TUN on Windows, yet the Microsoft Store, Xbox app, or other UWP clients still behave as if nothing is proxied—or they break in strange ways. This is rarely a broken subscription. It is usually a combination of Windows loopback isolation for packaged apps and routing gaps that domain rules alone cannot see. Below is a practical sequence you can follow without guessing.

1. What This Problem Looks Like

Typical reports sound contradictory at first. Chrome or Edge might show the correct exit IP while the Microsoft Store cannot download updates, in-app purchases fail, or a UWP game’s login page spins forever. Sometimes the Store opens but CDN-heavy downloads stall; other times only specific packaged apps fail while Win32 software on the same machine works perfectly through your Windows proxy stack.

Another frequent pattern is mixed use of TUN mode and system proxy: you pointed Windows at 127.0.0.1 for HTTP/S proxying, and legacy desktop apps respect it, but UWP traffic never reaches the local listener because the platform blocks loopback access by default. Separately, even with pure TUN forwarding, some traffic may still be classified in ways that your rule list does not match—especially when connections use raw IPs, QUIC, or split stacks that bypass the patterns you imported from community rule sets.

The goal of this guide is not to repeat generic advice like “turn TUN on and run as administrator.” You have already done that. Instead, we isolate two levers that power users actually use on Windows 10 and Windows 11: loopback exemption for app-container traffic and PROCESS-NAME (and related) rules in Clash Meta (mihomo) when hostname-based routing is insufficient.

2. Why “TUN On” Is Not a Magic Switch

TUN inserts a virtual interface and asks the operating system to route eligible IP traffic through your Clash core. That is powerful because it lifts application-level proxy awareness: many programs that ignore system proxy settings still follow the routing table—until they do not. Windows maintains multiple networking stacks; UWP apps run inside an app container with capability-based restrictions. Those restrictions include network isolation rules that are unrelated to whether your TUN adapter shows “up” in the control panel.

Moreover, Clash still evaluates rules in order. If your configuration sends Microsoft domains or entire countries to DIRECT because of a broad GEOIP or a conservative “domestic direct” list, then TUN being enabled does not override that policy—it simply delivers the packets to the correct outbound path you defined. Users often misread this as “TUN not working for UWP” when the engine is doing exactly what the YAML instructs.

Finally, some Microsoft services aggressively use QUIC (HTTP/3) or connect to edge caches whose names rotate. Community rule sets may lag slightly. That is where process-based matching becomes a pragmatic backstop: you identify the executable that owns the traffic, not only the domain name on the wire.

3. Loopback Isolation and UWP

By default, Windows prevents UWP applications from connecting to addresses on the local machine. The design intent is security: a malicious packaged app should not probe services on 127.0.0.1. Unfortunately, that same protection breaks legitimate scenarios where a local proxy or debugging tool listens on loopback. If your workflow relies on “system proxy → 127.0.0.1:7890” while TUN is off or partially used, UWP may silently fail rather than show a clear certificate or proxy error.

Loopback exemption (often discussed alongside CheckNetIsolation) explicitly whitelists a package family so it may use loopback interfaces. Tools such as Fiddler’s “WinConfig” or third-party loopback managers are thin wrappers around the same underlying APIs. After exemption, Store and other UWP clients can reach a local forwarder—useful when you are not relying exclusively on TUN, or when a component still tries to talk to localhost for authentication helpers.

Important nuance: if you run a pure Clash TUN setup where no critical path depends on a localhost HTTP proxy, you might still need exemption for edge cases (some frameworks spawn helper traffic locally). Do not treat exemption as obsolete just because TUN is enabled; treat it as part of a complete Windows networking profile for mixed clients.

4. Enabling Loopback Exemption (Step by Step)

Before running elevated commands, identify the package family name of the app. For Microsoft Store, names look like Microsoft.WindowsStore_8wekyb3d8bbwe (the publisher ID suffix is standard for Microsoft-signed packages). You can list installed packages in PowerShell and copy the exact string—precision matters because exemption is per package family.

The classic command-line approach uses CheckNetIsolation LoopbackExempt. An administrator PowerShell or CMD session can add an exemption entry similar to the following illustration (verify the name against your system):

# Run in an elevated shell; replace the package name with your exact FamilyName
CheckNetIsolation LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"

To audit what is already exempt, use the listing mode of the same utility and confirm your entry appears. If you prefer a graphical tool, use a reputable loopback exemption manager, apply changes, then reboot the app—not necessarily the whole OS—to clear cached network handles. After exemption, retest the Store with a small app update or a free title download while observing your Clash logs.

If you operate multiple UWP clients (games, subscription services, creative tools), repeat the process per family. Keep a short personal note of which packages required exemption so future reinstalls or Insider builds do not send you back to square one. This discipline matters because large Windows updates occasionally reset networking stacks or reorder adapters—another reason people mistakenly blame Clash TUN when the OS changed underneath.

5. When Domains Lie: PROCESS-NAME Rules

Modern Clash Meta builds support matching traffic by originating process name. That is invaluable for UWP binaries whose network behavior spans many hostnames, CDNs, and occasional IP literals. Instead of chasing every new Microsoft edge domain, you pin the executable—such as WinStore.App.exe for the Store shell—to a policy group that uses the proxy chain you trust.

Place PROCESS-NAME rules carefully: they are powerful but can be overly broad if you point a system binary at an aggressive outbound. Prefer narrow targets (the specific app you are fixing) and keep them near the top of your rule chain—before huge GEOIP shortcuts—so they actually take effect. Combine with PROCESS-PATH when you need finer discrimination on disk, especially if multiple executables share similar names.

Remember that rule precedence interacts with your TUN implementation: TUN ensures packets enter the engine; rules decide the outbound. If you route a process to DIRECT intentionally, TUN will not “force” a foreign exit IP—by design. Re-read your policy groups when debugging: a fallback or url-test group may still rotate nodes underneath a process rule if you pointed the rule at that group.

For hybrid environments—WSL2, Docker Desktop, virtual machines—remember those stacks have separate interfaces and sometimes separate DNS views. A UWP symptom on the host will not mirror a Linux guest’s behavior. Document which interface each workload uses so you do not conflate unrelated issues with Clash routing on the primary Windows desktop.

6. Example Snippets for mihomo / Clash Meta

The following YAML fragments are illustrative. Replace proxy group names with those defined in your own subscription merge, and confirm process names using Task Manager details or Clash logging. Mis-typed executable names silently fail to match.

① Route a specific Windows Store process to your chosen policy group:

rules:
  # Example only — confirm the .exe name on your build
  - PROCESS-NAME,WinStore.App.exe,🔰 Proxy
  - PROCESS-NAME,GameBarPresenceWriter.exe,DIRECT

② If you maintain a dedicated Microsoft or UWP group, chain it above broad direct rules for China or private networks. This ordering pattern is commonly used in “split” configs where domestic traffic stays fast but selected foreign-backed apps still need an exit node.

rules:
  - PROCESS-PATH,C:\Program Files\WindowsApps\*,🔰 Proxy
  # Wildcard paths are powerful — test thoroughly before relying on them in production
  - GEOIP,CN,DIRECT
  - MATCH,🔰 Proxy

Wildcard PROCESS-PATH entries can be risky; start with explicit PROCESS-NAME pairs and expand only when necessary. Always keep a rollback copy of your working YAML—Clash Verge Rev and similar clients make this easy through profile snapshots or merge files.

7. Common Misconceptions

“TUN replaces rules.”

TUN changes how traffic reaches the proxy core; it does not replace your YAML policy. Conflicting DIRECT shortcuts still win.

“System proxy equals UWP proxy.”

UWP does not behave like Win32. Loopback restrictions and capability flags matter as much as the proxy toggle.

“One domain rule should cover the Store.”

CDN front-ends and QUIC can dodge yesterday’s DOMAIN-SUFFIX lists. Process-level matching is the pragmatic safety net.

Another subtle mistake is assuming administrator elevation fixes UWP isolation. Running Clash elevated is often required for TUN installation, but elevation does not grant arbitrary UWP apps permission to speak to localhost—that is what loopback exemption addresses. Treat these as orthogonal concerns and verify both.

8. Verification Checklist

Work through this list in order: confirm TUN adapter status and Clash logs show the target flows; validate rule hit counters or trace output for the UWP process; temporarily simplify rules to a known-good profile to exclude subscription corruption; apply or re-apply loopback exemption and retest Store downloads; finally, add or tighten PROCESS-NAME rows and observe changes incrementally rather than editing ten variables at once.

Compared with opaque “connection reset” mysteries, this workflow is boring—and that is the point. You are aligning Windows platform constraints with Clash’s policy model. Once loopback and process rules agree, most stubborn UWP cases collapse into ordinary tuning: pick a stable node, avoid aggressive load-balancing for fragile services, and keep your rule sets updated.

Closing Thoughts

Getting Clash TUN, UWP containers, and fine-grained PROCESS-NAME policies to line up is less about secret flags and more about respecting how Windows isolates apps. The upside is predictability: once loopback exemption is in place and your YAML reflects real executables—not only yesterday’s domain lists—your desktop and Store apps finally share the same transparent story.

Modern Clash clients that bundle the mihomo core already give you the tools to express that story cleanly. If you are migrating from an older stack, the difference is night and day: fewer brittle workarounds, clearer logs, and routing that survives CDN churn. For a client that stays current with the ecosystem and keeps complex profiles manageable, many power users naturally land on actively maintained GUIs—much like the journey described in our CFW migration guide—while pairing them with disciplined YAML hygiene on Windows.

When you are ready to standardize on one installer channel and validate checksums in one place, use our download center instead of hunting scattered release pages—then layer TUN, rules, and exemptions in the order above. → Download Clash for free and experience the difference

Related Reading