Почему не работает отладка серверных процедур 1С на терминальном сервере и как это исправить?

← На главную

Разработчики 1С часто сталкиваются с неприятной ситуацией: на локальных рабочих станциях отладка серверных процедур и функций функционирует без нареканий, но при попытке запустить отладку на терминальном сервере (RDS) точки останова в серверном коде упорно игнорируются. При этом клиентская отладка (на клиенте) может продолжать работать.

В этой статье мы подробно разберем внутреннюю архитектуру механизмов отладки платформы «1С:Предприятие», выясним фундаментальные причины такого поведения системы и рассмотрим два практических способа решения проблемы: классический (через настройку портов TCP/IP) и современный (через переход на HTTP-протокол отладки).

Архитектурная особенность TCP/IP-отладки: почему стандартный подход не работает

Для того чтобы понять суть проблемы, нам необходимо проанализировать, как именно физически происходит сетевое взаимодействие между Конфигуратором и сервером приложений 1С в режиме классической TCP/IP-отладки.

Вопреки интуитивному представлению большинства специалистов, инициатором сетевого соединения при остановке на серверных вызовах выступает не клиент (Конфигуратор), а сервер 1С (конкретно — рабочий процесс rphost).

Схема взаимодействия выглядит следующим образом:

При запуске Конфигуратора в режиме отладки на терминальном сервере он захватывает свободный TCP-порт из стандартного диапазона (по умолчанию это 1560:1591) и переходит в режим ожидания («слушает» этот порт).
Когда пользователь совершает в режиме предприятия действие, вызывающее серверную процедуру, рабочий процесс сервера 1С rphost пытается инициировать обратное входящее соединение на IP-адрес терминального сервера и тот самый порт, который занял Конфигуратор.
Если на пути этого обратного соединения встает брандмауэр Windows (на терминальном сервере или на сервере 1С) или сетевой экран, пакеты блокируются. Точка останова в серверном коде не срабатывает, хотя сам сеанс продолжает выполняться.

Таким образом, для успешной работы классической отладки нам требуется обеспечить двустороннюю сетевую видимость по конкретным портам.

Решение №1: Настройка правил брандмауэра для TCP/IP

Если мы планируем оставаться на классическом протоколе TCP/IP, нам потребуется открыть порты как на стороне сервера 1С, так и на стороне терминального сервера.

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

Шаг 1. Определение используемого порта в Конфигураторе

Для начала выясним, по какому именно порту пытается работать Конфигуратор на терминальном сервере. Для этого в запущенном Конфигураторе перейдем по меню: Отладка — Подключение — Настройка. В открывшемся окне в нижней части будет указан текущий порт отладки (например, 1562).

Шаг 2. Проверка сетевой доступности

Мы можем проверить доступность этого порта непосредственно с сервера 1С с помощью утилиты PowerShell. Запустим PowerShell на сервере 1С и выполним команду проверки соединения, указав IP-адрес терминального сервера:

Test-NetConnection -ComputerName [IP_Адрес_Терминала] -Port 1562

Если в результате выполнения параметр TcpTestSucceeded возвращает значение False, значит, сетевой трафик блокируется брандмауэром.

Шаг 3. Создание правил в брандмауэре Windows

Чтобы решить эту проблему раз и навсегда, необходимо открыть весь стандартный диапазон портов на обоих серверах:

На сервере терминалов: создаем входящее правило (Inbound Rule) для протокола TCP, разрешающее порты с 1560 по 1591 для исполняемых файлов платформы 1С или для всей подсети разработчиков.
На сервере приложений 1С: создаем исходящее правило (Outbound Rule) для протокола TCP на этот же диапазон портов, разрешающее исходящие подключения рабочему процессу rphost.exe.

Важное примечание: Если на одном терминальном сервере работают одновременно несколько разработчиков, стандартного пула из 32 портов (1560:1591) может банально не хватить, так как каждый открытый Конфигуратор монопольно захватывает свои порты. В этом случае диапазон необходимо принудительно расширить.

Для этого создадим на сервере терминалов конфигурационный файл debugcfg.xml в каталоге установленной платформы (например, C:\Program Files\1cv8\8.3.XX.XXXX\bin\conf\) со следующим содержимым:


<config xmlns="http://v8.1c.ru/v8/debugcfg">
    <debugports range="1560:1690"/>
</config>

