Installs fail behind proxy


(Domantas Jackūnas) #1

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

NPM work only in old IPV4 World.
(Edarblanco) #2

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.

(Christopher J Brody) #3

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?

(Kat Marchán) #4

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.

(Domantas Jackūnas) #5

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

(Domantas Jackūnas) #6

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.

(Andreas Litt) #7

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?

(Domantas Jackūnas) #8

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.

(Kat Marchán) #9

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

(system) #10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.