Прокси в 1С:Предприятии: системные настройки, HTTP-соединения и диагностика доступа

Сайты и API открываются в браузере, но 1С не может отправить отчёт, получить обновление или обратиться к внешнему сервису. В корпоративной сети с прокси-сервером это типичная ситуация: браузер использует настройки текущего пользователя, а запрос из 1С может выполняться на другом компьютере и от имени другой учётной записи.

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

Поэтому диагностику нужно начинать не с перебора параметров, а с определения точки выполнения запроса. Только после этого можно проверять DNS, доступность прокси, авторизацию, TLS-сертификаты и настройки ИнтернетПрокси.

В статье разберём, чем отличаются системный прокси, параметры платформы и прокси, явно переданный в HTTPСоединение, а также составим последовательный алгоритм проверки.

Как определить, откуда 1С выполняет HTTP-запрос

Первый вопрос при любой сетевой ошибке — не «какой прокси указан в Windows», а «какой процесс отправляет запрос».

Операция, запущенная пользователем в интерфейсе 1С, не обязательно выполняется на его компьютере. В клиент-серверной информационной базе часть кода работает на клиенте, а часть — на сервере 1С.

Толстый и тонкий клиент

Если процедура выполняется на клиенте, исходящее соединение устанавливает компьютер пользователя. В этом случае важны:

• DNS-настройки рабочего компьютера;
• локальный firewall;
• доступность корпоративного прокси из пользовательской сети;
• параметры прокси для текущего пользователя;
• доверенные корневые сертификаты в пользовательском или системном хранилище.

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

Ориентироваться нужно на директивы компиляции и фактическую архитектуру конфигурации:

• &НаКлиенте — код выполняется в клиентском приложении с учётом доступности конкретных объектов платформы;
• &НаСервере — код выполняет сервер 1С;
• &НаСервереБезКонтекста — запрос также выполняется на сервере, но без данных формы;
• фоновое или регламентное задание — работает в серверном контексте без пользовательского интерфейса.

Серверный код и фоновые задания

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

Серверный запрос использует:

• сетевые настройки сервера;
• DNS, доступный серверу;
• правила firewall между сервером и прокси;
• сертификаты, доступные процессу;
• настройки платформы;
• параметры, переданные в объект HTTPСоединение;
• права учётной записи, от имени которой работает служба или рабочий процесс.

Пользовательский прокси, сохранённый в браузере администратора, к этому процессу может не относиться.

Веб-клиент

При работе через веб-клиент нужно дополнительно разделять запросы браузера и серверные операции 1С. Загрузка интерфейса или обращение JavaScript к веб-ресурсу происходит в браузерном контексте. Прикладная процедура 1С может передать выполнение на сервер.

Поэтому формулировка «ошибка возникает в веб-клиенте» ещё не определяет источник соединения. Нужно установить, какая процедура создаёт запрос и где она выполняется.

Как зафиксировать контекст

Перед изменением настроек ответьте на пять вопросов:

1. Какая операция завершается ошибкой?
2. Какой адрес пытается открыть 1С?
3. Запрос создаёт платформа, типовая конфигурация, расширение или собственный код?
4. Процедура выполняется на клиенте, сервере или в фоновом задании?
5. На каком компьютере и от имени какой учётной записи работает этот процесс?

Какие уровни настройки прокси существуют

В одной инфраструктуре одновременно могут присутствовать несколько независимых уровней настройки. Они не всегда наследуют параметры друг друга.

Прокси браузера и текущего пользователя

Браузер может получать параметры из настроек Windows, групповых политик, PAC-файла или собственной конфигурации.

PAC-файл — сценарий автоматического выбора прокси в зависимости от адреса назначения. Он может направлять часть запросов через прокси, а часть — напрямую.

Если сайт открывается в браузере, это подтверждает только работоспособность браузерного маршрута для конкретного пользователя. Это не доказывает, что те же параметры доступны службе сервера 1С.

WinHTTP в Windows

В Windows существует отдельная конфигурация WinHTTP, которую используют некоторые службы и приложения. Посмотреть её можно командой:

netsh winhttp show proxy

Результат полезен для диагностики, но его нельзя автоматически считать настройкой платформы 1С. Наличие прокси в WinHTTP не гарантирует, что конкретный объект HTTPСоединение будет использовать его.

Также не следует без проверки импортировать пользовательские настройки браузера в WinHTTP. Такое изменение затрагивает системный уровень и может повлиять на другие службы.

Настройки платформы в inetcfg.xml

Платформа 1С может использовать файл inetcfg.xml, в котором задаются параметры интернет-доступа, включая прокси для разных протоколов.

