Как исправить неклассифицированную ошибку работы с хранилищем конфигурации 1С при подключении по HTTP?

При совместной разработке в среде 1С:Предприятие одним из наиболее удобных инструментов является хранилище конфигурации. Однако при использовании веб-сервера IIS для удаленного подключения по протоколам HTTP или HTTPS разработчики часто сталкиваются с неприятным сбоем. На стороне конфигуратора возникает системное сообщение: «Неклассифицированная ошибка работы с хранилищем конфигурации», а в качестве первопричины указывается таймаут: «The page cannot be displayed because the client took too long to complete its request and the server closed the connection».

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

Выясняем причину: почему рвется соединение?

Основная причина этой ошибки кроется в специфике передачи данных. Конфигурация 1С состоит из огромного количества метаданных. При выполнении таких операций, как первое подключение к хранилищу, захват или помещение крупных объектов (например, целых подсистем или тяжелых общих модулей), клиентское приложение формирует тяжелые POST-запросы и отправляет их на веб-сервер.

Стандартные настройки веб-сервера IIS ориентированы на обычные веб-страницы и небольшие API-запросы. По умолчанию в IIS установлены жесткие ограничения на:

1. Максимальный размер загружаемого контента (запроса).
2. Время ожидания ответа от клиентской сессии (таймаут соединения).
3. Время выполнения скриптов и обработки запросов в пуле приложений.
4. Скорость передачи данных (защита от медленных HTTP-атак).

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

Решение 1. Выделение хранилища в отдельный пул приложений IIS

Очень часто сервер хранилища конфигурации публикуется на том же веб-сервере, где уже работают другие информационные базы 1С или сторонние веб-сервисы. Если все они используют один и тот же рабочий пул приложений (по умолчанию это DefaultAppPool), то длительные транзакции хранилища будут конкурировать с запросами обычных пользователей. Это неизбежно ведет к перегрузке пула и аварийному завершению рабочих процессов веб-сервера.

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

1. Запустите Диспетчер служб IIS (IIS Manager) на сервере.
2. В левой панели навигации разверните имя вашего сервера и перейдите в раздел Пулы приложений (Application Pools).
3. В правой панели действий выберите пункт Добавить пул приложений... (Add Application Pool).
4. В открывшемся окне введите имя нового пула (например, 1C_Repository_Pool). В поле "Версия среды .NET CLR" можно оставить значение по умолчанию или выбрать "Без управляемого кода" (No Managed Code), так как расширение 1С использует нативный код. Нажмите кнопку ОК.
5. Выберите созданный пул в списке, нажмите на него правой кнопкой мыши и выберите Дополнительные параметры... (Advanced Settings).
6. Найдите параметр Разрешены 32-разрядные приложения (Enable 32-Bit Applications). Если на вашем сервере используется 32-битная версия платформы 1С:Предприятие (и соответственно библиотека wsisapi.dll), обязательно установите для этого параметра значение True. Если используется 64-битная платформа, оставьте значение False. Нажмите ОК.
7. В левой панели IIS Manager перейдите к вашей виртуальной директории, в которой опубликовано хранилище 1С.
8. В правой панели действий нажмите Основные настройки... (Basic Settings).
9. Напротив поля "Пул приложений" нажмите кнопку Выбрать..., укажите созданный нами пул 1C_Repository_Pool и нажмите ОК.

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

Решение 2. Увеличение максимального размера загружаемых файлов

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

Для решения этой проблемы нам необходимо изменить параметр maxAllowedContentLength. Сделать это можно через конфигурационный файл или графический интерфейс:

Способ А. Настройка через файл web.config

Найдите физическую папку на диске, куда была выполнена публикация хранилища (там находится файл default.vrd). Создайте в этой папке (или отредактируйте, если он уже существует) файл с именем web.config. Добавьте в него следующие настройки:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <security>
            <requestFiltering>
                <requestLimits maxAllowedContentLength="4294967295" />
            </requestFiltering>
        </security>
    </system.webServer>
</configuration>

Значение 4294967295 байт соответствует максимальному лимиту (4 Гб), чего с запасом хватит для передачи конфигурации любого объема.

Способ Б. Настройка через Диспетчер IIS

1. В Диспетчере IIS выберите сайт или конкретную виртуальную директорию хранилища.
2. В центральной части дважды кликните по иконке Фильтрация запросов (Request Filtering).
3. В правой панели действий выберите пункт Изменение параметров функции... (Edit Feature Settings).
4. В поле Максимальная разрешенная длина содержимого (байт) укажите значение 4294967295. Нажмите ОК.

Решение 3. Настройка таймаутов выполнения ASP.NET

