Как открыть порты отладки 1С

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

По умолчанию сервер 1С использует диапазон портов 1560–1591: агент сервера слушает порт 1540, кластер работает на 1541, а рабочие процессы занимают порты из диапазона 1560–1591. Именно через эти порты идёт и отладочный трафик при отладке по протоколу TCP/IP. Отдельного «порта отладки» в 1С не существует — отладка работает поверх штатных портов сервера, но требует запуска сервера с параметром -debug.

Ниже разобран полный цикл: включение режима отладки на сервере, открытие портов в брандмауэре Windows и Linux, проверка доступности портов, настройка конфигуратора и типичные ошибки, из-за которых отладка не подключается.

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

Прежде чем открывать что-либо в брандмауэре, важно понимать, какие порты реально задействованы. Агент сервера 1С (ragent) по умолчанию слушает порт 1540, менеджер кластера (rmngr) — 1541, а рабочие процессы (rphost) занимают порты из диапазона 1560–1591. Если в кластере несколько рабочих процессов, каждый из них получает свой порт из этого диапазона.

Отладка по протоколу TCP/IP идёт через порты рабочих процессов — именно поэтому недостаточно открыть только 1540 и 1541: конфигуратор подключится к агенту, получит список процессов, но не сможет установить отладочное соединение с rphost. Это одна из самых частых причин ситуации «отладка включена, но предметы отладки не появляются».

Если порты были изменены при установке (например, кластер работает на 2541), все правила брандмауэра нужно строить относительно фактических значений. Узнать реальные порты можно в консоли кластера серверов или командой netstat -ano | find "LISTENING" с сопоставлением PID процессов ragent, rmngr и rphost.

Запуск сервера 1С в режиме отладки

Без режима отладки открытие портов бессмысленно: сервер не будет регистрировать предметы отладки. На Windows проще всего включить режим через реестр. Откройте редактор реестра, найдите ветку службы агента сервера (обычно HKLM\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent или похожую, в зависимости от версии и порта) и в параметре ImagePath добавьте ключ -debug в строку запуска ragent.

После правки обязательно перезапустите службу агента сервера — через оснастку «Службы» или командой net stop / net start с именем службы. Без перезапуска ключ не применится. Учтите, что перезапуск агента разорвёт все активные сеансы пользователей, поэтому делайте это вне рабочего времени или предупредите сотрудников.

На Linux ключ -debug добавляется в параметры запуска демона srv1cv8 — обычно в unit-файл systemd или скрипт запуска, в переменную с аргументами. После правки выполните systemctl daemon-reload и перезапустите службу.

Открытие портов в брандмауэре Windows

На сервере с Windows правила создаются через «Брандмауэр Защитника Windows» в режиме повышенной безопасности. Откройте оснастку wf.msc, перейдите в «Правила для входящих подключений» и создайте новое правило типа «Порт». Укажите протокол TCP и порты: 1540-1541, 1560-1591. Разрешите подключение, выберите нужные профили (обычно «Доменный» и «Частный») и задайте понятное имя правила, например «1C Server Debug».

Того же результата можно добиться одной командой в PowerShell от имени администратора, что удобно при настройке нескольких серверов:

New-NetFirewallRule -DisplayName "1C Server Debug" -Direction Inbound -Protocol TCP -LocalPort 1540-1541,1560-1591 -Action Allow

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

Открытие портов в Linux

На серверах с Linux правила добавляются через firewalld или iptables в зависимости от дистрибутива. Для firewalld команды выглядят так: firewall-cmd --permanent --add-port=1540-1541/tcp, затем firewall-cmd --permanent --add-port=1560-1591/tcp и firewall-cmd --reload для применения изменений.

Для iptables используются правила вида iptables -A INPUT -p tcp --dport 1540:1541 -j ACCEPT и аналогично для диапазона 1560:1591. Не забудьте сохранить правила, чтобы они пережили перезагрузку сервера — способ сохранения зависит от дистрибутива.

После настройки проверьте, что порты действительно слушаются: ss -tlnp | grep -E "154|156" покажет процессы ragent, rmngr и rphost с их портами. Если процесс есть, а порта в списке нет — проверьте, с какими параметрами запущен агент.

Проверка доступности портов и подключение отладки

Проверку начинайте с машины, на которой работает конфигуратор. Выполните telnet имя_сервера 1541 (или используйте Test-NetConnection имя_сервера -Port 1541 в PowerShell). Успешное подключение означает, что сеть и брандмауэр настроены корректно. Повторите проверку для нескольких портов из диапазона 1560–1591, особенно для тех, что заняты процессами rphost.

Затем в конфигураторе откройте «Отладка» → «Подключение» и убедитесь, что в настройках выбран тип отладки «По протоколу TCP/IP», а в поле поиска указан сервер. Нажмите кнопку поиска предметов отладки — в списке должны появиться серверные контексты. Если список пуст, проверьте, совпадает ли версия платформы конфигуратора с версией сервера: несовпадение версий — частая причина «невидимых» предметов отладки.

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

Самая распространённая ошибка — открыть только порты 1540 и 1541, забыв про диапазон рабочих процессов. Внешне всё выглядит рабочим: кластер виден, базы подключаются, но отладка молчит. Вторая частая проблема — режим отладки HTTP вместо TCP/IP: если в свойствах информационной базы выбран протокол HTTP, отладка идёт через веб-сервер, и порты кластера для неё не критичны, зато требуется корректная публикация на веб-сервере.

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

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