WS-соединение 1С: как закрыть соединение и освободить сеанс

WS-соединение в 1С — это подключение клиента к информационной базе через веб-сокет (WebSocket), которое используется в тонком и веб-клиенте при публикации базы на веб-сервере. Такие соединения держат сеанс открытым, занимают лицензии и память сервера, поэтому администраторам регулярно приходится закрывать их принудительно: при зависших сеансах, перед регламентным обслуживанием или при утечке лицензий.

Закрыть WS-соединение можно несколькими способами: через консоль кластера серверов 1С, программно из кода, настройкой таймаутов публикации или перезапуском служб. Выбор зависит от того, нужно ли завершить один зависший сеанс или все соединения сразу, и есть ли доступ к консоли кластера.

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

Что такое WS-соединение в 1С и почему оно «зависает»

При работе через веб-сервер (IIS или Apache) клиент 1С устанавливает с опубликованной базой постоянное соединение по протоколу WebSocket. В консоли кластера такие сеансы видны с типом клиента «Тонкий клиент» или «Веб-клиент», а в свойствах соединения фигурирует признак использования WS. Соединение поддерживается постоянным обменом служебными сообщениями (ping/pong).

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

Второй типичный сценарий — фоновые задания и длительные операции, запущенные через веб-клиент. Пока задание выполняется, сеанс остаётся активным, и закрыть его штатно из клиента невозможно.

Закрытие сеанса через консоль кластера серверов

Самый прямой способ — консоль администрирования серверов 1С. Откройте консоль, разверните нужный кластер, перейдите в раздел «Сеансы». Найдите нужный сеанс по имени пользователя, приложению или времени начала. Через контекстное меню выберите «Удалить» — сервер завершит сеанс и разорвёт связанное WS-соединение.

Если сеансов много, удобнее отсортировать список по колонке «Спящий сеанс» или по времени последней активности. Зависшие WS-сеансы обычно выдают себя давним отсутствием вызовов при формально активном состоянии.

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

1. 1
   Откройте консоль администрирования серверов 1С и подключитесь к кластеру
2. 2
   Разверните ветку «Сеансы» и найдите зависший сеанс по пользователю или времени начала
3. 3
   Убедитесь по времени последнего вызова, что сеанс действительно неактивен
4. 4
   Нажмите «Удалить» в контекстном меню сеанса
5. 5
   Обновите список сеансов и проверьте, что соединение исчезло, а лицензия освободилась

Программное завершение сеансов из кода

Когда нужно закрывать соединения регулярно или по условию, используют программный интерфейс. Через COM-соединение с агентом сервера (V83.COMConnector) или административную библиотеку можно получить список сеансов и завершить нужные.

Типовой подход на встроенном языке через объект агента сервера: подключиться к агенту, получить рабочие процессы и сеансы, отфильтровать по приложению «тонкий клиент» или по признаку спящего сеанса и вызвать метод завершения. Для регламентной чистки зависших сеансов такой код помещают в фоновое задание по расписанию.

На управляемых формах внутри самой базы доступен метод ЗавершитьРаботуСистемы() — но он закрывает только текущий клиент, а не чужие WS-соединения. Для управления чужими сеансами нужен доступ к агенту сервера и административные права на кластер.

// Завершение текущего клиентского приложения
ЗавершитьРаботуСистемы(Ложь); // Ложь — без перезапуска

// Получение сеансов текущей ИБ (для анализа)
Сеансы = ПолучитьСеансыИнформационнойБазы();
Для Каждого Сеанс Из Сеансы Цикл
    Сообщить(Сеанс.ИмяПриложения + " | " + Сеанс.Пользователь.Имя);
КонецЦикла;

Настройка таймаутов: как не закрывать соединения вручную

Автоматическое закрытие неактивных WS-соединений настраивается на трёх уровнях. Первый — свойства информационной базы в консоли кластера: параметры «Интервал перезапуска» и таймаут завершения спящих сеансов. Второй — файл публикации default.vrd, где для WebSocket задаются параметры поддержки соединения. Третий — настройки самого веб-сервера: в IIS и Apache есть собственные таймауты простоя, которые могут рвать соединение раньше 1С.

Практическая рекомендация: выставьте таймаут завершения спящих сеансов в кластере (например, 15–30 минут простоя) и убедитесь, что таймауты веб-сервера не короче, иначе клиенты будут терять соединение при активной работе. Согласованность этих значений важнее конкретных цифр.

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

Как закрыть все WS-соединения сразу

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

Первый: установить блокировку сеансов в свойствах информационной базы консоли кластера. Новые соединения перестанут создаваться, а существующие можно удалить пакетно. Второй: перезапуск службы агента сервера 1С — грубый, но гарантированный способ разорвать все соединения разом; применяйте его только вне рабочего времени. Третий: остановка публикации на веб-сервере (остановка сайта в IIS или виртуального хоста в Apache) — WS-соединения оборвутся на стороне веб-сервера.

Для регулярных регламентных окон удобнее всего связка «блокировка сеансов + сообщение пользователям + отложенное удаление оставшихся сеансов».

Проверка результата и частые ошибки

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

Типичные ошибки администраторов: удаление активного сеанса без проверки времени последнего вызова (пользователь теряет данные), несогласованные таймауты веб-сервера и кластера (массовые обрывы у работающих людей), ожидание мгновенного освобождения лицензии (в некоторых сценариях лицензия освобождается с задержкой) и попытка управлять сеансами файловой базы через консоль кластера, которой для файлового режима не существует.

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