Не удалось подключиться к серверу 1С:Предприятие: проверка кластера, портов и служб по шагам

Ошибка почти всегда означает одно из трёх: служба сервера 1С не работает, клиент не доходит до портов кластера (1540, 1541 и диапазон рабочих процессов) или имя сервера указывает не туда. Ниже порядок проверки за 15 минут: службы, порты, имя и файрвол, затем сам кластер, плюс разбор аварии из практики на 33 рабочих места.

Что означает «Не удалось подключиться к серверу 1С:Предприятие» и с чего начинать

Это не диагноз, а жалоба клиента: он не дозвонился до кластера серверов. Причин у неё десяток, но в моей практике на серверах 1С в офисах до 50 рабочих мест девять случаев из десяти укладываются в три группы. Первая: на сервере остановлена служба или упал один из процессов кластера. Вторая: сеть между клиентом и сервером режет порты, чаще всего файрвол или смена профиля сети. Третья: клиент обращается по имени, которое резолвится в чужой или старый адрес. Всё остальное, от прав администратора кластера до лицензий, встречается заметно реже.

Главная ошибка, которую я вижу у коллег и у самих себя в начале карьеры, это идти сверху вниз: сначала открывать базу, смотреть настройки публикации, лезть в консоль кластера. Я иду снизу вверх, от физики к приложению. Сначала жив ли сервер и его службы, потом слушают ли порты, потом достучится ли с клиента, потом разрешается ли имя, и только после этого смотрю сам кластер и информационную базу. Так на проверку уходит 10–15 минут, и каждый шаг однозначно отсекает половину вариантов.

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

• Не работает у всех: сначала сервер, службы и порты (шаги 1–2).
• Не работает у одного: имя сервера, DNS-кэш, локальный файрвол, строка подключения (шаги 3–4).
• Работает по IP, но не по имени: DNS или файл hosts.
• Подключается к серверу, но база недоступна: уже не сетевая ошибка, смотрим кластер и саму базу (шаг 5).

Шаг 1. Запущена ли служба сервера 1С и живы ли процессы ragent, rmngr, rphost

Сервер 1С:Предприятия состоит из трёх типов процессов. Агент сервера ragent запускается как служба, хранит реестр кластеров и запускает их процессы, главный менеджер кластера rmngr управляет кластером, рабочие процессы rphost обслуживают сеансы пользователей. Если ragent не запущен, клиенту просто некому ответить, и именно с этого я начинаю. Подключитесь к серверу по RDP или через консоль гипервизора и посмотрите, что реально работает.

Отображаемое имя службы содержит русское или английское «1С», причём буква С может оказаться кириллической, поэтому поиск по звёздочке с латинской C легко ничего не найдёт. Надёжнее искать по пути к исполняемому файлу службы. Я запускаю в PowerShell от имени администратора два запроса: первый показывает службу и её состояние, второй процессы кластера и сколько памяти они занимают.

Get-CimInstance Win32_Service | Where-Object { $_.PathName -like '*ragent*' } | Select-Object Name, State, StartMode, PathName
Get-Process ragent, rmngr, rphost -ErrorAction SilentlyContinue | Select-Object Name, Id, WorkingSet64

Если служба остановлена, запустите её и сразу смотрите, не падает ли она снова через минуту. Если запускается и держится, причина, скорее всего, была разовой: перезагрузка сервера без автозапуска службы, обновление Windows, нехватка места на диске. Если падает, смотрите журнал событий Windows и каталог данных кластера: в тот момент вопрос уже не «подключения», а «почему не стартует сервер», и это отдельная работа.

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

Шаг 2. Какие порты нужны серверу 1С и как проверить, что они доступны с клиента

По умолчанию агент сервера слушает порт 1540, главный менеджер кластера использует 1541, а рабочие процессы получают порты из диапазона 1560–1591. Эти значения заданы параметрами запуска ragent (-port, -regport, -range), и в конкретной установке их могли поменять, особенно если на одном сервере живут несколько кластеров или версий платформы. Поэтому не верьте таблице из интернета, в том числе моей: сначала посмотрите, что реально слушает ваш сервер, и сверьте с ключами в пути к исполняемому файлу службы. Сервер администрирования ras, если вы его запускали, по умолчанию использует порт 1545 и к подключению пользователей отношения не имеет.

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

Get-NetTCPConnection -State Listen -LocalPort 1540,1541 | Select-Object LocalAddress, LocalPort, OwningProcess
Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -ge 1560 -and $_.LocalPort -le 1591 } | Select-Object LocalPort, OwningProcess

Значение OwningProcess сверьте с идентификаторами процессов ragent, rmngr и rphost из прошлого шага: так видно, что порт занят именно 1С, а не чужой программой. С клиента проверка выглядит так:

Test-NetConnection -ComputerName srv-1c.example.com -Port 1540
Test-NetConnection -ComputerName srv-1c.example.com -Port 1541