После создания этого файла диапазон доступных портов расширится до 1690. Соответственно, эти же порты нужно будет открыть в сетевых экранах обеих машин.

Почему правила брандмауэра могут примениться не сразу?

Иногда системные администраторы сталкиваются с тем, что правила добавлены, но отладка начинает работать только «на следующее утро» или после перезагрузки. Это связано со следующими факторами:

Кэширование сокетов: Активные рабочие процессы rphost удерживают старые сетевые сессии и не всегда оперативно реагируют на изменения сетевых политик «на лету» без перезапуска службы.
Обновление групповых политик (GPO): В доменной среде настройки брандмауэра могут распространяться централизованно. В таких случаях изменения вступают в силу только после выполнения на серверах команды gpupdate /force.
Зависшие сеансы отладчика: В системе могут оставаться «спящие» или зависшие сессии пользователей, которые блокируют порты. Помогает принудительное завершение таких сеансов в консоли администрирования или очистка серверного кэша.

Если вы хотите избежать сложностей с пробросом портов в брандмауэрах и маршрутизацией обратных пакетов (особенно актуально при работе разработчиков через VPN), мы рекомендуем рассмотреть более современную альтернативу.

Решение №2: Переход на HTTP-отладку (Рекомендуемый способ)

Начиная с версии платформы 8.3.7, фирма «1С» представила качественно новый механизм — отладку по протоколу HTTP. Этот способ кардинально отличается от классического TCP/IP архитектурно и решает абсолютно все проблемы с блокировками обратных соединений на терминальных серверах.

При использовании HTTP-отладки в цепочку взаимодействия добавляется специальная промежуточная служба — локальный сервер отладки (dbgs.exe):

И Конфигуратор на терминале, и рабочий процесс rphost на сервере 1С устанавливают прямые исходящие соединения к службе dbgs.
Больше нет необходимости инициировать обратное соединение от сервера к клиенту. Терминальный сервер вообще не обязан принимать какие-либо входящие подключения от сервера 1С.
Для работы всей схемы достаточно открыть всего один единственный входящий порт на сервере 1С (по умолчанию это порт 1550).

Проанализируем пошагово процесс перевода системы на HTTP-отладку:

Шаг 1. Настройка службы Агента сервера 1С

Нам необходимо запустить службу Агента сервера 1С с параметрами, инициализирующими HTTP-отладку. Для этого откроем редактор реестра Windows (regedit) на сервере приложений 1С, перейдем к ветке службы сервера:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent\] (название ветки может незначительно отличаться в зависимости от версии платформы).

Найдем параметр ImagePath и отредактируем его значение, добавив в строку запуска ключи -debug -http:


"C:\Program Files\1cv8\8.3.22.1709\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug -http

После внесения изменений запишем параметры и перезапустим службу Агента сервера 1С через оснастку services.msc. При перезапуске Агент автоматически запустит сопутствующий процесс сервера отладки dbgs.exe, который по умолчанию начнет слушать порт 1550.

Внимание: убедитесь, что порт 1550 на сервере 1С открыт для входящих TCP-подключений с терминального сервера.

Шаг 2. Настройка Конфигуратора на терминальном сервере

Теперь укажем Конфигуратору, что отладку нужно выполнять по новому протоколу. На сервере терминалов запустим Конфигуратор, перейдем в меню: Сервис — Параметры — Отладка.

В группе настроек переключаем протокол отладки в положение: Отладка по протоколу HTTP.
В поле «Адрес сервера отладки» прописываем сетевой адрес сервера 1С с указанием порта службы dbgs, например: http://192.168.200.5:1550 или http://имя_сервера_1с:1550.
Нажимаем кнопку «Применить» и перезапускаем Конфигуратор для вступления настроек в силу.

После выполнения этих простых шагов отладка серверного кода на терминальном сервере начнет работать стабильно, быстро и независимо от количества работающих в системе разработчиков.

Резюме

Мы подробно разобрали, почему не срабатывают точки останова в серверных процедурах 1С при запуске Конфигуратора на терминальном сервере. Основная причина кроется в блокировании обратных TCP-запросов от рабочего процесса rphost к клиенту.

Для устранения проблемы мы можем пойти по пути точечной настройки брандмауэра для двустороннего обмена TCP-пакетами. Однако наиболее современным, безопасным и простым в администрировании решением является однократный перевод сервера и клиентов на использование протокола HTTP-отладки.