Ошибка выполнения HTTP-запроса в 1С: как найти причину и починить

Что значит «Ошибка выполнения HTTP-запроса» в 1С

Это сообщение платформы возникает на этапе, когда объект HTTPСоединение уже создан и вызывается один из методов — Получить(), ОтправитьДляОбработки(), ВызватьHTTPМетод(), Записать(), — но платформа не смогла довести обмен до получения корректного HTTPОтвет. Важное отличие: если сервер ответил любым кодом (даже 500), это не «Ошибка выполнения HTTP-запроса» — это штатный ответ, который нужно проверять по Ответ.КодСостояния. А вот когда обмен не состоялся вовсе (не установилось соединение, сорвался TLS, истёк таймаут), платформа поднимает исключение с текстом «Ошибка выполнения HTTP-запроса» и уточнением в скобках.

Поэтому первое, что нужно сделать при диагностике, — вывести ОписаниеОшибки() из блока Исключение и посмотреть текст в скобках. Именно там платформа пишет реальную причину: «SSL_connect failed», «Превышено время ожидания», «Не удалось разрешить имя узла», «Соединение отвергнуто» и т.п.

Причина 1. SSL/TLS: самоподписанный сертификат и старые протоколы

Самая частая причина «Ошибка выполнения HTTP-запроса» в 1С 8.3 при работе с https — не передан объект ЗащищённоеСоединениеOpenSSL в конструктор HTTPСоединение. Даже если порт указан 443, без явно заданного защищённого соединения платформа может отработать некорректно (особенно на старых релизах и при кастомных сертификатах).

// Правильный конструктор для https
ЗащСоединение = Новый ЗащищённоеСоединениеOpenSSL();

Соединение = Новый HTTPСоединение(
    "api.example.com",   // сервер без схемы и без слэша
    443,                 // порт https
    ,                    // пользователь
    ,                    // пароль
    ,                    // прокси
    60,                  // таймаут, сек
    ЗащСоединение        // ЗащищённоеСоединение
);

У ЗащищённоеСоединениеOpenSSL три параметра — сертификат клиента, сертификаты удостоверяющих центров и режим проверки отзыва. Для типового обмена с внешним API их можно оставить пустыми — платформа возьмёт системный набор корневых сертификатов. Если API работает по самоподписанному сертификату, добавьте его в СертификатыУдостоверяющихЦентров — «отключить проверку сертификата» в 1С в чистом виде нельзя, но можно явно передать доверенный набор:

// Свой корневой сертификат для самоподписанного API
СертификатыЦА = Новый СертификатыУдостоверяющихЦентровФайл("C:\certs\ca.pem");
ЗащСоединение = Новый ЗащищённоеСоединениеOpenSSL(, СертификатыЦА);

Признаки, что причина именно в SSL/TLS: в ОписаниеОшибки() встречаются подстроки «SSL_connect», «certificate verify failed», «unable to get local issuer certificate», «protocol version», «handshake failure». Если у сервера отключены старые протоколы (TLS 1.0/1.1), обновите платформу 1С — поддержка современных TLS-версий подтягивается вместе с релизом.

Причина 2. Таймаут соединения

Второй по частоте кейс: сервер отвечает медленно (тяжёлый отчёт, интеграция через очередь), а HTTPСоединение создано без параметра Таймаут. Через некоторое время платформа обрывает обмен и поднимает «Ошибка выполнения HTTP-запроса». Признак в тексте ошибки — «Превышено время ожидания», «timed out», «connection timeout».

// Таймаут в секундах; для тяжёлых интеграций ставьте с запасом
Соединение = Новый HTTPСоединение(
    "api.example.com", 443, , , ,
    120,                              // 120 секунд
    Новый ЗащищённоеСоединениеOpenSSL()
);

Значение 0 означает «без ограничения». В прикладном коде так делать не стоит: если сервер повиснет, зависнет и фоновое задание. Разумный диапазон — 30–120 секунд для синхронных API, 300+ секунд — для обмена файлами и выгрузок. Для асинхронных методов (ВызватьHTTPМетодАсинх, ПолучитьАсинх) таймаут работает так же — платформа обрывает ожидание по тому же счётчику.

Причина 3. DNS, прокси и неверный порт

Если ошибка выглядит как «Не удалось разрешить имя узла» или «Соединение отвергнуто», проблема на сетевом уровне:

• DNS не резолвится. На сервере 1С не настроен DNS или закрыт исходящий UDP/53. Проверяется командой nslookup api.example.com на самом сервере, где крутится rphost. С клиентской машины разрешаться может, а с сервера — нет.
• Прокси не передан в конструктор. В корпоративной сети выход в интернет обычно только через прокси. Настройки браузера 1С не подхватывает — прокси нужно передать явно:

Прокси = Новый ИнтернетПрокси(Ложь);
Прокси.Установить("http",  "proxy.corp.local", 3128, "user", "pass");
Прокси.Установить("https", "proxy.corp.local", 3128, "user", "pass");

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

Неверный порт — типовая ошибка при переезде API. Для https:// порт — 443, для http:// — 80. Если сервер слушает на нестандартном порту (например, 8443), его нужно указать явно и не полагаться на «догадки» платформы.

Причина 4. Неверный адрес ресурса и схема

В параметр Сервер передаётся только имя узла — без https://, без слэша в конце и без пути. А путь идёт в HTTPЗапрос.АдресРесурса и должен начинаться со слэша. Смешение этих двух правил — самая массовая ошибка новичков.

// Правильно: сервер без схемы, путь со слэшем
Соединение = Новый HTTPСоединение(
    "api.example.com", 443, , , , 60,
    Новый ЗащищённоеСоединениеOpenSSL()
);

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

Частые нарушения:

