WSL или VPS для разработки: что выбрать?

Стоит ли использовать WSL или VPS для разработки?

Выбор между WSL и VPS для разработки сводится к одному свойству: доступности. WSL (Windows Subsystem for Linux) запускает Ubuntu внутри виртуальной машины, которая существует только во время сеанса Windows. VPS (виртуальный выделенный сервер) запускает ту же Ubuntu на публичном IP-адресе, который остается активным, даже когда ваш ноутбук закрыт. Большинство разработчиков в итоге используют оба варианта, где сервер выступает в роли постоянно доступной машины.

Операционная система не является существенным различием, так как в обоих случаях используется Ubuntu. Разница заключается в аптайме, доступности из интернета, возможностях systemd, скорости работы с файлами, поведении сети и ответственности за резервное копирование. Каждый раздел ниже описывает различия, которые вы можете наблюдать на собственной машине.

Почему WSL останавливается при закрытии крышки ноутбука?

WSL 2 запускает полноценное ядро Linux внутри легковесной виртуальной машины, которую Windows активирует по требованию. Эта виртуальная машина существует только во время работы дистрибутива, а дистрибутив работает лишь до тех пор, пока его кто-то использует. Проверьте состояние из PowerShell:

wsl --version
wsl --list --running

Закройте все терминалы WSL, подождите минуту, а затем снова выполните wsl --list --running. Когда команда сообщит, что запущенных дистрибутивов нет, это означает, что оболочка, которую вы запустили, завершила работу, как и все запущенные в ней процессы. wsl --shutdown делает то же самое немедленно; это полезный способ проверить, как ваша конфигурация ведет себя после перезапуска.

Спящий режим и гибернация также останавливают виртуальную машину. Таймер, установленный на выполнение дампа базы данных в 03:00, не сработает, пока крышка ноутбука закрыта, так как ядро, которое должно было его выполнить, не работает. Ошибки при этом не логируются, поэтому кажется, что задача вообще не была запланирована. Именно из-за этого поведения пользователи переходят на вторую машину: очередь сборки, чат-бот, ночное резервное копирование или обработчик вебхуков требуют компьютера, который остается включенным.

Работает ли systemd в WSL?

Да. Поддержка появилась в WSL версии 0.67.6, но в старых установках она отключена по умолчанию. Без неё systemctl status ssh выводит следующее:

System has not been booted with systemd as init system (PID 1). Can't operate.

Сначала прочитайте файл конфигурации, так как он у вас уже может быть. Если в нём нет секции [boot], добавьте её; если она есть, добавьте единственную строку внутрь существующей секции.

cat /etc/wsl.conf
sudo tee -a /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF

Выполните wsl --shutdown в PowerShell, откройте новую оболочку Ubuntu, а затем проверьте результат с помощью systemctl list-units --type=service --state=running. Список юнитов означает, что systemd является PID 1, и с этого момента journalctl -b работает корректно.

Нюанс заключается в том, что именно enable гарантирует на каждой машине. На VPS sudo systemctl enable --now caddy означает, что сервис запускается при загрузке системы, поэтому он возобновляет работу после перезагрузки или обновления ядра, даже если никто не вошёл в систему. В WSL это означает, что сервис запускается при старте дистрибутива, а дистрибутив запускается при открытии терминала. Таким образом, сервис работает только пока вы работаете, что противоречит самому назначению сервисов. Контейнеры наследуют тот же недостаток, поэтому автозапуск сервисов Docker Compose зависит от загрузки, которую WSL выполняет только по вашему запросу.

Может ли вебхук обратиться к серверу, работающему в WSL?

Напрямую — нет, причина кроется в сетевой архитектуре. В стандартном режиме WSL 2 виртуальная машина находится за NAT (network address translation) на собственном виртуальном адаптере. Посмотрите на адрес:

ip -4 addr show eth0
ip route show default

Этот адрес является частным, и он переназначается при каждом запуске виртуальной машины, поэтому он постоянно меняется. Windows по-прежнему может обращаться к localhost:3000, так как WSL перенаправляет соединения с localhost внутрь дистрибутива. Другая машина в вашей сети этого сделать не сможет, если вы не добавите правило проксирования из PowerShell с правами администратора:

netsh interface portproxy add v4tov4 listenport=3000 listenaddress=0.0.0.0 connectport=3000 connectaddress=172.24.108.3

