Публикация базы 1С через IIS, Apache и Nginx: от ролей Windows до HTTPS

Чтобы настроить веб-сервер для 1С, нужны три вещи: сам веб-сервер (IIS на Windows или Apache на Linux), компонент платформы «Модули расширения веб-сервера» той же версии, что и сервер 1С, и публикация базы через Конфигуратор или утилиту webinst. Частое заблуждение — что базу можно опубликовать прямо в Nginx. Нельзя: модуль 1С работает только с IIS и Apache, а Nginx ставят перед ними как прокси для HTTPS и защиты.

Ниже пошагово для обеих систем — с командами, конфигами и ошибками, на которых обычно теряют полдня.

Какой веб-сервер выбрать для публикации 1С

Выбор почти всегда диктует операционная система сервера, а не вкус администратора.

Для внутренней сети на 10–30 пользователей хватает одного IIS или Apache без прокси. Если базу открывают из интернета, ставьте впереди Nginx: он держит сертификат, режет перебор паролей и не пускает к модулю 1С мусорный трафик.

Что подготовить на сервере до установки

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

Ориентировочные ресурсы под сам веб-сервер:

• 🖥️ до 20 одновременных пользователей — 2 ядра и 4 ГБ памяти поверх того, что нужно серверу 1С;
• 🖥️ 20–100 пользователей — 4 ядра и 8 ГБ;
• 🌐 сеть до сервера 1С — локальная, с минимальной задержкой: каждый клик веб-клиента превращается в запрос к кластеру.

Перед установкой проверьте список:

1. Знаете точную версию платформы на сервере 1С (видно в консоли кластера или в свойствах службы агента).
2. Есть дистрибутив платформы этой же версии и нужной разрядности.
3. Определились с адресом публикации: имя каталога (buh, zup) и домен, если нужен HTTPS.
4. Между веб-сервером и кластером открыты порты агента 1540, менеджера кластера 1541 и диапазон рабочих процессов (по умолчанию 1560–1591).
5. Для клиент-серверной базы знаете строку подключения: имя сервера 1С и имя базы в кластере.

Настройка IIS для 1С на Windows Server

Установка ролей IIS

В «Диспетчере серверов» добавьте роль «Веб-сервер (IIS)». В разделе разработки приложений отметьте «Расширения ISAPI» и «Фильтры ISAPI» — без них публикация откроется с ошибкой 404 или 500.

То же самое одной командой PowerShell от администратора:

Install-WindowsFeature Web-Server, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Mgmt-Console

Установка модулей расширения веб-сервера

Запустите установщик платформы и на шаге выбора компонентов включите «Модули расширения веб-сервера». Если платформа уже стоит, запустите установщик повторно и добавьте компонент через «Изменить».

Разрядность имеет значение. Поставили 32-битную платформу — в IIS придётся включать 32-битные приложения для пула. Проще сразу ставить 64-битную платформу на 64-битный Windows Server.

Публикация базы из Конфигуратора

1. Запустите 1С от имени администратора (правой кнопкой по ярлыку). Без этого Конфигуратор не сможет записать файлы в C:\inetpub\wwwroot и изменить настройки IIS.
2. Откройте базу в режиме Конфигуратора.
3. Выберите Администрирование → Публикация на веб-сервере.
4. Укажите имя (оно же часть адреса, например buh), веб-сервер Internet Information Services и каталог C:\inetpub\wwwroot\buh.
5. Оставьте отмеченным только то, чем будете пользоваться: тонкий и веб-клиент, OData, веб-сервисы, HTTP-сервисы.
6. Нажмите «Опубликовать». Конфигуратор предложит перезапустить IIS — соглашайтесь, если на сервере нет других рабочих сайтов в этот момент.

Проверка: откройте в браузере http://имя-сервера/buh. Должно появиться окно входа веб-клиента.

Публикация из командной строки

