Рассмотрим распространенную ситуацию, когда в соответствии с политиками безопасности компании прямая публикация веб-сервера 1С в общую корпоративную сеть запрещена. Вместо этого доступ организуется через обратный прокси-сервер (reverse proxy), например, Nginx, Apache или IIS. При такой схеме внешние пользователи обращаются к базе по защищенному адресу прокси-сервера, который затем перенаправляет запросы на внутренний веб-сервер 1С.
При некорректной настройке подобной связки администраторы часто сталкиваются с двумя критическими проблемами:
В этой статье мы подробно разберем причины возникновения этих неполадок и пошагово настроим систему для их устранения.
Проанализируем механизм маршрутизации запросов при использовании прокси-сервера. Предположим, что база данных 1С опубликована на внутреннем веб-сервере по адресу http://127.0.0.1/do/, а внешний адрес на прокси-сервере выглядит как https://doc.xxxxx.ru/.
Когда прокси-сервер настроен так, что внешний корневой путь / перенаправляет запросы на внутренний путь с именем базы /do/, возникает конфликт, называемый double path mapping (двойное сопоставление путей):
https://doc.xxxxx.ru/. Прокси-сервер корректно транслирует этот запрос во внутренний адрес http://127.0.0.1/do/.default.vrd и считывают из него реальное имя публикации базы — do.https://doc.xxxxx.ru/do/ru_RU/..../do/, он автоматически прибавляет входящий путь к адресу назначения. В результате на внутренний веб-сервер уходит некорректный дублированный запрос: http://127.0.0.1/do/do/ru_RU/..../do/do/ и закономерно возвращает ошибку 404 Not Found.Аналогичная проблема возникает при переходе по навигационным ссылкам из писем: веб-клиент пытается обработать хэш-часть URL, отправляет запросы с именем публикации и натыкается на дублирование путей.
Рассмотрим подробнее три практических метода настройки прокси-сервера (на примере Nginx) для устранения дублирования путей.
Самый надежный и простой способ — сделать так, чтобы внешние и внутренние пути публикации полностью совпадали. То есть пользователи из сети должны обращаться к базе по адресу https://doc.xxxxx.ru/do/. В этом случае трансляция путей происходит «один в один», без подмены корня.
Настроим блок конфигурации Nginx следующим образом:
server {
listen 443 ssl;
server_name doc.xxxxx.ru;
ssl_certificate /etc/nginx/ssl/doc.xxxxx.ru.crt;
ssl_certificate_key /etc/nginx/ssl/doc.xxxxx.ru.key;
location /do/ {
proxy_pass http://127.0.0.1/do/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Если по требованиям бизнеса база должна открываться строго по корневому адресу https://doc.xxxxx.ru/ без каких-либо суффиксов в URL, нам необходимо переопубликовать базу 1С на внутреннем веб-сервере (IIS или Apache) непосредственно в корень сайта (чтобы локальный путь был http://127.0.0.1/, а не http://127.0.0.1/do/).
В таком случае конфигурационный файл Nginx будет предельно простым и безопасным:
location / {
proxy_pass http://127.0.0.1/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
Если изменить настройки внутренней публикации на IIS/Apache невозможно (например, там опубликовано несколько разных баз 1С), а внешнюю ссылку нужно сохранить в корневом формате, мы можем заставить Nginx обрабатывать оба типа запросов — и корневые, и содержащие суффикс базы:
# Первичный вход пользователя по корневому адресу
location / {
proxy_pass http://127.0.0.1/do/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# Обработка последующих запросов веб-клиента с явным указанием "/do/"
location /do/ {
proxy_pass http://127.0.0.1/do/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
При такой конфигурации первый переход пользователя по ссылке https://doc.xxxxx.ru/ перенаправит его на внутреннюю базу, а последующие служебные AJAX-запросы веб-клиента, содержащие в пути /do/, будут перехвачены вторым блоком location и корректно отправлены на бэкенд без повторного добавления префикса.
После решения проблемы с маршрутизацией путей разберем причины медленной работы веб-клиента через прокси-сервер. Интерактивный интерфейс 1С критичен к задержкам сети и требует быстрой обработки множества мелких запросов.
Выполним оптимизацию прокси-сервера по четырем направлениям:
Современная платформа 1С использует протокол WebSockets для мгновенной передачи уведомлений и асинхронных вызовов. Если прокси-сервер не настроен на проброс веб-сокетов, 1С принудительно переключается на ресурсоемкую технологию Long-Polling (постоянные тяжелые HTTP-запросы). Это перегружает веб-сервер и вызывает видимые задержки отрисовки форм.
Добавим заголовки обновления соединения в конфигурационный файл Nginx:
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
По умолчанию Nginx пытается накопить ответ бэкенда в буфере перед отправкой конечному пользователю. Для тяжелых интерактивных интерфейсов 1С это создает задержку ввода. Отключим буферизацию для обеспечения мгновенного отклика:
proxy_buffering off;
Веб-клиент 1С при инициализации загружает сотни мелких картинок, стилей и JS-скриптов. В устаревшем протоколе HTTP/1.1 загрузка идет последовательно, что сильно замедляет старт системы. Протокол HTTP/2 поддерживает мультиплексирование (параллельную загрузку файлов по одному TCP-соединению).
Активируем поддержку HTTP/2 в директиве listen конфигурации сервера:
listen 443 ssl http2;
Сжатие тяжелых текстовых файлов (особенно библиотек JavaScript платформы 1С) позволяет сократить объем передаваемого трафика в несколько раз. Добавим глобальные настройки сжатия в конфигурацию:
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
gzip_comp_level 5;
Чтобы система формировала корректные навигационные ссылки для писем и внешних уведомлений, необходимо явно указать параметры публикации в самой базе данных 1С.
Разберем эти действия по шагам:
https://doc.xxxxx.ru/do/ при Варианте 1 или https://doc.xxxxx.ru/ при Варианте 2).http://127.0.0.1/do/).После выполнения этих настроек все ссылки на задачи, документы и бизнес-процессы, генерируемые программой для отправки по электронной почте, будут формироваться на основе правильного внешнего адреса, а запросы пользователей будут проходить через прокси-сервер без ошибок маршрутизации и задержек производительности.