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

«ECONNRESET» означает, что другая сторона TCP-диалога внезапно закрыла свой конец соединения. Скорее всего, это связано с одной или несколькими ошибками протокола приложения. Вы можете посмотреть журналы сервера API, чтобы узнать, не жалуется ли он на что-нибудь.

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

Быстрое и грязное решение для разработки:

Используйте longjohn, вы получите длинные трассировки стека, которые будут содержать асинхронные операции.

Чистое и правильное решение: технически в узле всякий раз, когда генерируется событие 'error' и его никто не слушает, его выкинут. Чтобы он не бросал, поставьте на него слушателя и разберитесь с ним самостоятельно. Таким образом, вы можете зарегистрировать ошибку с дополнительной информацией.

Чтобы иметь одного слушателя для группы вызовов, вы можете использовать домены, а также обнаруживать другие ошибки на время выполнения. Убедитесь, что каждая асинхронная операция, связанная с http (сервером / клиентом), находится в другом домене сравнения контекста для других частей кода домен будет автоматически прослушивать error события и передавать их своему собственному обработчику. Таким образом, вы слушаете только этот обработчик и получаете данные об ошибке. Вы также бесплатно получите дополнительную информацию.

ИЗМЕНИТЬ (22 июля 2013 г.)

Как я уже писал выше:

«ECONNRESET» означает, что другая сторона TCP-диалога внезапно закрыла свой конец соединения. Скорее всего, это связано с одной или несколькими ошибками протокола приложения. Вы можете посмотреть журналы сервера API, чтобы узнать, не жалуется ли он на что-нибудь.

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

Но одно можно сказать наверняка: у вас действительно есть ошибка чтения в вашем TCP-соединении, которая вызывает исключение. Вы можете убедиться в этом, посмотрев на код ошибки, который вы опубликовали при редактировании, который подтверждает это.

Причиной этого был простой tcp-сервер, который у меня был для обслуживания файла политики флэш-памяти. Теперь я могу поймать ошибку с помощью обработчика:

# serving the flash policy file
net = require("net")

net.createServer((socket) =>
  //just added
  socket.on("error", (err) =>
    console.log("Caught flash policy server socket error: ")
    console.log(err.stack)
  )

  socket.write("<?xml version=\"1.0\"?>\n")
  socket.write("<!DOCTYPE cross-domain-policy SYSTEM \"https://www.macromedia.com/xml/dtds/cross-domain-policy.dtd\">\n")
  socket.write("<cross-domain-policy>\n")
  socket.write("<allow-access-from domain=\"*\" to-ports=\"*\"/>\n")
  socket.write("</cross-domain-policy>\n")
  socket.end()
).listen(843)

У меня была аналогичная проблема, когда приложения начинали работать с ошибками после обновления Node. Я считаю, что это можно проследить до выпуска Node v0.9.10 этого элемента:

• net: не подавлять ECONNRESET (Бен Нордхейс)

В предыдущих версиях не возникало ошибок при прерывании работы клиента. Разрыв соединения от клиента вызывает ошибку ECONNRESET в Node. Я считаю, что это предназначенная функция для Node, поэтому исправление (по крайней мере, для меня) заключалось в обработке ошибки, что, как я полагаю, вы сделали в исключениях unCaught. Хотя я обрабатываю это в обработчике net.socket.

Вы можете продемонстрировать это:

Сделайте простой сервер сокетов и получите Node v0.9.9 и v0.9.10.

require('net')
    .createServer( function(socket) 
    {
           // no nothing
    })
    .listen(21, function()
     {
           console.log('Socket ON')
    })

Запустите его с помощью v0.9.9, а затем попытайтесь подключиться к этому серверу по FTP. Я использую FTP и порт 21 только потому, что у меня Windows и у меня есть FTP-клиент, но нет удобного telnet-клиента.

Затем со стороны клиента просто разорвите соединение. (Я просто нажимаю Ctrl-C)

Вы должны увидеть NO ERROR при использовании Node v0.9.9 и ERROR при использовании Node v.0.9.10 и выше.

В производстве я использую v.0.10. что-то и все равно выдает ошибку. Опять же, я думаю, что это задумано, и решение состоит в том, чтобы обработать ошибку в вашем коде.

Была такая же проблема сегодня. После некоторого исследования я нашел очень полезный --abort-on-uncaught-exception параметр node.js. Он не только обеспечивает более подробную и полезную трассировку стека ошибок, но также сохраняет файл ядра при сбое приложения, позволяя проводить дальнейшую отладку.

Я столкнулся с той же проблемой, но я решил ее решить, разместив:

server.timeout = 0;

до server.listen. server - здесь HTTP-сервер. Тайм-аут по умолчанию составляет 2 минуты в соответствии с документацией по API.

Я также получаю ошибку ECONNRESET во время разработки, я решаю ее, не используя nodemon для запуска моего сервера, просто используйте "node server.js" для запуска моего сервера, и моя проблема решена.

Странно, но у меня это сработало, теперь я больше не вижу ошибки ECONNRESET.