Когда баз много или публикацию нужно повторять после каждого обновления платформы, удобнее утилита webinst из каталога bin платформы. Запускайте командную строку от администратора:

"C:\Program Files\1cv8\8.3.24.1586\bin\webinst.exe" -publish -iis -wsdir buh -dir "C:\inetpub\wwwroot\buh" -connstr "Srvr=srv1c;Ref=buh;"

Результат тот же, что у Конфигуратора: каталог с default.vrd и web.config, обработчик в IIS. Такую команду удобно положить в bat-файл рядом с инструкцией по обновлению — тогда после смены версии платформы публикация восстанавливается за минуту, а не вспоминается по памяти.

Права и пул приложений

Учётной записи пула (группа IIS_IUSRS) нужны права «Чтение и выполнение» на каталог публикации и на каталог платформы C:\Program Files\1cv8\<версия>\bin. Для файловой базы добавьте права на изменение каталога с файлом 1Cv8.1CD.

Отдельно поправьте пул приложений, в котором работает публикация:

• ⏱️ «Время простоя» по умолчанию 20 минут — пул засыпает, первый вход утром долгий. Поставьте 0.
• 🔄 Плановая переработка каждые 1740 минут рвёт сеансы веб-клиента посреди дня. Замените интервал на конкретное время ночью.
• 🧩 «Разрешить 32-разрядные приложения» — True только для 32-битной платформы.

Веб-сервер 1С на Linux: Apache и Nginx перед ним

Установка Apache и компонента ws

На Ubuntu или Debian:

sudo apt install apache2

Начиная с платформы 8.3.20 под Linux используется единый установщик. Компонент веб-сервера в нём называется ws:

sudo ./setup-full-8.3.24.1586-x86_64.run --mode unattended --enable-components server,ws

Файлы ложатся в /opt/1cv8/x86_64/<версия>/, там же лежат модуль wsap24.so и утилита webinst.

Публикация через webinst

sudo mkdir -p /var/www/buh
sudo /opt/1cv8/x86_64/8.3.24.1586/webinst -publish -apache24 \
  -wsdir buh -dir /var/www/buh \
  -connstr "Srvr=srv1c;Ref=buh;" \
  -confpath /etc/apache2/apache2.conf
sudo systemctl restart apache2

Утилита создаёт в каталоге файл default.vrd и дописывает в конфиг Apache блок примерно такого вида:

LoadModule _1cws_module "/opt/1cv8/x86_64/8.3.24.1586/wsap24.so"

Alias "/buh" "/var/www/buh/"
<Directory "/var/www/buh/">
    AllowOverride All
    Options None
    Require all granted
    SetHandler 1c-application
    ManagedApplicationDescriptor "/var/www/buh/default.vrd"
</Directory>

Если что-то пошло не так, первым делом смотрите журнал ошибок Apache: sudo tail -n 50 /var/log/apache2/error.log. Сообщение о невозможности загрузить модуль означает неверный путь в LoadModule, отказ в доступе — права пользователя www-data на каталог публикации.

Nginx как прокси перед Apache

Переведите Apache на внутренний порт. В /etc/apache2/ports.conf замените Listen 80 на Listen 127.0.0.1:8080, в описании сайта по умолчанию — <VirtualHost *:80> на <VirtualHost 127.0.0.1:8080>.

Конфиг Nginx для домена:

server {
    listen 443 ssl http2;
    server_name 1c.example.ru;

    ssl_certificate     /etc/letsencrypt/live/1c.example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/1c.example.ru/privkey.pem;

    client_max_body_size 200m;

    location /buh/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 600s;
    }
}

client_max_body_size нужен, чтобы пользователи могли прикреплять файлы крупнее 1 МБ (это ограничение Nginx по умолчанию). Увеличенный proxy_read_timeout спасает долгие операции — закрытие месяца или тяжёлый отчёт — от обрыва по таймауту.

HTTPS для веб-клиента и тонкого клиента

