В практике системного администрирования 1С часто возникает задача создания единой точки входа для пользователей. Представим ситуацию: у вас есть основной веб-сервер (назовем его SERVER), который должен принимать все запросы, и несколько рабочих серверов (SERVER_01, SERVER_02), на которых фактически развернуты базы данных и службы 1С. Основная сложность заключается в том, что при попытке использовать стандартные средства перенаправления Apache, браузер работает корректно, а тонкий клиент 1С выдает ошибку подключения. В этой статье мы подробно разберем, почему так происходит, и как правильно настроить конфигурацию для стабильной работы.
Первое, с чем сталкиваются администраторы, — это попытка использовать директивы Redirect permanent или RedirectMatch. На первый взгляд это логично: запрос на http://SERVER/db01 должен перенаправляться на http://SERVER_01/db01. Однако здесь кроется фундаментальная особенность платформы «1С:Предприятие».
Проанализируем поведение компонентов. Браузер при получении ответа с кодом 301 (Moved Permanently) или 302 (Found) автоматически выполняет новый запрос по указанному адресу. Тонкий клиент 1С работает иначе. Он использует сложный протокол обмена данными поверх HTTP, включая передачу больших объемов данных в POST-запросах. При получении редиректа тонкий клиент зачастую теряет контекст авторизации или тело POST-запроса, что приводит к ошибке: «Попытка начала сеанса с информационной базой завершилась неудачно». Таким образом, мы приходим к выводу: для тонкого клиента использование редиректов недопустимо.
Чтобы пользователь мог обращаться по единому адресу и попадать в нужную базу, нам необходимо настроить SERVER не как «указатель», а как «посредник». В терминологии веб-серверов это называется обратным проксированием (Reverse Proxy). В этом случае сервер SERVER сам запрашивает данные у SERVER_01 и передает их клиенту, при этом для самого тонкого клиента всё выглядит так, будто он работает напрямую с главным сервером.
Для реализации этого механизма в Apache нам потребуются модули mod_proxy и mod_proxy_http. Рассмотрим пошагово процесс настройки на главном сервере.
Убедимся, что необходимые модули включены. В дистрибутивах Linux это обычно делается командой a2enmod, а в Windows — раскомментированием строк в файле httpd.conf.
Разберем список необходимых модулей:
mod_proxy — основной модуль проксирования.mod_proxy_http — поддержка протокола HTTP для прокси.mod_proxy_wstunnel — критически важен для версий 1С 8.3.18 и выше, так как они используют WebSockets.mod_headers — для корректной передачи заголовков.Теперь отредактируем файл настроек Apache (httpd.conf или файл виртуального хоста). Вместо директив Redirect мы будем использовать ProxyPass и ProxyPassReverse. Проанализируем пример конфигурации:
# Включаем механизм проксирования
ProxyRequests Off
ProxyPreserveHost On
# Настройка для первой базы на SERVER_01
ProxyPass "/db01" "http://SERVER_01/db01"
ProxyPassReverse "/db01" "http://SERVER_01/db01"
# Настройка для второй базы на SERVER_02
ProxyPass "/db02" "http://SERVER_02/db02"
ProxyPassReverse "/db02" "http://SERVER_02/db02"
Рассмотрим подробнее значение этих директив:
Host на целевой сервер. Это очень важно для 1С, чтобы внутренние ссылки в базе формировались корректно./db01) соответствует какому удаленному адресу.Если ваш главный сервер работает по защищенному протоколу HTTPS, а внутренние серверы — по HTTP, необходимо добавить директиву SSLProxyEngine on. Рассмотрим пример для защищенного соединения:
<VirtualHost *:443>
ServerName mainserver.ru
SSLEngine On
SSLProxyEngine On
# Проксирование запросов к базе 1С
ProxyPass "/base_accounting" "http://192.168.1.10/base_accounting"
ProxyPassReverse "/base_accounting" "http://192.168.1.10/base_accounting"
# Рекомендуется увеличить таймауты для тяжелых отчетов
ProxyTimeout 600
</VirtualHost>
При использовании такой схемы весь трафик неизбежно проходит через SERVER. Чтобы минимизировать нагрузку и обеспечить стабильность, обратим внимание на следующие моменты:
1. Поддержка WebSockets. Современные версии 1С активно используют пуш-уведомления. Если в логах 1С вы видите ошибки соединения с WebSockets, добавьте проксирование для протокола ws://. Порядок следования директив важен: специфичные правила должны идти перед общими.
ProxyPass "/db01/e1cib/ws" "ws://SERVER_01/db01/e1cib/ws"
ProxyPass "/db01" "http://SERVER_01/db01"
2. Таймауты. Стандартные настройки Apache могут обрывать соединение через 60 секунд. Для 1С это часто оказывается недостаточно (например, при формировании долгого отчета или закрытии месяца). Используйте параметр timeout=600 прямо в строке ProxyPass.
3. Использование VPN. Поскольку в вашей задаче серверы находятся в разных сетях (через Интернет), крайне рекомендуется объединить их в общую сеть через VPN-туннель. Это позволит главному серверу обращаться к серверам БД по внутренним IP-адресам, что значительно повысит безопасность и исключит необходимость открывать порты Apache на рабочих серверах для всего интернета.
Многие специалисты находят настройку проксирования в Nginx более простой и производительной. Если у вас есть возможность выбрать ПО для SERVER, рассмотрим пример конфигурации для Nginx:
location /db01/ {
proxy_pass http://SERVER_01/db01/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Этот вариант "из коробки" лучше справляется с WebSockets и имеет более наглядный синтаксис для передачи заголовков реального IP-адреса клиента, что может быть полезно для журналов регистрации 1С.
Мы выяснили, что тонкий клиент 1С не поддерживает HTTP-редиректы. Единственным надежным способом маршрутизации запросов через промежуточный веб-сервер является использование механизма Reverse Proxy. Настроив ProxyPass в Apache или аналогичные правила в Nginx, вы получите единую точку входа для всех пользователей, сохранив при этом прозрачность работы платформы и возможность гибко распределять базы по разным серверам.