Перезапуск веб-сервера 1С: IIS, Apache и Nginx без потери данных

Чтобы перезагрузить веб-сервер 1С, достаточно перезапустить веб-сервер, на котором опубликована база: в IIS это команда iisreset или перезапуск пула приложений, в Apache — systemctl restart apache2 (или httpd), в Nginx — systemctl reload nginx. Сервер 1С:Предприятия при этом трогать не нужно: он живёт отдельной службой.

Путаница начинается именно здесь. Под «веб-сервером 1С» люди понимают то веб-сервер с публикацией базы, то агент сервера 1С. Перезапуск первого оборвёт веб-сессии и тонкие клиенты по HTTP. Перезапуск второго оборвёт вообще всех. Разберём оба случая и порядок действий, чтобы не уронить лишнего.

Что именно перезапускать: веб-сервер или сервер 1С

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

Если сбой касается только веба (ошибка 500, 503, «не удаётся загрузить веб-модуль», зависшая страница входа), а тонкий клиент по обычному подключению работает, перезапускайте веб-сервер. Если не работает ничего, смотрите в сторону сервера 1С и СУБД.

Nginx отдельная история. Модуля публикации 1С для него нет, поэтому Nginx в такой схеме стоит перед Apache как обратный прокси: принимает HTTPS, отдаёт запросы дальше. Базу публикует именно Apache.

Диагностика перед перезапуском

Перезапуск стирает следы. Сначала соберите то, что потом не восстановить.

1. Откройте журнал ошибок веб-сервера и скопируйте последние записи. Пути указаны в разделе про логи ниже.
2. Проверьте, отвечает ли сам сервер: откройте адрес базы в браузере с самого сервера, а не с рабочего места. Если локально открывается, а снаружи нет, виноват брандмауэр или прокси, и перезапуск ничего не даст.
3. Посмотрите нагрузку: загрузку процессора и память, размер файла подкачки. Рабочий процесс IIS, съевший всю память, лечится утилизацией пула, а не перезагрузкой всей машины.
4. Откройте консоль администрирования серверов 1С и проверьте список сеансов. Так вы увидите, кого заденете.
5. Уточните, что менялось: публикация, версия платформы, сертификат, права на каталог публикации. Часто сбой вызвал вчерашний default.vrd или обновление платформы , а не зависший процесс.

💡 Если веб-клиент просто «тормозит» у одного пользователя, сначала проверьте его браузер: полное обновление страницы (Ctrl+F5) и очистка кэша браузера снимают половину жалоб.

Автономный сервер и встроенный веб-сервер платформы

Для файловой базы веб-доступ можно поднять без IIS и Apache. Платформа 8.3 содержит автономный сервер (ibsrv): он публикует базу по HTTP сам, без внешнего веб-сервера. Запускают его как службу или как обычный процесс.

Перезапуск здесь предельно прост:

• если автономный сервер работает как служба, перезапустите её в оснастке «Службы» или командой systemctl restart <имя службы> на Linux;
• если запущен из командной строки, закройте процесс и запустите снова с теми же параметрами.

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

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

Перезапуск IIS для платформы 1С

IIS — самый частый вариант в Windows-среде. Есть три уровня, от мягкого к жёсткому.

Утилизация пула приложений

Самый безопасный способ: затрагивает только одно приложение, остальные сайты работают.

1. Откройте «Диспетчер служб IIS».
2. В левой панели разверните сервер и выберите «Пулы приложений».
3. Выберите пул, в котором работает ваша публикация.
4. В правой панели нажмите «Перезапуск» или «Утилизация».

То же самое из командной строки с правами администратора:

%windir%\system32\inetsrv\appcmd recycle apppool /apppool.name:"ИмяПула"

Или через PowerShell:

Import-Module WebAdministration
Restart-WebAppPool -Name "ИмяПула"

Перезапуск сайта

Если пул утилизирован, а сайт всё равно не отвечает, перезапустите сайт: в Диспетчере выберите сайт и в правой панели нажмите «Остановить», затем «Запустить».

Полный перезапуск службы IIS

Остановит все сайты на машине, поэтому используйте как последнюю меру:

iisreset /status
iisreset /restart

Команду выполняйте в консоли, запущенной от имени администратора. Раздельно останавливать и запускать можно через iisreset /stop и iisreset /start. Ключ /status покажет состояние служб IIS, не меняя ничего.

⚠️ Если на этом IIS работают другие сайты и сервисы, iisreset оборвёт и их. Сначала попробуйте утилизацию пула.

Apache и Nginx в Linux

Apache

На Debian и Ubuntu служба называется apache2, на семействе Red Hat — httpd.

# проверить синтаксис конфигурации до перезапуска
apachectl configtest

# мягкий перезапуск: применяет конфигурацию, не обрывая текущие запросы
sudo systemctl reload apache2

# полный перезапуск
sudo systemctl restart apache2

# посмотреть состояние
sudo systemctl status apache2

