← На главную

При работе с базами данных 1С через веб-сервер (IIS или Apache) системные администраторы и пользователи часто сталкиваются со специфической ошибкой тонкого клиента: «Ошибка при выполнении запроса GET к ресурсу /e1cib/types». Данная неполадка полностью блокирует запуск информационной базы у конкретного пользователя, при этом на других рабочих станциях или через обычный веб-браузер база может открываться абсолютно корректно.

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

Что такое ресурс /e1cib/types и почему происходит сбой?

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

Адрес /e1cib/types представляет собой служебный ресурс публикации 1С. Через него тонкий клиент запрашивает у веб-сервера описание типов метаданных конфигурации, структуру интерфейса и схемы данных. Получив этот пакет информации, платформа 1С сохраняет его локально на компьютере пользователя в так называемом VRS-кэше (Virtual Resource System). Этот кэш физически представляет собой базу данных SQLite и располагается в каталоге %AppData%\Local\1C\1cv8.

Сбой при выполнении GET-запроса к /e1cib/types происходит в тот момент, когда тонкий клиент по какой-то причине не может либо получить корректный ответ от веб-сервера, либо записать полученную схему в локальный VRS-кэш на жестком диске. Как показывает практика, триггером для такой ошибки часто становится прерывание процесса обновления платформы 1С или запуск функции «Восстановить» (Repair) в установщике программ под учетной записью Windows с ограниченными правами.

---

Способ 1. Глубокая очистка локального кэша и каталога временных файлов

Обычное удаление базы из списка запуска 1С и её повторное добавление очищает лишь базовый кэш конфигурации, но практически никогда не затрагивает кэш виртуальных ресурсов (VRS), который и является источником проблемы. Нам потребуется произвести полную ручную очистку всех рабочих каталогов платформы. Выполним следующие действия по шагам:

1. Полностью закроем все запущенные процессы 1С. Для надежности откроем Диспетчер задач Windows и убедимся, что процессы 1cv8.exe, 1cv8c.exe и 1cestart.exe отсутствуют в списке активных.
2. Нажмем комбинацию клавиш Win + R на клавиатуре, введем команду shell:local appdata и нажмем Enter. В открывшемся проводнике перейдем в папку 1C и полностью удалим каталог 1cv8.
3. Снова нажмем Win + R, введем команду shell:appdata, перейдем в папку 1C и также удалим оттуда каталог 1cv8.
4. Очистим временные файлы операционной системы. Для этого в окне «Выполнить» (Win + R) введем команду shell:temp. Выделим все файлы в открывшейся папке и удалим их. Если какие-то файлы заблокированы запущенными системными процессами, просто пропустим их.
5. Проверим наличие виртуализированного кэша. Если в операционной системе Windows включен контроль учетных записей (UAC), система могла перенаправить запись кэша в специальную защищенную директорию. Перейдем по пути C:\Users\<Имя_Пользователя>\AppData\Local\VirtualStore. Если внутри этой папки обнаружится каталог 1C или 1cv8, его также необходимо безвозвратно удалить.

После проведения глубокой очистки запустим тонкий клиент и проверим работоспособность подключения.

---

Способ 2. Восстановление прав доступа к системным директориям Windows

Если сбой начался после проведения операции восстановления (Repair) платформы 1С, велика вероятность того, что установщик изменил владельца или права доступа к папкам временных файлов текущего пользователя. Тонкий клиент запускается от имени вашей учетной записи Windows, но из-за некорректных разрешений NTFS теряет право на запись информации в папку Temp.

Для того чтобы исправить права доступа, выполним следующие операции:

1. Откроем проводник и перейдем в каталог C:\Users\<Имя_Пользователя>\AppData\Local (папка AppData по умолчанию скрыта, поэтому предварительно включите отображение скрытых элементов в настройках проводника).
2. Нажмем правой кнопкой мыши на папку Temp и выберем пункт «Свойства».
3. Перейдем на вкладку «Безопасность» и нажмем кнопку «Дополнительно».
4. В верхней части окна найдем строку «Владелец» и убедимся, что владельцем папки является именно ваша текущая учетная запись Windows. Если это не так, нажмем кнопку «Изменить» и укажем своего пользователя.
5. В списке разрешений найдем свою учетную запись, выделим её и нажмем «Изменить». Убедимся, что для пользователя установлена галочка напротив пункта «Полный доступ».
6. Установим флажок «Заменить все записи разрешений дочернего объекта наследуемыми записями разрешений этого объекта» внизу окна и нажмем «Применить».
7. Аналогичную процедуру проверки прав выполним для каталога C:\Users\<Имя_Пользователя>\AppData\Local\1C.

