Сервер 1С отвечает кодом 403, 404, 500 или 503: ищем причину и чиним

Ошибка HTTP при обращении к серверу 1С почти никогда не означает, что «сломалась 1С». Код ответа приходит от веб-сервера (IIS, Apache, nginx) или от прокси перед ним, и по самому коду уже видно, где искать. Первое действие — посмотреть число в тексте ошибки: 401, 403, 404, 500, 502 или 503.

Код ошибки 503 в 1С, например, чаще всего значит, что остановлен пул приложений IIS или не запущена служба Apache. Остальные коды ведут к другим причинам. Ниже — таблица соответствия, а затем проверки по порядку: от самых частых к редким.

Что означает код ответа: быстрая расшифровка

Сообщение выглядит по-разному, в зависимости от клиента. В тонком клиенте и веб-клиенте это обычно:

• Ошибка HTTP при обращении к серверу
• HTTP 503 Service Unavailable
• Ошибка при вызове метода контекста (...): 404 Not Found

Сопоставьте код с причиной:

Проверка публикации на веб-сервере

Самая частая причина 404 и 500 — публикация сделана с ошибкой или потеряна после обновления платформы. Проверьте по порядку.

Адрес и имя публикации

1. Откройте базу в Конфигураторе: Администрирование → Публикация на веб-сервере.
2. Сверьте поле «Имя» с тем, что набрано в адресной строке. Регистр в Apache имеет значение, в IIS — нет.
3. Убедитесь, что каталог публикации существует и в нём лежит файл default.vrd.

Если каталога нет, а в списке публикаций она числится, виноваты чистка диска или переустановка веб-сервера. Публикацию нужно сделать заново.

Версия платформы и модуль расширения

Модуль веб-расширения (wsisapi.dll для IIS, wsap24.dll для Apache 2.4) копируется в момент публикации. После обновления платформы он остаётся старым.

• 🔄 Обновили платформу на сервере — переопубликуйте все базы.
• 🔄 Обновили Apache или IIS — проверьте, что модуль подключён.
• 🔄 Разрядность платформы и веб-сервера должна совпадать.

Типичный признак рассинхронизации: часть баз работает, другие отвечают 500 сразу после обновления.

Что проверить в IIS

• Установлены компоненты Расширения ISAPI и Фильтры ISAPI.
• В обработчиках сайта разрешено выполнение ISAPI-модуля.
• Приложение публикации лежит в нужном пуле, а параметры пула (версия .NET CLR, режим конвейера) соответствуют рекомендациям для вашей версии платформы.

Код 503: пул приложений и службы

503 в IIS ставит пул, который остановился. Он гаснет сам, если приложение несколько раз подряд падает за короткое время: срабатывает защита «быстрый сбой».

Пошагово

1. Откройте Диспетчер служб IIS → Пулы приложений.
2. Найдите пул вашей публикации. Статус «Остановлено» — запустите.
3. Откройте «Дополнительные параметры» пула и проверьте идентификатор: учётная запись должна существовать и иметь право входа как служба.
4. Если пул гаснет снова, смотрите журнал событий: Журналы Windows → Система и Приложение, источник WAS или IIS-W3SVC-WP.

Для Apache логика та же: проверьте, что служба запущена (services.msc), и прочитайте error.log. Если порт 80 или 443 занят другой программой, Apache не стартует вообще.

Код 403 и 401: права доступа и аутентификация

403 означает, что сервер понял запрос, но отказал. 401 — что не принял учётные данные. Путаются они часто, а лечатся по-разному.

Права на каталог публикации

Веб-сервер читает default.vrd и файлы расширения от имени своей учётной записи. Если прав нет, он ответит 403 или 500.

1. Откройте свойства каталога публикации → вкладка «Безопасность».
2. Добавьте учётную запись, под которой работает пул или Apache. Для IIS это IIS_IUSRS и при анонимном доступе IUSR.
3. Выдайте право на чтение и выполнение.

Отдельно проверьте каталог временных файлов платформы и каталог, где расположена сама база, если она файловая. Для файловой базы пользователь веб-сервера обязан писать в каталог базы.

Способ аутентификации

В IIS проверьте раздел Проверка подлинности вашего приложения:

• включена «Анонимная проверка» — веб-сервер не требует логин, пароль запрашивает 1С;
• включена «Windows» — вход идёт по домену, а имена пользователей должны совпасть с пользователями базы;
• включены обе — браузер может спрашивать пароль дважды.

Если в default.vrd задана аутентификация ОС, а пользователь в базе не связан с учётной записью Windows, будет 401 или сообщение об отсутствии пользователя.

