Ошибка при соединении с сервером 1С:Предприятие: что делать?

Проверяем доступность порта соединения

Первое, на что смотрит опытный администратор, это порт, через который клиенты стучатся к серверу. Строка запуска агента выглядит примерно так: ragent.exe -srvc -agent -regport 1541 -port, и путь к самому файлу зависит от версии платформы и разрядности системы. Если путь указан неверно или файл вообще отсутствует по этому адресу, дальше можно не проверять, дело именно в этом.

Смотрим на процессы rphost, rmngr и ragent

Открываем диспетчер задач и ищем три процесса: rphost.exe, ragent.exe и rmngr.exe. Ragent отвечает за сам агент сервера, rmngr управляет рабочими процессами, а rphost выполняет непосредственно рабочие сессии пользователей. Если хотя бы rmngr отсутствует в списке, а остальные два висят, обычно это признак того, что менеджер кластера упал, но агент этого еще не заметил. Бывает и обратная картина: rphost плодится в десятках копий и съедает память, а сервер при этом формально считается запущенным. Такое чаще случается на серверах, где базу не перезапускали месяцами.

Проверяем службу агента сервера в списке служб Windows

Дальше открываем оснастку служб и ищем что-то вроде "1C:Enterprise 8.3 Server Agent". Смотрим не только статус (запущена или нет), но и строку "Исполняемый файл": там должны совпадать версия платформы и порт, указанные при установке. Расхождение версии в этой строке с той, что реально стоит на сервере, встречается на удивление часто после обновлений 1С, когда старую службу забыли пересоздать.

Отдельно проверяем MS SQL Server

Если 1С работает на клиент-серверном варианте с MS SQL, часть проблем вообще не в 1С, а в самой СУБД. Идем в Пуск - Программы - средства настройки SQL Server (версия может быть любая, от 2008 R2 до текущих) и смотрим статус служб "SQL Server" и "Агент SQL Server". Оба должны показывать "Работает". На практике служба SQL Server иногда падает после планового обновления Windows с перезагрузкой, а автозапуск для нее почему то не включен, и тогда 1С будет валиться с ошибкой подключения, хотя сама платформа тут ни при чем.

Если все запущено, но сервер все равно недоступен

Бывает, что порт открыт, процессы на месте, служба показывает "Работает", а клиенты все равно не могут подключиться. В таком случае помогает жесткий перезапуск с полной очисткой временных данных, а не просто рестарт службы через оснастку. Ниже порядок действий, который используют для этого сценария.

1. Останавливаем службу агента сервера командой net stop "1C:Enterprise 8.3 Server Agent (x86-64)" (имя службы нужно скопировать точно так, как оно указано у вас в списке служб).
2. Принудительно завершаем процессы через командную строку: TASKKILL /F /FI "IMAGENAME eq rphost*", затем rmngr*, затем ragent*. Порядок именно такой, потому что rphost может держать блокировку файлов, которые нужны rmngr.
3. Чистим временные папки 1С по нескольким адресам сразу, а не выборочно.
4. Запускаем службу заново командой net start "1C:Enterprise 8.3 Server Agent (x86-64)" и проверяем подключение с клиента.

Папки, которые нужно почистить, обычно такие: C:\Users\«Пользователь»\AppData\Local\1C\1Cv8 и 1Cv82, C:\Users\«Пользователь»\AppData\Roaming\1C\1Cv8 и 1Cv82, а также каталог кластера, например C:\Program Files\1cv8\srvinfo\reg_1541. Именно там накапливается кэш конфигураций и временные файлы блокировок, которые со временем начинают мешать серверу нормально стартовать. На серверах с большим числом информационных баз (десять и больше) размер этого кэша иногда доходит до нескольких гигабайт, и очистка сама по себе заметно ускоряет последующий запуск.

Что делать, если проблема повторяется регулярно

Разовый сбой можно списать на случайность, вроде обновления Windows или скачка нагрузки. А вот если сервер 1С перестает откликаться раз в неделю или чаще, разумнее смотреть на причину системно, а не просто повторять один и тот же перезапуск каждый раз. Чаще всего за этим стоит нехватка оперативной памяти на сервере под текущее число пользователей, устаревшая версия платформы с известными утечками в rphost, либо конфликт антивируса с процессами 1С (антивирус периодически блокирует временные файлы кластера на уровне файловой системы).

Для компаний, где 1С крутится на арендованных мощностях, есть смысл сверить характеристики виртуального сервера с рекомендациями фирмы 1С по объему памяти на пользователя. LanCloud, например, предлагает под такие задачи выделенные виртуальные машины с гибкой настройкой ресурсов именно под серверные версии 1С с MS SQL или PostgreSQL на борту, и в саппорте можно сразу уточнить, хватает ли текущей конфигурации под нужное число пользователей, а не выяснять это методом проб после очередного сбоя.