Unable to connect to establish a TCP connection (ECONNREFUSED)

[JeffreyArt1]

Version

v17.0.1

Platform

Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64

Subsystem

No response

What steps will reproduce the bug?

I'm trying to connect to a micro-service with this piece of code:

const connect = (host, port) => {
  socket = new require('net').Socket();
  socket.connect(port, host)
    .on('connect', () => console.log('konected!'))
    .on('error', e => console.log(e));
};

connect('localhost', 5098);

this prints out:

Error: connect ECONNREFUSED ::1:5098
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1161:16)
    at TCPConnectWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
  errno: -61,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '::1',
  port: 5098
}

How often does it reproduce? Is there a required condition?

Since installed node 17

What is the expected behavior?

No errors.

What do you see instead?

Error: connect ECONNREFUSED ::1:5098
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1161:16) {
  errno: -61,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '::1',
  port: 5098
}

Additional information

As far a i tested (v14.18.1 and v16.12.0), this only happens in this version of node.

[nsainaney]

We have been having the same issue with node 17 and it appears to be a breaking change with how DNS.lookup works. With node 16, the lookup would return a IPv4 address but with node 17, it returns an IPv6 address which will break most REST clients that hardcode URLS like http://localhost:4040/api if the upstream server only binds to the IPv4 address (e.g. server.listen('127.0.0.1'...) etc..

sudo n latest
   installed : v17.0.1 (with npm 8.1.0)
╭─[prompt redacted]›
╰─$ node
Welcome to Node.js v17.0.1.
Type ".help" for more information.
> require('dns').lookup('localhost', null, (e,a,f) => console.log(e,a,f))
GetAddrInfoReqWrap {
  callback: [Function (anonymous)],
  family: 0,
  hostname: 'localhost',
  oncomplete: [Function: onlookup]
}
> null ::1 6
.exitit
╭─[prompt redacted]›
╰─$ sudo n 16.2.0
   installed : v16.2.0 (with npm 7.13.0)
╭─[prompt redacted]›
╰─$ node
Welcome to Node.js v16.2.0.
Type ".help" for more information.
> require('dns').lookup('localhost', null, (e,a,f) => console.log(e,a,f))
GetAddrInfoReqWrap {
  callback: [Function (anonymous)],
  family: 0,
  hostname: 'localhost',
  oncomplete: [Function: onlookup]
}
> null 127.0.0.1 4

Notice the results are null ::1 6 vs null 127.0.0.1 4 with null options

[richardlau]

For reference the change was #39987 -- Node.js no longer re-sorts results of IP address lookups and returns them as-is (i.e. it no longer ignores how your OS has been configured). You can change the behaviour via the verbatim option to dns.lookup() or set the --dns-result-order command line option to change the default.

[nsainaney]

Thanks, @richardlau. How is one supposed to fix this if they are not the author of the server/client. Libraries like axios do not let you pass in the verbatim option so I suppose we all have to use the command line option until packages catch up.

[nsainaney]

Update to my comment above. When dealing with 3rd party libraries, we can use dns.setDefaultResultOrder('ipv4first') and have to be careful to use this in child_processes as well

[wibobm]

v17.0.1 and v17.1.0 have same issue with remote debugging

Error in debuggerConnector: connect ECONNREFUSED ::1:49629
Error: connect ECONNREFUSED ::1:49629
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1161:16)

[treysis]

@richardlau The better option would of course be to change localhost to 127.0.0.1 when connecting to legacy localhost.

@nsainaney If you cannot fix server/client, the solution would be to stay on the support NodeJS version, i.e. <17, until the authors of server/client add compatibility for Node v17.

[nsainaney]

Thanks @treysis. There are enough workarounds that this isn't an issue for us.

[treysis]

@nsainaney Yes, I'm just mentioning it because I consider it to be the cleanest way. If you set the setDefaultResultOrder option you might forget about that in the future and will limit IPv6 capability of your applications.

[nsainaney]

That's a good point. Thank you