Почему в веб-клиенте 1С не отображаются табличные документы и как исправить ошибку mixed-content

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При работе с информационной базой 1С через веб-клиент, особенно после настройки защищенного соединения HTTPS, системные администраторы часто сталкиваются с неприятной ситуацией: интерфейс программы загружается корректно, но содержимое отчетов и любых табличных документов остается абсолютно пустым. Если мы откроем инструменты разработчика в браузере (клавиша F12) и перейдем на вкладку Network, то увидим критическую ошибку в консоли: (blocked:mixed-content). Эта ошибка обычно связана с файлом moxel.css.

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

Разберем причину возникновения ошибки Mixed Content

Давайте выясним, что именно блокирует браузер. Современные стандарты безопасности запрещают загрузку незащищенных ресурсов (по протоколу HTTP) на страницах, которые открыты по защищенному протоколу (HTTPS). Это и называется «смешанным содержимым» (Mixed Content).

Когда вы формируете отчет в веб-клиенте, платформа 1С динамически генерирует временный файл стилей moxel.css, который необходим для отрисовки ячеек таблицы. Если перед вашим веб-сервером (IIS или Apache) стоит прокси-сервер, балансировщик нагрузки или маршрутизатор, который принимает внешний HTTPS-трафик и передает его внутреннему серверу 1С по обычному протоколу HTTP, возникает путаница. Платформа 1С «не знает», что пользователь на самом деле работает через HTTPS, и формирует ссылку на moxel.css, используя протокол http://. Браузер, видя это несоответствие, блокирует загрузку стилей, и отчет остается невидимым.

Решение 1: Настройка заголовков на прокси-сервере (Nginx)

Если в качестве точки входа в вашу сеть используется Nginx, выполняющий роль обратного прокси (Reverse Proxy), то это наиболее правильный и «чистый» способ решения. Нам необходимо явно сообщить веб-серверу 1С, что исходный запрос от пользователя пришел по защищенному протоколу.

Рассмотрим, какие изменения нужно внести в конфигурационный файл Nginx. В секцию location, которая отвечает за проксирование запросов к 1С, добавим передачу заголовка X-Forwarded-Proto. Проанализируем пример настройки:


server {
    listen 443 ssl;
    server_name 1c.yourcompany.com;

    ssl_certificate /etc/ssl/certs/your_cert.crt;
    ssl_certificate_key /etc/ssl/private/your_key.key;

    location /your_base_name/ {
        proxy_pass http://internal_server_ip/your_base_name/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # Самая важная строка для решения проблемы moxel.css:
        proxy_set_header X-Forwarded-Proto https;
    }
}

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

Решение 2: Настройка IIS и модуля Application Request Routing (ARR)

Если ваша база опубликована на Microsoft IIS и он находится за другим прокси-сервером, стандартных настроек может быть недостаточно, так как IIS не всегда автоматически обрабатывает заголовок X-Forwarded-Proto. Разберем шаги по настройке:

  1. Установим расширение Application Request Routing (ARR) для IIS, если оно еще не установлено.
  2. В консоли управления IIS выберем сервер и перейдем в раздел URL Rewrite.
  3. Создадим правило, которое будет проверять наличие заголовка HTTP_X_FORWARDED_PROTO со значением https.
  4. Если такой заголовок найден, правило должно принудительно устанавливать переменную сервера HTTPS в значение on.

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

Решение 3: Изменение портов и прямой проброс (Альтернативный метод)

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

Пошагово это выглядит следующим образом:

  1. В консоли управления IIS перейдем в настройки Default Web Site (или того сайта, где опубликована база).
  2. Нажмем Изменить привязки... (Bindings) и сменим порт с 80 на любой другой свободный, например 7777.
  3. Перезапустим веб-сайт.
  4. На сетевом роутере (шлюзе) настроим проброс портов (Port Forwarding), перенаправляя внешний порт (например, тот же 7777 или стандартный 443, если используется SSL-терминация на стороне IIS) на внутренний IP сервера 1С и порт 7777.

Важный нюанс: при такой схеме локальным пользователям внутри сети также придется обращаться к базе с указанием нового порта в адресе, например http://1c-server:7777/base.

Решение 4: Принудительное использование HSTS

Проанализируем еще один способ «лечения» Mixed Content на стороне браузера. Если мы добавим в ответ сервера заголовок HSTS (HTTP Strict Transport Security), браузер получит инструкцию всегда обращаться к данному домену только по HTTPS.

В этом случае, даже если 1С попытается отдать ссылку на http://yourdomain.com/.../moxel.css, браузер сам «на лету» заменит http на https еще до того, как запрос уйдет в сеть. Это позволяет обойти блокировку безопасности, так как фактически незащищенного соединения не произойдет.

Дополнительные факторы: Права доступа и кэширование

Выясним, что еще может мешать корректному отображению moxel.css, если настройки протоколов верны:

Подведем итог: в большинстве случаев проблема решается именно на уровне прокси-сервера добавлением заголовка X-Forwarded-Proto https. Это стандарт де-факто для работы современных веб-приложений за балансировщиками нагрузки. Выбрав один из предложенных вариантов, мы обеспечим стабильную и безопасную работу пользователей с отчетами 1С через любой современный браузер.

← На главную