В выводе нас интересует строка TcpTestSucceeded. Значение True означает, что соединение установлено, False означает, что порт закрыт файрволом либо на этом адресе никто не слушает.

С рабочими процессами сложнее. В типовой схеме клиент по строке подключения Srvr="srv-1c" идёт на порт кластера (без явного номера это 1541), менеджер выдаёт ему адрес рабочего процесса, и дальше обмен идёт уже с rphost на порту из диапазона. Порт агента 1540 нужен консоли кластера, серверу ras и связи серверов между собой; я открываю его вместе с 1541, чтобы не гадать. Поэтому ошибка может возникнуть уже после успешной проверки 1540 и 1541. Поэтому я проверяю и порты диапазона, но только те, которые сервер реально слушает (их вы видели в предыдущем запросе). Проверять все 32 порта подряд смысла нет: свободные порты вообще никто не слушает, и тест вернёт False даже при идеальной сети. Про то, как правильно задавать число процессов, лимиты памяти и перезапуск, я писал в статье про производительность кластера серверов 1С, здесь это только вопрос доступности. | Порт (по умолчанию) | Кто слушает | Нужен ли клиенту | |---|---|---| | 1540 | ragent, агент сервера | Консоли и ras; открываю вместе с 1541 | | 1541 | rmngr, главный менеджер кластера | Да | | 1560–1591 | rphost, рабочие процессы | Да, реально занятые порты | | 1545 | ras, сервер администрирования | Нет, только администратору |

Шаг 3. Имя сервера, DNS и файрвол: почему по IP работает, а по имени нет

Следующая по частоте причина после остановленной службы, это имя. В строке подключения к базе или в списке баз клиента указано имя сервера, и если оно резолвится в старый адрес (сервер переехал, сменили IP, виртуальную машину клонировали), клиент стучится не туда. Проверка занимает полминуты: выполните на клиенте Resolve-DnsName srv-1c.example.com и сравните адрес с реальным адресом сервера. Если адрес неверный, сбросьте кэш DNS на клиенте командой ipconfig /flushdns и исправьте запись на DNS-сервере. А если в разных кабинетах разный результат, ищите дубликат записи или кэш на промежуточном DNS.

Теперь файрвол. На сервере правила, пропускающие порты 1С, должны действовать в том сетевом профиле, в котором сервер сейчас находится. Это ловушка, на которую я наступал сам: правила создаются для профиля Domain или Private, а после замены сетевого адаптера, переезда виртуальной машины или обновления Windows сеть получает профиль Public, и все ваши аккуратные правила перестают действовать. RDP при этом часто продолжает работать, потому что у него собственное правило, и вы теряете полчаса, убеждая себя, что «сеть же есть». Профиль смотрится командой:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory

Значения NetworkCategory бывают Public, Private и DomainAuthenticated. Если у сервера в офисной сети стоит Public, это первый подозреваемый.

Правило для 1С лучше создать один раз, сразу для нужных профилей и с ограничением по адресам офисной сети, а не «для всех». Диапазон портов и перечисление можно задавать в одной команде, а -RemoteAddress принимает подсеть:

New-NetFirewallRule -DisplayName '1C server cluster' -Direction Inbound -Protocol TCP -LocalPort 1540,1541,1560-1591 -RemoteAddress 10.10.0.0/24 -Profile Domain,Private -Action Allow

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

Шаг 4. Служба и порты в порядке, а ошибка осталась: проверяем кластер

Если с клиента порты доступны, служба работает, имя резолвится верно, а клиент по-прежнему не подключается, настало время заглянуть в сам кластер. Здесь есть три сюрприза. Первый: в кластере нет нужной информационной базы или она зарегистрирована под другим именем, чем указано в списке баз клиента. Второй: сам кластер на нестандартном порту, а в строке подключения указан порт по умолчанию. Третий: у клиента устаревшая или несовместимая версия платформы относительно сервера. Для клиент-серверного режима сборка платформы клиента должна совпадать с сервером до последней цифры (8.3.24.1691 и 8.3.25.1257 уже несовместимы), иначе вместо работы пользователь получает ошибку о несоответствии версий клиента и сервера. Ставить на клиенты ту же сборку, что и на сервере, должно быть правилом, а не пожеланием.

Состояние кластера удобно смотреть утилитой rac, которая работает через сервер администрирования ras. Запуск ras в документации ИТС описан в виде ras cluster --port=1545 srv-1c:1540, где --port задаёт порт самого ras, а в конце указан адрес агента сервера (по умолчанию localhost:1540). Для запуска службой Windows добавляют ключ --service, на Linux ras запускают с --daemon. Версия ras должна совпадать с версией кластера. Дальше с любой машины, где установлена платформа, смотрим кластеры и базы:

rac srv-1c:1545 cluster list
rac srv-1c:1545 infobase summary list --cluster=<UUID_кластера> --cluster-user=<администратор> --cluster-pwd=<пароль>

