Как проверить доступность веб-сервиса 1С

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

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

Ниже разобраны конкретные способы проверки каждого уровня: команды, ожидаемые результаты, типичные ошибки и признаки, по которым можно понять, где именно обрывается цепочка.

Что значит «доступен веб-сервис» и какие уровни проверять

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

Поэтому проверку удобно делить на пять уровней: сетевая связность, работа веб-сервера, корректность публикации, ответ самого сервиса (WSDL) и успешная авторизация с выполнением операции. Каждый уровень проверяется своим инструментом и даёт однозначный признак «работает / не работает».

Проверка сетевой доступности сервера

Первый шаг — убедиться, что компьютер, с которого выполняется проверка, вообще достигает сервера. Выполните в командной строке ping имя_сервера. Ответы с временем отклика означают, что сервер доступен по сети. Потери пакетов или «Превышен интервал ожидания» говорят о проблеме с сетью, DNS или тем, что сервер выключен.

Далее проверьте доступность порта веб-сервера — обычно это 80 (HTTP) или 443 (HTTPS). Команда telnet сервер 80 или Test-NetConnection сервер -Port 443 в PowerShell покажет, открыт ли порт. Если ping проходит, а порт закрыт — веб-сервер остановлен или порт блокирует брандмауэр.

Test-NetConnection server1c -Port 443

Обратите внимание на имя сервера: если используется DNS-имя, проверьте, что оно разрешается в правильный IP-адрес командой nslookup имя_сервера. Частая ситуация — сервис «не работает» только из-за того, что после переноса сервера DNS-запись указывает на старый адрес.

Проверка работы веб-сервера и публикации

Если порт открыт, проверьте, отвечает ли сам веб-сервер. Откройте в браузере корневой адрес — http://сервер/. IIS обычно показывает стартовую страницу, Apache — свою тестовую или ошибку 403/404, что тоже означает «сервер жив». Полное отсутствие ответа или ошибка подключения указывают на остановленную службу веб-сервера.

Затем проверьте публикацию базы 1С. Откройте адрес вида http://сервер/ИмяПубликации/. Признаки корректной публикации: открывается стартовая страница тонкого клиента или запрос авторизации. Ошибка 404 означает, что публикация с таким именем не существует или удалена. Ошибка 500 — что модуль расширения веб-сервера 1С не может подключиться к базе: неверный путь к базе, недоступен сервер 1С, несовпадение версии платформы и модуля расширения.

Полезно посмотреть логи веб-сервера: у IIS они лежат в каталоге вида C:\inetpub\logs\LogFiles, у Apache — в logs/access.log и error.log. По записям с нужным временем видно, доходят ли запросы до сервера и с каким кодом он отвечает.

Проверка самого сервиса через WSDL

Ключевая проверка — запрос WSDL-описания. Откройте в браузере адрес вида http://сервер/ИмяПубликации/ws/ИмяСервиса?wsdl. Имя сервиса должно точно совпадать с именем в конфигураторе, включая регистр в некоторых конфигурациях веб-серверов.

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

Проверка авторизации и прав доступа

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

Типичный признак проблемы с правами: WSDL открывается (или запрашивает авторизацию и принимает её), но вызов операции возвращает SOAP Fault с текстом про нарушение прав доступа. Отдельный случай — анонимная публикация: если в default.vrd не настроена аутентификация, а сервис требует её, внешний клиент получит 401.

Инструменты тестирования вызовов

Для проверки не только доступности, но и работы операций удобно использовать специализированные клиенты: SoapUI, Postman (с ручной формировкой SOAP-конверта) или простой скрипт на Python/PowerShell. Они позволяют отправить реальный запрос, увидеть ответ целиком и зафиксировать время выполнения.

Минимальная проверка «жив ли сервис» без полноценного клиента — команда curl, запрашивающая WSDL. Код ответа 200 и XML в теле ответа подтверждают доступность, коды 401/403/404/500 сразу локализуют проблему.

curl -i -u Пользователь:Пароль http://server/base/ws/ExchangeService?wsdl

Для постоянного контроля настройте мониторинг: периодический запрос WSDL или лёгкой операции сервиса с проверкой кода ответа и времени выполнения. Это позволит узнать о недоступности раньше, чем обнаружится сбой обмена.

1. 1
   Проверьте ping и доступность порта 80/443 на сервере
2. 2
   Откройте корневой адрес веб-сервера и адрес публикации базы
3. 3
   Запросите WSDL сервиса в браузере или через curl
4. 4
   Проверьте авторизацию под тем пользователем, под которым работает интеграция
5. 5
   Выполните тестовый вызов операции через SoapUI или Postman
6. 6
   При ошибке смотрите логи веб-сервера и журнал регистрации 1С

Частые сценарии сбоев и их диагностика

Сервис работал и внезапно перестал

Проверьте, не обновлялась ли платформа 1С — после обновления нужно заново опубликовать базу, иначе модуль расширения веб-сервера остаётся старой версии. Также посмотрите, не истёк ли пароль пользователя интеграции и не остановлен ли пул приложений IIS.

Сервис доступен изнутри сети, но не снаружи

Проблема почти всегда в сетевом периметре: закрыт порт на внешнем файрволе, не настроен проброс портов, либо запросы режет прокси или WAF. Проверяйте доступность с внешней машины теми же командами Test-NetConnection и curl.

WSDL открывается, но операции не выполняются

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

FAQ