Что делать, если веб-сервис 1С перестал работать после падения сервера и выдает ошибку 500?

← На главную

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

Метод 1: Полная очистка обработчиков и перепубликация (Основное решение)

Чаще всего при падении сервера происходит повреждение метаданных в конфигурационных файлах IIS или «зависание» сопоставлений обработчиков (Handler Mappings). Даже если вы нажимаете кнопку «Опубликовать» в 1С, конфигуратор может не обновить уже существующие, но некорректно работающие записи в IIS. Давайте выполним процедуру полной очистки системы.

Рассмотрим алгоритм действий по шагам:

Откроем Диспетчер служб IIS.
В дереве соединений выберем наш сайт или конкретное виртуальное приложение 1С.
Перейдем в раздел «Сопоставление обработчиков» (Handler Mappings).
Найдем и удалим все записи, связанные с 1С (обычно они называются 1C Web-service Extension и указывают на wsisapi.dll).
Остановим работу сайта или всего сервера IIS.
Теперь перейдем в Конфигуратор 1С от имени администратора.
Откроем меню «Администрирование» — «Публикация на веб-сервере».
Снимем флаг «Публиковать веб-сервисы» и нажмем «Опубликовать» (это принудительно отключит публикацию). Если система выдает ошибки, игнорируем их.
Снова запустим IIS.
Вернемся в окно публикации в 1С, установим нужные флаги (Публиковать веб-сервисы, Публиковать по умолчанию) и заново нажмем «Опубликовать».
На вопрос системы о перезапуске веб-сервера отвечаем согласием.

Проанализируем файл default.vrd. После перепубликации обязательно проверьте параметр alias. Бывают случаи, когда обращение идет по адресу site/ws/MyService?wsdl, а в конфигурации прописан другой псевдоним. Пример корректной секции в файле:


<point name="MyService"
    alias="ws1.1cws"
    enable="true"/>

Метод 2: Настройка подробных сообщений об ошибках

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

Выполним настройку:

В Диспетчере служб IIS выберем наше приложение и откроем пункт «Страницы ошибок». В правой панели нажмем «Изменить параметры групповых ошибок» и выберем вариант «Подробные сообщения об ошибках». После этого при попытке открыть страницу .../ws/?wsdl в браузере мы увидим более конкретный текст, например, указание на конкретный модуль или проблему с правами доступа.

Метод 3: Проверка разрядности пула приложений

Проанализируем системную ситуацию: если после сбоя вы решили обновить платформу или восстановить ее из бэкапа, могла возникнуть путаница между 32-битной и 64-битной версиями. Если пул приложений IIS настроен на 64 бита, а публикация указывает на wsisapi.dll из папки Program Files (x86), веб-сервис работать не будет.

Зайдем в «Пулы приложений» в IIS.
Найдем пул, на котором работает наше приложение.
Нажмем «Дополнительные параметры».
Проверим значение поля «Разрешить 32-разрядные приложения». Оно должно соответствовать разрядности установленной платформы 1С, чьи библиотеки используются в публикации.

Метод 4: Права доступа и аутентификация

Часто причиной ошибки 500 после «падения» системы становится сброс прав доступа на папки или изменение паролей служебных учетных записей. Выясним, есть ли у IIS доступ к исполняемым файлам 1С.

Проверим следующие моменты:

Пользователь, от имени которого запущен пул приложений (например, IIS AppPool\DefaultAppPool или NetworkService), должен иметь права «Чтение и выполнение» на папку bin установленной платформы 1С.
В разделе «Аутентификация» для вашего веб-приложения должна быть включена «Анонимная аутентификация». Проверьте, чтобы в ее настройках был выбран IUSR или «Удостоверение пула приложений».
Если для доступа к базе используется конкретный пользователь ОС, убедитесь, что его пароль не истек и не был изменен.

Метод 5: Ограничения ISAPI и CGI

При переустановке ролей сервера или критических сбоях расширение 1С может попасть в список запрещенных. Проанализируем настройки на уровне всего сервера IIS:

Выберем корень сервера в Диспетчере IIS.
Откроем «Ограничения ISAPI и CGI».
Убедимся, что путь к используемой wsisapi.dll присутствует в списке и имеет статус «Разрешено». Если записи нет, ее нужно добавить вручную, указав путь к библиотеке в папке bin нужной версии 1С.

Метод 6: Очистка временных файлов и кэша

Аварийное завершение работы часто оставляет «битые» временные файлы. Рассмотрим процедуру очистки кэша на стороне сервера:

Остановим службу 1С:Предприятия и IIS. Перейдем в каталог данных сервера (обычно это C:\Program Files\1cv8\srvinfo). Найдем папку соответствующей информационной базы и внутри нее очистим содержимое папки snccntx. Также рекомендуется очистить системные временные папки C:\Windows\Temp и %TEMP% пользователя, под которым запускаются службы.

Метод 7: Конфликты в Web.config

При повторных публикациях 1С иногда создает файл web.config в папке с default.vrd. Если в системе уже настроены параметры на уровне сайта, может возникнуть дублирование секций конфигурации. Проанализируем структуру web.config. Если там дублируются секции handlers, которые уже прописаны глобально, это приведет к внутренней ошибке сервера.

Пример корректного минимального файла конфигурации для 1С:


<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <add name="1C Web-service Extension" 
                 path="*" 
                 verb="*" 
                 modules="IsapiModule" 
                 scriptProcessor="C:\Program Files\1cv8\8.3.X.XXXX\bin\wsisapi.dll" 
                 resourceType="Unspecified" 
                 requireAccess="Execute" />
        </handlers>
    </system.webServer>
</configuration>

Подводя итог, отметим: если после падения сервера 1С перестал работать веб-сервис, а веб-клиент при этом доступен, проблема почти всегда кроется в сопоставлении обработчиков ISAPI или в правах доступа к библиотекам платформы. Последовательное выполнение предложенных методов позволяет восстановить работоспособность системы без полной переустановки IIS.