При разработке и внедрении интеграционных решений в платформе 1С программисты часто сталкиваются с ситуацией, когда разработанный механизм отправки HTTP-запросов отлично функционирует на тестовом компьютере, но полностью отказывается работать на сервере заказчика. Особенно загадочно выглядит проблема, когда при обращении к одному и тому же локальному веб-серверу (например, по адресу 192.1.2.125:80) через браузер Internet Explorer ответ возвращается мгновенно, а при попытке отправить запрос из 1С система сразу же выдает ошибку "Ошибка работы с интернет - Could not connect server".
В этой статье мы подробно разберем, почему возникает такое различие в поведении программ, детально проанализируем сетевые механизмы операционной системы Windows и платформы 1С, выясним причину мгновенного падения запроса без ожидания таймаута и составим пошаговый план решения этой проблемы совместно с системным администратором.
Рассмотрим классическую ситуацию. Нам необходимо отправить простой GET-запрос на локальный веб-сервер. При тестировании в браузере Internet Explorer (IE) все проходит успешно. Однако при попытке выполнить запрос из кода 1С или с помощью альтернативных браузеров (например, Google Chrome или Chrome Portable) мы получаем моментальный сброс соединения. При этом важной деталью является то, что ошибка в 1С генерируется мгновенно, полностью игнорируя установленный в коде таймаут (например, 20 секунд).
Если бы удаленный сервер был просто выключен или недоступен на физическом уровне, операционная система честно пыталась бы установить TCP-соединение на протяжении всего таймаута, отправляя повторные SYN-пакеты. Мгновенный же отказ свидетельствует о том, что программа получает активный запрет (пакет TCP RST или ICMP Destination Unreachable) либо на самом локальном компьютере, либо от ближайшего сетевого шлюза (прокси-сервера).
Для понимания природы проблемы разберем по шагам, как именно операционная система Windows осуществляет отправку сетевых запросов для разных приложений:
192.1.2.125 напрямую в обход корпоративного прокси-сервера.192.1.2.125 через этот прокси-сервер, который, в свою очередь, блокирует или некорректно маршрутизирует этот трафик.Когда запрос от 1С (через WinHTTP) уходит на корпоративный прокси-сервер, тот видит попытку обращения к внутреннему адресу локальной сети (диапазон RFC 1918, к которому относится подсеть 192.1.x.x). Из соображений безопасности на современных прокси-серверах и межсетевых экранах жестко настраивается защита от угроз класса SSRF (Server-Side Request Forgery).
Прокси-сервер мгновенно отклоняет попытку перенаправить запрос внутрь локальной сети и сразу же возвращает клиенту пакет сброса соединения (TCP RST) или ошибку авторизации/доступа. Для клиентского приложения (в данном случае 1С) это выглядит как моментальное прерывание связи без ожидания таймаута.
В крупных компаниях системные администраторы часто настраивают политики безопасности на рабочих станциях и серверах с помощью систем класса Endpoint Security (например, Kaspersky, ESET, Symantec) или встроенного брандмауэра Windows Defender. В таких политиках может быть жестко прописано правило:
«Разрешить исходящую сетевую активность по портам 80 и 443 только для одобренного списка веб-браузеров (iexplore.exe, chrome.exe)».
Когда процесс 1С (1cv8.exe, 1cv8c.exe или серверный процесс rphost.exe) пытается открыть сокет на 80-м порту, локальная система безопасности мгновенно блокирует создание сетевого подключения на уровне ядра ОС. Программа сразу получает системную ошибку доступа (например, код ошибки сокета WSAEACCES), что приводит к мгновенной генерации исключения в коде 1С.
Именно этим объясняется и поведение Chrome Portable в нашей ситуации: будучи запущенным из временного каталога без полноценной установки в систему, он не попал в список доверенных приложений брандмауэра и разделил участь 1С.
Для того чтобы успешно решить проблему, нам необходимо выполнить диагностику совместно с системным администратором заказчика. Проанализируем ключевые шаги по устранению неполадок.
Поскольку настройки прокси-сервера для WinHTTP живут отдельно от Internet Explorer, нам необходимо явно указать операционной системе, как работать с локальными адресами. Для этого попросим системного администратора открыть командную строку с правами администратора на сервере, где выполняется код 1С, и выполнить следующие действия:
1. Проверить текущие настройки прокси-сервера для службы WinHTTP с помощью команды:
netsh winhttp show proxy
2. Если в выводе команды указан прокси-сервер, но отсутствует список обхода (bypass-list) для локальной сети, необходимо перенастроить прокси, добавив исключение для нужной подсети:
netsh winhttp set proxy proxy-server="имя_прокси:порт" bypass-list="*.local;192.1.2.*"
3. Также можно импортировать уже настроенные рабочие параметры из Internet Explorer, где исключение локальных адресов уже работает:
netsh winhttp import proxy source=ie
Если настройка WinHTTP не принесла результатов, необходимо проверить локальные блокировки программной среды. Попросите администратора безопасности временно отключить сетевой экран антивирусного ПО на сервере 1С для проверки гипотезы.
Если соединение после этого успешно устанавливается, необходимо внести исполняемые файлы 1С в список доверенных программ, которым разрешена любая сетевая активность по любым портам. В зависимости от режима работы конфигурации (файловый или клиент-серверный) и контекста выполнения кода, правила нужно создать для следующих файлов:
1cv8.exe — для толстого клиента 1С.1cv8c.exe — для тонкого клиента 1С.rphost.exe — для кода, выполняющегося на сервере приложений 1С (в клиент-серверном варианте работы).Мы также можем повлиять на поведение платформы 1С непосредственно из кода нашей обработки или конфигурации. Если мы точно знаем, что запрос к локальному IP-адресу должен идти напрямую, минуя любые системные настройки прокси, мы можем явно инициализировать пустой объект ИнтернетПрокси в параметрах HTTP-соединения.
Рассмотрим подробнее, как правильно написать отказоустойчивый код для создания HTTP-соединения в 1С:
// Создаем объект пустого прокси-сервера, чтобы принудительно отключить обход через системный прокси
ПроксиБезОбхода = Новый ИнтернетПрокси(Ложь);
// Указываем параметры подключения к локальному серверу
СерверАдрес = "192.1.2.125";
ПортПодключения = 80;
ТаймаутСоединения = 20; // Время ожидания в секундах
Попытка
// Создаем HTTP-соединение, явно передавая пустой прокси-сервер
Соединение = Новый HTTPСоединение(
СерверАдрес,
ПортПодключения,
, // Имя пользователя (если нет авторизации)
, // Пароль (если нет авторизации)
ПроксиБезОбхода,
ТаймаутСоединения
);
// Формируем HTTP-запрос
Запрос = Новый HTTPЗапрос("/api/v1/getdata");
// Отправляем запрос и получаем ответ
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
ВызватьИсключение "Успешно! Ответ сервера: " + Ответ.ПолучитьТелоКакСтроку();
Иначе
ВызватьИсключение "Сервер вернул ошибку с кодом: " + Ответ.КодСостояния;
КонецЕсли;
Исключение
// Обработка критических ошибок подключения
ЗаписьЖурналаРегистрации(
"Интеграция.ОшибкаПодключения",
УровеньЖурналаРегистрации.Ошибка,
,
,
ПодробноеПредставлениеОшибки(ИнформацияОбОшибке())
);
ВызватьИсключение "Не удалось выполнить запрос: " + КраткоеПредставлениеОшибки(ИнформацияОбОшибке());
КонецПопытки;
Использование конструкции Новый ИнтернетПрокси(Ложь) принудительно заставляет платформу 1С игнорировать любые прокси-серверы, настроенные в операционной системе Windows, и устанавливать прямое TCP-соединение с указанным IP-адресом. Это убережет ваше решение от некорректно настроенного системного окружения на стороне заказчика.
Мгновенная ошибка подключения к локальному серверу из 1С при стабильно работающем Internet Explorer — это классический маркер инфраструктурных ограничений. Понимая разницу между сетевыми интерфейсами WinINet и WinHTTP, а также используя методы принудительного отключения прокси-серверов в коде 1С, вы сможете быстро локализовать проблему, составить грамотное техническое задание для системных администраторов и обеспечить стабильную работу интеграционных механизмов в любых локальных сетях.