Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

npm error EHOSTUNREACH #4237

Closed
2 tasks done
joshcangit opened this issue Jan 16, 2022 · 19 comments
Closed
2 tasks done

npm error EHOSTUNREACH #4237

joshcangit opened this issue Jan 16, 2022 · 19 comments
Labels
Bug thing that needs fixing Needs Triage needs review for next steps Release 8.x work is associated with a specific npm 8 release

Comments

@joshcangit
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

This issue exists in the latest npm version

  • I am using the latest npm

Current Behavior

npm ERR! code EHOSTUNREACH
npm ERR! syscall connect
npm ERR! errno EHOSTUNREACH
npm ERR! request to https://registry.npmjs.org/typescript failed, reason: connect EHOSTUNREACH 2606:4700::6810:1823:443

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/thinkpad/.npm/_logs/2022-01-16T16_01_04_905Z-debug-0.log

Expected Behavior


changed 14 packages in 2m

10 packages are looking for funding
  run `npm fund` for details

Steps To Reproduce

  1. In this environment...
  2. With this config...
  3. Run 'npm install typescript'
  4. See error...

Environment

  • npm: 8.3.0
  • Node.js: v17.3.1
  • OS Name: Ubuntu 20.04.3 LTS
  • System Model Name: ThinkPad X1 Carbon 6th
  • npm config:
; "cli" config from command line options

global = true 

; node bin location = /usr/bin/node
; cwd = /home/joshua
; HOME = /home/joshua
; Run `npm config ls -l` to show all defaults.
@joshcangit joshcangit added Bug thing that needs fixing Needs Triage needs review for next steps Release 8.x work is associated with a specific npm 8 release labels Jan 16, 2022
@joshcangit joshcangit changed the title npm install typescript EHOSTUNREACH npm error EHOSTUNREACH Jan 17, 2022
@joshcangit
Copy link
Author

joshcangit commented Jan 17, 2022

This also occurs for other actions connecting to registry.npmjs.org such as search.

It is also happening on Termux (version 0.118.0).

Environment

  • npm: 8.3.0
  • Node.js: v17.3.1
  • OS Name: Android 11
  • System Model Name: Samsung SM-G973F
  • npm config:
; "user" config from /data/data/com.termux/files/home/.npmrc

foreground-scripts = true

; "cli" config from command line options

global = true 

; node bin location = /data/data/com.termux/files/usr/bin/node
; cwd = /data/data/com.termux/files/home
; HOME = /data/data/com.termux/files/home
; Run `npm config ls -l` to show all defaults.

@joshcangit
Copy link
Author

Going to registry.npmjs.org on the browser works but npm itself was unable to access the web.

My home network seems to be blocking it but after using npm on mobile network, it then works regardless.

I guess it may have something to do with router IPv6 configuration.

@khorben
Copy link

khorben commented Jul 9, 2022

To me this looks more like a problem with the way nodejs uses uv_getaddrinfo(). See nodejs/node#41625 for what seems to be the same issue, and mentions uv_connect(), which should probably try the next address returned upon specific errors.

@treysis
Copy link

treysis commented Aug 10, 2022

The issue seems to be broken IPv6. The host has an IPv6 address and thus tries connecting to npm servers via IPv6. This fails. Maybe the router is blocking IPv6 connections. Since NodeJS doesn't have Happy Eyeballs there is no fallback.

@khorben
Copy link

khorben commented Aug 11, 2022

My own network does not have IPv6 (even locally, except for the fe80:: physical address), and yet this problem occurs. I have to hard-code registry.npmjs.org in /etc/hosts with its IPv4 address for this to work.

@treysis
Copy link

treysis commented Aug 11, 2022

@khorben Really? In that case it's weird that your OS is reporting IPv6 DNS records first if there's no valid route. Which OS are you using?

@khorben
Copy link

khorben commented Aug 11, 2022

NetBSD. As far as I know, IPv6 records are always supposed to be reported before IPv4 records, regardless of the OS. Each and every libc (or resolver library) may implement a different behaviour though.