По обычному HTTP пароль пользователя 1С идёт открытым текстом. Для доступа из интернета HTTPS обязателен.

На Linux с Nginx сертификат Let’s Encrypt выпускает certbot:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d 1c.example.ru

Certbot сам пропишет пути к сертификату и настроит автопродление.

На Windows с IIS сертификат удобно получать утилитой win-acme. Если сертификат уже есть в формате .pfx, импортируйте его в IIS и добавьте сайту привязку https на порт 443.

Как подключаться после настройки:

• 🌍 веб-клиент — https://1c.example.ru/buh в браузере;
• 💻 тонкий клиент — добавьте базу через «Добавить → Добавление в список существующей информационной базы», тип расположения «На веб-сервере», адрес тот же.

Перенаправление с HTTP на HTTPS в Nginx:

server {
    listen 80;
    server_name 1c.example.ru;
    return 301 https://$host$request_uri;
}

Оптимизация производительности веб-сервера 1С

Узкое место почти никогда не сам веб-сервер. Тормозят сеть до кластера, память рабочих процессов и сам способ работы пользователей.

Что даёт реальный эффект:

1. Тонкий клиент вместо веб-клиента для тех, кто работает в базе весь день. Тонкий клиент кеширует формы у себя, браузер грузит больше при каждом открытии.
2. Сжатие статики. В IIS включите статическое сжатие, в Nginx — gzip on для типов text/css и application/javascript. Первый вход веб-клиента станет заметно быстрее на медленных каналах.
3. Веб-сервер рядом с кластером. Задержка между ними важнее ширины канала до пользователя.
4. Пул OData под интеграции. Если базу опрашивают внешние системы, ограничьте пул сеансов в default.vrd, чтобы интеграция не съедала ресурсы кластера.

Пример блока в default.vrd с отключённым по умолчанию HTTP-сервисом и пулом OData:

<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/buh"
       ib="Srvr=&quot;srv1c&quot;;Ref=&quot;buh&quot;;">
    <standardOdata enable="true" reuseSessions="autouse"
                   sessionMaxAge="20" poolSize="10" poolTimeout="5"/>
    <httpServices publishByDefault="false"/>
</point>

После правки default.vrd перезапустите веб-сервер или пул приложений — в нерабочее время, сеансы веб-клиента прервутся.

Безопасность: как закрыть веб-доступ к базе 1С

Публикация в интернет — это открытая дверь в учёт. Минимальный набор мер:

• 🔑 Никаких логинов в строке подключения. Параметры Usr= и Pwd= в default.vrd пускают в базу любого, кто знает адрес. Их добавляют «для удобства» — и забывают.
• 👤 Пароли у всех пользователей 1С. Пользователь без пароля в опубликованной базе — готовая уязвимость. Проверьте список в Администрирование → Настройки пользователей и прав.
• 🚪 Наружу — только 443. Порты кластера 1540, 1541, 1560–1591 из интернета закрыты.
• ✂️ Лишние публикации выключены. Не пользуетесь OData и веб-сервисами — снимите флажки при публикации.
• 🧱 Ограничение по адресам. Если сотрудники работают из известных офисов, в Nginx оставьте только их: allow 203.0.113.10; deny all;. Для удалённых сотрудников надёжнее VPN, чем публикация на весь интернет.

Против перебора паролей в Nginx помогает ограничение частоты запросов:

limit_req_zone $binary_remote_addr zone=onec:10m rate=10r/s;

location /buh/ {
    limit_req zone=onec burst=40 nodelay;
    proxy_pass http://127.0.0.1:8080;
}

Значения подберите по нагрузке: веб-клиент при работе шлёт много мелких запросов, слишком жёсткий лимит ударит по обычным пользователям.

Ошибки при настройке веб-сервера для 1С

Большинство проблем после публикации укладывается в несколько сценариев.

Частые вопросы о веб-сервере для 1С