Это правило привязано к конкретному адресу, поэтому оно перестанет работать, как только адрес изменится. Лучший вариант — использование зеркалирования сети (mirrored networking): дистрибутив получает те же интерфейсы и адреса, что и Windows. По состоянию на август 2026 года для этого требуется Windows 11 22H2 или новее. Добавьте следующие параметры в %UserProfile%\.wslconfig и выполните wsl --shutdown:

[wsl2]
networkingMode=mirrored

Зеркальный режим решает проблему локальной сети. Однако он не предоставляет публичный IP-адрес. Ваш роутер снова использует NAT, большинство домашних подключений не имеют открытых входящих портов, которыми вы можете управлять, а многие провайдеры добавляют еще один уровень NAT поверх этого. Поэтому GitHub не может отправить POST-запрос с событием на ваш ноутбук, а коллега не сможет открыть вашу демонстрационную ссылку. Сервис туннелирования позволяет обойти это ограничение, но клиент туннеля должен быть запущен на ноутбуке, а значит, ноутбук должен оставаться включенным.

VPS решает эту проблему с другой стороны. У него есть публичный IPv4-адрес и, как правило, публичный IPv6-адрес, при этом открыты только те порты, которые вы разрешили. Направьте на него A-запись, откройте порты 80 и 443, и сервер будет доступен отовсюду. Это также является обязательным условием для получения публичного сертификата, так как проверка HTTP-01 требует, чтобы Let's Encrypt загрузил файл через 80-й порт по публичному доменному имени. Получение сертификата Let's Encrypt с помощью Certbot и nginx на сервере занимает пять минут, но невозможно в WSL. Для локальной разработки вы все еще можете получить HTTPS, которому доверяет браузер, внутри WSL, добавив собственный CA в хранилище доверенных сертификатов Ubuntu.

Почему git работает медленно в /mnt/c?

Потому что файлы находятся не в файловой системе Linux. WSL предоставляет две области хранения с существенно разной стоимостью доступа. Ваш домашний каталог расположен в файловой системе ext4 внутри виртуального диска, и он ведет себя как обычный диск Linux. /mnt/c — это диск Windows, доступ к которому предоставляется по протоколу 9P (протокол файловой системы Plan 9) компонентом на стороне Windows, поэтому каждое открытие файла и каждый вызов stat пересекают эту границу.

Один файл — это нормально. git status в большом репозитории выполняет тысячи вызовов stat, и каждый из них требует пересечения границы. Измерьте это самостоятельно, вместо того чтобы доверять цифрам из любых источников, включая эту страницу:

cd /mnt/c/Users/you/code/myrepo && time git status
cp -r /mnt/c/Users/you/code/myrepo ~/myrepo
cd ~/myrepo && time git status

Запустите каждую команду дважды и сравните результаты вторых запусков, чтобы кэши были прогреты. Антивирусное сканирование в реальном времени в Windows добавляет дополнительные накладные расходы на стороне /mnt/c, поэтому один и тот же репозиторий может работать медленнее на корпоративном ноутбуке, чем на личном.

Решение внутри WSL заключается в том, чтобы хранить рабочую копию в ~ и открывать её через режим удаленной работы (remote mode) вашего редактора, который запускает сервер редактора внутри дистрибутива, а не обращается к файлам через границу. Проводник (Explorer) по-прежнему может просматривать эти файлы по пути \\wsl.localhost\Ubuntu\home\you. У VPS такой проблемы нет, так как там используется одна файловая система, и это Linux. Там вы платите за сетевую задержку во время редактирования, поэтому пользователи работают в терминальном мультиплексоре или сессии удаленного редактора. Общий процессор — это существенное ограничение на небольшом сервере, и steal time от шумного соседа отображается в top в столбце st.

В чем WSL однозначно выигрывает

• Это бесплатно и уже есть на компьютере. Включите функцию, установите Ubuntu, и через минуту вы готовы к работе. Платить не нужно, а внешняя поверхность атаки отсутствует.
• Это решение легко удалить, в отличие от сервера. wsl --export Ubuntu D:\wsl-backups\ubuntu.tar записывает весь дистрибутив в один файл, а wsl --import восстанавливает или клонирует его под другим именем. Тестирование нового релиза Ubuntu здесь сводится к клонированию и откату, тогда как обновление VPS с 24.04 до 26.04 — это необратимый процесс, который требует планирования с учетом работающих сервисов.
• Прямая работа с GPU. С актуальным драйвером Windows видеокарта доступна внутри дистрибутива, поэтому рабочие нагрузки CUDA и ROCm выполняются на вашем собственном оборудовании. Аренда GPU аналогичного класса стоит реальных денег.
• Цикл разработки короче. Ваши файлы и браузер находятся локально, поэтому сервер разработки на localhost:5173 открывается в браузере, в котором вы уже авторизованы.

