К статье
Практический материал

Разработка и Конфигурация · 11 мин

Как прослушать порт в 1С: практическое руководство

Как организовать прослушивание порта в 1С: HTTP-сервисы, веб-сервисы, публикация на веб-сервере, проверка доступности порта и типичные ошибки настройки.

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

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

Отдельная ситуация — когда под «прослушать порт» понимают не приём запросов, а диагностику: проверить, какой процесс занял порт, доступен ли порт сервера 1С или кластера. Этот сценарий тоже рассмотрен в статье с конкретными командами для Windows и Linux.

Как устроен приём входящих соединений в 1С

Архитектура приёма запросов в 1С всегда трёхзвенная: клиент отправляет HTTP-запрос на порт веб-сервера, веб-сервер через модуль расширения (wsap24.dll для IIS или mod_1c для Apache) передаёт запрос в 1С, а платформа вызывает обработчик HTTP-сервиса, написанный на встроенном языке. Порт, который «слушает» система, — это порт веб-сервера, обычно 80 для HTTP или 443 для HTTPS.

Для клиент-серверных баз веб-сервер обращается к кластеру серверов 1С, для файловых — напрямую к файлу базы через веб-расширение. В обоих случаях конфигурация публикации хранится в файле default.vrd, который создаётся при публикации и описывает, какие сервисы доступны и по каким URL.

Создание HTTP-сервиса для приёма запросов

HTTP-сервис — самый гибкий и рекомендуемый способ. В конфигураторе откройте ветку «Общие» → «HTTP-сервисы» и добавьте новый объект. В свойстве «Корневой URL» задайте префикс, например api — тогда сервис будет доступен по адресу вида http://сервер/база/hs/api/....

