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

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

Базовый набор портов, которые участвуют в работе клиент-серверной 1С: порт агента сервера 1540, порты рабочих процессов из диапазона 1560–1591, порт кластера 1541 и порт менеджера кластера 1545. Для отладки по протоколу TCP сервер отладки использует порты из диапазона 1560–1591 (по умолчанию), а при отладке через веб-сервер дополнительно задействуются порты 80 или 443 веб-сервера. Файловый вариант базы отладку по сети не требует — там проблемы с портами почти не встречаются.

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

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

Прежде чем проверять, нужно понимать, что именно проверять. В типовой клиент-серверной установке задействованы следующие порты: 1540 — агент сервера 1С (ragent), 1541 — кластер серверов, 1545 — менеджер кластера (rmngr), 1560–1591 — рабочие процессы (rphost). Именно через rphost идёт основной трафик клиентских сеансов и отладочных подключений.

Сервер отладки (dbgs) при запуске занимает порт из того же диапазона 1560–1591, если в параметрах кластера не задан другой. Посмотреть фактические значения можно в консоли кластера серверов 1С: откройте свойства кластера и рабочего сервера — там указаны диапазоны портов. Если диапазон сужен администратором, ориентируйтесь на фактические настройки, а не на значения по умолчанию.

При отладке через веб-сервер (тонкий клиент или веб-клиент, публикация на IIS или Apache) добавляются порты веб-сервера: 80 для HTTP и 443 для HTTPS. В этом сценарии клиент общается с веб-сервером, а тот уже передаёт запросы рабочим процессам 1С, поэтому цепочка проверки становится длиннее.

Проверяем, какие порты слушает сервер 1С

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

netstat -ano | findstr "1540 1541 1545 1560"

В выводе ищите строки со статусом LISTENING. Если порт 1540 в состоянии LISTENING — агент сервера работает. Отсутствие строки означает, что служба «Агент сервера 1С:Предприятия» остановлена: проверьте её в оснастке services.msc и запустите вручную. По идентификатору процесса (PID) из последней колонки можно через диспетчер задач определить, какой именно процесс занял порт.

Более наглядный вариант — PowerShell-команда Get-NetTCPConnection, которая показывает состояние портов в удобном виде и позволяет фильтровать по процессу. Это полезно, когда на одном сервере работает несколько версий платформы или несколько кластеров с разными портами.

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

Проверяем доступность портов с клиентской машины

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

Самый удобный инструмент в современных версиях Windows — командлет Test-NetConnection в PowerShell. Он показывает, удалось ли установить TCP-соединение, и работает без установки дополнительных утилит.

Test-NetConnection -ComputerName srv1c -Port 1540

В результате смотрите на поле TcpTestSucceeded: значение True означает, что порт доступен, False — соединение блокируется или сервис не отвечает. Повторите проверку для портов 1541, 1545 и всего диапазона рабочих процессов. Если Test-NetConnection недоступен, используйте классический telnet: командой telnet srv1c 1540. Чёрный экран без ошибки — порт открыт, сообщение о сбое подключения — закрыт. Клиент telnet в Windows включается через «Компоненты Windows».

1. 1
   На сервере выполните netstat -ano и убедитесь, что порты 1540–1591 в состоянии LISTENING
2. 2
   С клиентской машины выполните Test-NetConnection -ComputerName <сервер> -Port 1540
3. 3
   Проверьте порты 1541, 1545 и диапазон 1560–1591 аналогично
4. 4
   При TcpTestSucceeded = False проверьте брандмауэр на сервере и промежуточное сетевое оборудование
5. 5
   После внесения изменений повторите проверку и запустите отладку в конфигураторе

Настройка брандмауэра Windows для отладки

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

Откройте «Брандмауэр Защитника Windows» → «Дополнительные параметры» → «Правила для входящих подключений». Создайте новое правило типа «Для порта», укажите протокол TCP и перечислите порты 1540, 1541, 1545, 1560-1591. Действие — «Разрешить подключение», профиль — доменный или частный (не выбирайте «Публичный» без необходимости). Аналогичного результата можно добиться одной командой PowerShell от администратора.

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

Более безопасная альтернатива — разрешить подключения не по портам, а по программам: ragent.exe, rmngr.exe, rphost.exe и dbgs.exe. Тогда при смене диапазона портов правила перенастраивать не придётся. Учтите также, что корпоративные антивирусы нередко содержат собственный сетевой экран, который работает независимо от брандмауэра Windows — его правила проверяются отдельно.

Особенности отладки через веб-сервер и по HTTPS

Когда клиент подключается через публикацию на веб-сервере, проверка начинается с портов веб-сервера. Убедитесь, что с клиентской машины доступны 80 или 443 порт: Test-NetConnection к веб-серверу по соответствующему порту. Затем проверьте, что веб-сервер сам может достучаться до рабочих процессов 1С — эта проверка выполняется уже с машины веб-сервера по схеме из предыдущих разделов.

Частая ситуация: веб-клиент работает, база открывается, но отладка не подключается. Причина обычно в том, что в конфигураторе не включён режим отладки по HTTP или на сервере отладки не разрешены подключения по этому протоколу. Проверьте в конфигураторе: «Сервис» → «Параметры» → «Отладка» → выберите протокол отладки, соответствующий публикации (HTTP или TCP), и при необходимости укажите адрес сервера отладки вручную.

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

Типичные ошибки и как их распознать

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

Ошибка «Сервер отладки не найден» или таймаут подключения указывает на сетевую блокировку: порт dbgs закрыт брандмауэром или сервер отладки слушает только локальный интерфейс. Проверьте вывод netstat: если в колонке Local Address стоит 127.0.0.1 вместо 0.0.0.0, сервис принимает только локальные подключения.

Ещё одна группа проблем — несовпадение версий платформы и разрядности компонентов, а также блокировка портов сторонними приложениями. Если порт 1540 занят не процессом ragent (это видно по PID в netstat), агент сервера не сможет стартовать. Освободите порт или перенастройте конфликтующее приложение.

Как убедиться, что проблема решена

После настройки портов и брандмауэра выполните контрольную проверку в правильной последовательности. Сначала Test-NetConnection со стороны клиента по всем нужным портам — все должны вернуть TcpTestSucceeded = True. Затем в конфигураторе откройте «Отладка» → «Подключение» и убедитесь, что в списке появляются доступные предметы отладки: сеансы пользователей и фоновые задания.

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

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