Как исправить ошибку «Ошибка работы с Интернет: не могу установить соединение» при REST/OData запросах в 1С?

← На главную

Приветствуем вас, коллеги! При интеграции 1С с внешними системами или использовании механизма OData разработчики часто сталкиваются с крайне странной ситуацией — для её диагностики есть инструмент логирования и анализа HTTP-запросов для 1С. Веб-сервис успешно опубликован на сервере IIS или Apache. Если ввести адрес в строку браузера на любом компьютере, он мгновенно запрашивает логин/пароль и корректно возвращает структуру XML или JSON. Однако при попытке выполнить тот же самый запрос программно из кода 1С с помощью объекта HTTPСоединение система выдает критическую ошибку: «Ошибка работы с Интернет: не могу установить соединение».

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

Типичный сценарий возникновения ошибки

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


СерверИсточник = "192.168.1.100"; // IP-адрес сервера публикации
Порт = 8080; // Четырехзначный порт веб-сервера
Попытка
    HTTPСоединение = Новый HTTPСоединение(СерверИсточник, Порт, "Администратор", "Пароль123");
Исключение
    ЗаписьЖурналаРегистрации("ИнтеграцияREST", УровеньЖурналаРегистрации.Ошибка,,, ОписаниеОшибки());
    Возврат;
КонецПопытки;

ТекстЗапроса = "/base_test/odata/standard.odata/AccountingRegister_Хозрасчетный/Balance?$top=1";
HTTPЗапрос = Новый HTTPЗапрос(ТекстЗапроса);

Попытка
    // Именно на этой строке происходит аварийное завершение работы
    HTTPОтвет = HTTPСоединение.Получить(HTTPЗапрос); 
    ТекстРезультата = HTTPОтвет.ПолучитьТелоКакСтроку();
Исключение
    ВызватьИсключение "Не удалось получить данные: " + ОписаниеОшибки();
КонецПопытки;

Данный код абсолютно верен с точки зрения синтаксиса 1С. Тем не менее, вызов методов Получить или ВызватьHTTPМетод приводит к сетевому сбою. Выясним основные технические причины, почему браузер «видит» публикацию, а код 1С — нет. Для интерактивного тестирования таких запросов без написания кода можно использовать консоль HTTP-запросов для управляемых форм.

Причина 1: Блокировка обратных запросов Loopback (LSA Loopback Check)

Если сервер 1С:Предприятие (или файловая база, запущенная в режиме толстого/тонкого клиента) и веб-сервер IIS находятся на одном и том же физическом или виртуальном компьютере, операционная система Windows по умолчанию блокирует сетевые запросы программы к самой себе, если они направлены на внешний IP-адрес или доменное имя (FQDN).

Это встроенная политика безопасности операционных систем Windows (начиная с Windows Server 2003 SP1), предназначенная для предотвращения атак отражения (reflection attacks). Браузер при этом может успешно обходить ограничение за счет использования локального кэша или запуска в контексте интерактивного пользователя, тогда как низкоуровневые вызовы платформы 1С блокируются ОС.

Решение проблемы:

На сервере IIS необходимо отключить проверку Loopback через системный реестр Windows:

Откройте редактор реестра regedit от имени Администратора.
Перейдите к ветке реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
Создайте новый параметр типа DWORD (32 бита).
Присвойте ему имя DisableLoopbackCheck.
Установите значение параметра равным 1.
Перезагрузите сервер или перезапустите службу IIS для вступления изменений в силу.

Причина 2: Контекст исполнения и права учетной записи службы 1С

Когда вы запускаете обработку на клиенте, запрос выполняется от имени текущего авторизованного пользователя Windows. Но если код выполняется на стороне сервера (например, в общем модуле с флагом «Сервер», в модуле менеджера или в фоновом задании), запрос отправляется от имени системной учетной записи, под которой запущена служба ragent (обычно это локальный пользователь USR1Cv8 или NetworkService).

У данной учетной записи часто отсутствуют необходимые сетевые привилегии:

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

Для явного обхода прокси-сервера в коде 1С мы можем использовать объект ИнтернетПрокси:


Прокси = Новый ИнтернетПрокси(Ложь); // Полное отключение использования прокси для данного соединения
HTTPСоединение = Новый HTTPСоединение(СерверИсточник, Порт, "Пользователь", "Пароль", Прокси);

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


<config xmlns="http://v8.1c.ru/v8/inetcfg">
    <proxy auto="true" bypassonlocal="true">
        <bypassaddr>192.168.*</bypassaddr>
        <bypassaddr>127.0.0.1</bypassaddr>
    </proxy>
</config>

Причина 3: Строгая проверка SSL-сертификатов (при использовании HTTPS)

