How to cope with "Error: read ECONNRESET"

[HugoMag]

Hi,
I have a proxy (in http and https. both with web sockets) that is working but if the target application (also in node) is stopped, the proxy receives the following error and stops running:

events.js:72
throw er; // Unhandled 'error' event
^
Error: read ECONNRESET
at errnoException (net.js:901:11)
at TCP.onread (net.js:556:19)

Can anyone please tell me how to overcome this?
I've added a handler to listen to 'error' events but the proxy is still terminated in the event of the target application is stopped.

Thanks!
Best regards,
Hugo

[jcrugzz]

@HugoMag could you please gist a reproducible example of this behavior? If you are listening on the error handler, this should not happen.

[HugoMag]

Hi,
I've created the https://gist.github.com/HugoMag/8914225 with the behavior.
I've tried using the callback API or the Event Emitter API.

From what I've gathered this error happens only in Windows. In OS X is working fine.

Thanks!
Best regards,
Hugo

[wclr]

+1 too have such an issue on Windows, I'm listening to error it still happens.
maybe this related #488

[wclr]

it seems that #488 fixes the issue

[baer]

+1 I can't get my app to stay up since upgrading to 1.x.x and I'm not able to catch it with the proxy error handler.

Error: read ECONNRESET
    at errnoException (net.js:901:11)
    at onread (net.js:556:19)
---------------------------------------------
    at fireErrorCallbacks (net.js:440:15)
    at Socket._destroy (net.js:472:3)
    at onread (net.js:556:10)

[wclr]

@baer try to apply this fix #488

[baer]

That PR does appear to fix the issue. I have two environments exhibiting this problem just to throw some context into the conversation:

Environment 1
node: 0.10.24
node-http-proxy: 1.0.2
OSX

Environment 2
node: 0.10.24
node-http-proxy: 1.0.2
Windows with IIS-Node (Azure Deployment)

They are both proxying to a hitting an IIS (Windows) deployment

[NinoSkopac]

7 years later, I have this issue.

I've copy-pasted the example code from README.md:

Setup a basic stand-alone proxy server

var http = require('http'),
    httpProxy = require('http-proxy');
//
// Create your proxy server and set the target in the options.
//
httpProxy.createProxyServer({target:'http://localhost:9000'}).listen(8000); // See (†)

//
// Create your target server
//
http.createServer(function (req, res) {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.write('request successfully proxied!' + '\n' + JSON.stringify(req.headers, true, 2));
  res.end();
}).listen(9000);

Saved as test.js, started with node test.js, and tested with curl http://x.com --proxy localhost:8000, and I got:

/Users/xxx/VisualStudioProjects/tests/node_modules/http-proxy/lib/http-proxy/index.js:120
    throw err;
    ^

Error: read ECONNRESET
    at TCP.onStreamRead (node:internal/stream_base_commons:211:20) {
  errno: -54,
  code: 'ECONNRESET',
  syscall: 'read'
}

I understand I can listen for error events so the script doesn't crash, but that still doesn't resolve the core issue, which is why the error happens.

---

EDIT

I ran sudo lsof -i :9000 on my mac and found out the port was already being used by php-fpm. Once I changed the ports in the code, it worked. I expected the script to crash at runtime if it can't bind to the necessary ports #bug?

var http = require('http'),
    httpProxy = require('http-proxy');
//
// Create your proxy server and set the target in the options.
//
httpProxy.createProxyServer({target:'http://localhost:14123'}).listen(13123); // See (†)
console.log('Started proxy');

//
// Create your target server
//
http.createServer(function (req, res) {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.write('request successfully proxied!' + '\n' + JSON.stringify(req.headers, true, 2));
  res.end();
}).listen(14123);
console.log('Started webserver');

It works:

xxx@Ninos-MacBook-Pro ~ % curl http://x.com --proxy localhost:13123
request successfully proxied!
{
  "proxy-connection": "Keep-Alive",
  "accept": "*/*",
  "user-agent": "curl/7.64.1",
  "host": "x.com",
  "connection": "close"
}

What I also could've done, to free up the necessary port instead of changing the code is brew services stop php

[yunfan]

how to know which side of this error occured?
i mean it could occured when read from request side and response side

[NinoSkopac]

@yunfan Sorry but i don't understand - language barrier.