Расположение файла и область его действия зависят от установленного компонента, операционной системы и версии платформы. Поэтому путь нужно проверять по руководству администратора именно для используемой версии 1С:Предприятия.

Перед изменением файла:

1. Найдите экземпляр inetcfg.xml, относящийся к нужному клиенту или серверному компоненту.
2. Сохраните резервную копию.
3. Проверьте синтаксис.
4. Зафиксируйте прежние значения.
5. Учитывайте необходимость перезапуска соответствующего процесса.
6. Сначала выполните проверку в тестовом контуре.

Наличие нескольких файлов inetcfg.xml на одном сервере может создавать путаницу: администратор меняет один экземпляр, а рабочий процесс читает другой.

Объект ИнтернетПрокси

Для управляемого программного подключения прокси можно задать непосредственно в коде. Объект ИнтернетПрокси хранит параметры прокси для поддерживаемых протоколов, включая HTTP и HTTPS.

Такой вариант делает маршрут запроса явным:

• разработчик указывает адрес и порт прокси;
• при необходимости передаёт данные авторизации;
• объект прокси передаётся в HTTPСоединение;
• соединение не зависит от случайных пользовательских настроек браузера.

При этом параметры нельзя бездумно хранить в модуле конфигурации. Логин и пароль должны загружаться из защищённого источника и не попадать в журнал регистрации, технологический журнал или текст исключения.

Автоматическое определение прокси

Поведение автоматического определения параметров менялось между версиями платформы и режимами совместимости. Оно также различается в Windows и Linux.

В актуальном поведении методы HTTPСоединение используют прокси, содержащийся в соответствующем свойстве соединения. На Linux объект ИнтернетПрокси, созданный с использованием прокси по умолчанию, при определённых условиях может получить параметры из inetcfg.xml или переменных среды.

Поэтому нельзя строить рабочую схему на предположении: «если прокси настроен в ОС, 1С сама его найдёт». Надёжнее явно проверить фактические параметры объекта и учитывать версию платформы.

Как настроить прокси для HTTP-соединения в коде 1С

Для обращения к внешнему HTTP- или HTTPS-ресурсу обычно используются три объекта:

• HTTPСоединение — устанавливает соединение с сервером;
• HTTPЗапрос — описывает путь, заголовки и тело запроса;
• ИнтернетПрокси — задаёт параметры промежуточного прокси-сервера.

Для HTTPS также требуется защищённое соединение.

Минимальный пример с явным прокси

Ниже приведён демонстрационный фрагмент. Замените адреса, порт и способ получения учётных данных на параметры своей инфраструктуры.

СерверПрокси = "proxy.corp.local";
ПортПрокси = 3128;

ПользовательПрокси = ПолучитьПользователяПроксиИзЗащищенногоХранилища();
ПарольПрокси = ПолучитьПарольПроксиИзЗащищенногоХранилища();

Прокси = Новый ИнтернетПрокси(Ложь);
Прокси.Установить(
    "https",
    СерверПрокси,
    ПортПрокси,
    ПользовательПрокси,
    ПарольПрокси);

ЗащищенноеСоединение = Новый ЗащищенноеСоединениеOpenSSL();

Соединение = Новый HTTPСоединение(
    "api.example.com",
    443,
    ,
    ,
    Прокси,
    30,
    ЗащищенноеСоединение);

Запрос = Новый HTTPЗапрос("/health");
Ответ = Соединение.Получить(Запрос);

Сообщить("Код состояния: " + Ответ.КодСостояния);

api.example.com и proxy.corp.local в примере являются заполнителями. В рабочем коде должны использоваться реальные адреса разрешённых корпоративных сервисов.

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

HTTP и HTTPS на прокси

Параметры прокси задаются для нужного протокола. Если конфигурация обращается к ресурсам по HTTP и HTTPS, проверьте оба сценария отдельно.

Работа обычного HTTP-запроса не доказывает исправность HTTPS. Для защищённого соединения могут дополнительно потребоваться:

• разрешение метода CONNECT на прокси;
• доверенная цепочка сертификатов;
• поддерживаемая версия TLS;
• корректное имя сервера в сертификате;
• корпоративный корневой сертификат при TLS-инспекции.

Авторизация на прокси

Ошибка 407 Proxy Authentication Required означает, что запрос дошёл до прокси, но тот не принял или не получил данные авторизации.

Проверьте:

• правильность имени пользователя;
• нужен ли домен в формате DOMAIN\user;
• используется ли обычная или интегрированная аутентификация;
• разрешена ли выбранная схема для учётной записи службы;
• не заблокирована ли учётная запись;
• имеет ли пользователь право обращаться к нужному адресу;
• не истёк ли пароль.