Это реальные преимущества, и именно поэтому обычно используют обе машины, а не одну.

Кто отвечает за резервные копии?

Вы отвечаете за них на обеих машинах, и в случае с WSL это часто становится неожиданностью. Дистрибутив представляет собой файл виртуального диска (ext4.vhdx) в профиле пользователя Windows. Ни один провайдер не делает его снимки автоматически. wsl --unregister Ubuntu удаляет его без возможности отмены, а переустановка Windows уничтожает его вместе со всеми остальными данными. Выполняйте экспорт по графику, который вы сможете соблюдать:

wsl --export Ubuntu D:\wsl-backups\ubuntu-2026-08-18.tar

На VPS снимок (snapshot) от провайдера защищает вас от выхода из строя физического хоста. Он не защищает от rm -rf в неверном каталоге, а снимок, хранящийся в той же учетной записи, что и сервер, исчезнет вместе с ним при компрометации доступа. Выгружайте резервные копии на уровне файлов за пределы сервера и выполняйте тестовое восстановление до того, как оно потребуется в экстренной ситуации. В обоих случаях ответственность лежит на вас. Практическая разница заключается в том, что сервер может отправлять собственную резервную копию в 03:00, не требуя, чтобы кто-то оставлял ноутбук включенным.

Мост: SSH из WSL на VPS

Вторая машина кажется обузой, пока соединение не настроено должным образом. Выполните это один раз внутри WSL.

Создайте ключ в дистрибутиве, а не на стороне Windows, чтобы закрытый ключ оставался в файловой системе ext4 с правами доступа Unix, которые принимает ssh:

ssh-keygen -t ed25519 -C "dev@laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10

Ключи Ed25519 короткие и быстрые, а ssh-copy-id добавляет открытый ключ в ~/.ssh/authorized_keys на сервере с правильными правами доступа. В основах управления SSH-ключами описано, как их ротировать и отзывать в дальнейшем.

Дайте серверу имя в ~/.ssh/config:

Host dev
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes
  ForwardAgent yes
  ServerAliveInterval 30

Теперь ssh dev устанавливает соединение. IdentitiesOnly yes запрещает клиенту предлагать все имеющиеся у него ключи, что вызывает Too many authentication failures, если в агенте загружено несколько ключей. ServerAliveInterval 30 предотвращает разрыв сессии при домашнем подключении без вывода сообщения.

ForwardAgent yes — это строка, которая делает рабочий процесс удобным. Когда ключ загружен в агент на ноутбуке, git clone git@github.com:you/app.git работает на сервере без необходимости копировать туда закрытый ключ. Проверьте это с помощью ssh -T git@github.com на VPS, команда должна вернуть Hi you! You've successfully authenticated. Перенаправляйте агента только на те серверы, которым вы доверяете, так как пользователь root на этой машине может использовать ваш сокет агента, пока вы подключены. На сервере, который вы делите с другими людьми, более безопасным выбором будет ключ развертывания (deploy key) для конкретного репозитория.

WSL не поддерживает работу агента между сессиями оболочки, поэтому каждый новый терминал снова запрашивает ключ. keychain решает эту проблему:

sudo apt update && sudo apt install -y keychain
echo 'eval "$(keychain --eval --quiet id_ed25519)"' >> ~/.bashrc

Откройте новую оболочку и выполните ssh-add -l. Она должна вывести отпечаток ключа. Error connecting to agent означает, что строка не считывается, поэтому проверьте, что ваша оболочка действительно выполняет ~/.bashrc.

Запускайте работу на сервере внутри терминального мультиплексора, чтобы разрыв соединения не прерывал её:

tmux new -s dev
# Ctrl-b then d to detach
tmux attach -t dev

Сборка продолжается, даже если вы закроете ноутбук, что и является главной причиной использования второй машины. По этой же схеме люди запускают Claude Code на VPS в tmux и возвращаются к сессии с другого устройства.

