Как я починил WSL Mirrored Networking через полный сброс сети Windows

Суть

Сегодня выяснил, что у меня в системе был жёсткий бардак с сетью.

В списке сетевых устройств обнаружились:

• Bluetooth-адаптер, просто потому что его кто-то когда-то создал;
• несколько адаптеров от старых установок OpenVPN;
• зависшие мосты от старых версий VMware;
• прочие сетевые артефакты, которые явно не помогали жить спокойно.

Из-за всего этого я не мог нормально завести режим mirrored в WSL, чтобы трафик из WSL тоже ходил через VPN: и для корпоративных ресурсов, и для сервисов вроде Gemini, OpenAI и Claude.

WSL либо отказывался запускаться в режиме mirrored или virtioproxy, либо сваливался в nat, либо в худшем случае уходил в none, оставляя виртуалку вообще без сети.

Что именно мешало WSL жить — я так и не выяснил. Конкретный затык найти не удалось.

Симптомы

У меня это выглядело примерно так:

• WSL не запускался с networkingMode=mirrored;
• virtioproxy тоже не помогал;
• вместо нужного режима WSL мог откатываться в nat;
• иногда сеть внутри WSL пропадала полностью;
• VPN на хосте работал, но WSL не ходил через него так, как хотелось;
• в системе было много старых и подозрительных сетевых адаптеров.

Короче, классика: ничего не понятно, но очень интересно.

Важное предупреждение

Этот способ радикальный.

Команда netcfg -d удаляет и пересоздаёт сетевые устройства Windows. После неё могут сброситься или пересоздаться:

• VPN-адаптеры;
• виртуальные адаптеры VMware/VirtualBox/Hyper-V;
• мосты;
• настройки некоторых сетевых клиентов;
• нестандартные сетевые конфигурации.

Перед выполнением лучше:

• сохранить важные VPN-конфиги;
• убедиться, что есть локальный доступ к машине;
• не делать это посреди рабочего созвона;
• понимать, как вернуть интернет, если что-то пойдёт не так.

Мне помогло. Но это не первая команда, которую стоит запускать при любой сетевой проблеме.

Что помогло

Я до последнего пытался решить проблему без радикальных шагов, потому что остаться совсем без интернета — удовольствие сомнительное.

Но в итоге помог такой алгоритм.

1. Закрыть софт, который зависит от сети

Сначала закрываем всё, что может плохо пережить резкое исчезновение сети:

• VPN-клиенты;
• браузеры;
• мессенджеры;
• TeamTalk (вряд ли вы его используете);
• SSH-сессии;
• всё, что активно использует сеть.

WSL тоже останавливаем:

wsl --shutdown

2. Сбросить сетевые адаптеры

Открываем PowerShell или Windows Terminal от имени администратора и выполняем:

netcfg -d

Команда может зависнуть секунд на 30 или больше, особенно если в системе много проблемных сетевых устройств.

Это нормально. Паниковать сразу не надо.

3. Сбросить сетевой стек Windows

В той же консоли администратора выполняем:

netsh winsock reset

Затем:

netsh int ip reset

После этого лучше не пытаться “ну сейчас ещё чуть-чуть проверю”, а сразу идти в перезагрузку.

4. Перезагрузить Windows

Перезагружаем систему:

shutdown /r /t 0

Можно, конечно, через меню “Пуск”. Но консоль-то уже открыта, да и не по-админски это - мышкой тыкать.

Что произошло после ребута

После перезагрузки всё завелось как часы:

• OpenVPN при необходимости пересоздал себе новый адаптер;
• sing-box тоже создаёт своё устройство при старте службы;
• WSL корректно настроился автоматически при первом запуске оболочки;
• VMware я на тот момент ещё не проверял, потому что он был не нужен.

Если VMware после такого сброса сломается, скорее всего, поможет repair install или переустановка сетевых компонентов VMware.

Мой конфиг WSL

Файл:

%UserProfile%\.wslconfig

Содержимое:

[wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=false

После изменения .wslconfig не забудь остановить WSL:

wsl --shutdown

И запустить нужный дистрибутив заново.

Как это ведёт себя у меня

В правила sing-box для разделения трафика у меня добавлено проксирование домена:

vpn.ifconfig.me

В итоге внутри WSL получается такое поведение:

curl ifconfig.me

возвращает мой реальный IP.

А:

curl vpn.ifconfig.me

возвращает IP VPN-сервера, к которому подключается sing-box.

То есть WSL в режиме mirrored нормально живёт вместе с VPN-маршрутизацией на хосте.

Доступ к сервисам, которые ограничивают пользователей из России, у меня после этого работает и из Windows, и из WSL.

Важный нюанс про sing-box

У меня sing-box работает как чистое ядро, завёрнутое в WinSW для запуска в качестве службы Windows.

Я не использую графические клиенты вроде:

• Throne;
• Hiddify;
• Clash;
• других оболочек поверх proxy-core.

Будет ли всё это вести себя так же с ними — не знаю. Там могут быть свои сетевые адаптеры, TUN-режимы, firewall-правила и прочая радость.

Когда стоит пробовать этот способ

Я бы рассматривал полный сброс сети, если:

• WSL не заводится в mirrored;
• WSL откатывается в nat или none;
• в системе накопились старые VPN/VMware/виртуальные адаптеры;
• обычные настройки .wslconfig не помогают;
• ты уже готов к тому, что часть сетевых компонентов придётся пересоздать.

Короткий чеклист

1. Закрыть VPN, браузеры, мессенджеры и другой сетевой софт.

2. Остановить WSL:

   wsl --shutdown

3. Открыть PowerShell от имени администратора.

4. Выполнить:

   netcfg -d

5. Выполнить:

   netsh winsock reset
   netsh int ip reset

6. Перезагрузить Windows.

7. Проверить .wslconfig.

8. Запустить WSL.

9. Проверить сеть:

   curl ifconfig.me

10. Проверить VPN-маршрутизацию, если она настроена отдельно:

    curl vpn.ifconfig.me

Итог

Иногда проблема не в одном конкретном флажке WSL, а в том, что Windows за годы накопила кладбище сетевых адаптеров, мостов и VPN-хвостов.

В моём случае аккуратные попытки не помогли, а полный сброс сетевых адаптеров и стека Windows внезапно оказался самым коротким путём к рабочему mirrored-режиму WSL.

Способ грубоватый, но рабочий. Главное — понимать, что именно он может снести по дороге.