Errore 407 dietro il proxy VPN aziendale: npm, Maven e VS Code

La pagina intranet che si apre nel browser dimostra che il proxy funziona per il browser, non per npm o Maven. Ogni client legge la propria configurazione, e una rete raggiungibile solo via VPN aggiunge una seconda domanda: se il client riesca ad arrivare al proxy. Parti dal codice di stato, poi segui la catena di configurazione dello strumento che ha fallito. Ecco perché un client può funzionare mentre quello accanto fallisce.

Che cosa dimostra davvero un 407

Un 407 Proxy Authentication Required arriva dal proxy, non dal registry o dal repository. Il client ha raggiunto il proxy e il proxy ha rifiutato la richiesta, di solito perché le credenziali mancavano, erano malformate o non erano accettate per quella destinazione.

Un timeout racconta una storia diversa. Il client può avere l'indirizzo del proxy sbagliato, nessuna rotta verso il proxy prima che il tunnel sia attivo, oppure una voce di bypass mancante per un host interno. Leggi il testo dell'errore prima di cambiare le credenziali.

Verifica l'host e la porta del proxy, lo schema di autenticazione e se il nome utente richiede un prefisso di dominio. Poi controlla se lo strumento che fallisce legge quel valore da un file, da una variabile d'ambiente o da entrambi. Un nome utente qualificato con il dominio è una causa comune di 407. Lo è anche una password salvata con la codifica sbagliata.

npm legge la propria catena di configurazione

npm accetta le chiavi proxy e https-proxy in un file .npmrc utente o di progetto. Includi lo schema, perché i valori sono URL, e codifica con URL encoding i caratteri riservati in una password, così che una chiocciola non spezzi il valore.

proxy=http://proxy.example.com:8080
https-proxy=http://proxy.example.com:8080
strict-ssl=true

Usa npm config list per vedere quale file ha fornito ogni valore effettivo. Un export della shell come npm_config_proxy può avere la precedenza sul file, e un .npmrc a livello di progetto che contiene una password personale non dovrebbe mai essere committato. Stampa anche il percorso di origine, oltre al valore.

Tieni abilitato strict-ssl. Un proxy che ispeziona TLS può richiedere la CA aziendale nel trust store; disattivare la verifica per superare l'errore nasconde il vero problema di fiducia.

Maven separa i proxy dai mirror

Maven legge proxy e mirror dal file delle impostazioni utente, non dal pom del progetto. Metti i proxy specifici della rete e i mirror dei repository interni in ~/.m2/settings.xml, e lascia le dichiarazioni dei repository pubblici nel progetto, dove devono stare.

Il blocco proxy richiede un id, un flag di attivazione, il protocollo, l'host e la porta, e una voce nonProxyHosts per il repository interno. Metti quei campi nel file delle impostazioni utente, non nel pom del progetto, così un cambio di rete non riscrive la build per tutto il team. Una voce di mirror è separata e punta Maven al repository interno.

Aggiungi il repository interno a nonProxyHosts così Maven si connette direttamente. Senza quella voce, il proxy diventa un salto inutile e il guasto sembra un'interruzione del repository. Una voce di mirror punta al repository interno; non sostituisce l'impostazione del proxy.

Gli sviluppatori che passano da una rete all'altra possono mantenere un file di impostazioni per rete e selezionare la copia giusta all'avvio della shell. Modificare a mano un unico file a ogni spostamento è il modo in cui un portatile funzionante diventa un ticket di supporto.

VS Code e i dev container hanno namespace diversi

VS Code legge http.proxy dalle impostazioni utente o del workspace, inclusi schema e porta. Questo copre le richieste del marketplace e delle estensioni dell'editor stesso, ma non configura automaticamente un terminale o un container avviato dall'editor. Controlla l'ambito dell'impostazione oltre al valore. Un'impostazione del workspace può avere la precedenza su quella utente per un singolo progetto.

Un dev container ha il proprio namespace di rete. Non eredita le variabili proxy dell'host né la rotta VPN dell'host, ed è per questo che una chiamata al marketplace può fallire dentro il container mentre la stessa chiamata funziona sull'host.

Fornisci al container quelle variabili, oppure dagli un resolver e una rotta propri. Quando i nomi si risolvono al suo interno ma il proxy non risponde mai, il pezzo mancante di solito è il percorso, non l'indirizzo.

Liste di bypass e precedenza delle variabili d'ambiente

Aggiungi il gateway VPN, i registry interni e i suffissi DNS privati alla lista di bypass. Se il client prova a raggiungere il gateway VPN attraverso il proxy prima che il tunnel esista, la connessione fallisce in un modo che sembra un'interruzione del proxy. Prova quel bypass con il tunnel abbassato.

Variabili d'ambiente e file possono essere in disaccordo. Esegui il dump di configurazione dello strumento stesso, non quello della shell, e confronta i valori che riporta. Una variabile duplicata in minuscolo, un valore obsoleto in una shell padre o un file di progetto possono tutti avere la meglio sull'impostazione che hai appena modificato.

In CI, passa il proxy come variabile segreta e prova l'installazione di un pacchetto nella stessa immagine. Un 407 dentro un container spesso significa che la variabile lì è semplicemente assente, mentre la shell dell'host ce l'ha.

Annota host e porta del proxy, i suffissi di bypass e il file o la variabile che li fornisce per ogni strumento. Quando un client restituisce 407 e un altro funziona, quell'annotazione trasforma il confronto di quattro configurazioni diverse in un controllo rapido.