Веб-сервер для 1С: установка, настройка и публикация базы

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

Что такое веб-сервер для 1С и как устроен веб-доступ

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

Цепочка получается такая:

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

Веб-доступ даёт три вещи: работу в браузере без установки клиента (веб-клиент), публикацию Web-сервисов SOAP и публикацию HTTP-сервисов для интеграции с сайтом, CRM или мобильным приложением. Все три включаются галочками в одном окне публикации.

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

Apache или IIS: что выбрать под 1С

Платформа одинаково хорошо живёт на обоих. Выбор чаще определяется тем, что уже стоит в инфраструктуре, а не техническими преимуществами.

Если сервер 1С уже работает на Windows Server в домене - берите IIS, доменная авторизация избавит пользователей от второго пароля. Если база живёт на Linux или вы просто не хотите тащить лишние роли Windows - Apache.

Отдельный вопрос - nginx. Модуля расширения для него в поставке платформы нет, напрямую с 1С он не работает. Его ставят фронтом: nginx принимает внешние соединения, терминирует HTTPS и проксирует запросы на Apache или IIS с публикацией. Схема рабочая и распространённая, но веб-сервером для 1С в ней остаётся всё тот же Apache или IIS. Сравнение самих движков - в статье Apache против nginx.

Установка веб-сервера Apache

Первая ловушка ждёт ещё на скачивании. На httpd.apache.org готовых сборок под Windows нет - фонд Apache выкладывает только исходники. Бинарники собирают сторонние проекты, из них для Windows обычно берут Apache Lounge или ApacheHaus.

Вторая ловушка - разрядность. Она должна совпадать с разрядностью платформы 1С. 64-битная платформа с 32-битным Apache не подружится, публикация оборвётся с сообщением о несовпадении разрядности.

Порядок установки под Windows:

1. Скачать сборку Apache 2.4 нужной разрядности и распаковать, например в C:\Apache24.
2. В conf\httpd.conf проверить ServerRoot и Listen - путь к каталогу и порт (80 по умолчанию).
3. Зарегистрировать службу из командной строки, запущенной от администратора: C:\Apache24\bin\httpd.exe -k install.
4. Запустить: httpd.exe -k start.
5. Открыть http://localhost и убедиться, что страница отдаётся.

Общая установка Apache без привязки к 1С разобрана подробнее в статье как установить веб-сервер Apache - здесь только то, что касается платформы.

Установка интернет-сервера IIS для 1С

IIS ставится ролью Windows Server, но со стандартным набором компонентов 1С не заработает. Нужны расширения ISAPI - именно через них платформа встраивается в веб-сервер.

В мастере добавления ролей отметьте:

• Веб-сервер (IIS) → Разработка приложений → Расширения ISAPI и Фильтры ISAPI;
• Веб-сервер (IIS) → Безопасность → Обычная проверка подлинности, если планируете авторизацию средствами 1С, и Проверка подлинности Windows, если нужен вход по доменной учётке.

CGI отмечать не нужно - платформа его не использует.

После установки откройте диспетчер IIS и проверьте, что сайт по умолчанию отвечает на http://localhost. Дальше настройка идёт уже из конфигуратора 1С, а не из консоли IIS: публикация сама создаст виртуальный каталог и пропишет обработчик.

Модуль расширения веб-сервера 1С: какой файл к какому серверу

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

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

Разрядность - вторая половина той же проблемы. 64-битный модуль требует 64-битного веб-сервера, 32-битный - 32-битного. Смешивать нельзя.

Публикация базы 1С на сервере IIS

Публикация делается из конфигуратора, а не из консоли веб-сервера. Конфигуратор запускайте от имени администратора - иначе он не сможет записать настройки в каталоги IIS.

1. Откройте конфигуратор нужной базы от администратора.
2. Меню Администрирование → Публикация на веб-сервере.
3. В поле Имя укажите имя виртуального каталога - по нему база будет доступна: http://сервер/имя. Латиницей, без пробелов.
4. В поле Веб-сервер выберите Internet Information Services.
5. Поле Каталог обычно подставляется само (C:\inetpub\wwwroot\имя). Каталог должен существовать - если его нет, создайте заранее.
6. Оставьте включённой галочку Публиковать доступ для клиентских приложений. Web-сервисы и HTTP-сервисы включайте только если они действительно нужны: лишние точки входа - лишняя поверхность атаки.
7. Нажмите Опубликовать и согласитесь на перезапуск веб-сервера.

