Almost guaranteed ECONNRESET on piped sockets if connecting to Node's HTTPS server which answers with "connection: 'close'" after setImmediate or setTimeout, on OSX #23169

decadent · 2018-09-29T23:33:23Z

Version: v10.11.0
Platform: Darwin localhost.local 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 21 20:07:40 PDT 2018; root:xnu-3248.73.11~1/RELEASE_X86_64 x86_64 (aka OSX 10.11.6, also happens on High Sierra)
Subsystem: ???

In the following code, pem is a module from NPM, and the rest is an HTTP proxy which serves CONNECT requests and pipes them to an HTTPS server defined in the same script:

const http = require('http');
const https = require('https');
const pem = require('pem');
const net = require('net');

const createHttpsServer = (callback) => {
  pem.createCertificate({
    days: 365,
    selfSigned: true
  }, (error, {serviceKey, certificate, csr}) => {
    const server = https.createServer({
      ca: csr,
      cert: certificate,
      key: serviceKey
    }, (req, res) => {
      setImmediate(() => {
        res.writeHead(200, {
          connection: 'close'
        });
        res.end('OK');
      });
    });

    server.listen((error) => {
      if (error) {
        console.error(error);
      } else {
        callback(null, server.address().port);
      }
    });
  });
};

const createProxy = (httpsServerPort) => {
  const proxy = http.createServer();
  proxy.on('connect', (request, requestSocket, head) => {
    const serverSocket = net.connect({
      port: httpsServerPort
    }, 'localhost', () => {
      requestSocket.write(
        'HTTP/1.1 200 Connection established\r\n\r\n'
      );

      serverSocket.write(head);
      serverSocket.pipe(requestSocket);
      requestSocket.pipe(serverSocket);
    });
  });

  proxy.listen(9000);
};

createHttpsServer((error, httpsServerPort) => {
  if (error) {
    console.error(error);
  } else {
    createProxy(httpsServerPort);
  }
});

If you run curl --proxy http://localhost:9000 https://qweasd/ -k, you'll see Curl receive the reply, and meanwhile the script will almost certainly fail with:

events.js:167
      throw er; // Unhandled 'error' event
      ^

Error: read ECONNRESET
    at TCP.onStreamRead (internal/stream_base_commons.js:111:27)
Emitted 'error' event at:
    at Socket.onerror (_stream_readable.js:690:12)
    at Socket.emit (events.js:182:13)
    at emitErrorNT (internal/streams/destroy.js:82:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:50:3)
    at process._tickCallback (internal/process/next_tick.js:63:19)

This issue is dependent on several parameters:

You're running OSX. El Capitan and High Sierra both exhibit this, an Ubuntu VM doesn't.
The server is HTTPS: an HTTP server and curl --proxytunnel work alright.
The server is running in the same script as the proxy.
The server answers with a connection: 'close' header.
The strangest one: the server request handler has setImmediate or setTimeout around the reply (with, I guess, any timeout value). process.nextTick doesn't do it. And if the handler instead serves the reply immediately, the server continues to answer perfectly alright until you hit a seemingly different ECONNRESET.

If you adorn the sockets with error event handlers, you'll see that the errors actually don't happen on each request, and when they do, it's primarily on the outgoing socket from the proxy to the HTTPS server; and often, but not necessarily, a second ECONNRESET occurs on the incoming socket to the proxy.

The text was updated successfully, but these errors were encountered:

decadent · 2018-09-30T00:03:42Z

Here's a log of events on the sockets involved. Legend:

→pr: incoming socket on the proxy
pr→: outgoing socket from the proxy to the server
→ser: incoming socket on the server from the proxy

