install fails for every version with "not found on server/mirror" despite the file existing

[sagebeme]

Description

nvm install <version> fails for every version I've tried, always after a
consistent ~30s delay, with:

FAILED v<version>: Node.js v<version> not found on server/mirror

This is not actually true -- the files exist and download fine directly:

curl -sI https://nodejs.org/dist/v24.20.0/node-v24.20.0-win-x64.zip
HTTP/1.1 200 OK
Content-Type: application/zip

Steps to reproduce

1. Fresh install of nvm-windows v2.0.0 (nvm-2.0.0-amd64-setup.exe)
2. nvm install 24.20.0 (or any other version)
3. Wait ~30s
4. Fails with "not found on server/mirror"

Versions tried (all fail identically)

• 24.21.0 (latest at time of testing)
• 24.20.0
• 22.17.1 -- notably, this is the exact version already running natively
  on this machine via a separate global Node install, so it's definitely
  a real, existing release

Environment

• nvm --version: 2.0.0
• nvm config: node_mirror is the default https://nodejs.org/dist
• Tried from both PowerShell and Git Bash/MinGW -- same failure in both,
  so it doesn't appear to be shell-specific (despite nvm env flagging
  Git Bash as "Unsupported")
• Windows 11 24H2 (10.0.26100)
• nvm doctor not yet run -- happy to attach output if useful

Expected

nvm install should succeed for versions that are genuinely published on
nodejs.org, since the exact same URLs are reachable via a plain HTTP
client.

[coreybutler]

Please try nvm doctor to see if that provides additional insight. It would help to know if you are behind a proxy too.

NVM for Windows v2 downloads 7z files, not zip files. The doctor command should tell you if there is a problem accessing the downloads, but you can also test with:

curl -o NUL https://nodejs.org/dist/v24.20.0/node-v24.20.0-win-x64.7z

Also, did you try the hotfix.1 release?

[coreybutler]

Tracked in nvm-windows/cli@66c9ed4 (referenced from nvm main). Does not close — still need reporter confirmation / possible timeout-vs-network root cause.

[sagebeme]

Thanks for looking at this. Answers:

• Proxy: none. netsh winhttp show proxy reports "Direct access (no proxy server)", and no HTTP_PROXY/HTTPS_PROXY env vars are set.
• 7z reachability: fine. curl -sI https://nodejs.org/dist/v24.20.0/node-v24.20.0-win-x64.7z returns 200 OK, Content-Type: application/x-7z-compressed, Content-Length: 23617217. So it's not that the 7z asset itself is missing or unreachable from this network.
• nvm doctor: output didn't point at anything obviously wrong -- verify-cache pubkey present, ACLs/shim/proxy paths all resolve, no proxy detected. Pasting the relevant section:

Verify cache
  Pubkey     : present (...\nvm\.verify\pubkey.cer)
  HKCU cache : 0 entries at HKCU\Software\Author Software\Preferences\nvm\VerifyCache
  Mode       : accelerated key ready; cache empty until install/use/reshim

Runtime ACLs
  InstallRoot: ...\nvm\installs
  DataRoot   : ...\nvm
  ShimDir    : ...\nvm\.shim
  Proxy      : ...\nvm\proxy.exe
  Tip        : run elevated `nvm doctor --autofix` to re-lock .shim/proxy DACLs
No checks directory found.

• hotfix.1: hadn't tried it, only tested against the v2.0.0 GA release. I see v2.0.1-hotfix.1 is available as a pre-release -- will try that next and report back.

Given the 7z is reachable directly and there's no proxy in the way, my guess is it's either a bug in how the CLI verifies/resolves that specific asset URL, or something timing-related (every failure I saw landed at almost exactly 30s, which smells like a hardcoded timeout somewhere hitting a slow step rather than a genuine 404).