Terminaal-aflaaie werk, maar VS Code-uitbreidings faal op VPN

curl werk in die houer en die uitbreiding installeer steeds nie. Vergelyk die plaaslike redigeerder en die afgeleë omgewing voordat jy proxy-instellings kopieer.

Aflaaie wat in die houer se terminaal slaag, is werklike bewyse oor daardie terminaal se omgewing. Hulle sê niks oor die redigeerderproses, die uitbreidingsinstalleerder of die binêre lêer wat ’n uitbreiding daarna haal nie. Om proxy-veranderlikes tussen dié drie te kopieer verander een mislukte versoek in ’n middag van onverwante wysigings.

Twee omgewings verskil gewoonlik in presies een opsig. Om dié opsig te vind is vinniger as om die proxy-dokumentasie twee keer te lees.

Watter proses het die mislukte versoek gemaak

Drie versoeke kan tydens ’n enkele installasie misluk, en elkeen het sy eie netwerkidentiteit. Die redigeerder vra die Marketplace om metadata en ’n pakket-URL en laai dan die pakket af. Eers daarna voer die uitbreidingsgasheer kode uit wat moontlik ’n taalserver of sy eie binêre lêer haal. Watter stadium ook al gebreek het, bepaal watter proses ’n proxy nodig het, en die foutoppervlak noem selde die stadium.

’n Werkende terminaal bewys die houer kan die internet bereik, nie dat die redigeerder dit kan nie. Lees die uitbreidingslog vir die laaste URL wat dit probeer het. Die gasheer wat daar genoem word, identifiseer die proses en die beleid wat daarop van toepassing is.

Plaaslike redigeerder en afgeleë houer is twee omgewings

In ’n afgeleë werkruimte hardloop ’n uitbreiding aan die kant wat sy tipe verklaar. Koppelvlak-uitbreidings bly by die plaaslike redigeerder, en werkruimte-uitbreidings hardloop in die houer. ’n Proxy wat in die een gestel is, is onsigbaar vir die ander, en ’n herbou skep die houer-omgewing uit sy konfigurasielêer eerder as uit wat jy in ’n skulp uitgevoer het. Dié skeiding verduidelik waarom dieselfde uitbreiding op ’n skootrekenaar installeer en op dieselfde projek oor SSH misluk.

Lees die installasieligging voordat jy enigiets wysig. Wanneer die log ’n afgeleë installasie rapporteer, is die houer se omgewing die een wat saak maak.

Plaas die proxy waar die versoek begin

Vir ’n Dev Container wat werklik ’n HTTP-proxy nodig het, hoort die veranderlike in die houer-konfigurasie sodat ’n herbou dit herproduseer. Die fragment hieronder stel dit vir daardie omgewing. Die plekhoueradres verteenwoordig jou eie deurgang, en die uitsonderings is nie opsionele vulsel nie.

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

Die veranderlike se naam beskryf die bestemmingsprotokol, so ’n HTTPS_PROXY-waarde mag wettiglik met http begin. Pas die verandering toe deur die ondersteunde herbou-pad, en behou die uitsonderings, want ’n proxy wat interne gashere onderskep, breek dienste wat die houer nodig het.

Skei vertrouensfoute van bereikbaarheid

’n Proxy wat verbind en dan ’n sertifikaatverifikasiefout terugstuur, het ’n later stadium bereik as een wat die verbinding weier. Die eerste fout wil die organisasie se goedgekeurde vertrouensmateriaal hê, geïnstalleer in die omgewing wat die versoek doen. Die tweede wil ’n bereikbare adres en poort hê. Om hulle as een probleem te behandel, lewer ’n oplossing wat vir geen van die twee werk nie.

Verifikasie deaktiveer, of die redigeerder met verhoogde regte laat loop, is nie ’n herstel vir ’n ontbrekende proxy of ’n afwesige vertrouensketting nie. Albei ruil ’n sigbare fout vir ’n stil een. Probeer daarna dieselfde uitbreiding weer en let op die volgende URL wat misluk.

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

Noteer watter kant van die werkruimte daardie URL opgelewer het. ’n Kort nota wat die stadium, die gasheer en die kant noem, is meer werd as ’n lys instellings wat iemand verander het, want daardie nota is wat die volgende persoon kan reproduseer.

Verwante artikels