[ pr→] lookup
[ pr→] connect
[→pr] pipe
[ pr→] pipe
[ pr→] ready
[ pr→] resume
[→pr] resume
[→pr] data
[ pr→] data
[→pr] data
[ pr→] data
[→pr] data
[ pr→] data
[ pr→] data
[→pr] data
[→ser] close
[ pr→] error
[ pr→] unpipe
proxy→server connection socket error: { Error: read ECONNRESET
    at TCP.onStreamRead (internal/stream_base_commons.js:111:27) errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' }
[→pr] error
[→pr] unpipe
proxy←client socket error: { Error: read ECONNRESET
    at TCP.onStreamRead (internal/stream_base_commons.js:111:27) errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' }
[→pr] close
[ pr→] close

Extracted with the following code:

const http = require('http');
const https = require('https');
const pem = require('pem');
const net = require('net');

const bedeckAnEventEmitterWithDebuggingOutpour = (emitter, name) => {
  const oldEmit = emitter.emit;
  emitter.emit = (...args) => {
    console.log('[%s] %s', name, args[0]);
    oldEmit.apply(emitter, args);
  };
};

const createHttpsServer = (callback) => {
  pem.createCertificate({
    days: 365,
    selfSigned: true
  }, (error, {serviceKey, certificate, csr}) => {
    const server = https.createServer({
      ca: csr,
      cert: certificate,
      key: serviceKey
    }, (req, res) => {
      setImmediate(() => {
        res.writeHead(200, {
          connection: 'close'
        });
        res.end('OK');
      });
    });
    server.on('connection', (socket) => {
      bedeckAnEventEmitterWithDebuggingOutpour(socket, '→ser');
      socket.on('error', (error) => {
        console.log('server←proxy socket error:', error);
      });
    });
    server.listen((error) => {
      if (error) {
        console.error(error);
      } else {
        callback(null, server.address().port);
      }
    });
  });
};

const createProxy = (httpsServerPort) => {
  const proxy = http.createServer();
  proxy.on('connect', (request, requestSocket, head) => {
    console.log('---------------------------------------------------------------------');
    const serverSocket = net.connect({
      port: httpsServerPort
    }, 'localhost', () => {
      requestSocket.write(
        'HTTP/1.1 200 Connection established\r\n\r\n'
      );
      serverSocket.write(head);
      serverSocket.pipe(requestSocket);
      requestSocket.pipe(serverSocket);
    });
    bedeckAnEventEmitterWithDebuggingOutpour(serverSocket, ' pr→');
    serverSocket.on('error', (error) => {
      console.log('proxy→server connection socket error:', error);
    });
    bedeckAnEventEmitterWithDebuggingOutpour(requestSocket, '→pr');
    requestSocket.on('error', (error) => {
      console.log('proxy←client socket error:', error);
      throw error;
    });
  });

  proxy.listen(9000);
};

createHttpsServer((error, httpsServerPort) => {
  if (error) {
    console.error(error);
  } else {
    createProxy(httpsServerPort);
  }
});

decadent · 2018-09-30T00:21:14Z

The question that most vexes me is whether this issue is related to ECONNRESET in absense of setImmediate/setTimeout, which manifests much more rarely but inescapably enough. The sequence of events is different in that case:

[ pr→] lookup
[ pr→] connect
[→pr] pipe
[ pr→] pipe
[ pr→] ready
[ pr→] resume
[→pr] resume
[→pr] data
[ pr→] data
[→pr] data
[→pr] data
[ pr→] data
[→pr] timeout
[→pr] close
[→pr] data
[→ser] prefinish
[→ser] finish
[ pr→] data
[→ser] close
[ pr→] data
[→pr] data
[ pr→] error
[ pr→] unpipe
proxy→server connection socker error: { Error: read ECONNRESET
    at TCP.onread (net.js:660:25) errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' }
[→pr] error
[→pr] unpipe
proxy←client socket error: { Error: read ECONNRESET
    at TCP.onread (net.js:660:25) errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' }

Most notably, the irritating timeout, which makes appearance here, doesn't seem to have basis in reality. I'm not certain whether this case warrants a posting of an issue, though.

crazywako · 2018-10-02T13:03:38Z

We get this error at TCP.onStreamRead (internal/stream_base_commons.js:111:27), errno=ECONNRESET, code=ECONNRESET, syscall=read with Node 10.11.0

Totally randomly when making requests with request library version 2.88.0

Confirmed working on Node 8.7.0

decadent · 2018-10-02T13:24:00Z

@crazywako that's probably different, sounds like normal network errors.

n-clark · 2019-01-31T20:05:29Z

I'm also getting the unhandled exception

{ Error: read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:111:27) errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' }

Error occurs on Node v10.15.1, OS Ubuntu 18.04.1, 4.15.0-44-generic.
Code was fine on Node 8.x.

It seems to occur around sending an HTTP socket to a forked child process via proc.send() in response to an upgrade request. The child process ends up receiving a null socket at the time the exception occurs on the main sending process, though not every time.

Happens very infrequently, perhaps once per million requests in the wild.

ajimix · 2019-02-12T13:52:36Z

Same problem here. Started happening after upgrading to 10.15.1 coming from node 8 as well. Ubuntu 16 in my case, same code.

ibc · 2019-03-07T03:07:02Z

Same here. It seems that the behavior is different in Node 8 and Node 10 (or there is a bug):

In Node 8 the socket emits "error" event, but nothing happens if there is no event listener for it.
However in Node 10, if there is no listener for that "error" event, the whole process fails with:

events.js:167
      throw er; // Unhandled 'error' event
      ^

Error: read ECONNRESET
    at TLSWrap.onStreamRead (internal/stream_base_commons.js:111:27)
Emitted 'error' event at:
    at emitErrorNT (internal/streams/destroy.js:82:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:50:3)
    at process._tickCallback (internal/process/next_tick.js:63:19)

grega913 · 2019-03-19T08:06:53Z

I've been strungling with this for quite some time now. Application is using knex, pooling, mysql.
My guess is (at least in my case) it has something to do with MySQL server. Sometimes server is killing connections if they're idle for sometime and the application crashes with error:
error:

Error: read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:111:27) -------------------- at Protocol._enqueue
We have this (or similar problem) with other clients for mysql (MySQL Workbench, Heidi, ...), and we managed to solve them for each client seperately.

With node, however, this keeps happening only when the code runs on localhost. It does not happen when the code is running on Digital ocean (https). Mysql server is on third machine and the same in both cases.

So I believe the problem is that mysql needs some ping quite often in order to keep connections alive.
If someone is able to solve this, it would be great..

grega913 · 2019-03-19T08:11:55Z

This is full stack, if someone is able to get something from it:
2019-03-19 08:55:57:755 - error: Error: read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:111:27) -------------------- at Protocol._enqueue (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\mysql\lib\protocol\Protocol.js:144:48) at Connection.query (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\mysql\lib\Connection.js:200:25) at C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\knex\lib\dialects\mysql\index.js:144:18 at Promise._execute (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\debuggability.js:313:9) at Promise._resolveFromExecutor (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\promise.js:483:18) at new Promise (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\promise.js:79:10) at Client_MySQL._query (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\knex\lib\dialects\mysql\index.js:135:12) at Client_MySQL.query (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\knex\lib\client.js:192:17) at Runner.<anonymous> (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\knex\lib\runner.js:138:36) at Runner.tryCatcher (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\util.js:16:23) at Runner.query (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\method.js:15:34) at C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\knex\lib\runner.js:47:21 at tryCatcher (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\util.js:16:23) at C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\using.js:185:26 at tryCatcher (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\util.js:16:23) at Promise._settlePromiseFromHandler (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\promise.js:512:31)

Johnz86 · 2019-03-21T09:20:42Z

I have similar problem. When using websockets following error appeared:

Error: read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:111:27)

I looked into source code. The exception is raised here:
https://github.com/nodejs/node/blob/v10.x/lib/internal/stream_base_commons.js

  if (nread !== UV_EOF) {
    return stream.destroy(errnoException(nread, 'read'));
  }

The only solution that currently worked for me is downgrade back to v 8.x

krisselden · 2019-04-11T20:02:41Z

Compiling the libuv/samples/socks5-proxy sample and proxying https through it intermittently fails with ECONNRESET or successfully gets the UV__EOF. There seems to be a race whether the last read will result in a UV_EOF or ECONNRESET. It only seems to happen when streaming https though. This was also on a mac. I reproduced it will curl and Chrome proxying through the libuv sample.

decadent · 2019-04-16T14:32:28Z

I wonder if any commenters here realize that this issue is for an incredibly specific case, most importantly an https server being in the same script as an http(s) proxy. The issue exists in the first place only because of a test. And it certainly doesn't have anything to do with MySQL.

Apparently the issue has become a magnet for everyone with an ECONNRESET. Well, if yall hope that Node.js devs will fix your problems based on the case in this issue, good luck to you.

n-clark · 2019-04-30T04:16:31Z

There appears to be some underlying bug in the node.js socket handling causing it to throw an unhandled exception. The main theme I'm seeing with all these reports is that it started with node v10.

imcotton · 2019-05-01T01:47:08Z

At a glance, seems related to PR #22449
/cc @addaleax

addaleax · 2019-05-01T22:57:00Z

@imcotton This also seems to occur with v10.0.0, which doesn’t include that PR. But thanks for pinging me, this might be something for me to look into.

addaleax · 2019-05-02T00:25:58Z

Bisecting confirms that this is caused by #18868, which seems to make sense (and may even be intentional). /cc @lpinca

n-clark · 2019-05-02T00:34:33Z

Wow this looks promising! Going to add an error handler to the upgrade socket and see if it resolves my issue (#20477) This change coming from v8.x was definitely unexpected. Thanks for looking into this @addaleax

lpinca · 2019-05-02T05:09:50Z

Yes, the 'error' event on the socket should be explicitly handled by the user after the 'connect' or 'upgrade' event is emitted. #18868 was tagged semver-major for this reason.

onewayticket255 · 2019-06-07T03:21:06Z

Add this
requestSocket.on('error',e=>console.log(e))
The reason is that requestSocket may throw this error

Error: read ECONNRESET
    at TCP.onStreamRead (internal/stream_base_commons.js:183:27) {
  errno: 'ECONNRESET',
  code: 'ECONNRESET',
  syscall: 'read'
}

vinbarnes · 2019-06-12T00:46:51Z

Add this
requestSocket.on('error',e=>console.log(e))

Add this where exactly? We're also getting this seemingly spurious error and would like to squelch it in our logs.

gajus · 2019-07-19T18:38:47Z

I have replicated what I believe is the same issue as described here.

https://github.com/gajus/http-proxy-connection-close

gajus · 2019-07-19T20:54:16Z

Probably not the same issues as described here. However, here is the solution to my issue.

https://stackoverflow.com/a/57119471/368691

mack1290 · 2019-09-18T03:18:47Z

Hey, Any fix for this problem?

diegoug · 2020-01-12T03:03:09Z

@mack1290 I could handle the error with the following code: #23169 (comment)

serverSocket.on('error', (error) => {
  log.error({
    error: serializeError(error)
  }, 'server socket error');

  clientSocket.write([
    'HTTP/1.1 503 Service Unavailable',
    'connection: close'
  ].join('\n') + '\n\n');

  clientSocket.end();
});

However, it is more a way to handle it than to make it a solution or to know what the problem is, in fact there is a lot of follow-up in the next thread

#27916

manjufy · 2020-03-08T13:31:39Z

This is full stack, if someone is able to get something from it:
2019-03-19 08:55:57:755 - error: Error: read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:111:27) -------------------- at Protocol._enqueue (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\mysql\lib\protocol\Protocol.js:144:48) at Connection.query (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\mysql\lib\Connection.js:200:25) at C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\knex\lib\dialects\mysql\index.js:144:18 at Promise._execute (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\debuggability.js:313:9) at Promise._resolveFromExecutor (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\promise.js:483:18) at new Promise (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\promise.js:79:10) at Client_MySQL._query (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\knex\lib\dialects\mysql\index.js:135:12) at Client_MySQL.query (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\knex\lib\client.js:192:17) at Runner.<anonymous> (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\knex\lib\runner.js:138:36) at Runner.tryCatcher (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\util.js:16:23) at Runner.query (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\method.js:15:34) at C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\knex\lib\runner.js:47:21 at tryCatcher (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\util.js:16:23) at C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\using.js:185:26 at tryCatcher (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\util.js:16:23) at Promise._settlePromiseFromHandler (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\promise.js:512:31)

I've been strungling with this for quite some time now. Application is using knex, pooling, mysql.
My guess is (at least in my case) it has something to do with MySQL server. Sometimes server is killing connections if they're idle for sometime and the application crashes with error:
error:

Error: read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:111:27) -------------------- at Protocol._enqueue
We have this (or similar problem) with other clients for mysql (MySQL Workbench, Heidi, ...), and we managed to solve them for each client seperately.