@khorben
Copy link

khorben commented Aug 11, 2022

And by the way, on that same system, Firefox deals perfectly fine with the same situation and can access registry.npmjs.org without any issue.

@treysis
Copy link

treysis commented Aug 12, 2022

Sure, it's up to the library. On Windows and most Linuxes at least they reorder the DNS results according to the routing table.
Firefox (as virtually every browser) uses the beforementioned mechanism called Happy Eyeballs (which is also useful for kind of round robin selection of multiple IPv4 addresses, e.g.). However, as I also stated earlier, NodeJS doesn't have an implementation for Happy Eyeballs yet.

@joshcangit
Copy link
Author

This seems to be a problem but not anymore on my end.

Should I reopen this?

@treysis
Copy link

treysis commented Aug 13, 2022

No. It's not a problem with npm. Neither with NodeJS.

@priyaapreeti
Copy link

i am not able to fix it pls help..

@treysis
Copy link

treysis commented Jun 24, 2023

@dedinsideout Did you upgrade to Node v20?

@apupier
Copy link

apupier commented Sep 6, 2023

I hit this issue when using npm ci, I used the following workaround:
npm ci --dns-result-order=ipv4first

reference: https://twitter.com/matteocollina/status/1640384245834055680

apupier added a commit to apupier/camel-lsp-client-vscode that referenced this issue Sep 6, 2023
On Jenkins CI host, seems ipV6 is activated but somewhere between the
host and the npmjs website ipV6 is not handled. Consequently applying
workaround of defaulting to ipv4 in priority

npm/cli#4237 (comment)

Signed-off-by: Aurélien Pupier <apupier@redhat.com>
apupier added a commit to apupier/camel-lsp-client-vscode that referenced this issue Sep 6, 2023
On Jenkins CI host, seems ipV6 is activated but somewhere between the
host and the npmjs website ipV6 is not handled. Consequently applying
workaround of defaulting to ipv4 in priority

npm/cli#4237 (comment)

Signed-off-by: Aurélien Pupier <apupier@redhat.com>
@MohammadGhorayshi
Copy link

MohammadGhorayshi commented May 22, 2024

I have this problem and resolve it.
IPv6 was causing network performance issues and compatibility problems with some systems and networks.

Solution: Disabled IPv6 on the Ubuntu server to resolve the performance and compatibility issues.

Edited /etc/sysctl.conf with administrative privileges.
Added the following lines at the end of the file:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Saved the file and applied the changes using the command sudo sysctl -p.

IPv6 is now permanently disabled on the Ubuntu server, and the network performance has improved.
For a detailed explanation of the process and alternative methods, refer to this Medium article: How to Disable IPv6 on Ubuntu Server

If you encounter similar issues, consider disabling IPv6 following these steps or exploring the alternative methods provided in the article.

@treysis
Copy link

treysis commented May 22, 2024

@MohammadGhorayshi No, you are not supposed to disable IPv6! Very bad practice!!!
Better to upgrade to Node 20.

@MohammadGhorayshi
Copy link

@treysis I think someone can't update theire node version, for example use node v14 until, this is not bad practice.
I know upgrade to Node v20 is best practice but I have a project that I can't change Node version and I have to disable IPV6.

thanks man.

@treysis
Copy link

treysis commented May 23, 2024

Disabling IPv6 is bad practice and will cause other problems sooner or later. Better just disable IPv6 lookup in NodeJS by using the verbatim option. Don't introduce a system wide change by disabling it for EVERYTHING.

@Alartan
Copy link

Alartan commented May 27, 2024

Disabling IPv6 is bad practice and will cause other problems sooner or later. Better just disable IPv6 lookup in NodeJS by using the verbatim option. Don't introduce a system wide change by disabling it for EVERYTHING.

Is it possible for you to describe this option?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug thing that needs fixing Needs Triage needs review for next steps Release 8.x work is associated with a specific npm 8 release
Projects
None yet
Development

No branches or pull requests

7 participants