1С отвечает «404 Not Found»: где сломалась публикация и что проверить

Код ошибки 404 в 1С означает одно: веб-сервер или сервис получил запрос, но не нашёл ресурс по указанному адресу. Сама платформа 1С:Предприятие 8.3 такого кода не придумывает. Его возвращает Apache, IIS, модуль веб-расширения 1С, ваш HTTP-сервис или чужой сайт, к которому обращается 1С.

Поэтому исправление всегда начинается с вопроса «кто ответил 404». Если ошибка появилась при открытии базы в браузере, ищите причину в публикации. Если при вызове /hs/ или /ws/ — в настройках сервиса. Если в обмене с сайтом или маркетплейсом — в адресе, который формирует код 1С.

Почему возникает ошибка 404 и кто её возвращает

Запрос к опубликованной базе проходит три звена. Сначала веб-сервер решает, какой обработчик отвечает за адрес. Затем модуль веб-расширения 1С читает файл default.vrd и понимает, к какой базе и какому сервису идёт обращение. В конце отвечает сама прикладная логика: HTTP-сервис, веб-сервис или OData.

Любое звено может сказать «не найдено». Чтобы понять какое, посмотрите на страницу ошибки:

• 🌐 оформленная страница IIS с подкодом вроде 404.0 или 404.3 — запрос не дошёл до 1С, проблема в настройке IIS;
• 📄 короткая страница Apache Not Found — The requested URL was not found on this server — Apache не знает этот адрес, директив публикации нет или путь не совпадает;
• 🧩 пустой ответ или текст ошибки, сформированный кодом конфигурации, — запрос дошёл до базы, а 404 вернул обработчик HTTP-сервиса;
• 🔗 ошибка в окне 1С при обмене с внешней системой — 404 вернул удалённый сервер, база здесь лишь клиент.

Как проверить публикацию базы на веб-сервере

Публикацию делают в Конфигураторе: Администрирование → Публикация на веб-сервере. Конфигуратор нужно запустить от имени администратора Windows, иначе он не сможет записать настройки веб-сервера. Без прав окно публикации отработает, а в конфигурации веб-сервера ничего не изменится.

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

Apache: директивы в httpd.conf

Для Apache 2.4 на Windows в httpd.conf должны быть примерно такие строки:

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

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

Что сверить:

1. Адрес в браузере совпадает с Alias. Публикация /buh не откроется по /Buh на Linux, и с опечаткой в имени тоже.
2. Путь в LoadModule ведёт на существующий файл. На Linux модуль называется wsap24.so и лежит в каталоге платформы внутри /opt/1cv8/.
3. Разрядность модуля совпадает с разрядностью Apache. 32-разрядный модуль с 64-разрядным Apache не загрузится, и веб-сервер не стартует.
4. Путь в ManagedApplicationDescriptor указывает на тот default.vrd, который вы правите.
5. Директива LoadModule _1cws_module встречается в файле один раз. Две строки на разные версии платформы — частая причина сбоев после обновления.

Проверить синтаксис файла можно командой httpd -t из каталога bin Apache. Она сообщит об ошибке и номере строки до перезапуска.

IIS: обработчик и ограничения

В IIS база публикуется как приложение или виртуальный каталог с обработчиком wsisapi.dll. Подкод 404 подсказывает причину точнее, чем сам код.

Подкод 404.13 встречается, когда через HTTP-сервис загружают большие файлы, например сканы или выгрузки. По умолчанию IIS пропускает тело запроса примерно до 30 МБ, всё, что больше, отклоняется ещё до 1С.

Для IIS у пула приложений важна разрядность. Если опубликован 32-разрядный модуль, в пуле должна быть включена поддержка 32-разрядных приложений. Иначе обычно приходит не 404, а ошибка 500, но проверить стоит в том же заходе.

Переопубликация утилитой webinst

