Почему при обращении к веб-сервису 1С возникает ошибка 403 и как ее исправить?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При работе с веб-сервисами 1С программисты часто сталкиваются с ситуацией, когда внутри локальной сети всё работает безупречно, но при попытке обращения из внешней среды (например, из облачного терминала или другой подсети) сервер возвращает ошибку Код ответа сервера: 403. Эта ошибка означает «Forbidden» (Запрещено), то есть сервер понял запрос, но отказывается его выполнять. Рассмотрим подробно, почему это происходит и как провести глубокую диагностику системы.

Анализ исходной ситуации

Разберем типичный сценарий. В конфигурации 1С написан код для инициализации веб-сервиса через WSОпределения. При выполнении этого кода в локальной сети объект создается успешно, но при запуске из облачной инфраструктуры система выдает следующую ошибку:


{ВнешняяОбработка.ТестВеб.Форма.Форма.Форма(12)}: Ошибка при вызове конструктора (WSОпределения)
    Веб = Новый WSОпределения(АдресWSDL, ИмяПользователя, Пароль, ,60);
по причине:
При создании описания сервиса произошла ошибка. URL сервиса: http://msk-1-t/dev9/ws/DataInput?wsdl Код ответа сервера: 403

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

Шаг 1. Детализация ошибки через логи IIS

Ошибка 403 в IIS никогда не бывает «просто 403». У нее всегда есть подкод, который указывает на конкретную причину отказа. Проанализируем, где искать эту информацию. Лог-файлы IIS обычно располагаются по пути %SystemDrive%\inetpub\logs\LogFiles. Откроем последний файл лога и найдем строку с запросом к DataInput?wsdl.

Нам нужно найти числовое значение после основного кода 403. Рассмотрим основные варианты:

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

Даже если в настройках публикации 1С включена анонимная проверка подлинности, веб-сервер IIS должен иметь физический доступ к файлам публикации. Разберем, какие права необходимо проверить:

  1. Перейдем в папку, где расположен файл default.vrd (путь, указанный при публикации базы).
  2. Проверим права доступа (NTFS) для этой папки.
  3. Убедимся, что у пользователя IUSR или группы IIS_IUSRS есть права «Чтение и выполнение».

Если ошибка плавающая, проанализируем настройки Пула приложений (Application Pool). Если пул настроен на запуск от имени конкретного пользователя, именно этот пользователь должен иметь доступ к папке с публикацией и к бинарным файлам платформы 1С.

Шаг 3. Исключение влияния сетевых экранов и прокси-серверов

Выясним причину, по которой запрос из облака может не доходить до веб-сервиса в первозданном виде. В современных корпоративных сетях часто используются прозрачные прокси-серверы или VPN-туннели. Проанализируем следующие моменты:

Шаг 4. Настройка файла конфигурации публикации (default.vrd)

Иногда проблема кроется внутри настроек самой публикации 1С. Рассмотрим структуру файла default.vrd. Особое внимание уделим параметру ib (строка соединения). Если там указано короткое имя сервера (как в нашем примере msk-1-t), убедимся, что облачный сервер может корректно разрешить это имя в IP-адрес. Рекомендуется использовать полное доменное имя (FQDN) или статический IP-адрес сервера.

Также проанализируем блок authentication. Если в нем жестко прописано использование Windows-авторизации, а облачный терминал находится вне домена или подключается под другой учетной записью, это гарантированно вызовет ошибку 403 при попытке анонимного обращения.

Шаг 5. Динамическое ограничение IP-адресов

В IIS существует модуль Dynamic IP Restrictions. Проанализируем ситуацию: если клиент 1С при создании WSОпределения генерирует серию быстрых запросов (например, для проверки сертификатов или подгрузки связанных схем), модуль защиты может расценить это как DoS-атаку и временно заблокировать IP-адрес облачного сервера. Это объясняет, почему ошибка возникает «через раз» — после периода ожидания доступ восстанавливается до следующей серии запросов.

Шаг 6. Расширенная диагностика через Failed Request Tracing

Если стандартные логи не дают ответа, воспользуемся самым мощным инструментом IIS — Трассировкой неудачных запросов (Failed Request Tracing). Разберем по шагам, как его настроить:

  1. В консоли управления IIS выберем наш сайт и откроем раздел Failed Request Tracing Rules.
  2. Добавим правило для кода ответа 403.
  3. Выполним запрос из облака, который приведет к ошибке.
  4. В папке C:\inetpub\logs\FailedReqLogFiles появится XML-отчет.

В этом отчете мы увидим пошаговое прохождение запроса через все модули IIS. Мы сможем точно определить, какой модуль (например, IpRestrictionModule или UrlAuthorizationModule) заблокировал запрос. Это позволит нам перестать гадать и перейти к точечной настройке системы.

Таким образом, решение проблемы 403 при публикации веб-сервисов 1С требует комплексного подхода: от проверки прав доступа пользователя IUSR до анализа MTU сетевого туннеля и глубокой трассировки модулей веб-сервера.

← На главную