Другой возможный случай (но редкий) может быть, если у вас есть связь между серверами и для server.maxConnections установлено очень низкое значение.

В основной библиотеке узла net.js будет вызовите clientHandle.close(), который также вызовет ошибку ECONNRESET:

if (self.maxConnections && self._connections >= self.maxConnections) {
  clientHandle.close(); // causes ECONNRESET on the other end
  return;
}

Да, использование вами файла политики определенно может вызвать сбой.

Чтобы повторить, просто добавьте задержку в свой код:

net.createServer( function(socket) 
{
    for (i=0; i<1000000000; i++) ;
    socket.write("<?xml version=\"1.0\"?>\n");
…

… И используйте telnet для подключения к порту. Если вы отключите telnet до истечения задержки, вы получите сбой (неперехваченное исключение), когда socket.write выдаст ошибку.

Чтобы избежать сбоя здесь, просто добавьте обработчик ошибок перед чтением / записью сокета:

net.createServer(function(socket)
{
    for(i=0; i<1000000000; i++);
    socket.on('error', function(error) { console.error("error", error); });
    socket.write("<?xml version=\"1.0\"?>\n");
}

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

И когда вы закончите, не забудьте убрать задержку.

У меня тоже была эта ошибка, и я смог ее решить после нескольких дней отладки и анализа:

мое решение

Для меня проблемой был VirtualBox (для Docker). У меня была настроена перенаправление портов на моей виртуальной машине, и ошибка возникла только на перенаправленном порту.

общие выводы

Следующие наблюдения могут сэкономить вам дни работы, которую мне пришлось вложить:

• Для меня проблема возникла только при подключении с localhost к localhost на одном порту. -> проверка, изменение любой из этих констант решает проблему.
• Для меня проблема возникла только на моей машине -> пусть кто-нибудь еще попробует.
• Для меня проблема возникла только через некоторое время и не могла быть воспроизведена надежно
• Моя проблема не может быть проверена ни одним из узлов или инструментов выражения (отладки). -> не тратьте на это время

-> выяснить, не работает ли что-то в вашей сети (-настройки), например, виртуальные машины, брандмауэры и т. д., это, вероятно, причина проблемы.

Я решил эту проблему:

• Выключаю Wi-Fi / Ethernet-соединение и включаю.
• Я набрал: npm update в терминале, чтобы обновить npm.
• Я попытался выйти из сеанса и снова войти в систему

После этого я попробовал ту же команду npm, и хорошо, что это сработало. Я не был уверен, что это так просто.

Я использую CENTOS 7

Я только что понял это, по крайней мере, в моем случае использования.

Я получал ECONNRESET. Оказалось, что мой клиент был настроен так, что он много раз обращался к серверу с вызовом API очень быстро - и ему нужно было только один раз попасть в конечную точку.

Когда я исправил это, ошибка исчезла.

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

Как обсуждалось выше, ECONNRESET означает, что TCP-диалог внезапно закрыл свой конец соединения.

Ваше интернет-соединение может блокировать вам подключение к некоторым серверам. В моем случае я пытался подключиться к mLab (облачная служба баз данных, в которой размещены базы данных MongoDB). И мой провайдер блокирует это.

ECONNRESET происходит, когда сторона сервера закрывает TCP-соединение и ваш запрос к серверу не выполняется. Сервер отвечает сообщением о том, что соединение, вы имеете в виду недопустимое соединение.

Почему сервер отправляет запрос с недопустимым соединением?

Предположим, вы включили постоянное соединение между клиентом и сервером. Таймаут проверки активности настроен на 15 секунд. Это означает, что если keep-alive бездействует в течение 15 секунд, он отправит запрос на закрытие соединения. Таким образом, через 15 секунд сервер говорит клиенту закрыть соединение. НО, когда сервер отправляет этот запрос, клиент отправляет новый запрос, который уже находится в полете на стороне сервера. Поскольку сейчас это соединение недействительно, сервер отклонит сообщение с ошибкой ECONNRESET. Таким образом, проблема возникает из-за меньшего количества запросов к серверу. Поэтому, пожалуйста, отключите keep-alive, и он будет работать нормально.

У меня была такая же проблема, и похоже, что проблема была в версии Node.js.

Я установил предыдущую версию Node.js (10.14.2), и все было в порядке с использованием nvm (позволяет установить несколько версий Node.js и быстро переключаться с одной версии на другую).

Это не «чистое» решение, но оно может служить вам временно.

Сокет Node JS не блокирует io. Рассмотрите возможность использования неблокирующего io-соединения из других источников. Например, если вы используете блокирующий сокет Java с узлом, он будет работать только в течение нескольких секунд, после чего будет выдана ошибка. Смягчите это, реализовав неблокирующее соединение, т. Е. socketchannel с селектором.

Попробуйте добавить эти параметры в socket.io:

const options = { transports: ['websocket'], pingTimeout: 3000, pingInterval: 5000 };

Я надеюсь, что это поможет вам !