Windows Proxy Maze: WinINet, WinHTTP, Clash System Proxy, and the Microsoft Store Offline Incident

General
, , , ,
1

These past two days I got “educated” by Windows’ proxy system again. The surface symptoms were:

  • Chrome browses normally
  • The command line can also reach most sites
  • But the Microsoft Store solemnly tells me: you’re offline

The truth in the end: it’s not that there’s no internet—it’s that they’re “using different network stacks.”

Conclusion first (for busy people)

On Windows, there are commonly at least three proxy entry points:

  1. WinINet: many desktop apps, browsers, and UWP foreground apps read this (what “system proxy” usually refers to)
  2. WinHTTP: many system services/background components use this (the netsh winhttp show proxy one)
  3. Environment-variable proxies: HTTP_PROXY/HTTPS_PROXY/NO_PROXY, mainly for CLI tools

When you click “System Proxy” in Clash, it usually changes WinINet, not necessarily WinHTTP.

My case: why “Store offline, browser online”

My configuration at the time:

  • WinINet = 127.0.0.1:7890 (mihomo local proxy)
  • WinHTTP = DIRECT
  • Clash TUN enabled

What I saw:

  • Chrome uses WinINet, can use the proxy, so it looks like “the network is fine”
  • Microsoft Store (UWP/AppContainer) throws network error 0x80072EFD (CannotConnect)

The key point is:

By default, UWP cannot access the local loopback address (127.0.0.1/localhost).

So when the Store tries to connect to your local proxy port, it may be blocked directly by sandbox rules. It’s not that it can’t reach the internet—it just can’t reach the “proxy entry point” first.

Why can “Mainland China Store is directly reachable” still fail?

Many people would say: storeedge.microsoft.com is directly reachable in Mainland China anyway. That’s correct, but incomplete.

Because the path is:

UWP app -> local proxy(127.0.0.1:7890) -> rule-based routing(DIRECT/PROXY) -> target site

If the first hop (UWP to local loopback) is blocked, the later “should have been DIRECT” never gets a chance to happen.

What actually fixed it this time

I didn’t turn off the global proxy, didn’t change WinHTTP, didn’t touch existing dependent services—just made the smallest change:

checknetisolation loopbackexempt -a -n=microsoft.windowsstore_8wekyb3d8bbwe
checknetisolation loopbackexempt -a -n=microsoft.storepurchaseapp_8wekyb3d8bbwe
checknetisolation loopbackexempt -a -n=microsoft.xboxidentityprovider_8wekyb3d8bbwe

Then I reopened the Store, and it recovered.

This is called UWP loopback exempt: whitelist specific UWP package names to allow them to access local localhost/127.0.0.1.

Why Windows proxies look “messy”

Because it’s not one road—it’s “multiple lanes in parallel”:

  • Browsers/some desktop apps: read WinINet
  • System services: read WinHTTP
  • Terminal tools: may only honor environment variables
  • UWP: also affected by AppContainer’s loopback security policy
  • TUN: may additionally take over part of the traffic at the IP layer

You’re looking at “one switch,” but inside the system it’s actually “five gates.”

Compared with Linux / macOS

Linux

  • No unified “master system proxy switch” that covers all apps
  • Commonly env variables + per-app configuration
  • Transparent proxying usually relies on tun + iptables/nftables + policy routing
  • Pros: controllable, scriptable; cons: obvious fragmentation

macOS

  • Relatively unified per-network-service proxy configuration (System Settings)
  • But CLI tools still often look at env variables
  • No UWP-style AppContainer loopback semantics (different sandbox model)

Windows

  • GUI experience feels like a “single entry,” but it has the most historical baggage underneath
  • WinINet / WinHTTP / UWP / TUN coexist, making “this works, that’s offline” the easiest to happen

A troubleshooting order I often use now

  1. Check WinINet: is the proxy set to 127.0.0.1:xxxx?
  2. Check WinHTTP: netsh winhttp show proxy
  3. Check whether the proxy port is actually listening (Get-NetTCPConnection)
  4. Check UWP loopback exemptions (checknetisolation loopbackexempt -s)
  5. Check app log error codes (e.g., Store’s 0x80072EFD)
  6. Then decide whether it’s a proxy issue, a DNS issue, or a target-site issue

One last rant to wrap up

Windows proxy issues aren’t “configured wrong,” but rather “you only configured one layer correctly.”

When you find the browser working fine but the Store screaming offline, don’t doubt your life first—doubt that they’re even taking the same path. :slightly_smiling_face:

1 Like