Почему не работает веб-сервис 1С на IIS и как исправить ошибку соединения?

← На главную

При публикации веб-сервисов 1С на веб-сервере Internet Information Services (IIS) часто возникает ситуация, когда внешне все настроено правильно: база открывается через браузер, файл определения WSDL доступен по ссылке, но при попытке вызвать операцию веб-сервиса из кода 1С или внешнего приложения возникает ошибка: «Не могу установить соединение» или «Ошибка вызова операции сервиса». Рассмотрим подробно, почему это происходит и как пошагово решить эту проблему.

Анализ исходной ситуации и типичная ошибка в коде

Типичный сценарий использования веб-сервиса предполагает создание объектов WSОпределения и WSПрокси. Проанализируем пример кода, который часто используется для подключения к сервису:


// Создание определения веб-сервиса
WSОпеределение = Новый WSОпределения("http://server-address/base/ws/RemoteControl?wsdl", Логин, Пароль);

// Создание прокси для обращения к операциям
WSПрокси = Новый WSПрокси(WSОпеределение, "http://www.sample-package.org/RemoteControl", "RemoteControl", "RemoteControlSoap12");
WSПрокси.Пользователь = Логин;
WSПрокси.Пароль = Пароль;

// Вызов операции
РезультатОпроса = WSПрокси.GetCurrentState();

В этой ситуации WSОпределения может создаваться успешно, так как 1С просто скачивает XML-описание сервиса. Однако на этапе вызова метода GetCurrentState() происходит реальное обращение к серверу, и именно здесь возникает сбой. Основная причина кроется в том, как IIS и сетевое оборудование обрабатывают сетевые порты.

Решение проблемы с пробросом портов (Port Forwarding)

Одной из главных причин ошибки соединения является несовпадение портов, на которых работает IIS, и портов, которые используются при публикации. Разберем ситуацию: если ваш сервер IIS настроен на работу на нестандартном порту (например, 8080 или 1350), а внешняя сеть (роутер) перенаправляет запросы с порта 80 на этот внутренний порт, веб-сервисы могут работать некорректно.

Почему это происходит? Веб-сервисы 1С на IIS чувствительны к «пробросу» портов. Если трансляция идет с изменением номера порта (например, внешний 80 -> внутренний 8080), протокол SOAP может терять контекст или пытаться переподключиться по адресу, указанному внутри самого WSDL-файла, который не соответствует внешнему порту.

Как исправить: Для стабильной работы необходимо настроить «прямое» соответствие портов. Если IIS работает на порту 8080, то и на роутере правило проброса должно быть 8080 -> 8080. Если база должна быть доступна по стандартному 80 порту, необходимо перенастроить сам сайт в диспетчере IIS на 80 порт и убрать все промежуточные трансформации портов на сетевом оборудовании.

Исправление адреса в WSDL-описании (атрибут Location)

Проанализируем еще одну скрытую причину: когда 1С генерирует WSDL-файл, она автоматически вставляет в него URL сервера. Если сервер находится за NAT, 1С может вписать туда локальное имя сервера или внутренний IP-адрес. В результате клиент скачивает описание по внешнему адресу, но затем пытается отправить данные на внутренний адрес, который ему недоступен.

Выясним, как это исправить через файл публикации. Найдем файл default.vrd в папке, куда была опубликована информационная база. Нам нужно вручную указать корректный внешний адрес в параметре vrd:point.


<point xmlns:vrd="http://v8.1c.ru/8.2/virtual-resource-system"
       base="/BaseName"
       publishExtensionsByDefault="true">
    <ws>
        <point name="RemoteControl" alias="service.1cws" 
               url="http://external-ip:8080/BaseName/ws/service.1cws"/>
    </ws>
</point>

Принудительное указание url в файле default.vrd заставит 1С выдавать правильные ссылки внутри XML-описания веб-сервиса.

Проверка настроек аутентификации в IIS

Часто веб-сервисы перестают работать из-за конфликтов проверки подлинности. В диспетчере IIS для виртуального каталога вашей базы могут быть включены одновременно «Анонимная проверка подлинности» и «Проверка подлинности Windows».

Рассмотрим рекомендации по настройке:

Для веб-сервисов 1С лучше всего оставить включенной только Анонимную проверку подлинности на уровне IIS.
Авторизацию пользователя следует выполнять средствами самой 1С, передавая логин и пароль в свойствах объекта WSПрокси.
Если используется Windows-авторизация, убедитесь, что клиентское приложение поддерживает передачу NTLM-заголовков, иначе IIS будет обрывать соединение с ошибкой 401 или 403.

Права доступа и разрядность пула приложений

Если сетевые настройки в порядке, но ошибка сохраняется, проанализируем права доступа. Пользователь, от имени которого запущен Пул приложений (Application Pool) в IIS, должен иметь права «Чтение и выполнение» на каталог bin установленной платформы 1С. Без этого расширение ISAPI (библиотека wsapvr.dll) не сможет инициализировать сеанс.

Также обратим внимание на разрядность. Если вы используете 32-битную платформу 1С на 64-битном сервере:

Откройте «Диспетчер служб IIS».
Перейдите в «Пулы приложений».
Выберите пул, на котором работает ваша база, и откройте «Дополнительные параметры».
Установите значение «Разрешить 32-разрядные приложения» в True.

Диагностика с помощью трассировки

Если причина ошибки остается неясной, воспользуемся инструментом «Трассировка неудачных запросов» (Failed Request Tracing) в IIS. Это позволит увидеть детальный лог прохождения HTTP-запроса через все модули сервера. Вы сможете точно определить, на каком этапе происходит сброс: при проверке прав, при обращении к расширению 1С или из-за ограничений размера пакета (параметр maxAllowedContentLength в web.config).

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