Labyrinthe des proxys Windows : WinINet, WinHTTP, proxy système Clash et incident hors ligne du Microsoft Store

AIDO debug
, , , , ,
1

Ces deux derniers jours, Windows et son système de proxy m’ont encore donné une leçon. Les symptômes en surface étaient :

  • Chrome navigue normalement
  • La ligne de commande peut aussi accéder à la plupart des sites
  • Mais le Microsoft Store me dit très sérieusement : vous n’êtes pas connecté à Internet

Au final, la vérité c’était : ce n’est pas qu’il n’y a pas Internet, c’est que “ça passe par une pile réseau différente”.

D’abord la conclusion (pour les pressés)

Sous Windows, on trouve couramment au moins trois “entrées” de proxy :

  1. WinINet : beaucoup d’applications desktop, les navigateurs, et l’avant-plan UWP le lisent (le “proxy système” fait généralement référence à celui-là)
  2. WinHTTP : beaucoup de services système / composants en arrière-plan passent par lui (la famille netsh winhttp show proxy)
  3. Les variables d’environnement : HTTP_PROXY/HTTPS_PROXY/NO_PROXY, principalement pour les outils CLI

Quand tu cliques sur “proxy système” dans Clash, tu modifies en général WinINet, pas forcément WinHTTP.

Mon cas : pourquoi “Store hors ligne, navigateur en ligne”

Ma configuration sur le moment :

  • WinINet = 127.0.0.1:7890 (proxy local mihomo)
  • WinHTTP = DIRECT
  • TUN de Clash activé

Comportement :

  • Chrome passe par WinINet, donc utilise le proxy : on a l’impression que “le réseau est normal”
  • Le Microsoft Store (UWP/AppContainer) remonte une erreur réseau 0x80072EFD (CannotConnect)

Le point clé est ici :

Par défaut, UWP ne peut pas accéder à l’adresse loopback locale (127.0.0.1/localhost).

Donc quand le Store essaie de se connecter au port proxy local, il peut être directement bloqué par les règles du bac à sable. Ce n’est pas qu’il ne peut pas accéder à Internet, c’est qu’il n’arrive même pas à atteindre “l’entrée du proxy”.

Pourquoi “le Store en Chine continentale peut être en direct” peut quand même planter ?

Beaucoup diront : storeedge.microsoft.com est accessible en direct en Chine continentale. C’est vrai, mais incomplet.

Parce que le chemin réel est :

Application UWP -> Proxy local(127.0.0.1:7890) -> Routage par règles(DIRECT/PROXY) -> Site cible

Si le premier saut (UWP vers la loopback locale) est bloqué, le “devrait être en direct” n’a tout simplement aucune chance de se produire.

L’action qui a vraiment corrigé le problème cette fois

Je n’ai pas désactivé le proxy global, je n’ai pas modifié WinHTTP, je n’ai touché à aucun service existant : j’ai fait le changement minimal suivant :

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

Puis j’ai relancé le Store : rétabli.

Ça s’appelle l’exemption loopback UWP (loopback exempt) : on met sur liste blanche un nom de package UWP spécifique, pour l’autoriser à accéder à localhost/127.0.0.1.

Pourquoi le proxy Windows paraît “chaotique”

Parce que ce n’est pas une seule route, mais des “voies parallèles” :

  • Navigateur / une partie des applis desktop : lit WinINet
  • Services système : lit WinHTTP
  • Outils terminal : peuvent ne reconnaître que les variables d’environnement
  • UWP : est aussi soumis à la stratégie de sécurité loopback d’AppContainer
  • TUN : peut encore intercepter une partie du trafic au niveau IP

Toi tu vois “un interrupteur”, mais dans le système, en réalité, c’est “cinq vannes”.

Comparaison avec Linux / macOS

Linux

  • Il n’existe pas de “bouton proxy système” unique qui couvre toutes les applications
  • Le plus courant : variables env + configuration propre à chaque application
  • Les proxys transparents reposent souvent sur tun + iptables/nftables + policy routing
  • Avantages : contrôlable, scriptable ; inconvénients : fragmentation évidente

macOS

  • Configuration de proxy des services réseau relativement unifiée (System Settings)
  • Mais les outils CLI regardent encore souvent les variables env
  • Il n’y a pas de sémantique AppContainer loopback comme UWP (modèle de sandbox différent)

Windows

  • L’expérience GUI ressemble à une “entrée unifiée”, mais l’historique technique est le plus lourd
  • WinINet / WinHTTP / UWP / TUN coexistent : c’est le plus facile d’obtenir “celui-ci marche, celui-là est hors ligne”

Un ordre de diagnostic que j’utilise souvent maintenant

  1. Regarder WinINet : le proxy pointe-t-il sur 127.0.0.1:xxxx ?
  2. Regarder WinHTTP : netsh winhttp show proxy
  3. Vérifier que le port proxy écoute vraiment (Get-NetTCPConnection)
  4. Vérifier les exemptions loopback UWP (checknetisolation loopbackexempt -s)
  5. Regarder les codes d’erreur dans les logs de l’appli (par ex. 0x80072EFD du Store)
  6. Ensuite déterminer si c’est un problème de proxy, de DNS, ou du site cible

Une phrase de râlage pour conclure

Le proxy Windows, ce n’est pas “mal configuré”, c’est “tu n’as bien configuré qu’une des couches”.

Quand tu constates : le navigateur va très bien, mais le Store crie qu’il n’y a pas Internet, ne commence pas par remettre ta vie en question : commence par suspecter qu’ils n’empruntent tout simplement pas la même route. :slightly_smiling_face:

1 « J'aime »