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.
export https_proxy=http://myproxy.corp.com:3128 npm install react # fails 503 curl https://npmjs.com # success curl https://registry.npmjs.com/react # 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 firstname.lastname@example.org 3 info using email@example.com 4 verbose npm-session e2f26f188507f056 5 silly install loadCurrentTree 6 silly install readLocalPackageData 7 http fetch GET 503 https://registry.npmjs.org/react 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 ]
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 linux
Exactly what is this error and why does it happen? I can not access https://status.npmjs.org/ or even https://registry.npmjs.org/, 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:
- The proxy configuration is working because the name resolved and an http request was completed.
- 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
registry.npmjs.com 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 - http://www.squid-cache.org/Doc/config/dns_v4_first/
Although it can be worked around the client side, there should be some resolution on the infrastructure of the npmjs.com as well.
Ahhh this is super helpful, thank you. I’ve forwarded this to the ops team.