Автозапуск служб на Windows Server после перезагрузки

MAATRIX

Сервер перезагрузился — плановое обновление, аварийный ребут после сбоя питания у провайдера, да хоть ручной restart из RDP-сессии — и через пять минут вы понимаете, что WireGuard-туннель не поднялся, RDP снаружи недоступен, а служба приложения тихо стоит в статусе «Остановлена». Это не редкая аномалия, а типовая ошибка конфигурации: служба была запущена вручную один раз и с тех пор жила только потому, что сервер ни разу не перезагружался. Ниже — как сделать так, чтобы после ребута сервис поднимался сам, без вашего участия, и что делать, если он падает уже после старта.

Почему службы не поднимаются сами после перезагрузки

Первая причина — банальная: тип запуска службы стоит на «Вручную» (Manual) или «Отключена» (Disabled), а не на «Автоматически» (Automatic). Так бывает почти всегда, когда службу устанавливали через MSI-инсталлятор с настройками по умолчанию, или когда администратор один раз стартовал её командой net start, увидел, что всё работает, и на этом остановился — сама служба от этого автоматической не становится.

Вторая причина — порядок старта. Даже если тип запуска правильный, служба может зависеть от сети, диска или другой службы, которая на момент её старта ещё не готова. Windows пытается запустить службу один раз, получает ошибку (например, «сетевой адаптер недоступен») и переходит к следующей — без сети, без DNS, без смонтированного тома.

Третья причина — специфика самой службы. WireGuard для Windows после установки тоннеля через wireguard.exe /installtunnelservice создаёт службу с именем WireGuardTunnel$<имя_конфига>, и по умолчанию она действительно ставится на автозапуск — но если конфигурацию правили руками или переустанавливали клиент, тип запуска может сброситься. RDP (служба TermService) в норме всегда автоматическая, и если она не стартует — это почти всегда не про автозапуск, а про зависимости или блокировку фаервола (об этом у нас отдельная статья — настройка файрвола Windows Server для туннеля).

Четвёртая, менее очевидная причина — служба стартует, но тут же падает из-за ошибки инициализации (не найден конфиг-файл, занят порт, недоступна база), и Windows по умолчанию не пытается её перезапустить. Про это — отдельный раздел про вкладку Recovery ниже.

Automatic vs Automatic (Delayed Start): в чём разница и когда что выбирать

В services.msc у типа «Автоматически» есть два варианта, и путаница между ними — вторая по частоте причина «служба вроде на автозапуске, но всё равно не работает после ребута».

Automatic (обычный) запускает службу как можно раньше в процессе загрузки, параллельно с десятками других системных служб. Это быстро, но именно тут чаще всего проявляется проблема зависимостей: сеть, DNS-клиент, драйверы виртуального адаптера (в случае WireGuard — WinTun) могут быть ещё не готовы, когда служба уже пытается стартовать.

Automatic (Delayed Start) — служба стартует автоматически, но с отложенным стартом: Windows сначала поднимает основной набор системных служб, освобождает загрузочный I/O, и только после этого, спустя условные 1–2 минуты (точное время не фиксировано и зависит от загрузки системы), запускает отложенные службы. Это медленнее, но надёжнее для всего, что зависит от сети или от других служб.

Практическое правило для сервера:

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

Настройка через services.msc

Самый наглядный способ — через графическую оснастку.

1. Win + R → services.msc → Enter.
2. Найдите нужную службу в списке (для WireGuard она называется WireGuardTunnel$ + имя конфигурации, например WireGuardTunnel$wg0).
3. Двойной клик → вкладка General.
4. В поле Startup type выберите Automatic или Automatic (Delayed Start).
5. Если служба сейчас остановлена — нажмите Start, чтобы не ждать следующего ребута для проверки.
6. Apply → OK.

Для проверки, что настройка реально применилась, откройте столбец Startup Type в основном окне services.msc (можно добавить через правый клик по заголовку таблицы) и отсортируйте по нему — так сразу видно все службы, оставшиеся на «Вручную».

Настройка через sc.exe и PowerShell

Для серверов без постоянного GUI-доступа (или когда нужно применить настройку скриптом на десятке машин) удобнее командная строка.

Через классический sc.exe (запускать из cmd с правами администратора):

:: Обычный автозапуск
sc config TermService start= auto

:: Автозапуск с задержкой
sc config "WireGuardTunnel$wg0" start= delayed-auto

:: Проверить текущий статус и тип запуска
sc qc "WireGuardTunnel$wg0"

Обратите внимание: после start= обязателен пробел — sc.exe при его отсутствии вернёт невнятную ошибку синтаксиса.

Через PowerShell (более читаемый вариант, работает начиная с Windows Server 2012 R2):

# Посмотреть текущий тип запуска
Get-Service -Name "WireGuardTunnel$wg0" | Select-Object Name, Status, StartType

# Поставить автозапуск с задержкой
Set-Service -Name "WireGuardTunnel$wg0" -StartupType AutomaticDelayedStart

# Обычный автозапуск для RDP (обычно уже так, но полезно для проверки)
Set-Service -Name TermService -StartupType Automatic

# Стартовать сразу, не дожидаясь ребута
Start-Service -Name "WireGuardTunnel$wg0"

