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

Веб-сервер 1С — это связующее звено между пользователями и информационной базой: именно через него работают веб-клиент, тонкий клиент по HTTP, мобильные приложения и веб-сервисы. Если база «не открывается в браузере», причина почти всегда находится в одном из четырёх мест: сам веб-сервер (IIS или Apache) не запущен, публикация 1С настроена неверно, нет связи с сервером 1С или СУБД, либо не хватает прав у служебной учётной записи.

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

Ниже описаны действия для двух типовых конфигураций: Windows с IIS и Linux/Windows с Apache. Команды приведены для стандартных установок; если публикация выполнялась вручную или на нестандартный порт, подставляйте свои значения.

Что именно проверяем: компоненты цепочки подключения

При обращении к базе через веб-сервер запрос проходит путь: браузер (или тонкий клиент) → веб-сервер → модуль расширения 1С (wsisapi.dll для IIS или mod_1cws для Apache) → кластер серверов 1С → СУБД. Сбой на любом участке выглядит для пользователя одинаково — «страница недоступна» или ошибка соединения, — но причины разные.

Поэтому перед диагностикой полезно зафиксировать симптом: ошибку HTTP (404, 500, 503), таймаут без ответа, сообщение 1С «Ошибка соединения с сервером» или бесконечную загрузку. Каждый симптом указывает на свой участок цепочки.

Шаг 1. Проверяем, что служба веб-сервера запущена

Для IIS откройте консоль «Диспетчер служб IIS» (inetmgr) и убедитесь, что узел с публикацией находится в состоянии «Запущен», а соответствующий пул приложений — тоже запущен. Дополнительно проверьте службу Windows «Служба веб-публикаций» (W3SVC):

Get-Service W3SVC, WAS | Format-Table Name, Status
Get-IISSite | Format-Table Name, State, Bindings

Для Apache на Windows проверьте службу (обычно Apache2.4), на Linux — состояние через systemctl:

systemctl status apache2    # Debian/Ubuntu
systemctl status httpd      # RHEL/CentOS

Если служба остановлена, попробуйте запустить её и сразу посмотрите лог ошибок: у Apache это error.log, у IIS — журнал событий Windows (раздел «Система» и «Приложение»). Частая причина падения Apache при старте — синтаксическая ошибка в httpd.conf после ручного редактирования; проверить конфигурацию можно командой httpd -t или apachectl configtest.

Шаг 2. Проверяем доступность публикации из браузера

Откройте браузер на самом сервере и перейдите по адресу вида http://localhost/ИмяПубликации. Если публикация открывается локально, но не открывается с других компьютеров — проблема в сети: брандмауэр, DNS-имя сервера или привязка сайта к конкретному интерфейсу.

Если не открывается даже локально, проверьте URL внимательно. Имя публикации чувствительно к регистру на Apache под Linux, а лишний или пропущенный слэш в конце адреса иногда приводит к 404. Точное имя смотрите в настройках виртуального каталога IIS или в директиве публикации в конфигурации Apache.

1. 1
   Откройте http://localhost/ИмяПубликации на самом сервере
2. 2
   Затем тот же адрес по IP сервера с другой машины в сети
3. 3
   Затем по DNS-имени сервера
4. 4
   Сравните результат: локально работает, по сети нет — проверяйте брандмауэр и привязки
5. 5
   Не работает нигде — проверяйте публикацию и модуль расширения 1С

Шаг 3. Проверяем порт и брандмауэр

Убедитесь, что веб-сервер реально слушает нужный порт (по умолчанию 80 для HTTP и 443 для HTTPS):

netstat -ano | findstr :80      # Windows
ss -tlnp | grep :80             # Linux

Если порт слушается, но с других машин недоступен, проверьте правила брандмауэра. В Windows нужно входящее правило для порта 80/443 (при публикации через мастер 1С оно не создаётся автоматически). На Linux проверьте firewalld или ufw. Также убедитесь, что порт не занят другим приложением — например, Skype или другой веб-сервер могут занять 80-й порт раньше.

Шаг 4. Проверяем настройки публикации и права

Публикация создаётся конфигуратором («Администрирование → Публикация на веб-сервере») или утилитой webinst. Основные точки отказа:

• Разрядность модуля. Для 64-разрядного IIS нужен 64-разрядный wsisapi.dll и отключённый параметр пула «Enable 32-bit applications». Несовпадение разрядности даёт ошибку 500.
• Права на каталоги. Учётная запись пула приложений (IIS) или службы Apache должна иметь чтение к каталогу публикации и к каталогу установки 1С.
• Файл default.vrd. В нём указано имя базы и строка подключения к кластеру. Если сервер 1С переехал или сменилось имя базы, публикация нужно обновить (перепубликовать).
• Обработчики ISAPI. В IIS модуль wsisapi.dll должен быть разрешён в списке ограничений ISAPI/CGI и сопоставлен расширению публикации.

Шаг 5. Проверяем связь веб-сервера с кластером 1С и логи

Если веб-сервер отвечает, но 1С сообщает об ошибке соединения, проверьте, что агент сервера 1С запущен (служба «Агент сервера 1С:Предприятия») и доступен с машины веб-сервера по портам кластера (по умолчанию 1540–1541, рабочие процессы 1560–1591). Если веб-сервер и сервер 1С на разных машинах, проверьте имя сервера в default.vrd и сетевую доступность.

Источники диагностической информации:

• Логи IIS: C:\inetpub\logs\LogFiles — коды состояния HTTP по каждому запросу.
• Логи Apache: access.log и error.log в каталоге logs.
• Журнал событий Windows: ошибки пула приложений и модулей.
• Журнал регистрации 1С: ошибки сеансов и соединений на стороне кластера.
• Технологический журнал 1С: включается через logcfg.xml, показывает детали обращений к кластеру.

Типичные ошибки и ограничения самостоятельной диагностики

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

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

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