Labirinto de proxies no Windows: WinINet, WinHTTP, proxy do sistema do Clash e indisponibilidade da Microsoft Store

AIDO debug
, , , , ,
1

Nesses últimos dois dias, fui “educado” mais uma vez pelo sistema de proxy do Windows. O sintoma na superfície era:

  • Chrome navega normalmente
  • A linha de comando também consegue acessar a maioria dos sites
  • A Microsoft Store, porém, com toda seriedade, me diz: você não está conectado à internet

No fim, a verdade foi: não é falta de internet, é que “está usando uma pilha de rede diferente”.

Primeiro a conclusão (para quem está com pressa)

No Windows, é comum existirem pelo menos três entradas de proxy:

  1. WinINet: muitos apps desktop, navegadores, UWP em primeiro plano leem isso (o “proxy do sistema” geralmente se refere a este)
  2. WinHTTP: muitos serviços do sistema/componentes em segundo plano usam isso (aquela coisa do netsh winhttp show proxy)
  3. Proxy por variáveis de ambiente: HTTP_PROXY/HTTPS_PROXY/NO_PROXY, principalmente para ferramentas CLI

Quando você clica em “proxy do sistema” no Clash, normalmente ele altera o WinINet, não necessariamente o WinHTTP.

Meu caso: por que “Store offline, navegador online”

Minha configuração na hora:

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

Comportamento:

  • Chrome usa WinINet, consegue usar o proxy, então parece que “a rede está normal”
  • Microsoft Store (UWP/AppContainer) dá erro de rede 0x80072EFD (CannotConnect)

O ponto-chave é este:

Por padrão, UWP não pode acessar o endereço de loopback local (127.0.0.1/localhost).

Então, quando a Store tenta se conectar à porta do proxy local, pode ser bloqueada direto pelas regras do sandbox. Não é que ela não consiga acessar a internet; é que ela nem consegue chegar primeiro na “entrada do proxy”.

Por que “a Store da China continental pode conectar direto” também pode dar ruim?

Muita gente diz: storeedge.microsoft.com na China continental já dá para acessar direto. Isso está correto, mas incompleto.

Porque o caminho é:

Aplicativo UWP -> proxy local(127.0.0.1:7890) -> desvio por regras(DIRECT/PROXY) -> site de destino

Se o primeiro salto (UWP para loopback local) é bloqueado, o “deveria ser direto” nem tem chance de acontecer.

O que realmente consertou desta vez

Eu não desliguei o proxy global, não mexi no WinHTTP, não toquei em serviços dependentes; fiz só a mudança mínima:

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

Depois reabri a Store, voltou ao normal.

Isso se chama exceção de loopback UWP (loopback exempt): abre uma whitelist para o nome do pacote UWP especificado, permitindo que ele acesse localhost/127.0.0.1 localmente.

Por que o proxy do Windows parece “bagunçado”

Porque não é uma estrada só, e sim “várias faixas em paralelo”:

  • Navegadores/parte dos apps desktop: leem WinINet
  • Serviços do sistema: leem WinHTTP
  • Ferramentas de terminal: podem só reconhecer variáveis de ambiente
  • UWP: ainda é afetado pela política de segurança de loopback do AppContainer
  • TUN: ainda pode assumir parte do tráfego na camada IP

Você vê “um interruptor”, mas no sistema na prática são “cinco comportas”.

Comparação com Linux / macOS

Linux

  • Não existe um “interruptor mestre de proxy do sistema” que cubra todos os apps
  • O comum é variáveis env + configuração específica de cada app
  • Proxy transparente normalmente depende de tun + iptables/nftables + policy routing
  • Vantagem: controlável, scriptável; desvantagem: fragmentação evidente

macOS

  • Há uma configuração de proxy relativamente unificada por serviço de rede (System Settings)
  • Mas ferramentas CLI ainda costumam olhar variáveis env
  • Não existe essa semântica de loopback do AppContainer tipo UWP (modelo de sandbox diferente)

Windows

  • A experiência GUI parece um “ponto de entrada unificado”, mas por baixo é o que tem mais dívida histórica
  • WinINet / WinHTTP / UWP / TUN coexistem; é o mais fácil de aparecer “este funciona, aquele fica offline”

Um fluxo de diagnóstico que eu uso bastante agora

  1. Ver WinINet: o proxy está apontando para 127.0.0.1:xxxx?
  2. Ver WinHTTP: netsh winhttp show proxy
  3. Ver se a porta do proxy está realmente escutando (Get-NetTCPConnection)
  4. Ver exceções de loopback UWP (checknetisolation loopbackexempt -s)
  5. Ver o código de erro nos logs do app (por exemplo o 0x80072EFD da Store)
  6. Aí decidir se é problema de proxy, DNS ou do site de destino

Um desabafo para fechar

O proxy do Windows não é “configuração errada”, e sim “você só configurou certo uma das camadas”.

Quando você perceber: o navegador está ok, mas a Store grita sem internet, não duvide da sua sanidade; suspeite primeiro que elas simplesmente não estão indo pela mesma estrada. :slightly_smiling_face:

1 Curtiu