В каталоге публикации после этого появятся два файла: default.vrd с настройками публикации и web.config с настройками IIS. Если их нет - публикация не прошла, что бы ни сказало окно.

Как настроить веб-сервер IIS для 1С

Публикация создаёт приложение в IIS, но два параметра почти всегда приходится поправить руками.

Разрядность пула приложений. Откройте диспетчер IIS → Пулы приложений → пул вашего приложения → Дополнительные параметры. Параметр «Разрешены 32-разрядные приложения» должен стоять в False для 64-битной платформы и в True для 32-битной. Несовпадение даёт HTTP 500 без внятных подробностей.

Права на каталоги. Учётные записи IUSR и группа IIS_IUSRS должны иметь права «Чтение и выполнение» на каталог публикации. Для файловой базы им дополнительно нужны права «Изменение» на каталог самой базы - иначе платформа не сможет писать в неё блокировки и журнал.

Отдельная учётная запись под пул - хорошая практика, если баз несколько и вы хотите развести их права. Тогда права на каталоги выдаются ей, а не общей IIS_IUSRS.

Публикация базы на сервере Apache

Порядок тот же, но с одним отличием, на котором спотыкаются почти все.

В окне публикации выберите веб-сервер Apache 2.4. Поле Каталог для Apache не подставляется автоматически, как для IIS: его надо заполнить самому и создать заранее. Пустой каталог, например C:\Apache24\htdocs\buh или /var/www/buh на Linux. Пока каталога нет, конфигуратор ругается на незаполненные параметры публикации - это самая частая причина той самой ошибки.

Дальше конфигуратор сам допишет в httpd.conf блок с LoadModule и Alias на каталог публикации. Проверить можно глазами: в конце файла появится секция с путём к вашей базе.

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

На Linux добавляется вопрос прав: пользователь, от которого работает Apache (apache, www-data - зависит от дистрибутива), должен иметь доступ на чтение к каталогу платформы и на запись к каталогу файловой базы.

На Windows служба Apache по умолчанию работает от системной учётной записи, и для локальных каталогов прав обычно хватает. А вот если файловая база лежит на сетевой шаре, системная учётка до неё не дотянется - службе придётся задать доменную учётную запись с правами на эту папку.

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

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

Пример для Apache 2.4 на Linux:

./webinst -publish -apache24 -wsdir buh -dir /var/www/buh \
  -connstr "Srvr=srv1c;Ref=buh;" -confPath /etc/httpd/conf/httpd.conf

Что означают ключи:

Строка соединения для файловой базы выглядит иначе: File="C:\bases\buh";. Кавычки внутри параметра нужно экранировать по правилам вашей командной оболочки - это отдельный источник вечерних развлечений.

Файл default.vrd: что внутри и когда править руками

default.vrd - обычный XML-файл в каталоге публикации. Именно он определяет, что и как опубликовано. Конфигуратор пишет его сам, но иногда быстрее открыть блокнотом.

Что там лежит:

• base - имя публикации, то, что стоит в URL после адреса сервера;
• ib - строка соединения с информационной базой;
• элементы ws и httpServices - опубликованные Web- и HTTP-сервисы;
• debug - настройки отладки;
• параметры пула соединений с сервером 1С.

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

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

Через какие порты работает веб-доступ к 1С

Вопрос всплывает, как только веб-сервер и сервер 1С разъезжаются по разным машинам.

Браузеру порты 1541 и 1560-1591 не нужны - он общается только с веб-сервером. Открывать их наружу не надо ни при каких обстоятельствах: это внутренний канал между веб-сервером и кластером 1С.

Если веб-сервер и сервер 1С стоят на одной машине, открывать в брандмауэре нужно только 80 и 443.

Публикация 1С на Apache SSL в локальной среде разработки

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

Генерация ключа и сертификата через OpenSSL:

openssl req -x509 -newkey rsa:2048 -nodes -days 365 \
  -keyout localhost.key -out localhost.crt -subj "/CN=localhost"

Дальше в httpd.conf включается модуль mod_ssl, а в виртуальный хост на 443 порту добавляются пути к файлам:

SSLEngine on
SSLCertificateFile "conf/ssl/localhost.crt"
SSLCertificateKeyFile "conf/ssl/localhost.key"

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