https://www.heidisql.com/forum.php?t=15850

https://stackoverflow.com/questions/31811517/mysql-workbench-drops-connection-when-idle/34498662

With node, however, this keeps happening only when the code runs on localhost. It does not happen when the code is running on Digital ocean (https). Mysql server is on third machine and the same in both cases.

So I believe the problem is that mysql needs some ping quite often in order to keep connections alive.
If someone is able to solve this, it would be great..

Have been experiencing the same issue.
@grega913 have you managed to find the root cause for the issue yet.

grega913 · 2020-03-08T15:08:41Z

I believe this got something to do with settimeout setting on mysql part, but honestly not sure anymore. Some suggested solution to make a dummy query (SELECT 1 from ….) every 10 sec . . Sorry for not being able to provide a better solution. regards From: Manjunath Reddy <[email protected]> Sent: Sunday, March 8, 2020 2:32 PM To: nodejs/node <[email protected]> Cc: Gregor Sotosek <[email protected]>; Mention <[email protected]> Subject: Re: [nodejs/node] Almost guaranteed ECONNRESET on piped sockets if connecting to Node's HTTPS server which answers with "connection: 'close'" after setImmediate or setTimeout, on OSX (#23169) This is full stack, if someone is able to get something from it: 2019-03-19 08:55:57:755 - error: Error: read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:111:27) -------------------- at Protocol._enqueue (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\mysql\lib\protocol\Protocol.js:144:48) at Connection.query (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\mysql\lib\Connection.js:200:25) at C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\knex\lib\dialects\mysql\index.js:144:18 at Promise._execute (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\debuggability.js:313:9) at Promise._resolveFromExecutor (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\promise.js:483:18) at new Promise (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\promise.js:79:10) at Client_MySQL._query (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\knex\lib\dialects\mysql\index.js:135:12) at Client_MySQL.query (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\knex\lib\client.js:192:17) at Runner.<anonymous> (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\knex\lib\runner.js:138:36) at Runner.tryCatcher (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\util.js:16:23) at Runner.query (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\method.js:15:34) at C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\knex\lib\runner.js:47:21 at tryCatcher (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\util.js:16:23) at C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\using.js:185:26 at tryCatcher (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\util.js:16:23) at Promise._settlePromiseFromHandler (C:\Users\dms3\Documents\testnode\bebackend\bebackend_201902\node_modules\bluebird\js\release\promise.js:512:31) I've been strungling with this for quite some time now. Application is using knex, pooling, mysql. My guess is (at least in my case) it has something to do with MySQL server. Sometimes server is killing connections if they're idle for sometime and the application crashes with error: error: Error: read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:111:27) -------------------- at Protocol._enqueue We have this (or similar problem) with other clients for mysql (MySQL Workbench, Heidi, ...), and we managed to solve them for each client seperately. 1. https://www.heidisql.com/forum.php?t=15850 2. https://stackoverflow.com/questions/31811517/mysql-workbench-drops-connection-when-idle/34498662 With node, however, this keeps happening only when the code runs on localhost. It does not happen when the code is running on Digital ocean (https). Mysql server is on third machine and the same in both cases. So I believe the problem is that mysql needs some ping quite often in order to keep connections alive. If someone is able to solve this, it would be great.. I have been experiencing the same issue. @grega913 <https://github.com/grega913> have you managed to find the root cause for the issue yet. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23169?email_source=notifications&email_token=ADBTWA4X7EQVNGUUCGKPEFLRGOM4BA5CNFSM4FYC5L4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOEWENY#issuecomment-596206135> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADBTWA4GSU64EYLDW7JTE43RGOM4BANCNFSM4FYC5L4A> . <https://github.com/notifications/beacon/ADBTWAZRTXZYCTO4ESG4KYDRGOM4BA5CNFSM4FYC5L4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOEWENY.gif>

