Elŝutoj en la terminalo funkcias, sed VS Code-etendaĵoj malsukcesas ĉe VPN

curl funkcias en la ujo kaj la etendaĵo ankoraŭ ne instaliĝas. Komparu la lokan redaktilon kaj la malproksiman medion antaŭ ol kopii prokseajn agordojn.

Elŝutoj, kiuj sukcesas en la terminalo de la ujo, estas reala pruvo pri la medio de tiu terminalo. Ili diras nenion pri la redaktila procezo, la etendaĵa instalilo aŭ la binara dosiero, kiun etendaĵo poste elŝutas. Kopii prokseajn variablojn inter tiuj tri transformas unu malsukcesan peton en tutan posttagmezon da nerilataj ŝanĝoj.

Du medioj kutime diferencas en ekzakte unu aspekto. Trovi tiun aspekton estas pli rapide ol dufoje legi la proksean dokumentaron.

Kiu procezo faris la malsukcesan peton

Tri petoj povas malsukcesi dum unu instalo, kaj ĉiu havas sian propran retan identecon. La redaktilo petas de Marketplace metadatenojn kaj pakaĵan URL-on, poste elŝutas la pakaĵon. Nur post tio la etendaĵa gastiganto rulas kodon, kiu povas elŝuti lingvan servilon aŭ sian propran binaran dosieron. Kiu ajn etapo rompiĝis decidas, kiun procezon bezonas prokseon, kaj la erara surfaco malofte nomas la etapon.

Funkcianta terminalo pruvas, ke la ujo povas atingi la interreton, ne ke la redaktilo povas. Legu la etendaĵan protokolon por la lasta URL, kiun ĝi provis. La gastiganto nomita tie identigas la procezon kaj la regularon, kiu aplikas al ĝi.

Loka redaktilo kaj malproksima ujo estas du medioj

En malproksima laborspaco etendaĵo ruliĝas ĉe la flanko, kiun deklaras ĝia tipo. Interfacaj etendaĵoj restas ĉe la loka redaktilo, kaj laborspacaj etendaĵoj ruliĝas en la ujo. Prokseo agordita en unu estas nevidebla por la alia, kaj rekonstruo kreas la ujan medion el ĝia agorda dosiero anstataŭ el tio, kion vi eksportis en ŝelo. Tiu divido klarigas, kial la sama etendaĵo instaliĝas sur tekkomputilo kaj malsukcesas en la sama projekto tra SSH.

Legu la instaladan lokon antaŭ ol ŝanĝi ion ajn. Kiam la protokolo raportas malproksiman instalon, la medio de la ujo estas tiu, kiu gravas.

Metu la prokseon tie, kie la peto komenciĝas

Por Dev Container, kiu vere bezonas HTTP-prokseon, la variablo apartenas al la uja agordo, por ke rekonstruo reproduktu ĝin. La suba fragmento agordas ĝin por tiu medio. La anstataŭiga adreso staras por via propra enirejo, kaj la esceptoj ne estas laŭvola plenigaĵo.

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

La nomo de la variablo priskribas la celan protokolon, do HTTPS_PROXY-valoro rajtas laŭleĝe komenciĝi per http. Apliku la ŝanĝon tra la subtenata rekonstrua vojo, kaj konservu la esceptojn, ĉar prokseo, kiu interkaptas internajn gastigantojn, rompas servojn, kiujn la ujo bezonas.

Apartigu fido-malsukcesojn de atingeblo

Prokseo, kiu konektiĝas kaj poste redonas atestilo-kontrolan eraron, atingis postan etapon ol unu, kiu rifuzas la konekton. La unua malsukceso volas la aprobitan fidan materialon de la organizo instalitan en la medio, kiu faras la peton. La dua volas atingeblan adreson kaj pordon. Trakti ilin kiel unu problemon produktas solvon, kiu funkcias por nek unu.

Malŝalti la kontrolon aŭ ruli la redaktilon kun altigitaj rajtoj ne estas riparo por mankanta prokseo aŭ mankanta fida ĉeno. Ambaŭ interŝanĝas videblan eraron kontraŭ silenta. Poste reprovu la saman etendaĵon kaj notu la sekvan URL-on, kiu malsukcesas.

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

Notu, kiu flanko de la laborspaco produktis tiun URL-on. Mallonga noto nomanta la etapon, la gastiganton kaj la flankon valoras pli ol listo de agordoj, kiujn iu ŝanĝis, ĉar ĝuste tiun noton la sekva persono povas reprodukti.

Rilataj artikoloj