Один нюанс: если в разработке участвует сервер взаимодействия или внешние сервисы, самоподписанный сертификат они могут не принять. Тогда либо добавляйте корневой сертификат в доверенные на всех участвующих машинах, либо поднимайте нормальный домен и обычный сертификат.

Создание сертификата Let's Encrypt

Для боевой публикации нужен сертификат от публичного центра. Let's Encrypt выдаёт их бесплатно и автоматически - при условии, что у вас есть доменное имя и сервер доступен снаружи.

На Linux с Apache процесс сводится к одной команде certbot:

certbot --apache -d 1c.example.ru

Certbot сам подтвердит владение доменом, получит сертификат, пропишет пути в конфиг и настроит автопродление через таймер systemd. На Windows с IIS ту же работу делает win-acme.

Со сроками в 2026 году стоит разобраться отдельно, потому что они меняются. Сертификаты по умолчанию по-прежнему живут 90 дней, продлевать их положено примерно за месяц до конца. С января 2026 года Let's Encrypt открыл для всех шестидневные сертификаты - профиль shortlived в ACME-клиенте. А с 10 февраля 2027 года срок по умолчанию сократится до 64 дней.

Конвертация SSL-сертификатов

Проблема возникает при переезде между Apache и IIS: они хранят сертификаты в разных форматах. Apache работает с текстовыми PEM-файлами, IIS - с бинарным PFX (он же PKCS#12), в котором сертификат и закрытый ключ лежат вместе.

Из PEM в PFX для IIS:

openssl pkcs12 -export -out cert.pfx \
  -inkey private.key -in cert.crt -certfile chain.crt

Обратно, из PFX в PEM для Apache:

openssl pkcs12 -in cert.pfx -nocerts -nodes -out private.key
openssl pkcs12 -in cert.pfx -clcerts -nokeys -out cert.crt

Про промежуточные сертификаты забывают чаще всего. Без цепочки (chain.crt) браузер на компьютере админа покажет зелёный замок, а мобильный клиент или внешняя система - ошибку доверия. Проверять надо не своим браузером, а сторонним онлайн-чекером SSL.

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

Перенаправление HTTP на HTTPS для веб-сервера IIS

Отдельного пункта «редирект на HTTPS» в консоли IIS нет - это устойчивый миф. Делают одним из двух способов.

Через модуль URL Rewrite (ставится отдельно, это рекомендуемый вариант) - правило в web.config вашего приложения:

Через Перенаправление HTTP - компонент роли IIS, но он умеет только перенаправлять весь сайт целиком, без условий. Для сайта с одной публикацией 1С этого хватает, для сайта с несколькими приложениями - уже нет.

На Apache то же самое делается тремя строками в виртуальном хосте на 80 порту:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

После включения редиректа проверьте тонкие клиенты и внешние интеграции. Если где-то в настройках прописан адрес с http://, редирект их не сломает, но добавит лишний хоп - адреса лучше поправить сразу.

Настройка возможности отладки HTTP-сервисов

Отладка через опубликованную базу нужна, когда HTTP-сервис ведёт себя не так, как в конфигураторе. Механизм отладки по протоколу HTTP появился в платформе 8.3.8 и живёт до сих пор - он работает через обычный HTTP-порт и потому проходит там, где отладка по TCP упирается в закрытые порты и VPN.

Включается в двух местах.

В файле default.vrd публикации появляется элемент с адресом сервера отладки:

В конфигураторе - Сервис → Параметры → вкладка Отладка: выбрать протокол HTTP и указать тот же адрес сервера отладки. Порт по умолчанию - 1550.

Сервер отладки - это процесс dbgs, он слушает порт 1550. На сервере 1С отладка включается ключом -debug при запуске службы.

Логирование HTTP-запросов ведёт сам веб-сервер: у Apache это access.log и error.log, у IIS - файлы в C:\inetpub\logs\LogFiles. Когда сервис возвращает 500, начинать надо с них, а не с кода обработчика.

Установка локального сервера взаимодействия

Сервер взаимодействия - отдельный продукт, а не часть платформы. На нём держатся «Обсуждения» в типовых конфигурациях: чаты, упоминания, обмен файлами между пользователями. К публикации базы на веб-сервере отношения не имеет, но развёртывают их обычно рядом, отсюда и путаница.

Дистрибутив забирают с сайта релизов 1С и ставят программой 1ce-installer.exe от администратора. В комплект входит сам сервер взаимодействия, распределённое хранилище Hazelcast для сессий и очередей и поисковый кластер Elasticsearch для полнотекстового поиска и подбора пользователей. Ресурсов эта связка ест заметно больше, чем можно подумать по словам «локальная установка».

Настройка идёт утилитой ring из командной строки с правами администратора: ей задают параметры пакетов, адреса и учётные записи.

С SSL для сервера взаимодействия работает своя схема, не такая, как у Apache и IIS. Сертификат и ключ объединяют в один файл PKCS#12, из него генерируют хранилище JKS и перезапускают службу cs_instance. Сертификат берут либо готовый, либо от Let's Encrypt через certbot - разницы для сервера взаимодействия нет.

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

Настройка IIS для разных версий платформы 1С

Ситуация обычная: бухгалтерия сидит на одной версии платформы, а зарплатная база требует другую. Обе надо опубликовать на одном IIS.

Работает это так. Каждая публикация ссылается на свой модуль расширения - конкретный wsisapi.dll из каталога конкретной версии платформы. Пути прописываются в web.config каждого приложения по отдельности, поэтому две базы на разных версиях мирно живут на одном сервере.

Что развести обязательно:

• Пулы приложений. Отдельный пул на каждую версию платформы. Общий пул - это гарантированные конфликты при перезапуске и трудноуловимые падения.
• Разрядность. Если версии разной разрядности, разделение по пулам становится обязательным - параметр «Разрешены 32-разрядные приложения» задаётся именно на уровне пула.

Публиковать каждую базу нужно из конфигуратора её версии. Опубликуете базу конфигуратором чужой версии - в web.config пропишется чужой путь к модулю, и приложение не поднимется.

Типовые ошибки публикации: симптом, причина, что делать

Первое, куда смотреть при любой из этих ошибок, - логи веб-сервера. error.log у Apache и журнал IIS почти всегда называют причину прямым текстом, и это быстрее, чем гадать по симптому.

Какой сервер нужен под веб-доступ к 1С

Сам веб-сервер ресурсов почти не ест - он передаёт запросы дальше и отдаёт готовые страницы. Нагрузка ложится на сервер 1С и СУБД, и растёт она от количества сеансов, а не от того, что вы включили веб-доступ.

Тут надо разобраться с ходовым мифом: будто веб-клиент перекладывает всю работу на сервер. Клиентский код платформа транслирует в JavaScript, и браузер исполняет его у себя - примерно так же, как это делал бы тонкий клиент. Профиль нагрузки на сервер 1С меняется не радикально.

Отличия всё же есть, и они в другом. Браузер медленнее нативного клиента на тяжёлых формах и объёмных отчётах. Трафика между браузером и веб-сервером ходит больше, и веб-клиент чувствительнее к задержкам канала, чем к его ширине. Плюс добавляется сам процесс веб-сервера с пулом соединений к кластеру - немного памяти он всё-таки займёт.

Разносить ли веб-сервер и сервер 1С по разным машинам - вопрос не производительности, а безопасности. Для внутренней сети без внешнего доступа держать всё на одной машине нормально, и большинство небольших компаний так и делает. Отдельная машина под веб-сервер нужна, когда база публикуется наружу: тогда веб-сервер выносят в демилитаризованную зону, а сервер 1С и СУБД остаются во внутреннем сегменте, и между ними открыты только порты кластера.

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

Частые вопросы

Что такое веб-сервер в 1С простыми словами?

Это Apache или IIS с модулем расширения платформы. Он принимает запрос браузера, передаёт его серверу 1С и возвращает пользователю готовую страницу. Без него база в браузере не откроется.

Нужен ли PHP для веб-сервера 1С?

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

Можно ли опубликовать файловую базу?

Да. В строке соединения указывается путь к каталогу базы вместо имени сервера 1С. Учётной записи веб-сервера нужны права на запись в этот каталог.

Как опубликовать базу 1С на веб-сервере Apache?

Создать пустой каталог публикации, открыть конфигуратор от администратора, зайти в «Администрирование» → «Публикация на веб-сервере», выбрать Apache 2.4, указать имя и путь к каталогу, нажать «Опубликовать» и перезапустить веб-сервер.

Чем отличается веб-клиент от тонкого?

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

Сколько баз можно опубликовать на одном веб-сервере?

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

Обязателен ли HTTPS?

Для доступа из интернета - да, без вариантов. Внутри локальной сети без выхода наружу можно обойтись HTTP, но если через веб-доступ ходят кадровые или финансовые данные, шифрование лучше включить и там.