mmomtchev · 2020-10-09T18:35:04Z

The reason you get so much ECONNRESETs on OS X is that OS X lingers sockets very aggressively. In fact, curl always closes its socket by a RST, instead of a normal FIN/ACK exchange.
One thing to try is to curl from another host, Linux, for example to your OS X host - you will get an EPIPE on the external facing socket (which will receive a FIN/ACK from Linux), but you will still get an ECONNRESET on your internal socket - between your proxy and your server.
Otherwise the issue is not limited to OS X. I was able to reproduce it on Linux, but with much lower probability (about 5% on Linux vs maybe 95% on OS X). Try running your curl command in while /bin/true loop, you will get an ECONNRESET in no more than 20 attempts. In this case the problem is caused by a race condition between making the read syscall from userland and the kernel closing the connection. The faster the connection, the more probable the problem will be - your best chances of reproducing it is with the loopback interface.
Globally, I don't think there is any problem in Node.js. This is a completely normal behavior of a TCP socket. If you implement a proxy in C using low-level sockets, you are going to get the exactly same behavior.
And in this particular case the ECONNRESET event is sent from libuv up the streams layer.
I wonder if it is worth it to try to filter out this, and if it belongs in Node.js streams or in libuv.
One thing I noticed while looking at the Node.js streams is that someone implemented a similar filter for Windows.
So maybe one could say that Node.js is supposedly a higher-level language that should hide those details from the developer. Food for thought.

