Как исправить ошибку «Удаленный хост принудительно разорвал подключение» на сервере 1С?

При администрировании базы через консоль кластера серверов 1С (нажатие пункта «Свойства» информационной базы) или при выполнении ресурсоемких операций (закрытие месяца, формирование сложных отчетов) может возникать сбой: «Ошибка параметров подключения информационной базы данных... Удаленный хост принудительно разорвал подключение» (ошибка сетевого доступа Windows Sockets 10054).

Разберем подробнее причины возникновения этой ситуации и варианты ее решения.

Причины возникновения ошибки

Проанализируем основные факторы, из-за которых происходит сброс соединения:

1. Аварийное завершение рабочего процесса rphost из-за нехватки памяти. На 32-разрядных серверах 1С каждый рабочий процесс ограничен объемом оперативной памяти 2–4 ГБ. При выполнении сложных отчетов или открытии параметров базы процесс может моментально исчерпать доступный лимит и падать. В этот момент клиенты и консоль администрирования получают разрыв подключения.
2. Несоответствие версий консоли MMC и сервера 1С. Графическая оснастка 1cv8.msc требует точного совпадения релиза платформы с запущенной службой на сервере вплоть до последней цифры сборки.
3. Корректность работы сетевого протокола IPv6. Часто снятие галочки в свойствах сетевого адаптера не отключает IPv6 полностью, что вызывает задержки и разрывы TCP-сессий между компонентами сервера.
4. Повреждение служебных файлов кластера. При сбоях питания или аварийных перезапусках могут повредиться файлы из каталога srvinfo (файлы списков .lst).

Шаг 1. Переход на 64-разрядный сервер 1С и перезапуск процессов

Если проблема вызвана падением rphost при выполнении тяжелых процедур (например, закрытия месяца):

1. Оперативный ремонт: перезапустить службу ragent или вручную завершить «зависшие» процессы rphost.exe через Диспетчер задач. Это высвободит память, но является лишь временным решением.
2. Стратегическое решение: перевести кластер серверов 1С на 64-разрядную версию платформы. 64-битный процесс rphost не ограничен лимитом в 4 ГБ и сможет выполнять ресурсоемкие операции без аварийного завершения.

Шаг 2. Настройка технологического журнала для поиска проблемного кода

Чтобы убедиться, что причиной падения является именно нехватка памяти или ошибка конкретного алгоритма, настроим Технологический журнал. Создадим файл logcfg.xml в каталоге конфигурации платформы:

<config xmlns="http://v8.1c.ru/v8/exc/log">
  <log location="C:\1C_Logs" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="ADMIN"/>
    </event>
  </log>
</config>

Проанализируем созданные логи. Ищем события EXCP (исключительные ситуации) и фиксируем контекст выполнения кода перед разрывом связи. Это позволит понять, не вызывает ли сбой новый неоптимальный отчет или обработка.

Шаг 3. Управление лимитами памяти в кластере серверов

Чтобы рабочий процесс не падал аварийно, настроим параметры перезапуска процессов в консоли кластера 1С:

1. Откроем консоль администрирования кластера серверов 1С.
2. Перейдем в свойства кластера.
3. Установим параметры:
   • Временно допустимый объем памяти процессов — значение в байтах, при превышении которого процесс помечается как устаревший и мягко завершается после выполнения всех сеансов.
   • Критический объем памяти процессов — порог, при котором платформой принудительно создается новый рабочий процесс, а текущий завершается.
   • Интервал перезапуска рабочих процессов — регулярное обновление процессов для предотвращения фрагментации памяти (например, 86400 секунд).

Шаг 4. Полное отключение IPv6 через реестр Windows

Если в сети включен IPv6 или он отключен некорректно, выполним его полное отключение на сервере 1С через системный реестр:

1. Откроем редактор реестра (regedit).
2. Перейдем в ветку: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
3. Создадим параметр DisabledComponents типа DWORD (32 бита) со значением 0xFF.
4. Перезагрузим сервер для применения изменений.

Шаг 5. Очистка служебных файлов и повторная регистрация базы

Если ошибка появляется исключительно при открытии свойств конкретной информационной базы в консоли:

1. Зафиксируем настройки подключения к СУБД (имя сервера, имя базы, логин и пароль).
2. Удалим запись информационной базы из консоли кластера серверов 1С (внимание: выбираем вариант без удаления базы данных на СУБД).
3. Зарегистрируем базу в консоли кластера заново.
4. Если сбой сохраняется для всех баз, остановим службу ragent, сделаем копию каталога srvinfo и выполним его очистку с последующей повторной настройкой кластера.