Node >v16.6.2 results in ECONNRESET behind proxy

[erikbrgn]

Version

=16.7.0

Platform

Darwin 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:37 PDT 2022; root:xnu-8020.121.3~4/RELEASE_ARM64_T6000 arm64

Subsystem

No response

What steps will reproduce the bug?

Hard to say as it might be connected to company proxy/firewall, however, running (any) npm command results in a ECONNRESET error on node versions above 16.6.2 (tried every minor version above up until LTS 18). Everything below 16.7.0 works fine.

This has to be done behind a proxy, set npm proxy by npm config set proxy http://YOURPROXY and npm config set https-proxy http://YOURPROXY (if there is one). Also make sure to set appropriate env variables.

Use nvm to easily switch between node versions and make sure to clean cache.

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

Everytime.

What is the expected behavior?

No ECONNRESET error on node versions higher than 16.6.2

What do you see instead?

npm ERR! code ECONNRESET
npm ERR! syscall read
npm ERR! errno -54
npm ERR! network read ECONNRESET
npm ERR! network This is a problem related to network connectivity.
npm ERR! network In most cases you are behind a proxy or have bad network settings.
npm ERR! network 
npm ERR! network If you are behind a proxy, please make sure that the
npm ERR! network 'proxy' config is set properly.  See: 'npm help config'

Additional information

I've tried on a different machine with the same results (Linux 5.4.0-121-generic #137-Ubuntu SMP Wed Jun 15 13:33:07 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux.). I can't seem to find anything between 16.6.2 and 16.7.0 that might be responsible for this behavior though. Perhaps someone here can enlighten me.

[bnoordhuis]

ECONNRESET means the other end closed the connection. You're reporting this as a bug, which it probably isn't, at least not in node. I can convert it to a discussion if help is more what you're looking for.

[erikbrgn]

Sure.

I was thinking something must’ve been introduced in 16.7.0 that changed the behavior (perhaps an unintended bug), but in the end help (be it a discussion) would be great.

[bnoordhuis]

If you think it's a regression (could be, it happens) and are in a position to run git-bisect, that'd be very helpful. I went over the list of commits between v16.6.2 and v16.7.0 and nothing obvious stands out.

[bnoordhuis]

Converted to a discussion then.

[navneetagrwl]

Same Issue, I tried with node 16.5.0, 16.6.0, 16.10.0 but getting same error

[Limsanity]

I spend some time diving into the problems and here is summary:

1. npm cause the problem，in this commit npm throw ECONNRESET error even if promise resolve, so you will get this problem after npm v7.19.0.
2. ECONNRESET indicate that server close the connection, for example if you use clash as proxy tool and use socks5 type, it will close the inbound socket immediately, if you comment this line of code and rebuild clash, ECONNRESET would be gone.
3. simplify the problem, if you use https.request to send a request to proxy server like nginx without connection: keep-alive header, you would get ECONNRESET error too, but it is ok with connection:keep-alive.

so just delay the proxy side socket close timing.

[duchymor]

In my case the version doesn't matter. I'm using current latest NODE 16, 18, 19 with updated NPM to 9.3.1.
On various projects I get different results for npm ci:

• PROJECT1, thousands of packages - fails every time
• PROJECT2, hundreds of packages - node 16 OK, 18 and 19 fails
• PROJECT3, very few packages - node 16, 18, 19 all OK

[hlj]

I install a package use npm install https://gitlab.matrix.org/api/v4/projects/27/packages/npm/@matrix-org/olm/-/@matrix-org/olm-3.2.3.tgz and set proxy to http://127.0.0.1:7890。 In node v16.15.1, This has a error: "ECONNRESET"。When I switch the node to v14.21.2，It's OK。 So I wondering maybe this is a bug from v16。

[raulcesar]

I had this issue with node version 18.15.0.
I use a local proxy, so my settings are as follows (from ~/.npmrc):

proxy=http://localhost:3128/
https-proxy=http://localhost:3128/
https_proxy=http://localhost:3128/
strict-ssl=false

On node version 16.19.1, no issues, so I was about ready to just downgrade, but as a last ditch effort I changed my proxy to 127.0.0.1 (instead of localhost) and it worked (node 18 and 16)!!!

I then decided to tinker with /etc/hosts file.
My ORIGINAL hosts file is as follows:

127.0.1.1       labdev.localdomain    labdev
::1             labdev.localdomain      labdev

I changed it to this:

127.0.1.1       labdev.localdomain      labdev  localhost
::1             labdev.localdomain      labdev

and it worked (both with node 16.x and 18.x)

IF I change hosts file to this:

127.0.1.1       labdev.localdomain      labdev  localhost
::1             labdev.localdomain      labdev  localhost

It again fails on node 18.x

Notice that in the working config, I explicitly put in "localhost" ONLY on the ipv4 line (127.0.1.1) and NOT the ipv6 line.

I decided to run npm install with --loglevel verbose, and noticed that the error was ECONNREFUSED ::1:3128

So in my case, I think that perhaps in node 18, it gives preference to ip6 when name resolves to ipv4 and ipv6 addresses, and my proxy probably only works with ip v4.

So anyway, I ended up solving the problem in my case, just explicitly setting the proxy to 127.0.1.1 (instead of localhost) and all is well!

Hope this helps.

[duchymor]

In our case it was caused by the rate limit on the proxy which isn't documented in our infrastructure. It fits my previous findings when installing small/big dependency tree. And probably also fits different behavior across versions (seems newer version performs additional requests to the repository).

[emmettmcdow]

Having the same issue with the jump from Node 14 to Node 16. mitmproxy/mitmproxy#6001 . TL;DR of my current problem, certain actions seem to "fix"(read: workaround) this. Such as artificially slowing down the proxy by increasing the log level. Accessing the registry using http as opposed to https also fixes it. Or, strangely enough, running the npm install command with sudo. Currently looking into it from the proxy side, but I'm still considering it could be something with the jump from Node 14 to 16. As far as I can tell, nothing stands out to me from the wireshark logs when I go to debug it.

edit: Looks like 18 and 20 work as far as I can tell.

[2HenryCardenas1]

Read this news
https://github.blog/2021-08-23-npm-registry-deprecating-tls-1-0-tls-1-1/

Try this commmand: npm install -g https://tls-test.npmjs.com/tls-test-1.0.0.tgz

[kiwavi]

Using docker too. Switched from node 18.20.2-alpine to node:latest and the errors disappeared.