Set-Service до PowerShell 7.4 не поддерживал AutomaticDelayedStart напрямую в старых версиях — если команда ругается на недопустимое значение параметра, используйте sc.exe как запасной вариант, он работает на любой версии Windows Server.

Полезно завернуть проверку в скрипт, который прогоняется после каждого разворачивания сервера или обновления конфигурации:

$services = @("WireGuardTunnel$wg0", "TermService")
foreach ($s in $services) {
    $svc = Get-Service -Name $s -ErrorAction SilentlyContinue
    if ($svc -and $svc.StartType -ne "Automatic" -and $svc.StartType -ne "AutomaticDelayedStart") {
        Set-Service -Name $s -StartupType Automatic
        Write-Host "Исправлен тип запуска: $s"
    }
}

Восстановление при сбое службы: вкладка Recovery

Правильный тип запуска решает проблему «служба не стартовала при загрузке», но не решает другую: «служба стартовала и через минуту упала». По умолчанию Windows на первый сбой не реагирует никак — служба просто остаётся в статусе Stopped до ручного вмешательства.

Настраивается это на вкладке Recovery в свойствах службы (services.msc → служба → правый клик → Properties → Recovery):

• First failure — что делать при первом сбое. Разумное значение — Restart the Service.
• Second failure — что делать при повторном. Тоже Restart the Service, но с увеличенной задержкой.
• Subsequent failures — при третьем и последующих сбоях подряд. Здесь стоит поставить Restart the Computer только для критичных случаев (и то с осторожностью — циклический ребут из-за незалеченной причины сбоя превратит проблему в постоянные простои) либо Take No Action, если хотите разбираться руками.
• Restart service after — задержка перед перезапуском, по умолчанию 1 минута. Для сетевых служб (WireGuard, RDP-зависимые сервисы) имеет смысл увеличить до 2–3 минут, чтобы дать время подняться сетевому стеку, если падение произошло из-за временной недоступности сети.
• Reset fail count after — через сколько дней (по умолчанию 1) счётчик сбоев обнуляется. Если не сбрасывать, после трёх сбоёв за месяц применится политика «Subsequent failures» даже без связи между инцидентами.

То же самое из командной строки — быстрее для массового применения:

sc failure "WireGuardTunnel$wg0" reset= 86400 actions= restart/60000/restart/120000/restart/180000

Здесь reset= 86400 — сброс счётчика сбоев через 86400 секунд (сутки), а actions= описывает тройку «действие/задержка в мс» для первого, второго и последующих сбоев. В данном примере — рестарт службы во всех трёх случаях с растущей задержкой.

Важный нюанс: параметр sc failure без дополнительного флага sc failureflag (доступен начиная с Windows Server 2008) применяется только к сбоям, а не к штатной остановке службы командой net stop или через диспетчер — так что тестовая остановка руками не спровоцирует лишний автозапуск, если вы отлаживаете конфиг.

Task Scheduler с триггером «При запуске системы» как альтернатива

Не для всех сценариев служба — правильный инструмент. Если у вас не служба Windows, а обычный exe или bat-скрипт (например, стартовый скрипт приложения, которое не оформлено как служба), альтернатива — задача в Планировщике заданий с триггером At startup.

Через GUI: Win + R → taskschd.msc → Create Task (не Basic Task — там меньше настроек) →

• General: имя задачи, «Run whether user is logged on or not», «Run with highest privileges».
• Triggers → New → Begin the task: At startup. Можно добавить задержку (Delay task for) на 30–60 секунд, чтобы не стартовать раньше сети — по сути тот же принцип, что Delayed Start у служб.
• Actions → New → Program/script — путь к exe или к powershell.exe с параметром -File путь_к_скрипту.ps1.
• Settings: включите «If the task fails, restart every» — это своего рода аналог вкладки Recovery для служб.

Через schtasks из командной строки:

schtasks /create /tn "StartMyApp" /tr "C:\App\start.bat" /sc onstart /delay 0000:30 /ru SYSTEM /rl highest

Флаг /delay 0000:30 даёт 30-секундную задержку после старта системы — часы:минуты. Запуск от SYSTEM (/ru SYSTEM) избавляет от привязки к конкретной учётной записи и работает даже без интерактивного входа, что важно на headless-сервере.

Плюс такого подхода — гибкость: можно задать несколько триггеров сразу (например, «при запуске» и «при восстановлении из сна»), настроить условия («не запускать при работе от батареи» — на сервере обычно неактуально, но параметр есть). Минус — Task Scheduler не даёт того же уровня интеграции с SCM (Service Control Manager), что настоящая служба: нет net start/stop, нет стандартного мониторинга через Get-Service, сложнее встроить в существующие скрипты администрирования.

Если у вас именно WireGuard и вы рассматриваете Task Scheduler как альтернативу штатной службе — как правило, в этом нет смысла: wireguard.exe /installtunnelservice уже создаёт полноценную службу с корректным автозапуском, и вопрос обычно сводится к тому, что описано выше в разделах про services.msc и sc.exe. Подробно процесс установки разобран в статье WireGuard на Windows Server: установка, а если туннель конкретно не поднимается после ребута — в статье WireGuard не работает после перезагрузки: причины и решение разобраны причины именно этого сценария, включая конфликты драйвера WinTun.

Частые вопросы