npm and yarn behind a proxy

Package managers download over HTTPS, so they need an HTTP CONNECT proxy — which is exactly the s4m HTTP endpoint on port 3128. npm keeps its own config, so setting the shell's environment variables is not always enough; you usually set both proxy and https-proxy in npm config so registry traffic is routed. Yarn's two generations differ: classic yarn v1 reads its own proxy / https-proxy settings (and largely honours npm's), while Yarn Berry (v2+) uses httpProxy and httpsProxy keys in .yarnrc.yml.

Across all of them, the standard http_proxy, https_proxy and no_proxy environment variables are honoured too, which is the fastest way to fix a one-off npm install on a locked-down machine. With s4m you authenticate with USER:PASS against proxy.s4m.online:3128. See the proxy page and the shared environment-variable guide; the sibling pip and conda guide covers the Python equivalent.

Two things break installs even after the proxy is set. First, special characters in the password: if it contains @, : or #, URL-encode them (for example @ becomes %40) or the config parses the URL wrong. Second, a mix of public and private registries: put any internal registry host in noproxy so it is reached directly, while the public npm registry goes through the proxy.

s4m's HTTP endpoint is an authenticated datacenter proxy, metered pay-as-you-go — a clean fit for CI runners and developer machines that must reach npm from behind a controlled egress. It is not a residential proxy and it is not a package cache; for offline installs use a real registry mirror. When your CI needs a single allowlisted egress IP, add a dedicated personal IP. A 407 means bad credentials — see the 407 guide. The same endpoint powers pip/conda and Docker; validate it with the tools.