Работа 1С через веб-сервер (по протоколам HTTP/HTTPS) является стандартом для территориально распределенных точек. Однако иногда системные администраторы сталкиваются с проблемой: на одной или нескольких точках тонкий клиент начинает «намертво» зависать, в то время как на других объектах всё работает стабильно. Рассмотрим причины такого поведения и разберем пошагово методы диагностики и решения проблемы, основываясь на практике эксплуатации систем 1С.
Проанализируем типичный сценарий: на конкретном рабочем месте 1С зависает либо при запуске, либо в процессе выполнения операций. При этом, если переключить компьютер на резервный канал связи (например, через 3G/4G модем), проблема исчезает, хотя скорость соединения формально ниже. Это прямо указывает на то, что причина кроется не в производительности сервера 1С и не в самой конфигурации, а в сетевом оборудовании или настройках провайдера на стороне клиента.
Для начала выясним причину с помощью базовых инструментов. Проверим стабильность соединения. Воспользуемся стандартной командой ping с увеличенным размером пакета и флагом запрета фрагментации. Это позволит понять, проходят ли через роутер и канал провайдера «тяжелые» пакеты, характерные для трафика 1С.
Одной из наиболее частых причин «необъяснимых» зависаний 1С является несоответствие размера MTU. Если веб-сервер отправляет большой объем данных (например, метаданные формы или результат тяжелого отчета), а роутер или оборудование провайдера не могут пропустить пакет такого размера без фрагментации, пакет может быть отброшен. В результате тонкий клиент бесконечно ждет ответа, что выглядит как зависание.
Разберем, как найти оптимальное значение MTU. Введем в командной строке (cmd):
ping [адрес_вашего_сервера] -f -l 1460
Если вы видите сообщение «Требуется фрагментация пакета», значит, значение слишком велико. Уменьшайте число 1460 с шагом 10-20 до тех пор, пока пакеты не начнут проходить. Найденное значение (например, 1420) необходимо прописать в настройках WAN-порта вашего роутера или в настройках сетевого адаптера Windows.
Посмотрим на ситуацию со стороны роутера. Часто сотрудники обслуживающих организаций (например, ЧОП при настройке тревожных кнопок или видеонаблюдения) вносят изменения в конфигурацию маршрутизатора. Рассмотрим критические параметры:
Иногда корень проблемы лежит во взаимодействии сетевой карты ПК и роутера. Современные адаптеры пытаются брать на себя часть функций по обработке пакетов, что не всегда корректно работает с трафиком веб-серверов. Выясним, какие настройки стоит изменить в свойствах сетевого адаптера (Диспетчер устройств -> Сетевые адаптеры -> Свойства -> Дополнительно):
Disabled.Disabled.Disabled).Это заставит центральный процессор обрабатывать пакеты классическим способом, что исключает ошибки микросхем сетевой карты при работе с сегментированным трафиком 1С.
Многие современные системы по умолчанию приоритезируют протокол IPv6. Если роутер или провайдер поддерживает его некорректно, каждое обращение 1С к серверу может сопровождаться длительным ожиданием таймаута IPv6 перед переключением на IPv4. Это воспринимается пользователем как периодические зависания на 15–30 секунд. Рекомендуется полностью отключить протокол IPv6 в свойствах сетевого подключения на проблемном компьютере.
Если диагностика на стороне клиента не дала стопроцентного результата, проанализируем настройки веб-сервера (Apache или IIS). Для стабильной работы тонкого клиента важно, чтобы сервер не закрывал соединение слишком быстро. В файле конфигурации Apache (httpd.conf) или через консоль управления IIS проверьте следующие параметры:
Это позволит тонкому клиенту поддерживать стабильный канал связи без постоянных переподключений.
В публикации базы 1С на веб-сервере используется файл default.vrd. В нем можно управлять сжатием данных. Иногда аппаратные шлюзы провайдеров некорректно обрабатывают сжатый Gzip-трафик. Рассмотрим пример настройки, отключающей сжатие для проверки стабильности:
<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="/YourBaseName"
ib="Srvr="ServerName";Ref="BaseName";">
<httpServices>
<service name="MyService" rootUrl="my" enable="false"/>
</httpServices>
<!-- Параметр сжатия может быть настроен здесь -->
</point>
Если после установки параметров, отключающих сжатие трафика на уровне веб-сервера, зависания прекратились, значит, проблема в DPI-системах провайдера или роутера, которые «спотыкаются» на анализе упакованных пакетов.
Если ни один из вышеперечисленных методов не помог, необходимо включить Технологический Журнал (ТЖ) на стороне клиента. Это позволит увидеть, на каком именно событии происходит остановка. Создайте файл logcfg.xml в папке conf установленной платформы со следующим содержимым:
<config xmlns="http://v8.1c.ru/8.0/logcfg">
<log location="C:\1C_Logs" history="24">
<event>
<eq property="Name" value="NETWORK"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="All"/>
</log>
</config>
Проанализируем полученные логи после очередного зависания. События NETWORK покажут задержки сетевых вызовов, а EXCP — возможные ошибки в работе платформы, связанные с обрывом связи.
Резюме: В большинстве случаев проблема решается либо заменой роутера на более производительную модель (не сегмента SOHO), либо корректной настройкой MTU и отключением функций сетевого ускорения (Offloading) в Windows. Помните, что 1С крайне чувствительна к потере даже одиночных пакетов в HTTP-сессии.