---

Способ 3. Сброс настроек платформы 1С в реестре Windows

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

Проанализируем процесс сброса настроек через редактор реестра:

1. Нажмем сочетание клавиш Win + R, введем команду regedit и нажмем Enter для открытия редактора реестра от имени администратора.
2. В левой части окна перейдем по следующему пути:
   HKEY_CURRENT_USER\Software\1C
3. Нажмем правой кнопкой мыши на раздел 1C и выберем пункт «Экспортировать». Сохраним этот файл в надежное место (например, на Рабочий стол) — это наша резервная копия на случай непредвиденных сбоев.
4. После успешного создания резервной копии снова кликнем правой кнопкой мыши по разделу 1C в реестре и выберем команду «Удалить». Подтвердим операцию.

При следующем старте тонкого клиента платформа автоматически пересоздаст чистую структуру параметров в реестре Windows, что исключит влияние устаревших или поврежденных ключей настроек.

---

Способ 4. Проверка чувствительности к регистру в адресе публикации базы

Малоизвестный, но крайне важный нюанс работы тонкого клиента 1С заключается в том, что он чрезвычайно чувствителен к регистру символов в строке подключения, в отличие от веб-браузеров. Браузер автоматически обрабатывает и перенаправляет некорректно написанные пути, тогда как тонкий клиент при обращении к `/e1cib/types` выдаст ошибку.

Разберем пример:

• Если в диспетчере IIS ваша база опубликована под именем TradeBase (с заглавными буквами), то и в строке подключения в окне запуска 1С адрес должен выглядеть строго как http://имя_сервера/TradeBase.
• Если вы укажете адрес как http://имя_сервера/tradebase или http://имя_сервера/TRADEBASE, то авторизацию вы пройти сможете, но при попытке получить типы метаданных тонкий клиент вернет ошибку GET к ресурсу `/e1cib/types`.

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

---

Способ 5. Настройка параметров авторизации на стороне веб-сервера IIS

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

Выполним аудит настроек на стороне IIS:

1. Откроем Диспетчер служб IIS на сервере, где опубликована база.
2. В левом дереве подключений выберем сайт и конкретную виртуальную директорию нашей информационной базы 1С.
3. В центральной части окна откроем раздел «Аутентификация» (Authentication).
4. Убедимся, что пункт «Анонимная проверка подлинности» (Anonymous Authentication) находится в состоянии «Включено». Если для базы включена только «Проверка подлинности Windows» (Windows Authentication), тонкий клиент при попытке загрузить схему метаданных без предварительной авторизации получит отказ доступа от веб-сервера (ошибку HTTP 401 или 403), что на стороне клиента отразится как сбой запроса к /e1cib/types.
5. Также проверим файл web.config, расположенный в каталоге публикации базы 1С. Убедимся, что там отсутствуют лишние правила перезаписи URL (URL Rewrite), которые могут перехватывать системные запросы платформы.

---

Способ 6. Создание нового профиля пользователя Windows (гарантированное решение)

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

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

Рассмотрим алгоритм перевода пользователя на новый профиль:

1. Откроем Панель управления Windows, перейдем в раздел «Учетные записи пользователей» и создадим нового локального пользователя с правами Администратора компьютера.
2. Выполним выход из текущей учетной записи Windows и зайдем в систему под именем нового созданного пользователя.
3. Запустим 1С:Предприятие, добавим базу данных через веб-ссылку и убедимся, что подключение происходит успешно, а структура метаданных загружается без ошибок.
4. После проверки перенесем необходимые рабочие файлы, документы и ярлыки из папки старого профиля C:\Users\<Старый_Пользователь> в папку нового пользователя C:\Users\<Новый_Пользователь>.

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