1С не достучалась до веб-сервера: разбираем код ответа и чиним публикацию

Ошибка НТТР (в тексте программы — латиницей, Ошибка HTTP при обращении к серверу) значит одно: клиент 1С отправил запрос веб-серверу и получил отказ или не получил ответа вовсе. Первое, что нужно сделать, — найти в тексте сообщения код ответа (401, 404, 500, 503) или фразу вроде Couldn't connect to server. От кода зависит, где искать причину: в сети, в настройках IIS или Apache, в публикации базы или на сервере 1С.

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

Где возникает ошибка HTTP и чем она отличается от других сбоев связи

Сообщение Ошибка HTTP при обращении к серверу выдаёт любой компонент 1С, который ходит в сеть по протоколу HTTP или HTTPS. Это три типовые ситуации:

• 🖥️ Тонкий клиент или веб-клиент, подключённый к базе через веб-сервер. В списке баз у такой базы адрес вида http://server/buh, а не Srvr=...;Ref=....
• 🔗 Обмены и интеграции: веб-сервисы, HTTP-сервисы, синхронизация данных между базами через интернет , мобильные приложения.
• 🌐 Сервисы интернет-поддержки: обновление классификаторов, курсов валют, загрузка обновлений конфигурации, 1С:Отчётность, ЭДО.

Если база подключена напрямую к кластеру серверов (Srvr=...), HTTP там не участвует. Ошибки соединения в таком режиме выглядят иначе: например, Сервер 1С:Предприятия не обнаружен или ошибка соединения с агентом на порту 1540. Их лечат через кластер и сетевые порты, а не через веб-сервер.

Короткое правило: если в тексте ошибки есть слово HTTP или адрес, начинающийся с http, — разбирайтесь с веб-сервером и публикацией.

Почему появляется ошибка НТТР: причины по коду ответа

Код ответа — главная подсказка. Он стоит в тексте ошибки или виден в журнале веб-сервера.

Если кода нет, а есть только Ошибка HTTP при обращении к серверу и адрес, ищите проблему на уровне сети: клиент не смог установить соединение.

Типовые причины, которые встречаются на практике:

• 🔄 обновили платформу на сервере, а публикация по-прежнему ссылается на модуль из каталога старой версии, которого уже нет;
• 🧩 версия модуля веб-расширения на веб-сервере не совпадает с версией кластера 1С, к которому он подключается;
• 🔐 у учётной записи пула приложений нет прав на каталог bin платформы или на папку файловой базы;
• ⚙️ разрядность пула IIS не совпадает с разрядностью установленного модуля 1С;
• 🧱 брандмауэр или антивирус режет порт 80 или 443;
• 📜 истёк или не совпадает с именем сервера SSL-сертификат.

Как найти причину ошибки HTTP: диагностика по шагам

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

Шаг 1. Откройте адрес в браузере

Скопируйте адрес из свойств базы в списке баз и откройте его в браузере на том же компьютере.

• Для базы через веб-сервер откройте http://server/buh/ — должен загрузиться веб-клиент.
• Для веб-сервиса откройте адрес описания: http://server/buh/ws/ИмяСервиса?wsdl — должен прийти XML.
• Для HTTP-сервиса откройте его корневой URL из метода GET, если он предусмотрен.

Браузер покажет код ошибки и часто подробное описание. Если браузер открывает базу, а тонкий клиент нет — проблема на стороне клиента: прокси, сертификат, учётные данные в настройках базы.

Шаг 2. Повторите проверку на самом веб-сервере

Откройте тот же адрес, но через http://localhost/buh/ прямо на веб-сервере. Если локально работает, а снаружи нет, виноваты сеть, DNS или брандмауэр. Если не работает и локально — дело в веб-сервере или публикации.

Проверьте доступность порта с клиента командой PowerShell:

Test-NetConnection server -Port 80
Test-NetConnection server -Port 443

В строке TcpTestSucceeded должно быть True.

Шаг 3. Посмотрите журнал веб-сервера

В IIS журналы по умолчанию лежат в C:\inetpub\logs\LogFiles\W3SVC1. В каждой строке есть поля sc-status и sc-substatus: например, 500 0 или 404 2. Подстатус сильно сужает поиск.

В Apache смотрите error.log в каталоге logs. Там видно, загрузился ли модуль 1С при старте службы.

Шаг 4. Проверьте журнал событий Windows и технологический журнал

В журнале «Приложение» ищите ошибки от источника IIS и процесса w3wp.exe. Если веб-сервер работает, а ошибка возникает при обращении к базе, включите технологический журнал 1С через файл logcfg.xml — в нём будут события с текстом исключения.

Как устранить ошибку НТТР при обращении к серверу 1С

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

Способ 1. Проверить настройки подключения на клиенте

1. Откройте список баз, выделите базу и нажмите Изменить.
2. Проверьте адрес: протокол (http или https), имя сервера, имя публикации.
3. На следующих страницах мастера проверьте параметры прокси и сертификатов. Если в компании прокси с авторизацией, укажите его явно или включите использование системных настроек.
4. Если сайт требует логин и пароль, проверьте их в настройках подключения.

Для сервисов интернет-поддержки и обменов настройки прокси задаются в самой программе. В типовых конфигурациях на БСП их ищите в разделе Администрирование → Интернет-поддержка и сервисы.

