Лабиринт прокси в Windows: WinINet, WinHTTP, системный прокси Clash и инцидент с офлайн-режимом Microsoft Store

AIDO debug
, , , , ,
1

В эти два дня Windows снова преподал мне урок про свою прокси-систему. Внешние симптомы такие:

  • Chrome нормально выходит в интернет
  • Командная строка тоже может открывать большинство сайтов
  • Microsoft Store же совершенно серьёзно сообщает: у вас нет подключения к интернету

В итоге правда оказалась такой: дело не в том, что «нет интернета», а в том, что «используются разные сетевые стеки».

Сначала вывод (для занятых)

В Windows обычно есть как минимум три «входа» для прокси:

  1. WinINet: многие десктопные приложения, браузеры, UWP на переднем плане читают его (то, что обычно называют «системным прокси», чаще всего про это)
  2. WinHTTP: многие системные службы/фоновые компоненты ходят через него (набор команд netsh winhttp show proxy)
  3. Прокси через переменные окружения: HTTP_PROXY/HTTPS_PROXY/NO_PROXY, в основном для CLI-инструментов

Когда вы в Clash нажимаете «системный прокси», обычно меняется WinINet, но не обязательно WinHTTP.

Мой кейс: почему «Store офлайн, браузер онлайн»

Моя конфигурация на тот момент:

  • WinINet = 127.0.0.1:7890（локальный прокси mihomo）
  • WinHTTP = DIRECT
  • Clash TUN включён

Проявления:

  • Chrome идёт через WinINet, может использовать прокси — поэтому «кажется, что сеть нормальная»
  • Microsoft Store（UWP/AppContainer）даёт сетевую ошибку 0x80072EFD（CannotConnect）

Ключевой момент здесь:

По умолчанию UWP не может обращаться к локальному loopback-адресу（127.0.0.1/localhost）。

Поэтому когда Store пытается подключиться к вашему локальному прокси-порту, его может напрямую блокировать правило песочницы. Дело не в том, что он не может выйти в интернет — он сначала не может добраться до «входа в прокси».

Почему даже «в материковом Китае Store и так ходит напрямую» может сломаться?

Многие скажут: storeedge.microsoft.com в материковом Китае и так доступен напрямую. Это верно, но не полностью.

Потому что цепочка такая:

UWP-приложение -> локальный прокси(127.0.0.1:7890) -> маршрутизация по правилам(DIRECT/PROXY) -> целевой сайт

Если первый прыжок（UWP к локальному loopback）блокируется, то дальше «должно было пойти напрямую» просто не имеет шанса произойти.

Что на самом деле починило это в этот раз

Я не выключал глобальный прокси, не менял WinHTTP, не трогал существующие зависимые службы — сделал только минимальное изменение:

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

Потом перезапустил Store — и всё восстановилось.

Это называется исключение loopback для UWP（loopback exempt）: добавляем белый список для указанного имени пакета UWP, разрешая ему доступ к локальному localhost/127.0.0.1。

Почему прокси в Windows выглядит «хаотично»

Потому что это не одна дорога, а «несколько полос параллельно»:

  • браузеры/часть десктопных приложений: читают WinINet
  • системные службы: читают WinHTTP
  • терминальные утилиты: могут признавать только переменные окружения
  • UWP: ещё и зависит от политики безопасности loopback в AppContainer
  • TUN: может на IP-уровне перехватывать часть трафика

Вы видите «один переключатель», а в системе по факту «пять шлюзов».

Сравнение с Linux / macOS

Linux

  • нет единого «общесистемного переключателя прокси», который покрывает все приложения
  • обычно это env-переменные + отдельные настройки в приложениях
  • прозрачный прокси обычно делается через tun + iptables/nftables + policy routing
  • плюсы: управляемо, легко автоматизировать скриптами; минусы: заметная фрагментация

macOS

  • есть относительно единая прокси-настройка сетевого сервиса（System Settings）
  • но CLI-инструменты всё равно часто смотрят env-переменные
  • нет семантики UWP AppContainer loopback（другая модель песочницы）

Windows

  • в GUI выглядит как «единая точка входа», но исторических слоёв больше всего
  • WinINet / WinHTTP / UWP / TUN сосуществуют — поэтому чаще всего и бывает «тут работает, а тут офлайн»

Мой текущий порядок диагностики

  1. Проверить WinINet: включён ли прокси на 127.0.0.1:xxxx
  2. Проверить WinHTTP: netsh winhttp show proxy
  3. Проверить, слушает ли реально прокси-порт（Get-NetTCPConnection）
  4. Проверить исключения loopback для UWP（checknetisolation loopbackexempt -s）
  5. Посмотреть код ошибки в логах приложения（например, у Store это 0x80072EFD）
  6. И только потом решать, это прокси, DNS или проблема целевого сайта

И напоследок — одна реплика

Прокси в Windows — это не «вы настроили неправильно», а «вы правильно настроили только один слой».

Когда видите: браузер работает как ни в чём не бывало, а Store кричит «нет сети», не спешите сомневаться в себе — сначала подозревайте, что они вообще не по одной и той же дороге ходят.:slightly_smiling_face:

1 лайк