Укрепите систему перед тем, как размещать на ней что-либо. Первые десять минут на новом VPS описывают создание пользователя без прав root, SSH только по ключам, настройку брандмауэра и автоматические обновления безопасности в порядке, который не заблокирует вам доступ.

Какую машину выбрать для конкретной задачи?

Используйте WSL, когда работа происходит непосредственно на вашем экране. Это редактирование кода, запуск набора тестов, dev-сервер на localhost, ноутбуки, эксперименты с GPU — всё, что вы запускаете и за чем наблюдаете.

Используйте VPS, когда работа должна быть доступна извне или должна продолжаться после завершения вашего сеанса. Это может быть staging-URL, который может открыть клиент, endpoint для вебхуков, cron-задача с реальным системным временем, бот, небольшая база данных, к которой обращается другой сервис, или процесс импорта, запущенный в пятницу вечером.

Если вы всё ещё решаете, для чего нужна вторая машина, список того, что люди реально запускают на VPS будет полезнее, чем сравнение технических характеристик, а что такое VPS объясняет принципы виртуализации, лежащие в основе. Если ваш инструментарий работает только на Windows, это отдельное решение, и сравнение Linux и Windows Server — это страница, которая вам нужна.

Одна привычка поможет не допустить превращения двух машин в две полунастроенные системы: код должен храниться в git, а обе машины должны быть клиентами репозитория. Ничего важного не должно существовать только на одной из них.

FAQ

Можно ли разместить веб-сайт с реальным доменом из WSL?

Ненадёжно. WSL 2 находится за NAT внутри вашего компьютера, ваш роутер также использует NAT, а большинство домашних интернет-провайдеров не предоставляют входящие порты для проброса. Сервис туннелирования может открыть локальный порт, но клиент туннеля работает на ноутбуке, поэтому сайт будет недоступен, когда ноутбук переходит в спящий режим. Сертификаты усложняют задачу, так как проверка HTTP-01 требует, чтобы Let's Encrypt получил файл через 80 порт по публичному доменному имени. VPS с публичным IP-адресом и A-записью удовлетворяет обоим условиям без дополнительных обходных путей.

Работает ли systemctl enable в WSL?

Работает, если включен systemd, что требует настройки systemd=true в секции [boot] файла /etc/wsl.conf с последующим wsl --shutdown. Без этого systemctl выдает ошибку System has not been booted with systemd as init system (PID 1). Can't operate.. Даже при запущенном systemd команда enable запускает сервис при старте дистрибутива, а дистрибутив запускается при открытии оболочки. На сервере та же команда означает, что сервис возобновит работу после перезагрузки, даже если никто не вошел в систему.

Почему мой IP-адрес в WSL постоянно меняется?

В режиме NAT по умолчанию виртуальная машина получает новый частный адрес от виртуального адаптера WSL при каждом запуске. Любое правило netsh interface portproxy или жестко заданный адрес перестают работать после wsl --shutdown. Проверяйте текущий адрес с помощью ip -4 addr show eth0. Режим зеркалирования сети (mirrored networking) в Windows 11 устраняет проблему отдельного адреса, предоставляя дистрибутиву те же интерфейсы, что и у Windows: установите networkingMode=mirrored в секции [wsl2] файла %UserProfile%\.wslconfig.

Действительно ли /mnt/c работает медленнее, или это миф?

Это медленнее, и минута тестирования на вашем компьютере это докажет. Файлы в ~ находятся на виртуальном диске ext4. Файлы в /mnt/c передаются по протоколу 9P компонентом со стороны Windows, поэтому каждый вызов stat пересекает границу, а git status по большому дереву каталогов совершает их тысячи. Скопируйте репозиторий в ~, запустите time git status дважды в каждом расположении и сравните время выполнения после прогрева кэша. Храните рабочие копии в ~ и используйте режим WSL remote в вашем редакторе.

Нужен ли мне WSL, если у меня уже есть VPS?

Большинство людей используют и то, и другое. WSL бесплатен и запускается мгновенно, поэтому он остается местом для редактирования и тестирования, а также для задач, требующих GPU. Сервер — это машина, которая работает постоянно: она удерживает публичное имя и выполняет задачи, которые должны продолжаться при закрытом ноутбуке. Храните код в git и используйте оба окружения как клиенты репозитория, тогда перенос работы между ними не потребует усилий.