Каждый системный администратор и специалист 1С рано или поздно сталкивается с ситуацией, когда пользователи начинают жаловаться на периодические сбои при запуске программы. Одной из наиболее коварных и труднодиагностируемых проблем является плавающая ошибка: «Ошибка установки соединения с сервером 1С». Она примечательна тем, что возникает не постоянно, а хаотично. Пользователю достаточно нажать кнопку «Выполнить запуск» два-три раза, и система успешно запускается. Однако такое поведение программы сильно раздражает сотрудников и снижает общую производительность работы организации.
В этой статье мы подробно разберем причины возникновения этой ошибки, проанализируем реальный лог технологического журнала (ТЖ) клиента и рассмотрим по шагам проверенные методы решения этой проблемы — от простых правок системных файлов до глубокой настройки сетевого стека операционной системы.
Для начала проанализируем выгрузку из технологического журнала (ТЖ) на стороне клиента, где зафиксирован момент воспроизведения ошибки. Это поможет нам понять физику процесса взаимодействия клиента и сервера:
38:44.513001-0,CONN,2,process=1cv8c,ClientID=1,Protected=1,Txt='Connected, client=(2)10.94.94.192:60645, server=(2)10.94.10.65:1541'
38:46.825001-2359001,CONN,1,process=1cv8c,ClientID=1,Txt=Outgoing connection closed
38:46.825002-0,EXCP,1,process=1cv8c,Exception=580392e6-ba49-4280-ac67-fcd6f2180121,Descr='src\VResourceSessionImpl.cpp(347): 580392e6-ba49-4280-ac67-fcd6f2180121: Ошибка установки соединения'
Давайте детально разберем эти строки:
CONN с текстом Connected показывает, что на физическом уровне TCP-соединение между клиентом (IP-адрес 10.94.94.192) и сервером приложений 1С (IP-адрес 10.94.10.65) на порт 1541 успешно установилось.2359001 микросекунд) происходит принудительное закрытие исходящего соединения: Outgoing connection closed.EXCP с кодом 580392e6-ba49-4280-ac67-fcd6f2180121 в модуле VResourceSessionImpl.cpp. Этот модуль отвечает за работу виртуальной системы ресурсов (VRS), которая обеспечивает передачу данных между тонким/толстым клиентом и сервером 1С.Таким образом, мы видим, что сетевой сокет открывается без проблем, но на этапе первоначального обмена служебными пакетами (handshake) или авторизации происходит сбой, из-за которого клиент принудительно обрывает связь. Выясним, почему это происходит и как это исправить.
Как показывает практика администрирования распределенных сетей, одной из главных причин такого поведения является механизм обращения сервера 1С к СУБД (например, MS SQL Server) или к другим рабочим серверам кластера. Даже если в настройках подключения базы или в консоли кластера вы явно прописываете IP-адреса серверов, платформа 1С на определенных этапах работы все равно пытается выполнить преобразование имен (DNS-запросы) и обратиться к ним по их сетевым именам (Hostname).
Если в локальной сети наблюдаются задержки в работе DNS-сервера или отсутствует обратная зона просмотра DNS, клиент не успевает вовремя сопоставить имя сервера с его IP-адресом. Происходит таймаут, и соединение разрывается.
Для решения этой проблемы выполним принудительное статическое сопоставление имен в файле hosts на клиентских машинах (а также на самом сервере 1С):
C:\Windows\System32\drivers\etc\ и откроем файл hosts. Убедитесь, что в фильтре поиска файлов в правом нижнем углу проводника выбрано «Все файлы (*.*)».
10.94.10.65 SRV-S3CM1
10.94.10.66 SRV-SQL01
Сохраним изменения. Этот простой шаг позволяет полностью исключить фазу DNS-запросов из цепочки авторизации, благодаря чему соединение устанавливается мгновенно, и плавающая ошибка исчезает.
Современные операционные системы Windows по умолчанию отдают приоритет протоколу IPv6 перед IPv4. При попытке разрешить имя сервера 1С или SQL-сервера, система сначала запрашивает запись типа AAAA (IPv6). Если IPv6 в вашей локальной сети не настроен должным образом или блокируется брандмауэром, происходит задержка (таймаут), после чего система «откатывается» на IPv4. Именно эти драгоценные секунды ожидания и приводят к ошибке VResourceSessionImpl.
Для устранения этой проблемы рекомендуется настроить приоритет IPv4. Рассмотрим, как настроить приоритет через реестр Windows:
regedit.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters.DisabledComponents.20 в шестнадцатеричной системе исчисления (или 32 в десятичной). Это значение установит приоритет IPv4 над IPv6, сохранив при этом работоспособность самого интерфейса IPv6 для системных нужд.Часто причиной микроразрывов сетевых соединений в высоконагруженных средах 1С являются технологии аппаратной оптимизации сетевых плат (Offloading). Эти функции призваны снизить нагрузку на центральный процессор сервера, перенося часть вычислений контрольных сумм и сегментации пакетов на чип сетевой карты. Однако драйверы многих сетевых карт (особенно интегрированных решений от Realtek, Broadcom или старых линеек Intel) выполняют эти операции некорректно под специфической нагрузкой 1С.
Рассмотрим, как отключить эти функции для стабилизации сетевого стека:
netsh int tcp set global chimney=disabled
netsh int tcp set global autotuninglevel=disabled
После внесения этих изменений сетевой трафик станет более предсказуемым, а задержки при передаче мелких пакетов (из которых в основном и состоит трафик платформы 1С) сократятся до минимума.
Если ваши пользователи работают в 1С через VPN, маршрутизаторы или различные подсети, промежуточное сетевое оборудование (брандмауэры, NAT-устройства) может принудительно разрывать сессии, которые оно считает неактивными. По умолчанию в Windows интервал отправки пакетов проверки активности (Keep-Alive) составляет 2 часа. Если сетевой экран настроен на сброс трансляций через 15-30 минут, соединение тихо умирает на сетевом уровне, а клиент 1С узнает об этом только при следующей попытке обращения к серверу, получая ошибку соединения.
Настроим отправку пакетов Keep-Alive более часто (каждые 5 минут):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.KeepAliveTime и зададим ему десятичное значение 300000 (что соответствует 300 000 миллисекундам или 5 минутам).KeepAliveInterval и зададим ему значение 1000 (интервал между повторными проверками при отсутствии ответа — 1 секунда).При одновременной работе большого количества пользователей и частых фоновых заданиях сервер 1С активно открывает и закрывает TCP-соединения с СУБД. Закрытые порты переходят в состояние TIME_WAIT и освобождаются операционной системой только через определенное время (по умолчанию 4 минуты). В пиковые периоды это может привести к дефициту свободных портов в системе.
Увеличим диапазон доступных портов и ускорим их освобождение:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters создадим параметр DWORD с именем MaxUserPort и установим значение 65534 в десятичной системе (это расширит пул портов).TcpTimedWaitDelay и установим значение 30 в десятичной системе (это сократит время удержания закрытого порта в состоянии TIME_WAIT до 30 секунд).В некоторых версиях платформы 1С (особенно ранних релизах ветки 8.3.5, как в рассматриваемом случае — 8.3.5.1186) присутствовали внутренние утечки памяти или ошибки в работе менеджера кластера при перераспределении нагрузки между рабочими процессами rphost. Если вышеперечисленные сетевые настройки выполнены, но ошибка изредка продолжает появляться, мы рекомендуем обновить технологическую платформу 1С до актуального стабильного релиза (например, старших версий веток 8.3.22, 8.3.24 или выше, в зависимости от требований вашей конфигурации).
Проведя комплексную настройку сетевой инфраструктуры по предложенным шагам, мы получим стабильное и быстрое подключение пользователей к базам данных 1С без раздражающих сбоев и необходимости повторного запуска программы.