Terminal-Downloads funktionieren, aber VS Code-Erweiterungen scheitern am VPN

Downloads, die im Container-Terminal gelingen, sind ein realer Beleg für die Umgebung dieses Terminals. Sie sagen nichts über den Editorprozess, den Erweiterungsinstaller oder die Binärdatei aus, die eine Erweiterung danach abruft. Proxy-Variablen zwischen diesen dreien zu kopieren verwandelt eine fehlgeschlagene Anfrage in einen ganzen Nachmittag unzusammenhängender Änderungen.

Zwei Umgebungen unterscheiden sich meist in genau einem Punkt. Diesen Punkt zu finden geht schneller, als die Proxy-Dokumentation zweimal zu lesen.

Welcher Prozess die fehlgeschlagene Anfrage gestellt hat

Bei einer einzigen Installation können drei Anfragen scheitern, und jede hat ihre eigene Netzwerkidentität. Der Editor fragt den Marketplace nach Metadaten und einer Paket-URL und lädt dann das Paket herunter. Erst danach führt der Erweiterungshost Code aus, der einen Language Server oder eine eigene Binärdatei abrufen kann. Welche Stufe brach, entscheidet, welcher Prozess einen Proxy braucht, und die Fehleroberfläche nennt die Stufe selten.

Ein funktionierendes Terminal beweist, dass der Container das Internet erreicht, nicht dass der Editor es erreicht. Lesen Sie im Erweiterungsprotokoll die zuletzt versuchte URL. Der dort genannte Host benennt den Prozess und die für ihn geltende Richtlinie.

Lokaler Editor und entfernter Container sind zwei Umgebungen

In einem entfernten Arbeitsbereich läuft eine Erweiterung auf der Seite, die ihr Typ deklariert. Oberflächenerweiterungen bleiben beim lokalen Editor, Arbeitsbereichserweiterungen laufen im Container. Ein im einen gesetzter Proxy ist für das andere unsichtbar, und ein Rebuild erzeugt die Containerumgebung aus ihrer Konfigurationsdatei statt aus dem, was Sie in einer Shell exportiert haben. Diese Trennung erklärt, warum dieselbe Erweiterung auf einem Laptop installiert und im selben Projekt über SSH scheitert.

Lesen Sie den Installationsort, bevor Sie etwas ändern. Meldet das Protokoll eine entfernte Installation, ist die Umgebung des Containers die maßgebliche.

Setzen Sie den Proxy dorthin, wo die Anfrage beginnt

Für einen Dev Container, der tatsächlich einen HTTP-Proxy braucht, gehört die Variable in die Containerkonfiguration, damit ein Rebuild sie reproduziert. Das folgende Fragment setzt sie für diese Umgebung. Die Platzhalteradresse steht für Ihr eigenes Gateway, und die Ausnahmen sind keine optionale Auffüllung.

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

Der Variablenname beschreibt das Zielprotokoll, daher darf ein HTTPS_PROXY-Wert legitim mit http beginnen. Wenden Sie die Änderung über den unterstützten Rebuild-Pfad an, und behalten Sie die Ausnahmen, weil ein Proxy, der interne Hosts abfängt, Dienste bricht, die der Container braucht.

Trennen Sie Vertrauensfehler von Erreichbarkeit

Ein Proxy, der verbindet und dann einen Zertifikatsprüfungsfehler zurückgibt, hat eine spätere Stufe erreicht als einer, der die Verbindung ablehnt. Der erste Fehler will das freigegebene Vertrauensmaterial der Organisation in der Umgebung installiert, die die Anfrage ausführt. Der zweite will eine erreichbare Adresse und einen Port. Behandelt man beide als ein Problem, entsteht eine Lösung, die für keines von beiden funktioniert.

Die Prüfung zu deaktivieren oder den Editor mit erhöhten Rechten zu starten ist keine Reparatur für einen fehlenden Proxy oder eine fehlende Vertrauenskette. Beides tauscht einen sichtbaren Fehler gegen einen stillen. Versuchen Sie danach dieselbe Erweiterung erneut und notieren Sie die nächste URL, die scheitert.

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

Notieren Sie, welche Seite des Arbeitsbereichs diese URL erzeugt hat. Eine kurze Notiz mit Stufe, Host und Seite ist mehr wert als eine Liste geänderter Einstellungen, weil genau diese Notiz die nächste Person reproduzieren kann.