mmomtchev · 2020-10-20T12:39:05Z

@ronag, curl on OS X sends a RST because of a very aggressive lingering on the socket, your take?
Should there be an 'error' event or should the reset be treated as a normal close?

HardikOO79 · 2021-02-17T08:32:39Z

Any fix for this? I am facing the same when running cron job on server.

Aashir1 · 2021-04-09T19:08:24Z

facing this issue while connecting my nodeJs application with remote database, while workbench successfully connected with remote database
Error:
read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:205:27) { errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read', fatal: true }

cloudnotify · 2021-06-21T16:40:08Z

Facing the same issue randomly, can any one help on it?

 [exec] Stack trace:
 [exec] Error: read ECONNRESET
 [exec]     at TCP.onStreamRead (internal/stream_base_commons.js:205:27)
 [exec] 
 [exec] Console trace:
 [exec] Error
 [exec]     at StandardRenderer.error (/root/.nvm/v12.16.1/lib/node_modules/bower/lib/renderers/StandardRenderer.js:88:37)
 [exec]     at Logger.<anonymous> (/root/.nvm/v12.16.1/lib/node_modules/bower/lib/bin/bower.js:113:30)
 [exec]     at Logger.emit (events.js:311:20)
 [exec]     at Logger.emit (/root/.nvm/v12.16.1/lib/node_modules/bower/lib/node_modules/bower-logger/lib/Logger.js:29:39)
 [exec]     at /root/.nvm/v12.16.1/lib/node_modules/bower/lib/commands/index.js:49:24
 [exec]     at _rejected (/root/.nvm/v12.16.1/lib/node_modules/bower/lib/node_modules/q/q.js:864:24)
 [exec]     at /root/.nvm/v12.16.1/lib/node_modules/bower/lib/node_modules/q/q.js:890:30
 [exec]     at Promise.when (/root/.nvm/v12.16.1/lib/node_modules/bower/lib/node_modules/q/q.js:1142:31)
 [exec]     at Promise.promise.promiseDispatch (/root/.nvm/v12.16.1/lib/node_modules/bower/lib/node_modules/q/q.js:808:41)
 [exec]     at /root/.nvm/v12.16.1/lib/node_modules/bower/lib/node_modules/q/q.js:624:44
 [exec] System info:
 [exec] Bower version: 1.8.8
 [exec] Node version: 12.16.1
 [exec] OS: Linux 3.10.0-957.12.2.el7.x86_64 x64
 [exec] Result: 1
 [echo] ExitValue from the task is : 1

i-m-alok · 2021-08-28T06:42:54Z

Suffering from the same issue anyone please help me out?

temp3l · 2021-10-26T21:35:48Z

For me this Bug happens when my http-proxy talks http1 but server and client agree on http2

Bug almost guaranteed with http2-Servers like google and curl-options:

curl --http1.0 ...
curl --http2 ...

Works fine when forcing 1.1 from the client:
curl --http1.1 ...

Assuming the server wants to push some data when proxy or client already closed the connection.

Vishal8523 · 2024-08-07T12:37:19Z

any update ?

ibc mentioned this issue Mar 7, 2019

Node 10: Unhandled 'error' event in wsServer.on('request') theturtle32/WebSocket-Node#351

Closed

ebaauw mentioned this issue Apr 6, 2019

Homebridge Crashs and shutdown ebaauw/homebridge-zp#66

Closed

addaleax added the http Issues or PRs related to the http subsystem. label May 3, 2019

xPaw mentioned this issue Jun 10, 2019

Randomly occurring crashes due to unhandled error in events.js thelounge/thelounge#3200

Closed

byCedric mentioned this issue Jun 16, 2019

Expo server crashes often. expo/expo-cli#519

Closed

TeddyDD mentioned this issue Jul 5, 2019

Konga crashes after some period of time pantsel/konga#410

Open

silh mentioned this issue Feb 20, 2020

Proxy issue between two vue apps when created with vue-cli3 vuejs/vue-cli#3738

Open

jasnell added the help wanted Issues that need assistance from volunteers or PRs that need help to proceed. label Jun 26, 2020

Ragzouken mentioned this issue Aug 21, 2020

zone stops accepting new connections Ragzouken/zone#56

Closed

mmomtchev mentioned this issue Nov 6, 2020

Closing a socket with a pending read makes Windows send a TCP RST packet libuv/libuv#3034

Closed

mmomtchev mentioned this issue Nov 19, 2020

res.end() from a https.server() handler sends a RST packet provoking ECONNRESET #36180

Closed

mmomtchev mentioned this issue Dec 31, 2020

http: replace destroySoon with socket.end #36205

Open

2 tasks

endel mentioned this issue Sep 13, 2021

ENOENT on player disconnect colyseus/colyseus#449

Closed

1 task

mikkorantalainen mentioned this issue Jan 31, 2022

The online demo doesn't seem to match the actual source code thealmarques/tinymce-collaborative-editing-plugin#2

Open

mark-wiemer mentioned this issue Jun 20, 2022

Cannot test via GitHub Actions on mac: Error: read ECONNRESET at TLSWrap.onStreamRead mark-wiemer/hello-vscode-extension#10

Closed

This comment was marked as spam.

Sign in to view

johenning mentioned this issue Apr 17, 2024

AxiosError: maxContentLength size of -1 exceeded axios/axios#4806

Closed

Almost guaranteed ECONNRESET on piped sockets if connecting to Node's HTTPS server which answers with "connection: 'close'" after setImmediate or setTimeout, on OSX #23169

Almost guaranteed ECONNRESET on piped sockets if connecting to Node's HTTPS server which answers with "connection: 'close'" after setImmediate or setTimeout, on OSX #23169

Comments

decadent commented Sep 29, 2018

decadent commented Sep 30, 2018

decadent commented Sep 30, 2018

crazywako commented Oct 2, 2018

decadent commented Oct 2, 2018

n-clark commented Jan 31, 2019 • edited Loading

ajimix commented Feb 12, 2019

ibc commented Mar 7, 2019

grega913 commented Mar 19, 2019 • edited Loading

grega913 commented Mar 19, 2019

Johnz86 commented Mar 21, 2019

krisselden commented Apr 11, 2019

decadent commented Apr 16, 2019

n-clark commented Apr 30, 2019 • edited Loading

imcotton commented May 1, 2019

addaleax commented May 1, 2019

addaleax commented May 2, 2019

n-clark commented May 2, 2019 • edited Loading

lpinca commented May 2, 2019

onewayticket255 commented Jun 7, 2019

vinbarnes commented Jun 12, 2019

gajus commented Jul 19, 2019

gajus commented Jul 19, 2019

mack1290 commented Sep 18, 2019

diegoug commented Jan 12, 2020

manjufy commented Mar 8, 2020 • edited Loading

grega913 commented Mar 8, 2020 via email

mmomtchev commented Oct 9, 2020

mmomtchev commented Oct 20, 2020 • edited Loading

HardikOO79 commented Feb 17, 2021 • edited Loading

Aashir1 commented Apr 9, 2021

cloudnotify commented Jun 21, 2021

i-m-alok commented Aug 28, 2021

temp3l commented Oct 26, 2021

This comment was marked as spam.

Vishal8523 commented Aug 7, 2024

n-clark commented Jan 31, 2019 •

edited

Loading

grega913 commented Mar 19, 2019 •

edited

Loading

n-clark commented Apr 30, 2019 •

edited

Loading

n-clark commented May 2, 2019 •

edited

Loading

manjufy commented Mar 8, 2020 •

edited

Loading

mmomtchev commented Oct 20, 2020 •

edited

Loading

HardikOO79 commented Feb 17, 2021 •

edited

Loading