«Failure when receiving data from the peer» в 1С: где рвётся соединение и как это найти

Сообщение Ошибка при работе с Интернет: failure when receiving data from the peer значит одно: платформа 1С установила соединение с внешним узлом, отправила запрос, а ответ не получила или получила оборванным. Сам узел при этом был достижим, иначе вы увидели бы другую ошибку про разрешение имени или таймаут подключения.

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

Определите, чья это проблема: ваша или чужая

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

Затем проверьте с другой машины, лучше из другой сети (например, с телефона, раздающего интернет). Результат подскажет, куда копать:

Если ошибка возникает при обращении к конкретному сервису (банк, оператор ЭДО, налоговая), загляните на его страницу статуса. Плановые работы и перегрузки в дни сдачи отчётности дают именно такой обрыв.

Диагностика сети и доступности узла

Узнайте, что именно открывает 1С. Адрес виден в тексте ошибки, в настройках обмена или в коде вызова. Дальше проверяйте по цепочке.

1. Разрешение имени: nslookup адрес_узла. Если имя не превращается в IP или превращается в странный локальный адрес, виноват DNS провайдера или внутренний DNS.
2. Достижимость порта. В PowerShell: Test-NetConnection адрес_узла -Port 443. Поле TcpTestSucceeded должно быть True.
3. Полный запрос с выводом диагностики: curl -v https://адрес_узла/. В Windows 10 и новее curl есть из коробки.

Что искать в выводе curl -v. Строки с SSL connection и сведениями о сертификате говорят, что рукопожатие прошло. Если на этом месте появляется Recv failure, connection reset или unexpected EOF, соединение рвут уже после установки, обычно из-за шифрования или DPI-фильтрации.

Что проверить в самой сети

• ⚠️ Нестабильный Wi-Fi или мобильный интернет: обрыв посреди ответа случается чаще, чем при проводном подключении.
• 📦 Ограничение размера пакета. Если ping адрес -f -l 1472 не проходит, а -l 1400 проходит, на пути режут MTU. Крупные ответы обрываются, мелкие доходят.
• 🔁 Двойной NAT и каскад роутеров. Старые модели обрывают долгие TLS-сессии.
• 🕒 Время на компьютере. Если часы ушли на сутки, сертификат узла покажется «ещё не действующим» или «просроченным», и соединение закроется.

Протоколы шифрования и настройки TLS

Вторая по частоте причина после прокси. Современные сервисы отключили TLS 1.0 и 1.1, а многие требуют только TLS 1.2 или 1.3. Если у клиента старая платформа или старая ОС, узел просто закрывает соединение без внятного сообщения. Платформа видит это как «ответ не получен».

Что сделать по порядку:

1. Узнайте точную версию платформы (меню «О программе» или окно запуска). Если она старая, обновите платформу до актуальной: это самое честное лекарство.
2. Проверьте ОС. Windows Server 2016 и новее, Windows 10 и новее поддерживают TLS 1.2 штатно. Для более ранних систем приходится включать его вручную, и лучше не тратить на них время, а мигрировать.
3. Проверьте, какой протокол предлагает узел: openssl s_client -connect адрес_узла:443 -tls1_2. Если выдаётся сертификат, TLS 1.2 работает. Ошибка handshake failure или alert говорит о несовпадении наборов шифров.
4. Проверьте цепочку сертификатов. Если у компьютера нет корневого сертификата удостоверяющего центра, к которому привязан сертификат узла, соединение закрывается. Откройте адрес в браузере, посмотрите цепочку, при необходимости установите корневой сертификат в «Доверенные корневые центры сертификации».

Отдельный случай: российские узлы с сертификатами по ГОСТ. Для них нужен криптопровайдер (КриптоПро CSP или VipNet CSP) и настроенный в нём TLS. Без него обычное подключение закончится тем же обрывом.

Антивирус, прокси и межсетевой экран

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

Антивирус с проверкой HTTPS

Многие антивирусы подменяют сертификат узла своим («перехват шифрованного трафика»). Браузер этот сертификат принимает, потому что корневой сертификат антивируса добавлен в хранилище Windows. Платформа 1С в части операций опирается на свои механизмы проверки, и подменённый сертификат ей не подходит.

Как проверить без риска:

1. На минуту отключите в антивирусе именно проверку защищённых соединений (не защиту целиком).
2. Повторите действие в 1С.
3. Если сработало, добавьте адрес узла или процесс 1cv8.exe (и 1cv8c.exe, если запускаете тонкий клиент) в исключения проверки HTTPS.

Прокси-сервер

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