Добавьте шаблон URL, например /status или /orders/*, и метод (GET, POST). Для метода создаётся обработчик — функция на встроенном языке, которая получает объект HTTPСервисЗапрос и должна вернуть HTTPСервисОтвет. Минимальный обработчик выглядит так:

Функция StatusПолучить(Запрос)

Ответ = Новый HTTPСервисОтвет(200);

Ответ.УстановитьТелоИзСтроки("{""status"":""ok""}");

Ответ.Заголовки.Вставить("Content-Type", "application/json");

Возврат Ответ;

КонецФункции

Обратите внимание: код обработчика выполняется на сервере (или в файловой базе — в контексте веб-расширения), поэтому в нём доступны запросы к данным, но недоступен интерактивный интерфейс. Для POST-запросов тело читается через Запрос.ПолучитьТелоКакСтроку(), параметры строки запроса — через Запрос.ПараметрыЗапроса.

Публикация базы на веб-сервере

Без публикации HTTP-сервис не будет получать запросы. В конфигураторе откройте «Администрирование» → «Публикация на веб-сервере». Укажите имя публикации (латиницей, без пробелов), выберите веб-сервер (IIS или Apache) и каталог, где будет размещён default.vrd. На вкладке «HTTP-сервисы» отметьте флажком созданный сервис и нажмите «Опубликовать».

Для IIS предварительно должны быть установлены компоненты: службы IIS, расширения ISAPI, а также настроено сопоставление обработчика для 32- или 64-разрядной версии модуля wsap24.dll. Для Apache поддерживаются версии 2.2 и 2.4 (для 2.4 нужен соответствующий модуль из поставки платформы). Публикацию удобнее выполнять с правами администратора, иначе конфигуратор не сможет записать настройки веб-сервера.

Порядок действий для приёма запросов
  1. 1
    Установите и настройте веб-сервер (IIS или Apache)
  2. 2
    Создайте в конфигураторе HTTP-сервис с шаблоном URL и обработчиком
  3. 3
    Опубликуйте базу: Администрирование → Публикация на веб-сервере, отметьте HTTP-сервис
  4. 4
    Откройте порт веб-сервера в брандмауэре Windows или сетевом экране
  5. 5
    Проверьте сервис запросом из браузера или curl с другого компьютера

Открытие порта и проверка доступности

После публикации проверьте, что порт веб-сервера не блокируется. В Windows откройте «Брандмауэр Защитника Windows» → «Правила для входящих подключений» и создайте правило для TCP-порта (80, 443 или нестандартного, например 8080). На Linux для Apache используйте firewall-cmd или ufw allow 80/tcp.

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

netstat -ano | findstr :80

Если в выводе есть строка со состоянием LISTENING и адресом 0.0.0.0:80 или конкретным IP — веб-сервер принимает соединения. Далее проверьте сам сервис: с другого компьютера выполните curl http://сервер/база/hs/api/status или откройте URL в браузере. Ответ с кодом 200 означает, что цепочка «порт → веб-сервер → 1С» работает полностью.

Контрольные точки

Как проверить результат

netstat -ano | findstr :80
Норма

Строка LISTENING с нужным портом

Тревожный признак

Порт отсутствует в выводе — веб-сервер не запущен или слушает другой порт

Запрос к URL сервиса с другого ПК
Норма

HTTP 200 и ожидаемое тело ответа

Тревожный признак

Таймаут — закрыт порт; 404 — ошибка в URL или публикации; 500 — ошибка в коде обработчика

default.vrd в каталоге публикации
Норма

Файл содержит описание HTTP-сервиса

Тревожный признак

Файл отсутствует или пуст — публикация не выполнена

Альтернативные способы принимать данные без веб-сервера

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

Второй вариант — внешняя компонента или сторонняя программа-шлюз, которая слушает порт и передаёт данные в 1С через файловый обмен, COM-соединение или очередь сообщений. Такой подход применяют для интеграции с оборудованием (сканеры, весы, кассы), где устройство умеет только отправлять данные на TCP-порт. Учтите, что это нештатное решение: поддержку шлюза и обработку сбоев придётся реализовывать самостоятельно.

Сравнение способов приёма запросов

HTTP-сервис + веб-сервер

Штатный и рекомендуемый способ. Гибкие URL, любые методы. Требует установки IIS или Apache и прав на публикацию.

Веб-сервис (SOAP)

Подходит для интеграции с системами, ожидающими SOAP и WSDL. Менее гибкий, больше накладных расходов на формат.

Исходящий опрос по расписанию

Не требует открытых портов и веб-сервера. Минус — задержка до интервала опроса и лишняя нагрузка.

Внешний шлюз (компонента/программа)

Единственный вариант для «сырых» TCP-соединений от оборудования. Требует отдельной разработки и сопровождения.

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

Обратная задача встречается при установке сервера 1С или веб-сервера: установщик сообщает, что порт занят. Стандартные порты агента сервера 1С — 1540, кластера — 1541, менеджера кластера — 1545, но они могут быть изменены при установке. Чтобы найти процесс, занявший порт, выполните:

netstat -ano | findstr :1540

tasklist | findstr

Первая команда покажет PID процесса, вторая — имя исполняемого файла. Если порт занял другой экземпляр агента сервера (ragent.exe) или сторонняя программа, либо завершите лишний процесс, либо назначьте серверу 1С другой диапазон портов через оснастку администрирования кластера. На Linux аналог — ss -tlnp | grep 1540.

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

Самая частая ошибка — ожидание, что 1С начнёт слушать порт сразу после создания HTTP-сервиса. Без публикации на веб-сервере сервис недоступен извне вообще. Вторая типичная проблема — ошибка 404 после публикации: обычно причина в неверно собранном URL. Проверьте все три части адреса: имя публикации, корневой URL сервиса и шаблон.

Ошибка 500 указывает на исключение в коде обработчика — смотрите технологический журнал или временно оберните код в Попытка/Исключение с записью текста ошибки в тело ответа. Также помните об ограничениях: для файловых баз одновременная обработка запросов ограничена, при высокой нагрузке HTTP-сервисы следует использовать только в клиент-серверном варианте. И не публикуйте сервисы без аутентификации наружу — настройте хотя бы базовую аутентификацию IIS/Apache или проверку токена в обработчике.

Типичные ошибки
01
Сервис создан, но база не опубликована — запросы никуда не попадают
02
Публикация выполнена, но порт закрыт брандмауэром — снаружи соединение отклоняется по таймауту
03
Неверный URL: пропущен корневой URL сервиса или имя публикации — ответ 404
04
Нет аутентификации на опубликованном сервисе — данные базы доступны любому, кто знает адрес
05
Попытка слушать порт напрямую из кода 1С — платформа такой возможности не предоставляет

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

Можно ли прослушать TCP-порт напрямую из кода 1С без веб-сервера?

Штатных средств для работы с сырыми TCP-сокетами в режиме сервера у платформы нет. Прямое прослушивание порта возможно только через внешнюю компоненту или отдельную программу-шлюз, которая передаёт данные в 1С через файлы, COM или HTTP. Для HTTP-интеграций всегда используйте связку «веб-сервер + HTTP-сервис».

Подходит ли файловая база для приёма HTTP-запросов?

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

Какой порт нужно открыть, чтобы 1С принимала запросы?

Открывать нужно порт веб-сервера: 80 для HTTP, 443 для HTTPS или нестандартный порт, указанный в настройках IIS/Apache. Порты самого сервера 1С (1540, 1541, 1545) открывать наружу для HTTP-сервисов не требуется — веб-сервер общается с кластером внутри сервера или локальной сети.

Почему сервис отвечает 404, хотя публикация выполнена?

Чаще всего ошибка в структуре URL: правильный адрес собирается как http://сервер/имя_публикации/hs/корневой_URL/шаблон. Проверьте, что в default.vrd присутствует описание сервиса, что имя публикации в адресе совпадает с указанным при публикации, и перезапустите веб-сервер после изменения публикации.

Как защитить опубликованный HTTP-сервис?

Минимальный набор: включить аутентификацию на уровне веб-сервера или проверять токен/ключ в заголовках запроса внутри обработчика, использовать HTTPS вместо HTTP и ограничить доступ по IP-адресам средствами IIS/Apache, если круг вызывающих систем известен. Не публикуйте сервисы с анонимным доступом в открытую сеть.

Что делать, если порт 1540 занят при установке сервера 1С?

Найдите процесс командой netstat -ano | findstr :1540 и определите его по PID через tasklist. Если это предыдущий экземпляр агента сервера — корректно остановите лишнюю службу. Если порт занят сторонним приложением, либо перенастройте его, либо назначьте агенту 1С другой рабочий порт через параметры службы.

Итог

Что важно запомнить

1С не слушает порты напрямую: входящие запросы принимает веб-сервер и передаёт их в HTTP-сервисы опубликованной базы. Последовательность проста: создать HTTP-сервис, опубликовать базу на IIS или Apache, открыть порт в брандмауэре и проверить ответ извне. Для диагностики занятых портов используйте netstat, а для оборудования с сырым TCP — внешний шлюз.