Ограничения по адресам

403 дают и правила веб-сервера: список разрешённых IP в IIS, директивы Require ip в Apache, allow/deny в nginx. Если сервис открывали «только для офиса», а вы зашли через VPN с другого адреса, сработает именно это.

Брандмауэр, антивирус и сеть

Если веб-сервер вообще не отвечает или соединение обрывается, код HTTP вы не получите — клиент напишет об ошибке соединения. Но иногда антивирус или фильтр отвечает вместо сервера, и тогда приходит 403 или 502.

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

1. С клиента: Test-NetConnection имя_сервера -Port 80 (или 443) в PowerShell. Если порт закрыт — дело в сети.
2. Правила брандмауэра Windows на сервере: входящие порты веб-сервера. Для самого сервера 1С — порты кластера, они к HTTP не относятся.
3. Исключения антивируса: каталог публикации, каталог платформы и процесс w3wp.exe (или httpd.exe).
4. Прокси и шлюз безопасности перед сервером: у корпоративных фильтров бывает свой лимит размера запроса и своя сигнатура «подозрительных» POST.

Журналы: где найти настоящую причину

Страница ошибки в браузере лаконична. Подробности лежат в журналах, и без них угадывание превращается в лотерею.

Как читать журнал IIS

В строке журнала найдите колонки sc-status и sc-substatus. Пара «404.0» и «404.13» — разные причины, хотя пользователь видит одно и то же 404. Подстатус сужает поиск: например, 500.19 говорит о неверной конфигурации (часто ломается web.config), а 403.14 — что запрошен каталог без документа по умолчанию.

Технологический журнал

Если веб-сервер ответил нормально, а ошибку вернула сама платформа, включите технологический журнал. Минимальный logcfg.xml с записью исключений:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\1clogs" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

Положите файл в каталог conf платформы, воспроизведите ошибку и откройте свежие файлы в C:\1clogs. Не оставляйте подробное логирование надолго: журналы быстро растут.

HTTPS: сертификаты и порты

После перехода на защищённое соединение ошибки получают новый набор причин.

• 🔒 Сертификат просрочен или выписан на другое имя. Клиент отказывается соединяться; в тонком клиенте это тоже выглядит как ошибка при обращении к серверу.
• 🔒 Цепочка сертификатов неполная: корневой или промежуточный сертификат не установлен на клиенте.
• 🔒 Привязка сайта в IIS указывает на старый сертификат после продления.
• 🔒 Смешанное содержимое: страница по https подгружает ресурсы по http, и браузер их блокирует.
• 🔒 В адресе базы стоит порт 80, а сайт отвечает только на 443 (или наоборот).

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

За обратным прокси (например, nginx) убедитесь, что он передаёт заголовки Host и X-Forwarded-Proto, а размер запроса разрешён: загрузка больших файлов упирается в лимит и даёт 413.

Что ещё даёт сбой при обращении к сервису

Бывает, что публикация исправна, а ошибка возникает в одном сценарии.

Веб-сервисы и HTTP-сервисы

Вы вызываете HTTP-сервис или веб-сервис из внешней системы и получаете 404? Проверьте:

• опубликован ли нужный сервис: в default.vrd перечислены только отмеченные при публикации сервисы;
• совпадает ли шаблон URL с запросом, включая слэши;
• не требует ли сервис авторизации, которую клиент не передаёт.

Большие запросы и таймауты

Долгие операции (выгрузка отчётов, обмен) упираются во время ожидания. Прокси режет соединение раньше, чем отвечает 1С, и пользователь видит 502 или 504. Увеличьте таймаут на прокси или переведите долгую операцию в фоновое задание.

Частые ошибки при диагностике

• ❌ Переустанавливают платформу вместо проверки кода ответа. Код почти всегда указывает на веб-сервер.
• ❌ Меняют права на весь диск «для проверки» и забывают вернуть.
• ❌ Лечат 503 перезапуском пула, не открыв журнал: ошибка возвращается через час.
• ❌ Проверяют только из браузера на своём компьютере. С самого сервера картина иногда другая.
• ❌ Редактируют default.vrd вручную и теряют правки при следующей публикации из Конфигуратора.

Как не получать эту ошибку снова

• 📌 После каждого обновления платформы переопубликуйте базы и проверьте вход.
• 📌 Держите описание публикаций: имя, каталог, пул, способ входа.
• 📌 Настройте мониторинг доступности адреса: сообщение придёт раньше пользователей.
• 📌 Календарь продления сертификатов — за месяц до срока.
• 📌 Не размещайте на одном пуле приложений нестабильное стороннее ПО.

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