Windows-Proxy-Labyrinth: WinINet, WinHTTP, Clash-Systemproxy und Microsoft-Store-Offline-Vorfall

AIDO debug
, , , , ,
1

In den letzten zwei Tagen hat mich das Proxy-System von Windows wieder einmal „unterrichtet“. Das offensichtliche Symptom war:

  • Chrome kommt normal ins Internet
  • In der Kommandozeile komme ich auch auf die meisten Websites
  • Der Microsoft Store sagt mir aber todsernst: Du bist nicht online

Am Ende war die Wahrheit: Nicht „kein Internet“, sondern „ein anderer Netzwerk-Stack“.

Erst das Fazit (für Eilige)

Unter Windows gibt es in der Praxis mindestens drei gängige Proxy-Einstiegspunkte:

  1. WinINet: Viele Desktop-Apps, Browser, UWP-Frontends lesen das (mit „Systemproxy“ ist meist dieses gemeint)
  2. WinHTTP: Viele Systemdienste/Background-Komponenten laufen darüber (die netsh winhttp show proxy-Schiene)
  3. Proxy per Umgebungsvariablen: HTTP_PROXY/HTTPS_PROXY/NO_PROXY, hauptsächlich für CLI-Tools

Wenn du in Clash auf „Systemproxy“ klickst, änderst du in der Regel WinINet, nicht zwingend WinHTTP.

Mein Fall: Warum „Store offline, Browser online“

Meine damalige Konfiguration:

  • WinINet = 127.0.0.1:7890 (lokaler mihomo-Proxy)
  • WinHTTP = DIRECT
  • Clash TUN an

Verhalten:

  • Chrome nutzt WinINet, kann über den Proxy, sieht daher „Netzwerk ist ok“ aus
  • Microsoft Store (UWP/AppContainer) wirft den Netzwerkfehler 0x80072EFD (CannotConnect)

Der Knackpunkt ist hier:

UWP darf standardmäßig nicht auf die lokale Loopback-Adresse zugreifen (127.0.0.1/localhost).

Wenn der Store also versucht, deinen lokalen Proxy-Port zu erreichen, wird das eventuell direkt von den Sandbox-Regeln geblockt. Nicht weil er das Internet nicht erreicht, sondern weil er zuerst gar nicht bis zum „Proxy-Eingang“ kommt.

Warum kann selbst „China-Store geht direkt“ trotzdem scheitern?

Viele sagen: storeedge.microsoft.com ist in China (Festland) ohnehin direkt erreichbar. Das stimmt, ist aber unvollständig.

Denn die Kette ist:

UWP-App -> lokaler Proxy(127.0.0.1:7890) -> Regelbasiertes Routing(DIRECT/PROXY) -> Zielseite

Wenn schon der erste Hop (UWP zur lokalen Loopback) geblockt wird, bekommt „eigentlich DIRECT“ gar keine Chance, überhaupt stattzufinden.

Die Aktion, die es diesmal wirklich gefixt hat

Ich habe weder den globalen Proxy abgeschaltet noch WinHTTP umgestellt noch bestehende abhängige Dienste angefasst—ich habe nur die minimale Änderung gemacht:

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

Dann Store neu geöffnet, wieder ok.

Das heißt UWP-Loopback-Ausnahme (loopback exempt): Für den angegebenen UWP-Paketnamen eine Whitelist setzen, damit er auf das lokale localhost/127.0.0.1 zugreifen darf.

Warum wirken Windows-Proxys so „chaotisch“?

Weil es nicht nur einen Weg gibt, sondern „mehrere Spuren parallel“:

  • Browser/Teile der Desktop-Apps: lesen WinINet
  • Systemdienste: lesen WinHTTP
  • Terminal-Tools: erkennen ggf. nur Umgebungsvariablen
  • UWP: wird zusätzlich von der Loopback-Sicherheitsrichtlinie des AppContainer beeinflusst
  • TUN: kann auf IP-Ebene nochmals einen Teil des Traffics übernehmen

Du siehst „einen Schalter“, im System sind es in Wirklichkeit „fünf Schleusen“.

Vergleich mit Linux / macOS

Linux

  • Es gibt keinen einheitlichen „Systemproxy-Hauptschalter“, der alle Apps abdeckt
  • Häufig: env-Variablen + app-spezifische Konfiguration
  • Transparenter Proxy meist über tun + iptables/nftables + policy routing
  • Vorteil: kontrollierbar, skriptbar; Nachteil: deutlich fragmentiert

macOS

  • Relativ einheitliche Proxy-Konfiguration pro Netzwerkdienst (System Settings)
  • Aber CLI-Tools schauen trotzdem oft auf env-Variablen
  • Keine UWP-artige AppContainer-Loopback-Semantik (anderes Sandbox-Modell)

Windows

  • GUI wirkt wie „einheitlicher Einstieg“, aber darunter steckt die meiste historische Altlast
  • WinINet / WinHTTP / UWP / TUN koexistieren—am ehesten entsteht „das hier geht, das andere ist offline“

Eine Checkliste, die ich jetzt oft zur Diagnose nutze

  1. WinINet prüfen: zeigt der Proxy auf 127.0.0.1:xxxx?
  2. WinHTTP prüfen: netsh winhttp show proxy
  3. Prüfen, ob der Proxy-Port wirklich lauscht (Get-NetTCPConnection)
  4. UWP-Loopback-Ausnahmen prüfen (checknetisolation loopbackexempt -s)
  5. App-Log/Fehlercode prüfen (z. B. Store 0x80072EFD)
  6. Dann erst entscheiden: Proxy-Problem, DNS-Problem oder Zielseiten-Problem

Zum Schluss ein kurzer Rant

Windows-Proxy ist nicht „falsch konfiguriert“, sondern „du hast nur eine der Schichten richtig konfiguriert“.

Wenn du merkst: Browser läuft super, aber der Store ruft „offline“—zweifle nicht sofort an dir selbst, sondern daran, dass sie überhaupt nicht denselben Weg nehmen.:slightly_smiling_face:

1 „Gefällt mir“