Способ 2. Переопубликовать базу

Публикация — это каталог на веб-сервере с файлом default.vrd и (для IIS) web.config. Самый надёжный способ исправить битую публикацию — создать её заново из Конфигуратора той версии платформы, что стоит на сервере.

1. Запустите Конфигуратор от имени администратора — без этого публикация в IIS не запишется.
2. Откройте Администрирование → Публикация на веб-сервере.
3. Проверьте имя, каталог и тип веб-сервера, нажмите Опубликовать.

Тот же результат даёт утилита webinst из каталога bin платформы:

cd "C:\Program Files\1cv8\8.3.24.1586\bin"
webinst -publish -iis -wsdir buh -dir "C:\inetpub\wwwroot\buh" -connstr "Srvr=srv1c;Ref=buh;"

Номер версии в пути замените на свой. Для Apache 2.4 вместо -iis используется ключ -apache24 с указанием файла конфигурации через -confpath.

Способ 3. Привести в порядок IIS

Проверьте четыре вещи:

• Компоненты. В ролях Windows должен быть установлен Веб-сервер (IIS) → Разработка приложений → Расширения ISAPI. Без него публикация отвечает кодом 404 или 500.
• Ограничения ISAPI и CGI. На уровне сервера в диспетчере IIS модуль wsisapi.dll должен быть в списке разрешённых.
• Разрядность пула. Если установлен 32-разрядный модуль веб-расширения, в дополнительных параметрах пула включите Разрешены 32-разрядные приложения. Для 64-разрядного модуля этот параметр выключен.
• Права. Учётной записи пула (или группе IIS_IUSRS) дайте чтение и выполнение на каталог bin платформы. Для файловой базы нужны права на изменение папки с базой.

Способ 4. Проверить Apache

В httpd.conf найдите строки, которые добавила публикация:

LoadModule _1cws_module "C:/Program Files/1cv8/8.3.24.1586/bin/wsap24.dll"

Alias "/buh" "C:/www/buh/"
<Directory "C:/www/buh/">
    AllowOverride All
    Options None
    Require all granted
    SetHandler 1c-application
    ManagedApplicationDescriptor "C:/www/buh/default.vrd"
</Directory>

Путь в LoadModule должен вести к реально существующему файлу нужной версии. В Linux модуль называется wsap24.so и лежит в каталоге платформы внутри /opt/1cv8. Проверить синтаксис можно командой httpd -t (в Debian и Ubuntu — apachectl -t).

Способ 5. Перезапустить веб-сервер

Для IIS часто хватает перезапуска только нужного пула приложений — это затронет меньше пользователей, чем iisreset.

Пример из практики: ошибка 500 на IIS после обновления платформы

Исходные данные: база buh опубликована на IIS, пользователи работают через тонкий клиент по адресу http://srv1c/buh. Администратор обновил платформу с 8.3.23 до 8.3.24 и удалил старую версию. Утром все пользователи получили Ошибка HTTP при обращении к серверу с кодом 500.

Как разбирали:

1. Открыли http://localhost/buh/ на сервере — та же ошибка 500. Значит, сеть ни при чём.
2. В журнале IIS — строка с кодом 500 0. Модуль-обработчик не смог выполнить запрос.
3. Открыли C:\inetpub\wwwroot\buh\web.config и нашли обработчик:

<add name="1C Web-service Extension" path="*" verb="*"
     modules="IsapiModule"
     scriptProcessor="C:\Program Files\1cv8\8.3.23.1865\bin\wsisapi.dll"
     resourceType="Unspecified" requireAccess="None" />

Путь вёл в каталог удалённой версии.

4. Переопубликовали базу из Конфигуратора 8.3.24, запущенного от имени администратора. Путь в web.config обновился.
5. В списке Ограничения ISAPI и CGI проверили, что новый wsisapi.dll разрешён.
6. Перезапустили пул приложений сайта в обеденный перерыв.

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

💡 Чтобы это не повторялось, перед удалением старой версии платформы переопубликуйте все базы. Список публикаций в IIS виден в диспетчере как приложения или виртуальные каталоги сайта.

Ошибки администраторов, из-за которых снова появляется НТТР-ошибка

• ❌ Удаляют старую платформу до переопубликации. Публикации теряют модуль, и все веб-подключения падают разом.
• ❌ Держат на веб-сервере другую версию, чем на кластере. Модуль веб-расширения работает как клиент кластера, и их версии должны совпадать.
• ❌ Публикуют без прав администратора. Публикация не создаётся или создаётся не полностью, и адрес отвечает кодом 404.
• ❌ Правят web.config вручную и оставляют синтаксическую ошибку. IIS отвечает кодом 500.19 на все запросы к каталогу.
• ❌ Забывают про лимит размера запроса. Загрузка больших файлов через веб-клиент или обмен упирается в maxAllowedContentLength (по умолчанию около 30 МБ) и даёт 404.13. Лимит меняют в разделе requestFiltering файла web.config.
• ❌ Ставят самоподписанный сертификат и не раздают его клиентам. Подключение по HTTPS обрывается на проверке сертификата.

Вопросы, которые задают про ошибку HTTP в 1С