npm Community Forum (Archive)

The npm community forum has been discontinued.

To discuss usage of npm, visit the GitHub Support Community.

Installs fail behind proxy

What I Wanted to Do

I wanted to build a project and install any package (for the sake of the example it’s react)

What Happened Instead

As of yesterday, any install behind a squid proxy fails.

Reproduction Steps

export https_proxy=
npm install react  # fails 503
curl  # success
curl # fail 503


0 info it worked if it ends with ok
1 verbose cli [ '/usr/local/bin/node',
1 verbose cli   '/usr/local/bin/npm',
1 verbose cli   'install',
1 verbose cli   'react',
1 verbose cli   '--verbose' ]
2 info using npm@5.6.0
3 info using node@v8.11.3
4 verbose npm-session e2f26f188507f056
5 silly install loadCurrentTree
6 silly install readLocalPackageData
7 http fetch GET 503 70166ms attempt #3
8 silly fetchPackageMetaData error for react@latest 503 Service Unavailable: react@latest
9 verbose stack Error: 503 Service Unavailable: react@latest
9 verbose stack     at fetch.then.res (/usr/local/lib/node_modules/npm/node_modules/pacote/lib/fetchers/registry/fetch.js:42:19)
9 verbose stack     at tryCatcher (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)
9 verbose stack     at Promise._settlePromiseFromHandler (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:512:31)
9 verbose stack     at Promise._settlePromise (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:569:18)
9 verbose stack     at Promise._settlePromise0 (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:614:10)
9 verbose stack     at Promise._settlePromises (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:693:18)
9 verbose stack     at Async._drainQueue (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:133:16)
9 verbose stack     at Async._drainQueues (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:143:10)
9 verbose stack     at Immediate.Async.drainQueues (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:17:14)
9 verbose stack     at runCallback (timers.js:810:20)
9 verbose stack     at tryOnImmediate (timers.js:768:5)
9 verbose stack     at processImmediate [as _immediateCallback] (timers.js:745:5)
10 verbose cwd /
11 verbose Linux 4.16.11-100.fc26.x86_64
12 verbose argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "react" "--verbose"
13 verbose node v8.11.3
14 verbose npm  v5.6.0
15 error code E503
16 error 503 Service Unavailable: react@latest
17 verbose exit [ 1, true ]

Platform Info

Same reproducible within node:8.11.3 docker image

$ npm --versions
5.6.0 as well as npm@latest and yarn
$ node -p process.platform

Exactly what is this error and why does it happen? I can not access or even, was there a change in the servers ?? I live in Cuba, does this influence? Until 2 days ago everything was fine, install perfectly, and yesterday started this.

Proxy in the OP seems to be using http protocol while npm seems to be intended to work over https. Could this explain the issue? I wonder if the documentation may be outdated?

503s are a very general and occasional error. It’s usually just a hiccup in the registry and goes away soon enough. It’s also possible the proxy itself is throwing those 503s, but it’s worth noting that if it got to that point:

  1. The proxy configuration is working because the name resolved and an http request was completed.
  2. It’s not a client-side issue because it’s in the 500 range.

Beyond that? No clue. I also kind of assume the problem spontaneously went away for @JackLeo, since that’s how a lot of support issues end up going.

No it does not as any other resource on the internet works just fine ignoring the http/https protocol in the proxy.

I had occasionally been testing from Friday afternoon until the end of business hours. I had just checked again, and no it did not go away. It’s still there.

We observed the same error behind our corporate firewall since friday afternoon.

After intensive debugging and finally forcing squid to use IPv4 DNS first (the option is called: dns_v4_first), everything works again as expected…

Was something changed regarding the DNS Entries of on friday?

Indeed that works around this. Seems that there are issues with the IPv6 stack on the registry DNS server. Squid docs regards this -

Although it can be worked around the client side, there should be some resolution on the infrastructure of the as well.

Ahhh this is super helpful, thank you. I’ve forwarded this to the ops team.