Даже если лимит размера данных увеличен, IIS может прервать запрос, если он выполняется слишком долго. Для предотвращения этого необходимо скорректировать параметры времени выполнения в секции ASP.NET. Откройте ваш файл web.config и добавьте внутрь секции <system.web> элемент <httpRuntime> с увеличенными лимитами времени выполнения:

<configuration>
    <system.web>
        <httpRuntime maxRequestLength="2097151" executionTimeout="3600" />
    </system.web>
</configuration>

Разберем, за что отвечают эти параметры:

• executionTimeout — устанавливает максимальное время выполнения запроса в секундах до того, как он будет закрыт ASP.NET. Значение 3600 секунд (1 час) гарантирует, что даже на медленных каналах связи операция сравнения и объединения метаданных успеет завершиться корректно.
• maxRequestLength — указывает максимальный размер запроса, обрабатываемого ASP.NET, в килобайтах. Значение 2097151 соответствует примерно 2 Гб.

Решение 4. Отключение защиты от медленной передачи данных

В современных версиях IIS встроена система защиты от атак типа "Slowloris" (медленный HTTP-запрос). Если клиент отправляет пакеты данных со скоростью ниже определенного порога, сервер считает это атакой и закрывает сессию. При работе с конфигуратором 1С такое поведение часто становится ложноположительным триггером: клиент локально формирует кэш, из-за чего отправка данных приостанавливается, а IIS обрывает соединение.

Для отключения этой проверки нам потребуется отредактировать глобальный конфигурационный файл IIS applicationHost.config, который обычно находится по пути: C:\Windows\System32\inetsrv\config\applicationHost.config.

Внимание: Перед редактированием этого файла обязательно сделайте его резервную копию!

1. Откройте файл applicationHost.config с помощью текстового редактора с правами администратора.
2. Найдите секцию <webLimits>.
3. Установите значение параметра minBytesPerSecond равным 0. Это полностью отключит лимит минимальной скорости передачи.

Пример корректной секции в файле:

<system.applicationHost>
    <webLimits minBytesPerSecond="0" connectionTimeout="00:10:00" />
</system.applicationHost>

Обратите внимание, что параметр connectionTimeout мы также можем увеличить (например, до 10 минут, как в примере выше), чтобы дать веб-серверу больше времени на ожидание отклика от конфигуратора 1С.

Решение 5. Настройка размера буфера предварительного чтения

При передаче крупных объемов через SSL (HTTPS) или при обработке POST-запросов IIS использует буфер предварительного чтения (Read-Ahead Buffer). По умолчанию его размер составляет всего 49 Кб. Если размер заголовков или передаваемых данных превышает этот буфер, сервер возвращает ошибку 413 (Request Entity Too Large) или уходит в глубокий таймаут.

Давайте увеличим этот параметр:

1. В Диспетчере IIS выберите ваш сайт.
2. В центральной части откройте инструмент Редактор конфигурации (Configuration Editor).
3. В выпадающем списке разделов (Section) вверху перейдите по пути: system.webServer -> serverRuntime.
4. Найдите параметр uploadReadAheadSize и измените его значение по умолчанию на максимальное: 2147483647 байт.
5. Нажмите кнопку Применить (Apply) в правом верхнем углу.

Решение 6. Контроль версий платформы и локальная профилактика

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

• Соблюдайте идентичность версий: Все разработчики, подключающиеся к данному хранилищу, а также сам веб-сервер IIS (используемая им библиотека wsisapi.dll) должны работать на абсолютно одинаковом релизе платформы. Разница даже в одну цифру сборки (например, у одного разработчика 8.3.8.1652, а на сервере 8.3.8.1650) может приводить к взаимным блокировкам базы данных хранилища и зависанию сессий IIS.
• Очищайте локальный кэш конфигуратора: Регулярные сбои связи забивают локальный кэш метаданных на компьютерах разработчиков, из-за чего последующие сравнения версий начинают длиться бесконечно долго. Периодически удаляйте папки временных файлов 1С из каталога пользователя: %localappdata%\1C\1Cv8.
• Тестируйте базу хранилища: База данных хранилища (файл 1Cv8ddb.1CD) при частых аварийных отключениях может получить внутренние повреждения таблиц. Настоятельно рекомендуется периодически запускать конфигуратор локально (без HTTP), открывать хранилище монопольно и выполнять команду "Администрирование хранилища" -> "Проверка целостности".

Применив эти настройки в комплексе, мы гарантируем стабильное соединение конфигуратора 1С с веб-сервером IIS. Это полностью устранит проблему неклассифицированных ошибок и позволит разработчикам комфортно работать с хранилищем даже при медленном интернет-соединении и больших объемах метаданных.