Volta error: Could not download [email protected]

[zsoltvad]

Can't install node with volta, but every other tool (native, nvm, etc.) works. Is it a cert issue?

---

SYSTEM

ProductName: macOS
ProductVersion: 13.3
BuildVersion: 22E252

Kernel: 22.4.0 Darwin

---

NPM INSTALL

> npm i

Volta error: Could not download [email protected]
from https://nodejs.org/dist/v16.13.0/node-v16.13.0-darwin-x64.tar.gz

Please verify your internet connection and ensure the correct version is specified.
Error details written to /Users/zsoltvad/.volta/log/volta-error-2023-05-02_13_25_24.156.log

---

ERROR LOG

Volta v1.1.1

Could not download [email protected] from https://nodejs.org/dist/v16.13.0/node-v16.13.0-darwin-x64.tar.gz

Please verify your internet connection and ensure the correct version is specified.

Error cause: Io Error: Socket is not connected (os error 57)

---

MacOS CONSOLE LOG (filtering with "volta" keyword)

---

CURL

(works perfectly!)

> curl -IL -w "%{http_code}" https://nodejs.org/dist/v16.13.0/node-v16.13.0-darwin-x64.tar.gz

HTTP/2 200 
date: Tue, 02 May 2023 11:34:37 GMT
content-type: application/gzip
content-length: 29939071
last-modified: Tue, 26 Oct 2021 16:02:09 GMT
etag: "61782681-1c8d57f"
cache-control: public, max-age=14400, s-maxage=14400
cf-cache-status: HIT
accept-ranges: bytes
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-content-type-options: nosniff
server: cloudflare
cf-ray: 7c0ff4c16b0cc1c1-BUD

---

NVM

(works perfectly!)

> Downloading and installing node v16.13.0...
Downloading https://nodejs.org/dist/v16.13.0/node-v16.13.0-darwin-x64.tar.xz...
#######         

[ukdvivek]

I am noticing the same issue.

[malsup]

+1

[R80Richard]

+1

[belbebe]

+1

[szgabsz91]

Same for me

[cmaycumber]

I'm getting the same thing but with yarn

[wandersonca]

+1, any workaround? reinstall nvm?

[BryanHunt]

I just ran into this as well and I discovered that volta is not workin at all when I'm connected to work over VPN. When I turn off VPN, I can install anything except node. These two problem may be unrelated.

Any ideas when y'all might get to look at this? I have several CI builds at work that are now broken and I'm probably going to have to ditch volta which makes me very sad.

[iwatchme]

Same for me

[simonsmith]

I am also seeing this. Strangely if I access the binaries directly it seems to work fine. So:

~/.volta/bin/volta install [email protected]

~/.volta/bin/node -v # triggers volta to look up the version in package.json

[timonmasberg]

