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

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

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

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

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

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

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

EDIT (2013-07-22)

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

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

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

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

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

• net: не подавляйте ECONNRESET (Ben Noordhuis)

предыдущие версии не будут ошибаться при прерываниях от клиента. Разрыв соединения от клиента вызывает ошибку ECONNRESET в узле. Я считаю, что это предназначено для 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)

вы не увидите ошибки при использовании узла v0.9.9, и ошибка при использовании узла V. 0.9.10 и выше.

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

я столкнулся с той же проблемой, но я смягчил ее, поместив:

server.timeout = 0;

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

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

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

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

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

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

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

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

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

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

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

в ядре узла lib net.js он будет вызывать clientHandle.close() что также вызовет ошибку ECONNRESET:

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

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

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

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

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

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

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

мое решение

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

общие выводы

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

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

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

попробуйте добавить эти параметры в сокет.Ио:

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

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