Почему при публикации 1С на IIS в Windows 10 возникает ошибка 500 или открывается список файлов?

← На главную

Публикация информационной базы 1С на веб-сервере IIS в среде Windows 10 часто сопровождается техническими сложностями, которые не всегда очевидны при использовании стандартного мастера публикации из Конфигуратора. Разберем основные сценарии, когда вместо запуска веб-клиента мы получаем либо список файлов в браузере (Directory Browsing), либо критическую ошибку Internal Server Error 500. Проанализируем причины такого поведения и пошагово настроим сервер для стабильной работы.

Причина 1: Вместо 1С открывается список файлов в браузере

Если при обращении по адресу публикации вы видите содержимое каталога и файл default.vrd, это означает, что IIS воспринимает вашу папку как обычное файловое хранилище, а не как активное веб-приложение. Выясним причину: сервер не знает, как обрабатывать расширение .vrd, или не активированы необходимые компоненты среды выполнения.

Для решения этой проблемы выполним следующие действия:

Проверим наличие установленных компонентов IIS в Windows 10. Перейдем в "Включение или отключение компонентов Windows" и убедимся, что в разделе "Службы IIS" -> "Службы интернета" -> "Компоненты разработки приложений" отмечены пункты Расширения ISAPI и Фильтры ISAPI. Без них 1С не сможет взаимодействовать с веб-сервером через свои библиотеки wsapvr.dll.
Проанализируем файл web.config в папке публикации. Если он отсутствует или поврежден, IIS не получит инструкций по передаче запроса модулю 1С. Попробуем переопубликовать базу из Конфигуратора от имени администратора.
Проверим "Сопоставление обработчиков" (Handler Mappings) в консоли управления IIS для нашего сайта. Там должен присутствовать обработчик, указывающий на путь к DLL-файлу расширения веб-сервера 1С.

Причина 2: Ошибка HTTP 500.0 — Internal Server Error

Эта ошибка является наиболее общей и часто указывает на конфликт разрядности или отсутствие прав доступа. Рассмотрим подробнее, как исправить ситуацию, когда 1С установлена в 64-битной версии.

Разберем настройку пула приложений:

Откроем Диспетчер служб IIS и перейдем в раздел Пулы приложений.
Найдем пул, который используется вашим веб-сайтом (по умолчанию это DefaultAppPool).
Зайдем в "Дополнительные параметры" пула.
Найдем параметр Разрешены 32-разрядные приложения. Если вы используете 64-битную платформу 1С, установите это значение в False. И наоборот, если платформа 32-битная — в True.
Убедимся, что в поле "Версия среды CLR .NET" выбрано актуальное значение (обычно v4.0), хотя для 1С это менее критично, чем разрядность.

Проанализируем права доступа к файловой системе. Это критически важный этап, так как веб-сервер работает от имени специальной учетной записи. Выполним настройку прав:

Дадим права "Чтение и выполнение" группе IIS_IUSRS на папку, где лежит файл web.config и default.vrd.
Важный момент: Необходимо также предоставить права на чтение и выполнение этой же группе (или пользователю пула приложений ApplicationPoolIdentity) на папку с бинарными файлами 1С. Обычно это путь вида C:\Program Files\1cv8\8.3.X.X\bin. Если сервер не сможет прочитать wsapvr.dll, вы получите ошибку 500.

Причина 3: Ошибка Request.Path и проблемы загрузки файлов

Иногда после успешного запуска веб-клиента пользователи сталкиваются с ошибкой: Обнаружено потенциально опасное значение Request.Path, полученное от клиента (:). Это происходит при попытке передачи файлов или специфических навигационных команд, содержащих спецсимволы, которые система безопасности IIS блокирует по умолчанию.

Посмотрим на два способа решения этой проблемы:

Способ 1: Изменение режима управляемого конвейера.
В дополнительных параметрах пула приложений (DefaultAppPool) найдем пункт "Режим управляемого конвейера" (Managed Pipeline Mode). Переключение его из режима Integrated в режим Classic часто решает проблему совместимости со старыми механизмами передачи путей, однако это может несколько снизить общую производительность системы.

Способ 2: Настройка через конфигурационный файл.
Более современный и безопасный метод — внести изменения непосредственно в файл web.config, который находится в папке с вашей публикацией. Мы можем разрешить использование определенных символов в путях запросов. Рассмотрим пример того, как должен выглядеть блок настроек внутри секции <system.web>:


<system.web>
    <httpRuntime requestPathInvalidCharacters="" />
</system.web>

Дополнительно, для обеспечения возможности загрузки файлов и корректной обработки "двойного экранирования", рекомендуется добавить следующий блок в секцию <system.webServer>:


<security>
    <requestFiltering allowDoubleEscaping="true" />
</security>

Дополнительная отладка через детальные ошибки

Если причина ошибки 500 все еще не ясна, мы можем заставить IIS выводить подробную техническую информацию прямо в окно браузера, вместо стандартной заглушки. Рассмотрим, как это сделать:

В консоли IIS выберите ваш сайт или папку публикации.
Откройте раздел Страницы ошибок (Error Pages).
В правой панели выберите "Изменить настройки функции" (Edit Feature Settings).
Выберите вариант Подробные ошибки (Detailed errors) и нажмите ОК.

После этого при обновлении страницы в браузере вы увидите точное указание на модуль или файл конфигурации, вызвавший сбой. Не забудьте вернуть эту настройку обратно после завершения отладки в целях безопасности.

Резюме по разрядности и путям

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

C:\Program Files\1cv8\8.3.X.X\bin\wsapvr.dll

Если там указан путь в папку Program Files (x86), а пул настроен на 64 бита — публикация не заработает. Всегда проверяйте соответствие настроек пула приложений IIS и фактической разрядности установленной платформы 1С.