• Прокси, указанный в параметрах Windows, и прокси, указанный в программе 1С, могут отличаться. Сверьте их.
• Для узла, к которому обращается 1С, должна быть разрешена передача по HTTPS (метод CONNECT) на порт 443. Спросите у сетевого администратора, нет ли белого списка адресов.
• Если на сервере 1С интернетом пользуется служба, запускаемая под отдельной учётной записью, прокси нужно настраивать именно для неё. Настройки вашего пользователя на неё не действуют.

Межсетевой экран

Проверьте, что исходящие соединения для 1cv8.exe, 1cv8c.exe и серверных процессов не режутся ни локальным брандмауэром Windows, ни корпоративным шлюзом. В журнале шлюза ищите блокировки по IP получателя за момент ошибки.

Параметры соединения внутри платформы 1С

Если на уровне сети и шифрования всё чисто, переходите к настройкам программы. В типовых конфигурациях (Бухгалтерия предприятия 3.0, ЗУП 3.1, Управление торговлей 11) они лежат в разделе Администрирование → Интернет-поддержка и сервисы. Там есть пункт, где задаётся способ подключения к интернету: прокси, адрес, порт, пользователь, пароль.

Что настроить:

• Прокси: тип (системный или собственный), адрес и порт, учётные данные, если прокси требует авторизации. Для адресов, которые должны идти напрямую, включите обход прокси.
• Пароль и логин интернет-поддержки. Устаревший пароль сам по себе даёт другую ошибку, но связанные операции иногда обрываются на авторизации и выглядят как сетевой обрыв.
• Таймаут. Если вы пишете код с HTTPСоединение, пятого параметра конструктора (таймаут в секундах) может не хватать для тяжёлых запросов. Нулевое значение означает «ждать без ограничения».

Для кода проверьте, что адрес и протокол заданы правильно. Минимальный вызов выглядит так:

Соединение = Новый HTTPСоединение("example.ru", 443, , , , 60, Новый ЗащищенноеСоединениеOpenSSL);
Запрос = Новый HTTPЗапрос("/api/status");
Ответ = Соединение.Получить(Запрос);
Сообщить(Ответ.КодСостояния);

Если в таком вызове ошибка воспроизводится, а в браузере тот же адрес открывается, возвращайтесь к разделам про TLS и прокси: для кода проверка идёт через системное хранилище сертификатов, а прокси задаётся отдельным объектом ИнтернетПрокси.

Провайдер и оборудование

Если дошли сюда, сеть, шифрование и посредники уже проверены. Остаётся канал.

• Нестабильное оборудование: роутер со старой прошивкой, коммутатор с ошибками на порту, кабель с перебитой жилой. Признак: обрывы не привязаны к одному узлу, падают и другие сервисы, нестабильно идёт видео.
• Фильтрация провайдера. Часть операторов режет соединения по IP, по SNI или обрывает «подозрительные» сессии. Признак: узел открывается через мобильную сеть и не открывается из офиса. Если это ваш случай, напишите провайдеру с адресом узла и временем сбоя: просьбу о проверке обычно рассматривают быстро.
• Перегрузка канала в рабочее время. Ночью всё работает, днём рвётся. Проверьте загрузку канала, нет ли тяжёлых обновлений и резервного копирования в пиковые часы.
• Ограничение исходящих соединений на роутере (например, лимит числа одновременных подключений). Для офиса на 30 человек со старым роутером это реальная проблема.

Журнал регистрации и технологический журнал

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

Журнал регистрации

Откройте Администрирование → Журнал регистрации (или соответствующий пункт меню раздела «Администрирование») и отберите события по уровню «Ошибка» за нужный период. Для регламентных заданий и обменов там видна полная формулировка ошибки, пользователь и сеанс. Это быстро показывает, падает ли вызов постоянно или только в определённое время.

Технологический журнал

Журнал регистрации показывает, что произошло, но не показывает, почему оборвалось соединение. Для этого включают технологический журнал: в каталоге конфигурации платформы создаётся файл logcfg.xml, в котором задаётся каталог для логов и события, которые нужно писать. Для сетевых сбоев пригодится событие EXCP (исключения) и события, связанные с вызовами клиента. Точный синтаксис файла описан в документации платформы; не копируйте его с форумов вслепую.

По записям в журнале смотрите на:

• время события и процесс, в котором оно произошло;
• текст исключения: он иногда содержит код системной ошибки (сброс соединения, ошибка сертификата);
• повторяемость. Если ошибка приходит строго раз в N минут, ищите планировщик, резервное копирование или проверку антивируса по расписанию.

Что делать по шагам, если нужно быстро

Последовательность, в которой ошибку лучше всего ловить:

Частые вопросы