Публикация 1С не открывается: пошаговая диагностика IIS, прав и файлов

Проверить публикацию базы 1С быстрее всего так: откройте в браузере http://сервер/имя_публикации/ и посмотрите, что вернётся. Пришла форма входа 1С — публикация жива. Пришёл код HTTP (404, 500, 503) — проблема в веб-сервере. Пришло окно с текстом ошибки 1С — веб-сервер работает, а не дотягивается до самой базы.

Дальше администратор идёт по цепочке: Конфигуратор → диспетчер IIS → файлы публикации → права → модуль расширения → логи. Каждое звено проверяется отдельно, и ниже порядок именно такой. Всё сказанное относится к платформе 8.3 и IIS на Windows Server 2016 и новее. Для Apache даны отдельные пометки.

Состояние публикации в Конфигураторе и консоли IIS

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

В окне видно:

• 🔹 имя публикации — это часть адреса после имени сервера;
• 🔹 веб-сервер (Internet Information Services или Apache);
• 🔹 каталог публикации на диске;
• 🔹 флажки публикации тонкого и веб-клиента, HTTP- и веб-сервисов, стандартного интерфейса OData.

Если база уже опубликована, кнопка «Отключить» активна. Если поле каталога пустое, а кнопка «Опубликовать» предлагает создать публикацию заново — Конфигуратор не нашёл её у этого веб-сервера.

Затем откройте диспетчер IIS (inetmgr):

1. Разверните сайт (обычно Default Web Site) и найдите узел с именем публикации.
2. Убедитесь, что это приложение (значок с глобусом), а не обычный виртуальный каталог. Если узел обычный, щёлкните по нему правой кнопкой и выберите «Преобразовать в приложение».
3. В «Основных настройках» узла проверьте физический путь. Он должен совпадать с каталогом из Конфигуратора.
4. Посмотрите, к какому пулу приложений привязано приложение, и откройте раздел «Пулы приложений». Пул должен быть в состоянии «Запущен».

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

Номер версии в пути подставьте свой. Для Apache 2.4 вместо -iis используется ключ -apache24 и параметр -confpath с путём к httpd.conf.

Настройки IIS, без которых публикация не работает

Большая часть отказов после установки — в недостающих компонентах IIS и в ограничениях ISAPI. Проверьте три места.

Компоненты роли «Веб-сервер»

В «Диспетчере серверов» откройте добавление ролей и компонентов, роль «Веб-сервер (IIS)». В группе «Разработка приложений» должны быть отмечены:

• ✅ Расширения ISAPI;
• ✅ Фильтры ISAPI.

Без них модуль 1С просто не загрузится. ASP.NET для публикации 1С не нужен.

Ограничения ISAPI и CGI

На уровне сервера (корневой узел в inetmgr) откройте «Ограничения ISAPI и CGI». Там должна быть строка с путём к wsisapi.dll нужной версии платформы и статусом «Разрешено». Если строки нет или статус «Запрещено», браузер получит HTTP 404.2.

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

Встаньте на приложение публикации и откройте «Сопоставления обработчиков». Должен быть обработчик с путём *, модулем IsapiModule и исполняемым файлом ...\bin\wsisapi.dll. Его же видно в web.config каталога публикации:

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

Если IIS ругается HTTP 500.19 с текстом This configuration section cannot be used at this path, раздел handlers заблокирован на уровне сервера. Откройте на корневом узле «Делегирование компонентов» и переключите «Сопоставления обработчиков» в режим «Чтение/запись».

Разрядность пула

Модуль 1С должен совпадать по разрядности с пулом:

Несовпадение даёт HTTP 500 и запись в журнале событий о том, что модуль не удалось загрузить.

Права доступа: пул приложений и учётные записи

Рабочий процесс IIS (w3wp.exe) работает от имени учётной записи пула. По умолчанию это виртуальная учётная запись вида IIS AppPool\ИмяПула. Анонимные запросы идут от IUSR. Права нужны в трёх местах.

1. Каталог платформы. Чтение и выполнение для IIS_IUSRS на папку bin той версии, что указана в web.config. Обычно это право есть по наследованию, но после ручного копирования платформы его теряют.

2. Каталог публикации. Чтение для IIS_IUSRS и IUSR на папку из web.config и default.vrd.

3. Сама база — для файлового варианта. Учётной записи пула нужно право «Изменение» на каталог базы с файлом 1Cv8.1CD. Без него при входе 1С сообщит о нехватке прав на файл. Если база лежит на сетевой папке, виртуальная учётная запись пула туда не пройдёт. Тогда в «Дополнительных параметрах» пула задайте удостоверение доменной учётной записи с правами на эту папку.

Для клиент-серверной базы права на файлы не нужны. Важно другое:

• 🔸 с веб-сервера должен быть доступен сервер 1С по портам 1540, 1541 и диапазону рабочих процессов (по умолчанию 1560–1591);
• 🔸 версия платформы на веб-сервере должна совпадать с версией сервера 1С до последней цифры.

