I download nel terminale funzionano, ma le estensioni di VS Code falliscono sulla VPN

I download che riescono nel terminale del container sono una prova reale dell'ambiente di quel terminale. Non dicono nulla sul processo dell'editor, sull'installatore di estensioni o sul binario che un'estensione scarica in seguito. Copiare le variabili proxy tra questi tre trasforma una richiesta fallita in un intero pomeriggio di modifiche non correlate.

Due ambienti di solito differiscono esattamente in un aspetto. Trovare quell'aspetto è più veloce che leggere due volte la documentazione del proxy.

Quale processo ha fatto la richiesta fallita

Tre richieste possono fallire durante una sola installazione, e ciascuna ha la propria identità di rete. L'editor chiede al Marketplace i metadati e un URL del pacchetto, poi scarica il pacchetto. Solo dopo l'host delle estensioni esegue codice che può recuperare un language server o un binario proprio. La fase che si è rotta decide quale processo ha bisogno di un proxy, e la superficie dell'errore raramente nomina la fase.

Un terminale funzionante dimostra che il container può raggiungere Internet, non che l'editor possa. Leggi il log dell'estensione per l'ultimo URL che ha tentato. L'host indicato lì identifica il processo e la policy che si applica a esso.

L'editor locale e il container remoto sono due ambienti

In un workspace remoto un'estensione viene eseguita dal lato che il suo tipo dichiara. Le estensioni di interfaccia restano con l'editor locale, e le estensioni del workspace vengono eseguite nel container. Un proxy impostato in uno è invisibile all'altro, e una ricostruzione ricrea l'ambiente del container dal suo file di configurazione invece che da ciò che hai esportato in una shell. Questa separazione spiega perché la stessa estensione si installa su un portatile e fallisce nello stesso progetto via SSH.

Leggi il percorso di installazione prima di modificare qualsiasi cosa. Quando il log segnala un'installazione remota, è l'ambiente del container quello che conta.

Metti il proxy dove inizia la richiesta

Per un Dev Container che ha davvero bisogno di un proxy HTTP, la variabile appartiene alla configurazione del container perché una ricostruzione la riproduca. Il frammento qui sotto la imposta per quell'ambiente. L'indirizzo segnaposto sostituisce il tuo gateway, e le esclusioni non sono un riempimento facoltativo.

"containerEnv": {
  "HTTP_PROXY": "http://proxy.corp.example:8080",
  "HTTPS_PROXY": "http://proxy.corp.example:8080",
  "NO_PROXY": "localhost,127.0.0.1,.internal.example"
}

Il nome della variabile descrive il protocollo di destinazione, quindi un valore HTTPS_PROXY può legittimamente iniziare con http. Applica la modifica tramite il percorso di ricostruzione supportato e mantieni le esclusioni, perché un proxy che intercetta host interni rompe servizi di cui il container ha bisogno.

Separa i fallimenti di fiducia dalla raggiungibilità

Un proxy che si connette e poi restituisce un errore di verifica del certificato ha raggiunto una fase più avanzata di uno che rifiuta la connessione. Il primo fallimento vuole il materiale di fiducia approvato dall'organizzazione installato nell'ambiente che esegue la richiesta. Il secondo vuole un indirizzo e una porta raggiungibili. Trattarli come un solo problema produce una correzione che non funziona per nessuno dei due.

Disattivare la verifica, o eseguire l'editor con privilegi elevati, non è una riparazione per un proxy mancante o una catena di fiducia assente. Entrambe scambiano un errore visibile con uno silenzioso. Riprova la stessa estensione dopo e annota il prossimo URL che fallisce.

env | grep -iE '^(http|https|no)_proxy='
code --install-extension ms-python.python --force

Annota quale lato del workspace ha prodotto quell'URL. Una nota breve che nomina la fase, l'host e il lato vale più di un elenco di impostazioni che qualcuno ha cambiato, perché è quella nota che la persona successiva può riprodurre.