Laberinto de proxies en Windows: WinINet, WinHTTP, proxy del sistema de Clash e incidente de Microsoft Store sin conexión

General
, , , ,
1

Estos dos días volví a recibir una lección del sistema de proxies de Windows. El síntoma superficial era:

  • Chrome navega normal
  • La línea de comandos también puede acceder a la mayoría de los sitios
  • Pero Microsoft Store, muy seria, me dice: no estás conectado a Internet

Al final, la verdad fue: no es que no haya Internet, es que “usan pilas de red distintas”.

Primero la conclusión (para gente ocupada)

En Windows, comúnmente hay al menos tres entradas de proxy:

  1. WinINet: muchas apps de escritorio, navegadores y UWP en primer plano lo leen (normalmente “proxy del sistema” se refiere a este)
  2. WinHTTP: muchos servicios del sistema/componentes en segundo plano usan este (la familia de netsh winhttp show proxy)
  3. Proxy por variables de entorno: HTTP_PROXY/HTTPS_PROXY/NO_PROXY, principalmente para herramientas CLI

Cuando en Clash haces clic en “proxy del sistema”, normalmente cambia WinINet, no necesariamente WinHTTP.

Mi caso: por qué “Store sin conexión, navegador con conexión”

Mi configuración en ese momento:

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

Comportamiento:

  • Chrome va por WinINet, puede usar el proxy, así que parece que “la red está normal”
  • Microsoft Store (UWP/AppContainer) da error de red 0x80072EFD (CannotConnect)

El punto clave es este:

UWP por defecto no puede acceder a la dirección de loopback local (127.0.0.1/localhost).

Así que cuando Store intenta conectarse al puerto del proxy local, puede que lo bloquee directamente la regla del sandbox. No es que no pueda acceder a Internet, es que primero no puede llegar a la “entrada del proxy”.

¿Por qué incluso si “Store en China continental puede ir directo” también se rompe?

Mucha gente dirá: storeedge.microsoft.com en China continental de por sí puede ir directo. Eso no está mal, pero está incompleto.

Porque la ruta es:

App UWP -> proxy local(127.0.0.1:7890) -> desvío por reglas(DIRECT/PROXY) -> sitio objetivo

Si el primer salto (UWP hacia loopback local) ya está bloqueado, lo de “debería ir directo” ni siquiera tiene oportunidad de ocurrir.

La acción que de verdad lo arregló esta vez

No apagué el proxy global, no cambié WinHTTP, no toqué servicios existentes de los que dependo; solo hice el cambio mínimo:

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

Luego reabrí Store y se recuperó.

Esto se llama excepción de loopback de UWP (loopback exempt): se añade el nombre del paquete UWP indicado a una lista blanca, permitiéndole acceder al localhost/127.0.0.1 local.

Por qué el proxy de Windows parece “un caos”

Porque no es un solo camino, sino “varios carriles en paralelo”:

  • Navegadores / parte de las apps de escritorio: leen WinINet
  • Servicios del sistema: leen WinHTTP
  • Herramientas de terminal: puede que solo reconozcan variables de entorno
  • UWP: además está afectado por la política de seguridad de loopback de AppContainer
  • TUN: además puede tomar control de parte del tráfico a nivel IP

Tú ves “un interruptor”, pero en el sistema realmente son “cinco compuertas”.

Comparación con Linux / macOS

Linux

  • No hay un “interruptor general de proxy del sistema” que cubra todas las apps
  • Lo común es variables env + configuración propia de cada app
  • El proxy transparente suele apoyarse en tun + iptables/nftables + policy routing
  • Ventaja: controlable y automatizable; desventaja: fragmentación evidente

macOS

  • Tiene una configuración de proxy relativamente unificada por servicio de red (System Settings)
  • Pero las herramientas CLI aún suelen mirar variables env
  • No existe esta semántica de loopback de AppContainer tipo UWP (el modelo de sandbox es distinto)

Windows

  • La experiencia GUI parece “una entrada unificada”, pero por debajo es donde más deuda histórica hay
  • WinINet / WinHTTP / UWP / TUN conviven: es lo más fácil para que pase “esto funciona, aquello está offline”

Un orden de diagnóstico que ahora uso a menudo

  1. Revisar WinINet: si el proxy está puesto en 127.0.0.1:xxxx
  2. Revisar WinHTTP: netsh winhttp show proxy
  3. Revisar si el puerto del proxy realmente está escuchando (Get-NetTCPConnection)
  4. Revisar las excepciones de loopback de UWP (checknetisolation loopbackexempt -s)
  5. Revisar el código de error en los logs de la app (por ejemplo 0x80072EFD de Store)
  6. Luego decidir si es problema de proxy, de DNS o del sitio objetivo

Un comentario final de queja

El proxy de Windows no es “que lo configuraste mal”, sino “solo configuraste bien una de las capas”.

Cuando veas que: el navegador va perfecto pero Store grita que no hay Internet, no dudes de tu vida: duda primero de que ni siquiera estén pasando por el mismo camino. :slightly_smiling_face: