Как отладить HTTP/HTTPS-запросы из 1С и устранить ошибки 404 и 415

← На главную

Разработка интеграций с внешними веб-сервисами по API — стандартная задача для современного разработчика 1С. Однако в процессе написания кода мы часто сталкиваемся с ситуацией, когда запрос, прекрасно работающий в сторонних утилитах (например, в Postman), наотрез отказывается выполняться из кода 1С, возвращая неинформативные коды ошибок вроде 404 (Not Found) или 415 (Unsupported Media Type).

При этом 1С работает по принципу «черного ящика»: отправляя запрос через объект HTTPСоединение, мы не видим в явном виде сформированный пакет (сырые заголовки, структуру тела, кодировку). В этой статье мы подробно рассмотрим, почему возникают такие ошибки, как правильно анализировать ответы сервера и какими способами можно перехватить и детально изучить исходящий трафик из 1С.

Разбор типовой ситуации: почему возникает ошибка 404 при отправке запроса

Рассмотрим классическую проблему, с которой часто сталкиваются разработчики на начальном этапе интеграции. Код выглядит синтаксически верным и логичным:


&НаСервере
Функция ОтправитьЗапроскAPI(ТекстЗапросаКAPI)
    // Создаем защищенное соединение SSL
    HTTPСоединение = Новый HTTPСоединение("api.myservice.ru", 443,,,,, Новый ЗащищенноеСоединениеOpenSSL());
    
    // Создаем запрос к ресурсу "pub"
    HTTPЗапрос = Новый HTTPЗапрос("pub"); 
    HTTPЗапрос.Заголовки.Вставить("Content-Type", "application/json");
    HTTPЗапрос.Заголовки.Вставить("x-client-key", "Application " + СокрЛП(Токен));
    
    // Передаем JSON-строку
    HTTPЗапрос.УстановитьТелоИзСтроки(ТекстЗапросаКAPI, КодировкаТекста.UTF8, ИспользованиеByteOrderMark.НеИспользовать);
    
    // Отправляем запрос методом POST (через ОтправитьДляОбработки)
    Ответ = HTTPСоединение.ОтправитьДляОбработки(HTTPЗапрос);
    Возврат Ответ.КодСостояния;
КонецФункции

При выполнении этого кода сервер возвращает статус 404. Первая мысль разработчика — «неправильный URL ресурса» или «сервер недоступен». Однако проверка корня сайта в браузере или отправка пинга показывает, что хост работает штатно. В чем же дело?

Причина кроется в нестыковке используемого HTTP-метода и архитектуры целевого API:

Метод HTTPСоединение.ОтправитьДляОбработки() выполняет HTTP-запрос методом POST.
Адрес ресурса (URI), к которому выполняется обращение (в нашем примере — pub), настроен на веб-сервере только на обработку запросов методом GET (например, для получения общей информации или статуса связи).
Многие веб-серверы (например, Nginx или IIS) при попытке обратиться к GET-эндпоинту методом POST не возвращают корректный статус 405 Method Not Allowed, а сразу отдают стандартную ошибку 404 Not Found в целях безопасности или из-за особенностей маршрутизации.

Поэтому, если вы получаете 404 ошибку при отправке POST-запроса, обязательно проверьте документацию к API. Возможно, для метода POST предназначен совершенно другой путь (например, pub/v1/Shops), а тестовый эндпоинт требует исключительно GET-запроса через метод соединения Получить().

Как получить полную информацию из HTTP-ответа в 1С

Никогда не ограничивайтесь анализом только кода состояния (КодСостояния). Даже при возникновении ошибок веб-серверы часто присылают подробное описание проблемы в теле ответа или в заголовках. Разберем, как выжать максимум информации из полученного объекта HTTPОтвет:


КодОтвета = Ответ.КодСостояния;
ЗаголовкиОтвета = Ответ.Заголовки; // Это объект Соответствие

// Получаем тело ответа в виде строки
ТекстОтвета = Ответ.ПолучитьТелоКакСтроку(КодировкаТекста.UTF8);

Сообщить("Код состояния: " + КодОтвета);
Для Каждого Заголовок Из ЗаголовкиОтвета Цикл
    Сообщить(Заголовок.Ключ + ": " + Заголовок.Значение);
КонецЦикла;
Сообщить("Тело ответа: " + ТекстОтвета);

Если тело ответа пустое, обратите внимание на заголовок Allow (он может содержать список разрешенных методов для этого URI, например: GET, HEAD) или на заголовок Content-Type, который подскажет, в каком формате сервер пытался вернуть ошибку.

Способ 1. Использование эхо-сервисов для перехвата запросов

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

Проанализируем по шагам, как это работает:

Перейдите на сайт сервиса (например, Webhook.site) в браузере. Система мгновенно сгенерирует для вас уникальный URL-адрес (например: https://webhook.site/12345678-90ab-cdef-1234-567890abcdef).
Временно скорректируйте код создания подключения в 1С, перенаправив запросы на этот хост:


// Вместо "api.myservice.ru" указываем хост эхо-сервиса
HTTPСоединение = Новый HTTPСоединение("webhook.site", 443,,,,, Новый ЗащищенноеСоединениеOpenSSL());

// В качестве пути передаем ваш уникальный идентификатор
HTTPЗапрос = Новый HTTPЗапрос("12345678-90ab-cdef-1234-567890abcdef"); 
// Далее заполняем заголовки и тело в штатном режиме...

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

Способ 2. Локальный перехват и дешифрование HTTPS через Fiddler

Если отладка происходит на локальном компьютере разработчика или на тестовом сервере, где есть права администратора, лучшим инструментом станет прокси-сниффер Fiddler Classic или Charles Proxy. Они позволяют перехватывать абсолютно весь трафик между 1С и внешним миром.

Однако для работы с 1С есть две важные особенности настройки, которые необходимо разобрать подробнее.

А. Явное указание прокси в 1С

По умолчанию платформа 1С может игнорировать системные настройки прокси-сервера Windows, через которые работает Fiddler (обычно это адрес 127.0.0.1 и порт 8888). Чтобы принудительно пустить трафик через сниффер, инициализируйте объект соединения с параметром прокси:


// Вариант 1. Использовать системные настройки прокси
Прокси = Новый ИнтернетПрокси(Истина); 

// Вариант 2. Ручная жесткая привязка к локальному Fiddler
Прокси = Новый ИнтернетПрокси();
Прокси.Установить("https", "127.0.0.1", 8888);
Прокси.Установить("http", "127.0.0.1", 8888);

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

Б. Проблема SSL-сертификатов (HTTPS)

Поскольку Fiddler дешифрует защищенный HTTPS-трафик, он использует технику подмены сертификатов (Man-in-the-Middle). В этот момент 1С заблокирует соединение, выдав ошибку: «Удаленный узел не прошел проверку».

Чтобы решить эту проблему, выполните следующие действия:

В настройках Fiddler включите дешифрование HTTPS (Tools -> Options -> HTTPS -> Decrypt HTTPS traffic).
Экспортируйте корневой сертификат Fiddler на рабочий стол (кнопка Actions -> Export Root Certificate to Desktop).
Откройте экспортированный файл сертификата в текстовом редакторе (например, в Блокноте) и скопируйте его текстовое представление (код Base64 между строками -----BEGIN CERTIFICATE----- и -----END CERTIFICATE-----).
Найдите файл доверенных сертификатов платформы 1С — cacert.pem. Он находится по пути установки текущей версии платформы, например: C:\Program Files\1cv8\8.3.XX.XXXX\bin\cacert.pem.
Откройте этот файл от имени Администратора, перейдите в самый конец и вставьте скопированный сертификат Fiddler. Сохраните изменения. Если запрос отправляется в фоновом задании на сервере, не забудьте перезапустить службу сервера 1С.

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

Решение ошибки 415 (Unsupported Media Type) и особенности кодировок

После успешного исправления ошибки 404 (путем выбора правильного пути или метода) разработчики нередко натыкаются на следующую преграду — ошибку 415 (Unsupported Media Type). Она означает, что принимающий сервер не понимает формат пересылаемых данных или кодировку. В контексте 1С это лечится анализом двух факторов.

1. Маркер Byte Order Mark (BOM)

При сериализации строк в JSON или XML платформа 1С может по умолчанию записывать в начало файла/строки невидимые служебные байты BOM (префикс EF BB BF для кодировки UTF-8). Современные веб-серверы и парсеры (особенно на Node.js или Go) не ожидают увидеть эти байты в начале JSON-строки и сразу отвергают запрос с кодом 415 или 400.

При записи тела запроса всегда явно указывайте запрет использования BOM:

HTTPЗапрос.УстановитьТелоИзСтроки(ТекстЗапроса, КодировкаТекста.UTF8, ИспользованиеByteOrderMark.НеИспользовать); 2. Точное указание кодировки в заголовках

Некоторые строгие REST API требуют, чтобы в заголовке Content-Type была явно прописана кодировка данных. Также помните, что веб-серверы могут быть чувствительны к регистру символов в названии заголовка. Вместо:

HTTPЗапрос.Заголовки.Вставить("Content-type", "application/json");

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

HTTPЗапрос.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");

Инструмент сравнения: сопоставление с Postman "под микроскопом"

Если в утилите Postman ваш запрос работает корректно, а в 1С падает с ошибкой, воспользуйтесь функцией генерации «сырого» кода в Postman:

Откройте вкладку с работающим запросом в Postman.
В правой боковой панели найдите и нажмите кнопку Code (обозначается как </>).
В выпадающем списке языков выберите вариант HTTP.
Перед вами появится текстовый образ оригинального запроса со всеми заголовками и телом.
В коде 1С непосредственно перед отправкой запроса настройте выгрузку сформированного пакета в текстовый файл:


ПутьКЛогу = "C:\temp\1c_request_raw.txt";
ТекстовыйФайл = Новый ТекстовыйДокумент();
ТекстовыйФайл.ДобавитьСтроку("POST /pub/v1/Shops HTTP/1.1");
ТекстовыйФайл.ДобавитьСтроку("Host: api.myservice.ru");
Для Каждого Заголовок Из HTTPЗапрос.Заголовки Цикл
    ТекстовыйФайл.ДобавитьСтроку(Заголовок.Ключ + ": " + Заголовок.Значение);
КонецЦикла;
ТекстовыйФайл.ДобавитьСтроку("");
ТекстовыйФайл.ДобавитьСтроку(ТекстЗапросаКAPI);
ТекстовыйФайл.Записать(ПутьКЛогу, КодировкаТекста.UTF8);

Откройте оба файла (сгенерированный из Postman и выгруженный из 1С) в любом текстовом редакторе с функцией сравнения файлов (например, Notepad++ с плагином Compare или VS Code). Сравните их построчно. Особое внимание обратите на наличие скрытых пробелов в заголовке авторизации, правильность указания префикса токена (например, Bearer или Application ), а также на переносы строк в теле JSON.

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