Не выводите пароль в сообщения 1С и не записывайте его в журнал. Также не передавайте пароль в командной строке: он может сохраниться в истории или стать видимым другим процессам.

Обработка ошибок

Сетевой вызов нужно помещать в Попытка…Исключение, но одного общего сообщения «нет интернета» недостаточно.

Попытка
    Ответ = Соединение.Получить(Запрос);

    Если Ответ.КодСостояния >= 200
        И Ответ.КодСостояния < 300 Тогда

        Сообщить("Соединение установлено. Код: "
            + Ответ.КодСостояния);
    Иначе
        Сообщить("Внешний сервис вернул код: "
            + Ответ.КодСостояния);
    КонецЕсли;

Исключение
    ОписаниеОшибки = КраткоеПредставлениеОшибки(
        ИнформацияОбОшибке());

    Сообщить("Ошибка HTTP-соединения: " + ОписаниеОшибки);
КонецПопытки;

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

Токены, пароли, содержимое документов и персональные данные журналировать нельзя.

Как проверить сеть до изменения настроек 1С

До редактирования кода и inetcfg.xml нужно проверить базовый маршрут. Иначе ошибка DNS или firewall будет ошибочно воспринята как проблема платформы.

Проверьте разрешение имён

На узле, где выполняется запрос, проверьте имена прокси и целевого сервиса:

Resolve-DnsName proxy.corp.local
Resolve-DnsName api.example.com

Если имя не разрешается, изменение параметров HTTPСоединение не поможет. Сначала нужно исправить DNS или указать корректное полное доменное имя.

Проверку следует выполнять именно на сервере 1С, если код работает на сервере. Результат с пользовательского компьютера может отличаться.

Проверьте доступность порта прокси

Для проверки TCP-соединения в Windows PowerShell можно использовать:

Test-NetConnection proxy.corp.local -Port 3128

Параметр TcpTestSucceeded должен иметь значение True.

Если соединение не устанавливается, проверьте:

• адрес и порт;
• локальный firewall;
• межсетевой экран между сервером 1С и прокси;
• маршрутизацию;
• список разрешённых источников на прокси;
• сетевые политики хостинг-провайдера или площадки.

Успешная TCP-проверка подтверждает только доступность порта. Она не проверяет авторизацию и разрешение обращения к целевому ресурсу.

Выполните контрольный запрос без 1С

Если политика организации разрешает использовать curl, выполните контрольный запрос через тот же прокси:

curl.exe -I --proxy http://proxy.corp.local:3128 https://api.example.com/health

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

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

Проверьте системное время

Значительное расхождение времени может привести к ошибкам проверки сертификатов и токенов. Проверьте дату, время, часовой пояс и синхронизацию на всех узлах кластера.

Повторите запрос из нужного контекста 1С

После сетевых проверок выполните минимальный запрос:

• в той же информационной базе;
• на том же сервере;
• из той же процедуры или фонового задания;
• с тем же объектом ИнтернетПрокси;
• к простому диагностическому endpoint без передачи рабочих данных.

Если тест из клиентской процедуры проходит, а фоновое задание завершается ошибкой, сравнивать нужно не ответы сервиса, а контексты выполнения.

Типичные ошибки прокси в 1С

Ошибка 407 и ошибка 401 — не одно и то же

Код 407 возвращает прокси-сервер. Он сообщает, что требуется авторизация на промежуточном узле.

Код 401 Unauthorized обычно возвращает целевой сервис. В этом случае прокси мог успешно пропустить соединение, но API не принял токен, логин или другой способ авторизации.

Исправлять параметры прокси при ответе 401 обычно бессмысленно.

Ошибки TLS

При корпоративной TLS-инспекции прокси может устанавливать защищённое соединение с внешним сервисом, а клиенту выдавать сертификат, подписанный внутренним удостоверяющим центром.

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

Не следует отключать проверку сертификатов ради устранения ошибки. Это скрывает причину и снижает защищённость соединения.

Исключения для внутренних ресурсов

Внутренние адреса обычно не должны отправляться на внешний прокси. Исключения могут потребоваться для:

• локальных доменных имён;
• адресов частных сетей;
• внутренних API;
• служб лицензирования;
• серверов обмена внутри организации.

Список исключений должен соответствовать политике сети. Слишком широкое правило может отправить запрос напрямую в обход обязательного контроля, а слишком узкое — сломать доступ к локальному сервису.

Последовательность диагностики доступа

Рабочая диагностика должна менять по одному уровню за раз.

Шаг 1. Зафиксируйте ошибку

Запишите:

