Какие порты открыть в SQL Server для работы 1С

При клиент-серверной работе 1С:Предприятия с Microsoft SQL Server большинство проблем с подключением сводится к закрытым портам на брандмауэре. Типовая картина: база создана, сервер 1С запущен, но клиенты получают ошибку «соединение с сервером баз данных не установлено» или «server not found». Причина почти всегда в том, что сетевой экран блокирует трафик между тремя компонентами: клиентом 1С, сервером 1С и SQL Server.

Важно понимать, что клиентское приложение 1С напрямую с SQL Server не работает — оно обращается к серверу 1С:Предприятия, а уже тот общается с СУБД. Поэтому открывать порты нужно на двух машинах: на сервере SQL Server и на сервере 1С. Если обе роли совмещены на одном компьютере, все правила создаются на нём.

Ниже разобран конкретный набор портов, правила для брандмауэра Windows, настройка статического порта в SQL Server и способы проверить, что связность действительно появилась.

Какие порты использует связка 1С и SQL Server

Полный минимальный набор портов выглядит так. Со стороны SQL Server это TCP 1433 — стандартный порт экземпляра по умолчанию, и UDP 1434 — порт службы SQL Server Browser, которая сообщает клиентам, на каком порту слушает именованный экземпляр. Со стороны сервера 1С:Предприятия используются: 1540 — порт агента кластера, 1541 — порт менеджера кластера, 1560–1591 — диапазон динамических портов рабочих процессов (rphost).

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

Настройка портов на стороне SQL Server

Сначала проверьте, какой порт реально слушает ваш экземпляр. Откройте SQL Server Configuration Manager, перейдите в раздел «Сетевая конфигурация SQL Server» → «Протоколы для <имя экземпляра>» → свойства TCP/IP. На вкладке «IP-адреса» в самом низу, в разделе IPAll, смотрите поля «TCP Dynamic Ports» и «TCP Port». Если в поле динамических портов стоит значение, а статический пуст — экземпляр при каждом перезапуске может менять порт, что ломает правила брандмауэра.

Практическая рекомендация для 1С — зафиксировать статический порт. Для этого очистите поле «TCP Dynamic Ports» (оставьте пустым), а в «TCP Port» укажите 1433 или другой свободный порт. После изменения перезапустите службу SQL Server. Убедитесь также, что сам протокол TCP/IP включён — на свежих установках он иногда отключён по умолчанию.

Дополнительно проверьте, что в свойствах сервера разрешены удалённые подключения и выбран режим проверки подлинности «Смешанный режим» (SQL Server и Windows), если вы подключаетесь под пользователем SQL типа sa или отдельной учётной записью для 1С. Без этого ошибка будет не про порт, а про аутентификацию, но симптомы похожи.

1. 1
   Откройте «Брандмауэр Защитника Windows» → «Дополнительные параметры»
2. 2
   Выберите «Правила для входящих подключений» → «Создать правило»
3. 3
   Тип правила — «Для порта», протокол TCP, порт 1433
4. 4
   Действие — «Разрешить подключение», профиль — «Доменный» (или нужный)
5. 5
   Задайте имя, например «SQL Server 1433», и сохраните
6. 6
   Повторите для UDP 1434, если используется именованный экземпляр

Порты сервера 1С:Предприятия

На машине, где установлен сервер 1С, откройте TCP-порты 1540, 1541 и диапазон 1560–1591. Брандмауэр Windows позволяет указать диапазон одним правилом: в поле порта введите 1560-1591. Эти порты нужны, чтобы клиенты подключались к кластеру: сначала клиент обращается к агенту (1540), получает адрес рабочего процесса и дальше работает с rphost на одном из портов диапазона.

Если консоль администрирования кластера находится на другой машине, ей тоже нужен доступ к 1540 и 1541. Частая ситуация: база работает, а консоль кластера с рабочего места администратора не подключается — это признак того, что открыт только диапазон рабочих процессов, а 1540/1541 закрыты.

Если сервер 1С и SQL Server разнесены по разным машинам, то на сервере 1С правила нужны для входящих подключений от клиентов, а на SQL Server — для входящих от сервера 1С. Исходящие подключения брандмауэр Windows по умолчанию разрешает, поэтому отдельных исходящих правил обычно не требуется.

Именованный экземпляр: Browser или статический порт

Именованный экземпляр (например, SRV\SQL2019) создаёт две стратегии настройки. Первая — включить службу SQL Server Browser и открыть UDP 1434: тогда клиенты указывают имя экземпляра, а Browser сообщает им актуальный динамический порт. Вторая — назначить экземпляру статический порт, открыть только его и указывать в настройках базы 1С адрес в формате SRV,1435 (через запятую, без имени экземпляра).

Для продуктивной среды предпочтителен статический порт: меньше открытых портов, нет зависимости от дополнительной службы, проще диагностика. SQL Server Browser оставляют, когда экземпляров много и администрировать статические порты на каждый неудобно.

Проверка связности после настройки

После создания правил проверьте доступность портов с машины клиента и с сервера 1С. Самый быстрый способ — PowerShell: команда Test-NetConnection sqlserver -Port 1433 покажет TcpTestSucceeded: True, если порт открыт и SQL Server его слушает. Аналогично проверьте 1540 на сервере 1С.

Дополнительно убедитесь, что служба слушает порт локально: на SQL Server выполните netstat -ano | findstr 1433 — в выводе должна быть строка LISTENING. Если порта в списке нет, проблема не в брандмауэре, а в конфигурации SQL Server: отключён TCP/IP или служба не перезапущена после изменения настроек.

Финальная проверка — запуск информационной базы из клиента 1С. Если база открывается, списки пользователей и документы загружаются без ошибок соединения, сетевая часть настроена корректно.

Test-NetConnection sqlserver01 -Port 1433; Test-NetConnection srv1c -Port 1540

Типичные ошибки и ограничения

Самая частая ошибка — открыть 1433, но забыть, что экземпляр именованный и реально слушает динамический порт. Вторая по популярности — правила созданы для профиля «Частный», а сервер находится в доменном профиле сети, поэтому правило не применяется. Проверяйте профиль сети командой Get-NetConnectionProfile.

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

Отдельно: не открывайте порт 1433 наружу, в интернет. Публикация SQL Server во внешнюю сеть — прямой путь к перебору паролей и шифровальщикам. Для удалённого доступа используйте VPN, а порты СУБД оставляйте доступными только внутри периметра.

FAQ