Если ручные правки запутались, проще опубликовать заново из командной строки. Утилита webinst.exe лежит в каталоге bin нужной версии платформы:

webinst -publish -apache24 -wsdir buh -dir "C:\Apache24\htdocs\buh" -connstr "Srvr=srv1c;Ref=buh;" -confPath "C:\Apache24\conf\httpd.conf"

Для IIS вместо -apache24 указывают -iis. Запускайте утилиту той версии платформы, на которой работает сервер 1С, и от имени администратора.

Ошибка 404 при обращении к HTTP-сервисам и веб-сервисам

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

Сначала файл default.vrd

Сервисы должны быть разрешены в публикации. Минимальный рабочий фрагмент default.vrd:

<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/buh"
       ib="Srvr=&quot;srv1c&quot;;Ref=&quot;buh&quot;;">
  <ws pointEnableCommon="true"/>
  <httpServices publishByDefault="true"/>
  <standardOdata enable="true"/>
</point>

Если элемента httpServices нет, адреса /hs/ не публикуются. Если нет standardOdata с enable="true", адрес /odata/standard.odata/ вернёт ошибку. В окне публикации Конфигуратора это флажки «Публиковать HTTP-сервисы по умолчанию», «Публиковать стандартный интерфейс OData» и список веб-сервисов.

Затем адрес запроса

Адрес HTTP-сервиса собирается так: http://сервер/публикация/hs/корневой_URL/шаблон. Пример: у сервиса корневой URL orders, у шаблона — /item/{id}. Рабочий адрес: http://server/buh/hs/orders/item/15.

Проверьте по порядку:

1. В адресе есть сегмент hs. Без него запрос уходит в веб-клиент.
2. Корневой URL совпадает со свойством «Корневой URL» сервиса в Конфигураторе, включая регистр.
3. Путь после корня совпадает с одним из шаблонов. Лишний слеш в конце или пропущенный параметр дают 404.
4. Для шаблона создан метод с нужным HTTP-методом. Запрос POST к шаблону, у которого есть только GET, обработчик не найдёт.
5. Конфигурация базы данных обновлена. Новый сервис, сохранённый только в основной конфигурации, ещё не существует для публикации.

Для веб-сервисов адрес другой: http://server/buh/ws/ИмяПубликации.1cws?wsdl или http://server/buh/ws/ИмяПубликации?wsdl. Имя берётся из свойства «Имя файла публикации», а не из имени объекта метаданных. Это разные свойства, и путают их постоянно.

404, который вернул ваш же код

Иногда всё опубликовано верно, а 404 формирует обработчик сервиса. Разработчики так сообщают, что запрошенного объекта нет:

Функция ЗаказGET(Запрос)
    Номер = Запрос.ПараметрыURL["id"];
    Заказ = Документы.ЗаказКлиента.НайтиПоНомеру(Номер);
    Если Заказ.Пустая() Тогда
        Ответ = Новый HTTPСервисОтвет(404);
        Ответ.УстановитьТелоИзСтроки("Заказ не найден: " + Номер);
        Возврат Ответ;
    КонецЕсли;
    // формирование ответа с данными заказа
КонецФункции

Отличить такой ответ просто: у него есть тело с текстом от конфигурации. Тогда ошибка не в публикации, а в данных — нет объекта с таким номером, или номер ищется за другой год. Имя документа в примере условное, у вас будет свой объект.

Ошибка 404 в веб-клиенте и браузере

Веб-клиент открывается по адресу публикации. Платформа сама добавляет к нему путь вида /ru_RU/, это нормально.

Типичные причины 404 у пользователей:

• 🔤 адрес набран с другим регистром или опечаткой: /Buh вместо /buh;
• 🔖 в закладках браузера осталась ссылка на старую публикацию после переименования;
• 🔀 обратный прокси (nginx перед Apache или IIS) пробрасывает только часть путей, и запросы к /hs/ или /e1cib/ не доходят до сервера;
• 🧹 браузер подставляет старый ответ из кеша после исправления публикации.