Сначала всегда configtest. Если вы правили httpd.conf или файл публикации и ошиблись, restart просто не поднимет сервер, и вы получите простой вместо починки.

Мягкая перезагрузка (reload или apachectl graceful) подойдёт, когда вы изменили конфигурацию. Если завис сам процесс или веб-модуль 1С, нужен полный restart.

Для Apache под Windows используется httpd -k restart из каталога сервера или перезапуск службы в оснастке «Службы».

Nginx

В связке с 1С Nginx обычно стоит впереди и проксирует запросы:

sudo nginx -t
sudo systemctl reload nginx

nginx -t проверяет конфигурацию, reload применяет её без обрыва соединений. Полный restart нужен редко. Если после перезагрузки веб-клиент выдаёт ошибку 502, проблема не в Nginx, а в Apache за ним: проверьте, что он запущен.

Служба сервера 1С на Linux

Агент сервера 1С — отдельная служба, и перезапускают её только осознанно, потому что она обрывает всех. Название зависит от установки; найти его можно так:

systemctl list-units | grep -i 1c

После этого sudo systemctl restart <найденное имя>. Перед этим завершите сеансы в консоли администрирования или предупредите людей.

Очистка кэша и временных файлов

Многие «зависания» после смены публикации или обновления связаны не с сервером, а с устаревшим кэшем.

Кэш клиента 1С. Каталоги кэша лежат в профиле пользователя: %LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8. Закройте все окна 1С и удалите из них вложенные папки с длинными именами из букв и цифр. Список баз (ibases.v8i) трогать не нужно. Мягче: запустить клиент с ключом /ClearCache.

Кэш браузера. Для веб-клиента сбрасывайте его полным обновлением страницы или очисткой через настройки браузера.

Кэш в сеансе на сервере. Не удаляйте служебные каталоги кластера (в каталоге кластера лежат файлы вида reg_1541) вручную. Это прямой путь к потере настроек кластера. Если нужно сбросить состояние, перезапустите службу сервера 1С в согласованное окно.

💡 Ошибка после обновления конфигурации иногда лечится одним действием: пользователь закрывает 1С и открывает заново. Прежде чем перезапускать сервер, спросите об этом.

Порядок, если перезагружается вся машина

Иногда веб-сервер, сервер 1С и СУБД стоят на одной машине, и её нужно перезагрузить целиком, например после обновления системы. Порядок важен.

1. Предупредите пользователей и дождитесь, пока они закроют работу.
2. Остановите веб-сервер, чтобы новые веб-сеансы не создавались.
3. Завершите оставшиеся сеансы в консоли администрирования и остановите службу сервера 1С.
4. Остановите СУБД штатно, через её службу.
5. Перезагрузите машину.

После старта поднимайте всё в обратном порядке: СУБД, сервер 1С, веб-сервер. Если веб-сервер стартует раньше сервера 1С, первые обращения получат ошибку подключения, хотя ничего не сломано. Подождите минуту и повторите вход.

Для служб, которые должны подниматься сами, проверьте тип запуска: «Автоматически» в Windows или systemctl enable <служба> в Linux. Без этого после ночной перезагрузки утром придётся поднимать веб-сервер руками.

Диагностика после перезапуска

Перезапуск сделан. Теперь убедитесь, что всё поднялось.

1. Проверьте статус службы: systemctl status apache2 или iisreset /status.
2. Откройте адрес базы в браузере и войдите. Дождитесь полной загрузки интерфейса, а не только страницы входа.
3. Откройте журнал ошибок.

Где искать логи:

Смотрите на коды ответов:

• 500 — ошибка внутри приложения: часто это публикация или права на каталог.
• 502 — Nginx не достучался до Apache.
• 503 — пул приложений остановлен или сервер перегружен. В IIS пул мог остановиться сам из-за быстрых повторных сбоев.
• 404 — публикация не найдена: проверьте имя базы в адресе и файл default.vrd.

Автоматизация контроля и восстановления

Если приходится перезапускать вручную каждую неделю, это сигнал не к расписанию, а к поиску причины. Но подстраховку настроить стоит.

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

Проверка доступности скриптом. Простой пример для Linux, который раз в несколько минут проверяет ответ и перезапускает Apache при сбое:

#!/bin/bash
code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 20 http://localhost/mybase/)
if [ "$code" != "200" ] && [ "$code" != "302" ]; then
    systemctl restart apache2
    echo "$(date) restart, code=$code" >> /var/log/web1c-watch.log
fi

Адрес mybase замените на имя вашей публикации. Скрипт добавляют в cron (например, раз в 5 минут). Код 302 нужен, потому что при настроенной авторизации сервер часто отвечает перенаправлением.

На Windows аналог делает «Планировщик заданий» с PowerShell-скриптом, который проверяет страницу через Invoke-WebRequest и при неудаче вызывает Restart-WebAppPool.

⚠️ Автоперезапуск без журнала опасен: он прячет проблему. Всегда пишите в лог время и код ответа, и раз в неделю смотрите, как часто срабатывает.

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