В первой команде вы получите идентификатор кластера, имя и порт, во второй список баз кластера. Точный синтаксис зависит от версии платформы, поэтому выполните rac help на своём сервере и сверьтесь с ним. Если команда cluster list не отвечает, значит, не работает уже сам слой администрирования: проверьте, запущен ли ras и слушает ли он порт 1545. Подробнее об администрировании кластера через rac и о том, какие операции безопасны на живой системе, я писал в материале про управление кластером 1С через rac.

Отдельно скажу про соблазн «просто удалить список кластеров и пересоздать». В документации для старых версий платформы описан сценарий, когда при повреждённой конфигурации кластера останавливают ragent, удаляют файл со списком кластеров (srvribrg.lst) и запускают ragent снова. Рядом лежат каталоги регистрации вида reg_1541, названные по порту кластера. Так можно вернуть кластер по умолчанию, но вместе с ним теряются настройки: параметры рабочих серверов, регистрация баз, администраторы кластера. Делать это я бы стал только после полной копии каталога данных кластера и только когда исчерпаны остальные варианты. В 8.2 и 8.3 имена другие: список кластеров агента лежит в файле 1cv8wsrv.lst в каталоге srvinfo (путь задан ключом -d в строке запуска службы), а список баз кластера в 8.3 хранится в reg_1541\1CV8Clst.lst. Если базы «пропали» из кластера, сначала сохраните копию этого файла: по ней можно вернуть параметры подключения баз. Проверьте имена у себя, а не копируйте команды из статей.

Разбор из практики: «Соколиный питомник», 33 рабочих места, сервер 1С недоступен после переезда ВМ

Клиент, условный питомник животных «Соколиный питомник», 33 рабочих места, один сервер 1С на виртуальной машине под Windows Server в рабочей группе, без домена, база в клиент-серверном режиме. В понедельник в 8:40 бухгалтер и менеджеры по продажам написали в один голос, что 1С не открывается с ошибкой подключения к серверу. Накануне вечером, как выяснилось, сотрудник подрядчика переносил виртуальную машину на другой хост гипервизора и заменил виртуальный сетевой адаптер. Мне позвонили в 8:50. Сервер пинговался, по RDP заходил, и все были уверены, что «сеть работает».

Я пошёл по описанному выше порядку. Служба сервера 1С работала, процессы ragent, rmngr и rphost были на месте, диск свободен. Дальше проверка портов: на сервере 1540 и 1541 слушались, а с клиентской машины Test-NetConnection вернул False по обоим. Получается, порты открыты на приложении, но закрыты на пути. Команда Get-NetConnectionProfile показала у нового адаптера категорию Public, а правило для портов 1С было создано два года назад только для профиля Private. Windows увидела «новую» сеть и, поскольку контроллера домена нет, применила к ней профиль по умолчанию, то есть самый строгий. До этой команды мы потеряли минут десять, потому что сначала проверяли саму базу и права пользователей, то есть шли сверху вниз.

Исправление заняло две минуты: профиль сети вернули в Private командой Get-NetConnectionProfile -InterfaceAlias <имя адаптера> | Set-NetConnectionProfile -NetworkCategory Private, и работа возобновилась. Всего простой составил около 50 минут, примерно 27 человеко-часов потерянной работы на 33 рабочих места. После этого я сделал три вещи. Пересоздал правило файрвола сразу для профилей Domain и Private и с ограничением по подсети офиса. Добавил в мониторинг проверку TCP-портов 1540 и 1541 с точки зрения соседней машины, а не самого сервера. Записал в регламент переносов ВМ пункт «после замены адаптера проверить сетевой профиль и порты 1С». С тех пор подобных историй у клиента не было. Подробнее о том, как мы подключаем сервер 1С к Zabbix, написано в мониторинге сервера 1С в Zabbix.

Как не получать эту ошибку снова: мониторинг, регламент и резерв

Главное, что я бы сделал после любой такой аварии: научил систему сообщать о проблеме раньше пользователей. Минимум для небольшого офиса это проверка доступности TCP-портов 1540 и 1541 снаружи самого сервера, статус службы ragent и свободное место на диске с данными кластера. Если порт перестал отвечать, вы узнаёте об этом из уведомления, а не из звонка бухгалтера. Всё это настраивается в Zabbix за час, и именно такие проверки оправдывают мониторинг в небольшой компании сильнее, чем красивые графики.

Второй слой это регламент изменений. Из десятка аварий с недоступным сервером 1С, которые я разбирал, большинство начиналось с чьего-то планового действия: перенос ВМ, замена адаптера, обновление Windows, смена IP. Поэтому у нас в АйТи-Фреш любое такое действие заканчивается короткой проверкой: службы, порты, подключение тестового клиента. Это занимает пять минут и закрывает основной источник проблем.

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

• Проверка TCP 1540 и 1541 с отдельной машины, оповещение при сбое.
• Контроль службы ragent и свободного места на диске кластера.
• Правила файрвола для нужных профилей и подсетей, а не «для всех».
• Чек-лист после любых работ на сервере: службы, порты, тестовое подключение.

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