Аутентификация на уровне IIS и 1С

Это две разные проверки. IIS решает, пропустить ли запрос вообще. 1С решает, какого пользователя базы пустить.

Файлы публикации и модуль расширения веб-сервера

Публикация — это два файла в каталоге и одна библиотека платформы. Проверьте каждый.

default.vrd

Откройте файл блокнотом. Ключевая строка выглядит так:

<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;;">

Что сверить:

• 🔍 base совпадает с именем приложения в IIS;
• 🔍 в ib правильное имя сервера 1С и имя базы в кластере — именно имя в кластере, а не представление из списка баз;
• 🔍 для файловой базы стоит File="D:\Bases\buh";, и путь существует;
• 🔍 файл — корректный XML: одна лишняя кавычка ломает всю публикацию.

web.config после обновления платформы

Самая частая поломка на «вчера работало». Платформу обновили, старую версию удалили, а web.config по-прежнему ссылается на ...\8.3.22.xxxx\bin\wsisapi.dll, которого уже нет. IIS отдаёт ошибку 500.

Проверяйте путь в scriptProcessor после каждого обновления платформы на веб-сервере. Самый чистый способ — заново опубликовать базу из Конфигуратора новой версии или командой webinst: путь перезапишется сам.

Модуль wsisapi.dll

Модуль ставится вместе с платформой только при отмеченном компоненте «Модули расширения веб-сервера». Если файла wsisapi.dll в каталоге bin нет, запустите установщик платформы повторно, выберите «Изменить» и добавьте этот компонент.

Для Apache 2.4 используется wsap24.dll. Проверьте в httpd.conf строку LoadModule _1cws_module — путь в ней должен вести к существующему файлу нужной версии. Синтаксис конфигурации проверяет команда httpd -t.

Проверка доступности через браузер и разбор логов

После правок проверьте публикацию с самого сервера, а затем с рабочего места. Так вы отделите проблемы IIS от проблем сети и брандмауэра.

Адреса для проверки

Для OData пустой список — не ошибка публикации. Значит, в базе не задан состав стандартного интерфейса OData.

Тонкий клиент проверяется так же: добавьте в список баз новую с типом «На веб-сервере» и адресом http://srv/buh. Если веб-клиент открывается, а тонкий клиент нет, сравните версию клиента на рабочем месте с версией на веб-сервере.

Журналы IIS

Логи лежат в %SystemDrive%\inetpub\logs\LogFiles\W3SVC1 (цифра — идентификатор сайта). В каждой строке есть код ответа и подкод. Именно подкод отличает причины:

• 📄 404 2 — модуль запрещён в ограничениях ISAPI;
• 📄 404 3 — нет сопоставления обработчика;
• 📄 500 19 — ошибка в web.config или заблокированный раздел;
• 📄 401 2 — не настроена проверка подлинности.

Если кода в журнале мало, включите «Трассировку неудачно завершённых запросов» для приложения: IIS запишет подробный XML-отчёт по каждому запросу с ошибкой.

Журнал событий Windows и технологический журнал

В журнале «Приложение» ищите записи от источников IIS и 1C:Enterprise 8.3 в момент сбоя. Здесь видно, что модуль не загрузился или процесс w3wp.exe аварийно завершился.

Если веб-сервер отвечает, но 1С выдаёт ошибку подключения к базе, включите технологический журнал файлом logcfg.xml в каталоге conf платформы на веб-сервере. Он покажет, к какому серверу и с какими параметрами обращается модуль.

Скрипт мониторинга публикаций

Когда публикаций несколько, их удобно проверять по расписанию. Скрипт ниже опрашивает список адресов, проверяет состояние пулов и пишет результат в файл. Его можно повесить в «Планировщик заданий» раз в 5–10 минут.

Import-Module WebAdministration

$urls  = @(
    "http://localhost/buh/",
    "http://localhost/zup/"
)
$pools = @("DefaultAppPool")
$log   = "C:\Scripts\1c_publish_check.log"
$now   = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

foreach ($p in $pools) {
    $state = (Get-WebAppPoolState -Name $p).Value
    Add-Content $log "$now POOL $p $state"
}

foreach ($u in $urls) {
    try {
        $r = Invoke-WebRequest -Uri $u -UseBasicParsing -TimeoutSec 30
        Add-Content $log "$now OK $u $($r.StatusCode)"
    }
    catch {
        $code = $_.Exception.Response.StatusCode.value__
        Add-Content $log "$now FAIL $u $code $($_.Exception.Message)"
    }
}

Скрипт запускайте от имени администратора: модулю WebAdministration нужны повышенные права. Строки с FAIL можно отправлять в почту или мессенджер — это уже зависит от вашей системы оповещений.

Для Linux и Apache тот же смысл даёт одна строка в cron:

curl -s -o /dev/null -w "%{http_code} %{url_effective}\n" http://localhost/buh/ >> /var/log/1c_publish_check.log

Что проверять после изменений на сервере

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