Если ваша публикация OData работает по защищенному протоколу HTTPS, платформа 1С осуществляет жесткую проверку безопасности. В отличие от браузеров, которые при обнаружении самоподписанного (self-signed) или просроченного SSL-сертификата выводят предупреждение и позволяют продолжить работу («Перейти на сайт небезопасно»), платформа 1С при малейшем несоответствии мгновенно разрывает сетевой сокет.

Пошаговое решение для диагностики:

Для проверки того, виновен ли SSL-сертификат в ошибке соединения, временно отключите его валидацию, инициализировав защищенное соединение без проверок:


// Отключаем проверку подлинности и цепочки сертификатов
НепроверяемаяЗащита = Новый ЗащищенноеСоединениеOpenSSL(Неопределено, Неопределено);
HTTPСоединение = Новый HTTPСоединение(СерверИсточник, Порт, "Пользователь", "Пароль",,, НепроверяемаяЗащита);

Если с использованием этого кода запрос прошел успешно, значит, проблема действительно в сертификате. Для постоянного и безопасного решения вам потребуется импортировать SSL-сертификат веб-сервера в локальное хранилище доверенных корневых сертификатов Windows на машине, где запущен сервер 1С (под учетной записью службы 1С).

Причина 4: Блокировки брандмауэра и антивирусного ПО

Сетевые экраны (брандмауэр Windows, Kaspersky Endpoint Security и др.) часто настраиваются по правилам доверенных приложений. Доступ к определенным портам может быть разрешен системным процессам браузеров (Chrome, Edge), но заблокирован для сторонних исполняемых файлов.

В зависимости от режима работы 1С, исходящий запрос отправляют разные процессы:

При запуске в толстом или тонком клиенте на компьютере пользователя — процесс 1cv8.exe.
При выполнении на сервере (в фоновом или регламентном задании) — рабочий процесс сервера 1С rphost.exe.

Проанализируйте настройки брандмауэра на сервере 1С и добавьте процессы rphost.exe и 1cv8.exe в список исключений для исходящих TCP-соединений на целевой порт вашего веб-сервера.

Причина 5: Некорректные привязки (Bindings) сайта в IIS

В диспетчере служб IIS для каждого веб-сайта настраиваются привязки (Bindings). Если сайт привязан строго к определенному доменному имени (Host Header, например, odata.company.local), веб-сервер будет ожидать этот заголовок в HTTP-пакете.

Если в браузере вы вводили доменное имя, а в коде 1С в переменную СерверИсточник передали чистый IP-адрес (например, 192.168.1.100), веб-сервер IIS сразу же сбросит такое подключение как несоответствующее правилам маршрутизации сайтов.

Решение: Всегда указывайте в качестве сервера источника в коде 1С именно то доменное имя, которое прописано в привязках IIS:


СерверИсточник = "odata.company.local"; // Вместо IP-адреса
HTTPСоединение = Новый HTTPСоединение(СерверИсточник, Порт, "Логин", "Пароль");

Как найти точную причину с помощью расширенных журналов?

Если вышеописанные методы не помогли локализовать проблему, рассмотрим, как активировать расширенное логирование и увидеть детальные системные ошибки, скрывающиеся за неинформативным сообщением 1С.

1. Настройка Технологического журнала 1С (ТЖ)

ТЖ позволяет зафиксировать низкоуровневые ошибки сетевых сокетов операционной системы. Создайте файл конфигурации ТЖ logcfg.xml в каталоге C:\Program Files\1cv8\conf\ следующего содержания:


<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\v8_logs\network" history="12">
        <event>
            <eq property="Name" value="CONN"/>
        </event>
        <event>
            <eq property="Name" value="EXCP"/>
        </event>
        <property name="all"/>
    </log>
</config>

Запустите процесс обмена снова. В созданных логах в папке C:\v8_logs\network найдите события CONN и EXCP. Там отобразится точный системный код ошибки сокета, например:

WSAECONNREFUSED (10061) — подключение отклонено (порт закрыт, служба IIS не запущена или заблокирована брандмауэром).
WSAETIMEDOUT (10060) — превышено время ожидания ответа (проблема с маршрутизацией или прокси).

2. Анализ лог-файлов IIS

Проанализируем файлы логов веб-сервера IIS, которые по умолчанию располагаются по пути: C:\inetpub\logs\LogFiles\W3SVC....

Попробуйте воспроизвести ошибку из 1С и проверьте, появилась ли новая запись в логе IIS с IP-адреса машины 1С. Если записи нет, это со 100% вероятностью означает, что сетевой пакет от 1С физически не доходит до IIS (блокировка на уровне сети, брандмауэра или DNS).

Резюме

Мы подробно разобрали все скрытые технические нюансы работы платформы 1С с HTTP-соединениями. Последовательно проверяя настройки брандмауэра, контекст прав учетной записи USR1Cv8, отключая проверку Loopback Check в реестре Windows и контролируя валидность SSL-сертификатов, вы легко сможете решить проблему «Ошибка работы с Интернет» и настроить стабильный обмен данными.