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

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

Определить веб-сервер можно несколькими независимыми способами: по конфигурационным файлам публикации, по работающим процессам и службам, по HTTP-заголовкам ответа и по административным консолям. Надёжнее всего комбинировать минимум два метода, потому что на одном сервере могут одновременно стоять и Apache, и IIS, при этом активна только одна публикация.

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

Где 1С хранит информацию о веб-сервере и публикации

При публикации базы через конфигуратор (Администрирование → Публикация на веб-сервере) 1С создаёт файл default.vrd в каталоге публикации. Этот файл описывает параметры подключения к информационной базе, но сам по себе не указывает тип веб-сервера — он общий для Apache и IIS. Однако его расположение подсказывает, какой веб-сервер настроен.

Для Apache каталог публикации обычно прописан в конфигурации виртуального хоста (файлы httpd.conf, apache2.conf или отдельные файлы в sites-enabled). Для IIS каталог привязан к виртуальному каталогу или приложению в консоли диспетчера служб IIS. Найдя, какой из веб-серверов ссылается на каталог с default.vrd, вы однозначно определяете обслуживающий сервер.

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

Способ 1. Проверка по HTTP-заголовкам ответа

Самый быстрый способ, не требующий доступа к серверу, — посмотреть заголовок Server в HTTP-ответе. Для этого достаточно выполнить запрос к адресу публикации, например http://server/base, и изучить служебные заголовки. Apache обычно отвечает строкой вида Server: Apache/2.4.x, IIS — Server: Microsoft-IIS/10.0.

Посмотреть заголовки можно в браузере: откройте инструменты разработчика (клавиша F12), перейдите на вкладку Network, обновите страницу и выберите первый запрос — в разделе Response Headers будет нужная строка. Альтернатива — команда из терминала.

curl -I http://server/base

Учтите ограничение метода: заголовок Server можно отключить или изменить в настройках безопасности, а если перед веб-сервером стоит прокси (nginx, балансировщик), вы увидите заголовок прокси, а не реального сервера публикации. Поэтому этот способ — первый шаг, а не окончательный вердикт.

Способ 2. Определение по процессам и службам

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

Проверка на Windows

Откройте диспетчер задач или выполните в командной строке tasklist | findstr /i "httpd w3wp". Процесс httpd.exe означает Apache, процессы w3wp.exe — рабочие процессы IIS. Дополнительно проверьте службы: служба W3SVC (Служба веб-публикаций) указывает на IIS, служба с именем вида Apache2.4 — на Apache, установленный как служба Windows.

Проверка на Linux

Выполните systemctl list-units --type=service | grep -Ei "apache|httpd|nginx" или ps aux | grep -E "apache|httpd". Активный юнит apache2 (Debian/Ubuntu) или httpd (CentOS/RHEL) подтверждает Apache. Заодно проверьте, какой процесс слушает порт 80 или 443: ss -tlnp | grep -E ":80|:443" — в выводе будет имя процесса-владельца порта.

1. 1
   Откройте терминал или диспетчер задач на сервере публикации
2. 2
   Найдите процессы httpd, apache2 или w3wp
3. 3
   Проверьте, какой процесс занимает порты 80 и 443
4. 4
   Сопоставьте найденный процесс с каталогом публикации 1С
5. 5
   Откройте конфигурацию найденного веб-сервера и убедитесь, что в ней указан каталог с default.vrd

Способ 3. Проверка конфигурации Apache и IIS

Если процессы найдены, следующий шаг — убедиться, что именно этот веб-сервер обслуживает публикацию 1С, а не просто установлен на машине. Для Apache откройте основной конфигурационный файл и поищите директивы, добавляемые публикацией 1С: загрузку модуля wsap24.dll (или mod_1c на Linux) и блок <Directory> с путём к каталогу публикации. Утилита публикации webinst от 1С прописывает эти строки автоматически.

Для IIS откройте Диспетчер служб IIS (inetmgr), разверните дерево сайтов и найдите приложение или виртуальный каталог с именем вашей базы. В его свойствах будет физический путь к каталогу с default.vrd, а в сопоставлениях обработчиков — обработчик ISAPI или модуль 1С. Наличие такого приложения — прямое доказательство, что публикация обслуживается IIS.

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

Способ 4. Косвенные признаки и журналы

Когда прямой доступ к серверу ограничен, помогают косвенные признаки. Страница ошибки веб-сервера различается: IIS показывает характерные страницы с кодами ошибок и оформлением Microsoft, Apache — минималистичное сообщение с подписью сервера внизу. Вызовите заведомо несуществующий адрес внутри публикации и посмотрите на оформление ошибки 404.

Журналы доступа тоже различаются по расположению: Apache пишет access.log и error.log в каталоге logs своей установки или в /var/log/apache2 (либо /var/log/httpd), IIS — в C:\inetpub\logs\LogFiles с подкаталогами по идентификаторам сайтов. Формат строк и имена полей в этих журналах разные, что позволяет определить сервер даже по одному фрагменту лога.

Ещё один признак — расширения обработчиков в адресах: для IIS в конфигурации публикации нередко фигурируют настройки пулов приложений, а в журналах событий Windows источники с именами, связанными с IIS. Для Apache на Windows ошибки модуля 1С попадают в error.log Apache.

Что делать, если перед 1С стоит прокси

В крупных установках публикацию 1С часто прячут за nginx или другим обратным прокси: прокси принимает запросы на 443 порт, терминирует TLS и передаёт трафик внутреннему Apache или IIS. В этом случае заголовок Server покажет nginx, а реальный сервер публикации останется скрытым.

Чтобы докопаться до истины, изучите конфигурацию прокси: директива proxy_pass в nginx укажет внутренний адрес и порт бэкенда. Затем перейдите на сервер бэкенда и определите веб-сервер там по процессам и конфигурации, как описано выше. Дополнительно помогут заголовки X-Forwarded-For и Via, которые прокси добавляет к запросам.

Типичные ошибки и ограничения

Первая ошибка — судить о веб-сервере только по установленным программам. Apache может быть установлен «про запас» и не запущен, а фактическую публикацию обслуживает IIS, или наоборот. Всегда проверяйте именно активные процессы и занятые порты.

Вторая ошибка — доверять только заголовку Server. Его легко переопределить, а прокси подменяет его полностью. Третья — путать веб-сервер публикации с сервером 1С: агент сервера 1С (ragent, rphost) — это отдельная компонента клиент-серверной архитектуры, она не является веб-сервером и не заменяет Apache или IIS.

Ограничение самостоятельной диагностики: на продуктивном сервере не перезапускайте службы «для проверки» — это оборвёт сессии пользователей. Все описанные методы пассивны и безопасны: просмотр процессов, заголовков, конфигураций и журналов ничего не нарушает. Любые изменения конфигурации делайте только с резервной копией файлов.

Итог

Определить веб-сервер 1С несложно, если действовать последовательно: начать с заголовка Server в HTTP-ответе, подтвердить результат по процессам и портам на сервере, затем закрепить вывод проверкой конфигурации Apache или IIS и пути к default.vrd. При наличии прокси сначала находят бэкенд через конфигурацию прокси, а уже потом определяют реальный веб-сервер публикации.

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