• Сервер = "https://api.example.com" — платформа воспринимает https:// как часть имени узла.
• АдресРесурса = "v1/orders" без ведущего слэша — сервер возвращает 404 или обрывает соединение.
• АдресРесурса с русскими символами без URL-кодирования — нужен КодироватьСтроку(..., СпособКодированияСтроки.КодировкаURL).

Причина 5. Тело запроса, Content-Type и User-Agent

Если соединение установлено, но сервер отвечает 400/415/500, а платформа поднимает исключение только когда мы читаем ответ, — источник проблемы в теле или заголовках. Наиболее частые ошибки:

• Кодировка тела. Метод УстановитьТелоИзСтроки принимает кодировку вторым параметром. Для JSON и большинства REST API — только "UTF-8". Кодировка Windows-1251 приведёт к «кракозябрам» на сервере и, как следствие, к 500.
• Content-Type не совпадает с телом. Отправляете JSON — заголовок application/json. Форму — application/x-www-form-urlencoded. Файл — multipart/form-data. Без корректного Content-Type сервер либо не распарсит тело, либо отдаст 415.
• User-Agent обязателен. Некоторые API (в том числе публичные Яндекс, Google, ФНС) отклоняют запросы без User-Agent, отвечая 403 или обрывая соединение — тогда клиент 1С видит «Ошибка выполнения HTTP-запроса».

Заголовки = Новый Соответствие;
Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
Заголовки.Вставить("Accept",       "application/json");
Заголовки.Вставить("User-Agent",   "1C-Enterprise/8.3 (integration; company=example)");
Заголовки.Вставить("Authorization","Bearer " + Токен);

Запрос = Новый HTTPЗапрос("/v1/orders", Заголовки);
Запрос.УстановитьТелоИзСтроки(ТелоJSON, "UTF-8", ИспользованиеByteOrderMark.НеИспользовать);

Ответ = Соединение.ОтправитьДляОбработки(Запрос);

Параметр ИспользованиеByteOrderMark.НеИспользовать критичен: BOM в начале JSON-тела ломает парсер на серверной стороне и даёт молчаливый 400.

Как правильно прочитать ответ и код состояния

Даже если запрос ушёл без исключений, обязательно проверяйте HTTPОтвет.КодСостояния. 2xx — успех, 4xx — виноват клиент (тело, авторизация), 5xx — сервер. Тело читаем через ПолучитьТелоКакСтроку() с явной кодировкой:

Попытка
    Ответ = Соединение.ОтправитьДляОбработки(Запрос);
Исключение
    Лог.Ошибка("HTTP: " + ОписаниеОшибки());
    ВызватьИсключение;
КонецПопытки;

Если Ответ.КодСостояния >= 400 Тогда
    ТелоОтвета = Ответ.ПолучитьТелоКакСтроку("UTF-8");
    Лог.Ошибка("HTTP " + Ответ.КодСостояния + ": " + ТелоОтвета);
    ВызватьИсключение "Сервер вернул " + Ответ.КодСостояния;
КонецЕсли;

ТелоОК = Ответ.ПолучитьТелоКакСтроку("UTF-8");

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

Клиент, сервер и права

Один и тот же код HTTPСоединение может отработать на клиенте и упасть на сервере — и наоборот. Причины:

• Сеть. Сервер 1С стоит в закрытом контуре, у него нет доступа к внешнему API, а у пользователя — есть. Проверьте с самого хоста rphost.
• Права. На клиенте Внешние ресурсы разрешены, а на сервере — нет. В защищённом режиме (безопасный профиль) нужно явно разрешить доступ к нужным серверам во «Внешних ресурсах» профиля безопасности.
• Прокси. Прокси прописан в настройках пользователя Windows, а rphost работает от системной учётки без прокси. Передавайте ИнтернетПрокси явно, не полагайтесь на «настройки системы».

Правило простое: тяжёлые HTTP-обмены и интеграции — только на сервере (директива &НаСервере) и с явно переданными параметрами соединения. Клиентский вызов оставляйте только для интерактивных сценариев (открыть ссылку, проверить логин).

Частые ошибки при работе с HTTPСоединение в 1С

• Схема и слэш в имени сервера. "https://api.example.com/" вместо "api.example.com" — платформа не разберёт имя узла.
• Порт 80 для https. Или наоборот — 443 для http. Проверяйте, что порт соответствует схеме.
• Забытый ЗащищённоеСоединениеOpenSSL. Без него на https платформа может либо упасть, либо использовать несовместимый TLS.
• Таймаут по умолчанию. На медленных API это гарантированный обрыв. Всегда задавайте явно (30–120 секунд).
• Тело в Windows-1251. Для JSON и большинства REST API — только UTF-8, без BOM.
• Content-Type не соответствует телу. JSON без application/json — 415 от сервера.
• Проглатывание исключения. Попытка … Исключение КонецПопытки; без ОписаниеОшибки() в журнале регистрации — расследовать инцидент потом невозможно.
• Проверка ответа только по исключению. Сервер вернул 500, но обмен состоялся — платформа не поднимет ошибку. Всегда смотрите КодСостояния.

Чек-лист диагностики

• Прочитайте ОписаниеОшибки() — там реальная причина в скобках.
• Проверьте КодСостояния и первые 500 символов тела ответа.
• Убедитесь, что сервер в конструкторе — без схемы и без слэша.
• Для https передан ЗащищённоеСоединениеOpenSSL.
• Порт соответствует схеме (443/80/кастомный).
• Задан Таймаут — не значение по умолчанию.
• С сервера 1С (rphost) DNS резолвится, прокси передан явно.
• Content-Type в заголовках соответствует телу, тело в UTF-8 без BOM.
• Проверили на сервере (&НаСервере), а не только на клиенте.

Частые вопросы об ошибке HTTP-запроса в 1С