Последнее проверяется окном в режиме инкогнито. Если там всё открывается, очистите кеш браузера для этого сайта.

Если перед веб-сервером стоит nginx, правило проксирования должно передавать весь префикс публикации, а не отдельные адреса. Например, location /buh/ с передачей на внутренний сервер целиком.

Логи веб-сервера и техжурнал 1С

Когда проверка «на глаз» не помогла, логи отвечают за минуту. Смотрите сначала журнал веб-сервера: он показывает, какой адрес пришёл на самом деле.

Часто в access.log сразу видна причина: клиент шлёт /buh/hs/Orders/item/15/ с заглавной буквой и слешем в конце, а шаблон ждёт другое.

Технологический журнал включают файлом logcfg.xml в каталоге conf платформы. Для разбора HTTP-обращений полезны события VRSREQUEST и VRSRESPONSE и исключения EXCP. Включайте сбор на короткое время и с фильтром по базе: журнал быстро растёт и нагружает диск.

Мобильный клиент, мобильные приложения и внешние сервисы

Мобильный клиент и приложения на мобильной платформе

Мобильный клиент 1С подключается к базе по адресу публикации, так же как веб-клиент. В настройках подключения указывают полный адрес: https://server/buh. Ошибка 404 здесь почти всегда значит неверный путь или публикацию, недоступную снаружи.

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

Когда 1С сама получает 404 от чужого сервера

При обмене с сайтом, банком, службой доставки или маркетплейсом 1С выступает клиентом. Код 404 приходит от удалённой стороны. В типовых конфигурациях такая ошибка всплывает в окне обмена или в журнале регистрации.

В доработках проверяйте, как собран запрос:

Соединение = Новый HTTPСоединение("api.example.ru", 443, , , , 30, Новый ЗащищенноеСоединениеOpenSSL);
Запрос = Новый HTTPЗапрос("/v2/orders/15");
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 404 Тогда
    ЗаписьЖурналаРегистрации("Обмен с сайтом", УровеньЖурналаРегистрации.Ошибка, , ,
        "Ресурс не найден: " + Ответ.ПолучитьТелоКакСтроку());
КонецЕсли;

Ошибки, которые дают 404:

1. В HTTPСоединение передан полный адрес с https:// и путём. Туда пишут только имя сервера, путь уходит в HTTPЗапрос.
2. Путь в HTTPЗапрос собран склейкой строк, и получился двойной слеш //orders.
3. Партнёр сменил версию API, а в 1С зашит старый путь: /v1/ вместо /v2/.
4. Идентификатор объекта передан в другом формате: номер документа 1С вместо внутреннего ID сайта.

Тело ответа часто объясняет причину лучше кода. Сохраняйте его в журнал регистрации, как в примере.

Профилактика: как не ловить 404 после обновлений

Большинство 404 появляется после изменений: обновили платформу, переименовали публикацию, добавили сервис. Несколько правил снимают проблему заранее.

• 📌 Держите публикацию в одном каталоге и с одним именем. Переименование ломает закладки, мобильные клиенты и интеграции.
• 🔄 После обновления платформы на сервере переопубликуйте базу утилитой той же версии и проверьте путь в LoadModule.
• 🗂 Храните копию default.vrd и фрагмента httpd.conf или web.config. Восстановить их проще, чем вспомнить настройки.
• 🧪 После добавления HTTP-сервиса обновите конфигурацию базы данных и проверьте адрес запросом из браузера или curl до передачи интеграторам.
• 📝 Ведите список адресов, которые используют внешние системы. При изменении публикации пройдитесь по нему.

Проверка curl из командной строки сервера покажет код ответа без браузерного кеша:

curl -i http://localhost/buh/hs/orders/item/15

Первая строка ответа содержит код состояния. Если локально 200, а снаружи 404, проблема в прокси или маршрутизации до сервера.

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