• точное время;
• действие пользователя или название фонового задания;
• адрес сервиса;
• код HTTP, если он получен;
• текст исключения;
• имя информационной базы;
• версию платформы;
• режим совместимости;
• узел кластера.

Не ограничивайтесь пересказом «1С не видит интернет».

Шаг 2. Найдите место выполнения запроса

Проверьте процедуру, директиву компиляции и цепочку вызовов. Для фонового задания установите, на каком сервере кластера оно выполнялось.

Если используются разные узлы, проверку нужно повторить на каждом потенциальном исполнителе.

Шаг 3. Определите источник настроек

Установите, откуда запрос должен получить параметры прокси:

• из явно созданного ИнтернетПрокси;
• из inetcfg.xml;
• из прокси по умолчанию;
• из настроек прикладной конфигурации;
• из отдельного механизма типового сервиса.

Не смешивайте эти варианты в одном тесте.

Шаг 4. Проверьте DNS и TCP

На нужном узле проверьте разрешение имени и доступность порта прокси. Если этот этап не пройден, переходить к коду 1С рано.

Шаг 5. Проверьте прокси отдельно

Выполните безопасный запрос к тестовому адресу без передачи рабочих данных. Сопоставьте результат с журналом прокси.

Если в журнале нет попытки соединения, запрос либо не дошёл до прокси, либо отправился другим маршрутом.

Шаг 6. Выполните минимальный запрос из 1С

Создайте тест с явно заданными параметрами. Сначала проверьте простой endpoint, затем рабочий сервис.

Так можно отделить ошибку транспортного уровня от особенностей прикладного API.

Шаг 7. Проверьте HTTPS и сертификаты

Если HTTP работает, а HTTPS нет, проверьте:

• возможность туннелирования HTTPS через прокси;
• имя в сертификате;
• срок действия;
• корневой и промежуточные сертификаты;
• системное время;
• наличие корпоративного удостоверяющего центра в нужном хранилище.

Шаг 8. Сопоставьте журналы

Сравните одно и то же событие по времени в:

• журнале регистрации 1С;
• технологическом журнале;
• журнале прокси;
• системном журнале;
• журнале целевого сервиса.

Сопоставление по точному времени и адресу быстрее показывает, где оборвалась цепочка.

Шаг 9. Верните временные изменения

После диагностики удалите тестовые учётные данные, временные правила firewall, дополнительные журналы и диагностический код.

Если изменялся inetcfg.xml, сохраните рабочую версию и документируйте причину. Не оставляйте несколько конфликтующих способов задания прокси.

Заключение

Прокси в браузере, системный прокси Windows, параметры inetcfg.xml и объект ИнтернетПрокси решают похожую задачу, но относятся к разным уровням инфраструктуры.

Если 1С не получает доступ к внешнему сервису, сначала определите место выполнения кода. Затем последовательно проверьте DNS, доступность прокси, авторизацию, маршрут HTTPS и сертификаты. Только после этого имеет смысл изменять конфигурацию платформы или прикладной код.

Явная передача объекта ИнтернетПрокси в HTTPСоединение делает поведение запроса предсказуемее, но требует безопасного хранения учётных данных и контроля версий платформы.

Что почитать дальше

• Серверная инфраструктура 1С — как устроена серверная среда и на каком узле может выполняться прикладной код.
• Сетевые порты сервера 1С — какие соединения нужны компонентам 1С и как проверять сетевую доступность.
• 1С-ЭДО не отправляет или не принимает документы — диагностика прикладного сценария после проверки сети и прокси.
• 1С-Отчетность: почему не отправляется отчет — что проверить при ошибке отправки отчётности.

Когда стоит обратиться к специалистам

Самостоятельная диагностика подходит, если известны адрес прокси, параметры авторизации и место выполнения запроса. Привлечение специалиста оправдано, когда проблема возникает только в фоновых заданиях, затрагивает несколько узлов кластера, связана с TLS-инспекцией или требует изменения рабочей конфигурации.

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

Кратко

• Сайт в браузере и HTTP-запрос из 1С могут использовать разные сетевые маршруты.
• Сначала нужно определить, где выполняется код: на клиенте, сервере или в фоновом задании.
• Пользовательские настройки прокси не обязательно применяются к службе сервера 1С.
• Объект ИнтернетПрокси позволяет явно передать параметры в HTTPСоединение.
• Ошибка 407 относится к авторизации на прокси, а 401 обычно возвращает целевой сервис.
• Проверку начинают с DNS и доступности порта, а не с изменения кода.
• TLS-инспекция требует доверия к корпоративному сертификату в нужном контексте.
• Пароли прокси нельзя хранить в модуле, журнале или командной строке.