npm e yarn atrás de um proxy

Os gerenciadores de pacotes fazem o download via HTTPS, então eles precisam de um proxy HTTP CONNECT — que é exatamente o endpoint HTTP s4m na porta 3128. O npm mantém sua própria configuração, então definir as variáveis de ambiente do shell nem sempre é suficiente; geralmente você define tanto proxy quanto https-proxy na configuração do npm para que o tráfego do registro seja roteado. As duas gerações do Yarn diferem: o yarn clássico v1 lê suas próprias configurações de proxy / https-proxy (e em grande parte respeita as do npm), enquanto o Yarn Berry (v2+) usa as chaves httpProxy e httpsProxy em .yarnrc.yml.

Em todos eles, as variáveis de ambiente padrão http_proxy, https_proxy e no_proxy também são respeitadas, que é a maneira mais rápida de corrigir uma única instalação npm em uma máquina restrita. Com o s4m você se autentica com USER:PASS contra proxy.s4m.online:3128. Veja a página do proxy e o guia de variáveis de ambiente compartilhadas; o guia irmão pip e conda cobre o equivalente em Python.

Duas coisas quebram instalações mesmo após o proxy ser configurado. Primeiro, caracteres especiais na senha: se contiver @, : ou #, codifique-os em URL (por exemplo, @ se torna %40) ou a configuração analisa a URL incorretamente. Segundo, uma mistura de registros públicos e privados: coloque qualquer host de registro interno em noproxy para que seja acessado diretamente, enquanto o registro público do npm passa pelo proxy.

O endpoint HTTP do s4m é um proxy de datacenter autenticado, pago conforme o uso — uma combinação ideal para runners de CI e máquinas de desenvolvedor que precisam acessar o npm de trás de uma saída controlada. Não é um proxy residencial e não é um cache de pacotes; para instalações offline, use um espelho de registro real. Quando seu CI precisa de um único IP de saída permitido, adicione um IP pessoal dedicado. Um 407 significa credenciais inválidas — veja o guia 407. O mesmo endpoint alimenta pip/conda e Docker; valide-o com as ferramentas.