В WSL 3.0.5 появился управляемый доступ контейнеров к localhost Windows

В версии WSL 3.0.5, отмеченной в репозитории Microsoft 29 октября 2026 года, для WSLC SDK добавили настройку доступа контейнеров к сервисам, запущенным на самом компьютере с Windows. Изменение касается прежде всего приложений, которые создают собственные сеансы Linux-контейнеров и сталкиваются с ошибками подключения к локальному серверу.

Контейнеры WSLC теряли доступ к host.wslc.internal в отдельных сеансах

Проблему хорошо показывает обращение в репозиторий Microsoft от 21 октября. Разработчик запустил контейнер через стандартный сеанс WSLC, и тот смог обратиться к HTTP-серверу на Windows по имени host.wslc.internal. При первом запуске контейнера в собственном, созданном через SDK сеансе то же имя переставало определяться.

В журнале появлялась ошибка curl: (6) Could not resolve host: host.wslc.internal. Запрос даже не доходил до локального HTTP-сервера: контейнер не мог преобразовать имя узла в сетевой адрес. Позднее в описанном сценарии соединение начинало работать, что делало неисправность особенно неудобной для воспроизведения.

Такая ситуация затрагивает программы, которые создают отдельные контейнерные среды для сборки проектов, тестирования или запуска локальных инструментов. Например, приложение на Windows может поднять собственный HTTP-сервис и ожидать, что Linux-контейнер сможет к нему подключиться во время первой сборки образа.

Настройка HostLoopback задаёт адрес Windows-хоста для сеанса WSLC

В WSL 3.0.5 Microsoft добавила в WSLC SDK необязательную настройку имени хоста. С её помощью разработчик может разрешить контейнерам определённого сеанса обращаться к сервисам, слушающим локальный интерфейс Windows, через выбранное доменное имя — например, host.wslc.internal.

В интерфейсах для C# и C++/WinRT эта возможность представлена свойством SessionSettings.HostLoopback. Для приложений на C предусмотрена функция WslcSetSessionSettingsHostLoopback. Настройка задаётся при создании сеанса; по умолчанию она выключена. Таким образом, включение доступа остаётся решением приложения, управляющего контейнерами.

Есть и дополнительное условие: у контейнера должна быть включена сеть. В документации Microsoft в качестве примера указан режим Bridged. Одного указания имени хоста недостаточно, если контейнер запущен без сетевого подключения.

Изменение касается WSLC SDK, а не всех дистрибутивов WSL

WSL позволяет запускать Linux-программы и дистрибутивы внутри Windows. С сентября 2026 года Microsoft также предоставляет WSL Containers (WSLC) — отдельный механизм работы с Linux-контейнерами через команду wslc.exe и программный API. Именно этот API получил новую настройку.

У обычных дистрибутивов WSL уже существуют свои способы связи с Windows-хостом. В сетевом режиме NAT для подключения из Linux к службе Windows обычно используют адрес хоста, а в режиме mirrored доступен 127.0.0.1. Новая возможность WSLC решает более узкую задачу: позволяет приложению задать адрес локального Windows-сервиса для контейнеров конкретного сеанса.

Различие существенно для диагностики. Если Linux-дистрибутив открывает сервис Windows через localhost, из этого ещё не следует, что контейнер, созданный через собственный сеанс WSLC SDK, получит такой же доступ без настройки.

Доступ к локальным службам остаётся отключённым по умолчанию

Microsoft отдельно предупреждает, что службы на Windows, слушающие только интерфейс loopback, могут не рассчитывать на соединения из контейнерных сред. Поэтому новое свойство HostLoopback имеет пустое значение по умолчанию. При использовании C API передачей NULL доступ отключается.

Для нового интерфейса требуется среда выполнения WSL 3.0.5 или новее. Если приложение пытается создать сеанс с включённой функцией на более старой версии, SDK сообщает о необходимости обновления среды выполнения (RuntimeUpdateNeeded, в нативном API — WSLC_E_RUNTIME_UPDATE_NEEDED).

На 30 октября в репозитории Microsoft присутствует тег 3.0.5, но страница releases/latest по-прежнему указывает на 3.0.3. Само наличие тега поэтому не подтверждает, что новая версия уже стала стабильным обновлением для всех пользователей.

Исправление устраняет конкретное ограничение пользовательских сеансов

Разработчики WSLC получили способ явно управлять доступом контейнеров к локальным службам Windows. Это даёт приложению инструмент для решения проблемы с недоступностью host.wslc.internal при первом запуске собственного сеанса, если новая настройка включена и у контейнера работает сеть.

В документации пока нет оснований считать, что механизм автоматически меняет поведение всех существующих контейнеров или сетевые настройки обычных Linux-дистрибутивов WSL. Область действия нововведения ограничена сеансами, создаваемыми через WSLC SDK.