For me, the issue only exists when I have a VPN active. If so, also calling the URL directly results in an Internal Server Error (https://nodejs.org/dist/v20.2.0/node-v20.2.0-darwin-arm64.tar.gz), which indicates that the error is not from volta.

[lafe]

Can it be related to node itself? Sometimes I can download the given URL (in my case https://nodejs.org/dist/v12.22.12/node-v12.22.12-win-x64.zip) directly through the browser and sometimes I have to retry it, because the first try does not seem to register.

[ravioshankar]

I am also getting same issue on macOS

from https://nodejs.org/dist/v14.15.2/node-v14.15.2-darwin-x64.tar.gz

Please verify your internet connection and ensure the correct version is specified.
Error details written to /Users/ravbhara/.volta/log/volta-error-2023-07-06_11_05_26.131.log ```

[Grawl]

It's because there is no built Node version for your platform. Just tried to install 18.6.1 with that error, changed it to 18.6.0 and its installed

[DacoDev]

Same issue with volta install node (which defaults to the previously mentioned 18.6.1)/node@latest/[email protected]/[email protected]

All return

error: Could not unpack Node v20.5.1

Please ensure the correct version is specified.

EDIT: I gave it a few shakes - removed all traces of Volta and any other installation of node/npm/nvm/nodenv etc. - reinstalled and it's working. There was not much left as far as those other programs go so I think I just needed to clean the slate and importantly, use a fresh terminal window. It is indicated in the instructions but I'd just opened a new tab as I'm sure that instruction was written explicitly to prevent.

[chriskrycho]

Sorry for the long delay on response here – it’s not wholly clear to me that all of these are the same issue, but if it's related to not having the right architecture (as it is in at least some of these cases!) then maybe we could at least provide a better error message (if we can somehow figure out that that's the issue from within the Volta run).

[vladttt1123]

facing the exact same issue error: Could not download Node version registry from https://nodejs.org/dist/index.json

[aidanbiggscw]

We experienced the same issue, any time we did volta install [email protected] we would experience the same error.

Volta v1.1.1

Could not download [email protected]
from https://nodejs.org/dist/v18.18.0/node-v18.18.0-win-x64.zip

Please verify your internet connection and ensure the correct version is specified.

Error cause: Io Error: invalid peer certificate contents: invalid peer certificate: UnknownIssuer

Error cause: Io Error: invalid peer certificate contents: invalid peer certificate: UnknownIssuer

We found that if we run the command curl --head https://nodejs.org/dist/v18.18.0/node-v18.18.0-win-x64.zip

And then

volta install [email protected]

It will then work

[techmatt101]

Downgrading to v1.0.8 seems to resolve the issue us. Which suggests the error could be related to https://github.com/volta-cli/volta/pull/1214 and https://github.com/volta-cli/volta/pull/1375.

Which matches the Error cause: Io Error: invalid peer certificate contents: invalid peer certificate: UnknownIssuer error we have seen in our logs.

We are able to recreate the issue frequently so happy to provide more debug info.

[elwayman02]

We experienced the same issue, any time we did volta install [email protected] we would experience the same error.

Volta v1.1.1

Could not download [email protected]
from https://nodejs.org/dist/v18.18.0/node-v18.18.0-win-x64.zip

Please verify your internet connection and ensure the correct version is specified.

Error cause: Io Error: invalid peer certificate contents: invalid peer certificate: UnknownIssuer

Error cause: Io Error: invalid peer certificate contents: invalid peer certificate: UnknownIssuer

We found that if we run the command curl --head https://nodejs.org/dist/v18.18.0/node-v18.18.0-win-x64.zip

And then

volta install [email protected]

It will then work

Sadly, not a universal fix:

curl --head https://nodejs.org/dist/v18.18.2/node-v18.18.2-darwin-x64.tar.gz
curl: (6) Could not resolve host: nodejs.org

Tried your exact command (though I'm on mac) as well:

curl --head https://nodejs.org/dist/v18.18.0/node-v18.18.0-win-x64.zip
curl: (6) Could not resolve host: nodejs.org

[indy-singh]

Errr, that means you can't reach nodejs at all. Totally different problem.

On Mon, 30 Oct 2023, 23:12 Jordan Hawker, @.***> wrote:

We experienced the same issue, any time we did volta install @.*** we would experience the same error.

Volta v1.1.1

Could not download @.*** from https://nodejs.org/dist/v18.18.0/node-v18.18.0-win-x64.zip

Please verify your internet connection and ensure the correct version is specified.

Error cause: Io Error: invalid peer certificate contents: invalid peer certificate: UnknownIssuer

Error cause: Io Error: invalid peer certificate contents: invalid peer certificate: UnknownIssuer

We found that if we run the command curl --head https://nodejs.org/dist/v18.18.0/node-v18.18.0-win-x64.zip

And then

volta install @.***

It will then work

Sadly, not a universal fix:

curl --head https://nodejs.org/dist/v18.18.2/node-v18.18.2-darwin-x64.tar.gz curl: (6) Could not resolve host: nodejs.org

— Reply to this email directly, view it on GitHub https://github.com/volta-cli/volta/issues/1506#issuecomment-1786188497, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAORQWXMSXVYD2NBEKUD543YCAX67AVCNFSM6AAAAAAXS5VEHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBWGE4DQNBZG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[eodb]

I'm working on osx and experiencing exact the same issue as @zsoltvad. Using volta v1.1.1. 'volta install node' or 'volta install yarn' fails with the same error when working behind a VPN.

Error in the log: Please verify your internet connection and ensure the correct version is specified. Error cause: Io Error: Socket is not connected (os error 57)

It works without any issue when the VPN is not used, but since we are always working within the VPN, this is a bit cumbersome. Any news on the topic?

[sumugapadman]

+1 . This issue is still persistent in OSX when working with VPN's.

Could not download [email protected]
from https://nodejs.org/dist/v18.16.0/node-v18.16.0-darwin-arm64.tar.gz

Please verify your internet connection and ensure the correct version is specified.

[ShadowLNC]

I think this might relate to DNS lookup in some way. Even when I set my /etc/hosts to have 127.0.0.1 nodejs.org I got the same connection issue - which (I think) means it was still trying to connect to something external. I know for a fact that my employer blocks access to external DNS servers while connected to the VPN.

I happen to have Squid proxy running in a Docker container (on the same machine, on the VPN) for other purposes. I ran the following command: HTTPS_PROXY='http://127.0.0.1:3126' volta --verbose fetch node@22 and it immediately connected.

I am not certain if Volta (specifically, its attohttpc dependency) dependency is delegating the DNS lookup to the proxy, but I suspect it is.

(I got a certificate error at first, because I still had my /etc/hosts entry 😛 but I removed it and then it was successful.)

[ShadowLNC]

Update - it's IPv6.

(NB: I have edited this post a bit to reflect my new discoveries after I originally posted this.)

It seems like Volta or its dependency attohttpc is leveraging Happy Eyeballs in a way that means the application fails if IPv6 is not available on the given network adapter (causing os error 57 aka socket is not connected).

If IPv6 link-local is available (i.e. when not on VPN), then IPv4 wins and the IPv6 connection will get os error 65 (no route to host), but it is ignored. It's unclear why os error 57 (socket is not connected) isn't ignored by attohttpc when the IPv4 request is still in flight.

It is also unclear under what circumstances IPv6 would not be available for even link-local purposes, and it may simply be a limitation of or defect in the VPN client (in my case, the Cisco SecureClient).

---

My Testing Methodology (expand)

I've been using volta install node@23 since Node 23 isn't out yet, and can't be installed, and won't download anything unnecessarily (in this case "success" looks like a "no matching version" error). After each test, I also removed the cache with rm ~/.volta/cache/node/index.json* to ensure a new connection attempt on the following test.

I ran a Wireshark packet capture and found that it makes a DNS lookup and gets both A and AAAA records, and in one measured test, the A records arrived first.

I did not use /etc/hosts for any of this testing due to my previous experience with the record seemingly being ignored.

Local DNS

Based on my previous comment in this issue, /etc/hosts is ignored (edit: I'm looking further into this but will post as a separate comment).

I set up a dnsmasq instance in Docker (exposed via port 5153). I then added the following line:

# So that macOS won't cache it for long
local-ttl=10

host-record=nodejs.org,127.0.0.1

Then, I added the file /etc/resolver/nodejs.org (this only works on macOS):

nameserver 127.0.0.1
port 5153
options timeout:1

I verified the system was using my local dnsmasq instance by watching the resolved address with ping nodejs.org. Then, running volta, I saw a certificate error, which is consistent with my self-signed local certificate.

IPv4 DNS (Only A Records)

I then removed the 127.0.0.1 entry and added the current upstream A (IPv4) records:

host-record=nodejs.org,104.20.22.46
host-record=nodejs.org,104.20.23.46

And my command worked.

IPv4/IPv6 Hybrid DNS (Both A and AAAA Records)

When I added the AAAA records in addition to the A records (for a total of 4 records):

host-record=nodejs.org,2606:4700:10::6814:172e
host-record=nodejs.org,2606:4700:10::6814:162e

Volta refused to connect.

IPv6 DNS (Only AAAA Records)

When I removed the A records, leaving just the AAAA records, I got the same result (os error 57).

Off the VPN

• With A records only: Success
• With both AAAA and A records: Success
• With AAAA records only: Error cause: Io Error: No route to host (os error 65)

(I explicitly configured IPv6 to Link-Local Only in System Preferences, there is no option to disable it in my dropdown, and I didn't mess around too much with this. I have IPv6 set this way for security, as tethering from Android gives no IPv6 firewall, and so my local services would be exposed to the wider internet.)

Summary From Testing

• volta (or presumably its attohttpc dependency) will always ~~prefer~~ attempt to connect to IPv6 if records are available in DNS.
• It actually appears to wait for both A and AAAA record queries to resolve before attempting a connection.
• This network request appears to successfully fall back to IPv4 if os error 65 is returned.
• Something about the VPN clients (in my case, the Cisco SecureClient) causes os error 57 instead.

---

On the topic of /etc/hosts and further tests (off VPN)

So at some point as I was writing this or typing it out, I realised that it couldn't possibly be "preferring" IPv6 if I had it disabled. And how come /etc/hosts was seemingly ignored, as if it was querying upstream (like Node's dns.resolve()), and yet /etc/resolver/nodejs.org was respected (unlike Node's dns.resolve())?

So I changed my dnsmasq config to have the following lines:

log-queries
log-debug
# Plus the local-ttl entry and all 4 host-records from above

And ran a quick volta command to confirm that it was looking up both A and AAAA records.

dnsmasq[1]: query[A] nodejs.org from 192.168.65.1
dnsmasq[1]: config nodejs.org is 104.20.22.46
dnsmasq[1]: config nodejs.org is 104.20.23.46
dnsmasq[1]: query[AAAA] nodejs.org from 192.168.65.1
dnsmasq[1]: config nodejs.org is 2606:4700:10::6814:172e
dnsmasq[1]: config nodejs.org is 2606:4700:10::6814:162e

I went into my /etc/hosts and put in a few entries:

127.0.0.1       nodejs.org
::1             nodejs.org

When I ran volta, I got the certificate error again, indicating it connected to my local machine. In the dnsmasq logs, there were no queries. I decided to try a bunch of different entries in /etc/hosts.

I picked 169.254.99.99 as an IP which should be unreachable (it's part of the self-assigned non-DHCP block) and didn't respond to ping. Presumably it was unallocated, I just wanted something that would achieve a slow "connection timed out". On IPv6, I used 100:: from the "discard prefix" where all traffic will be dropped.

My phone's IP is reachable, but will refuse connections as it doesn't have a webserver running.

Results

Key for IPv6: 🚫 Link-Local Only, 🔗 Internet Link

/etc/hosts IPv4	/etc/hosts IPv6	dnsmasq Queries	IPv6	Volta Result
None	None	A, AAAA	🚫	✅
127.0.0.1	::1	None	🚫	🔒 Cert Error (localhost)
127.0.0.1	None	AAAA	🚫	🔒 Cert Error (localhost IPv4 wins, no IPv6 route)
None	::1	A	🚫	🔒 Cert Error (localhost IPv6 wins)
169.254.99.99	None	AAAA	🚫	❌ (no route to host, os error 65)
169.254.99.99	None	AAAA	🔗	✅ (IPv6 wins)
My Phone 📱	None	AAAA	🚫	❌ (no route to host, os error 65)
My Phone 📱	None	AAAA	🔗	✅ (IPv6 wins)
My Phone 📱	My Phone 📱	None	🚫	❌ (no route to host)
My Phone 📱	My Phone 📱	None	🔗	❌ (connection refused, os error 61)
169.254.99.99	My Phone 📱	None	🔗	❌ (connection refused, os error 61)
None	My Phone 📱	A	🔗	✅ (IPv4 wins)
169.254.99.99	100::	None	🔗	❌ (connection timed out)
169.254.99.99	100::	None	🚫	❌ (no route to host, os error 65)

Note: In certain circumstances, I found Volta (or more correctly, the macOS system resolver) continued making queries for A or AAAA and ignored the corresponding /etc/hosts entry, but when I changed the entries, this resolved (pun not intended) itself, and I couldn't reproduce the issue (despite seeing it 2 or 3 times). I suspect macOS may have been unable to read the updated /etc/hosts entries correctly for some reason.

Conclusions

• Queries for A and AAAA read /etc/hosts independently - you need both an IPv4 and an IPv6 entry to suppress any upstream queries.
• On the VPN, something about the os error 57 (socket is not connected) via IPv6 throws an unhandled exception and immediately terminates Happy Eyeballs.
• Conversely, os error 65 (no route to host) is silently handled as part of Happy Eyeballs.
• Excluding the os error 57 (socket is not connected) situation, if both connections fail, then the error from the IPv6 connection is shown, regardless of which finishes first.