407 hinter dem Firmen-VPN-Proxy: npm, Maven und VS Code

Die erfolgreiche Intranet-Seite im Browser beweist nur, dass der Proxy für den Browser arbeitet, nicht für npm oder Maven. Jeder Client liest seine eigene Konfiguration, und ein Netz, das nur über das VPN erreichbar ist, wirft eine zweite Frage auf: ob der Client den Proxy überhaupt erreicht. Beginne mit dem Statuscode und folge dann der Konfigurationskette des Werkzeugs, das versagt hat. Darum kann ein Client funktionieren, während der daneben scheitert.

Was ein 407 tatsächlich beweist

Ein 407 Proxy Authentication Required kommt vom Proxy, nicht von der Registry oder vom Repository. Der Client hat den Proxy erreicht, und der Proxy hat die Anfrage abgelehnt, meist weil Zugangsdaten fehlten, falsch aufgebaut waren oder für dieses Ziel nicht akzeptiert wurden.

Ein Timeout erzählt etwas anderes. Vielleicht hat der Client die falsche Proxy-Adresse, keine Route zum Proxy, bevor der Tunnel steht, oder einen Bypass-Eintrag, der für einen internen Host fehlt. Lies den Fehlertext, bevor du Zugangsdaten änderst.

Prüfe Proxy-Host, Port, Authentifizierungsverfahren und ob der Benutzername ein Domänenpräfix braucht. Dann prüfe, ob das fehlerhafte Werkzeug den Wert aus einer Datei, einer Umgebungsvariable oder aus beidem liest. Ein domänenqualifizierter Benutzername ist eine häufige Ursache für 407. Ebenso ein Passwort, das mit falscher Kodierung gespeichert wurde.

npm liest seine eigene Konfigurationskette

npm akzeptiert die Schlüssel proxy und https-proxy in einer .npmrc auf Benutzer- oder Projektebene. Gib das Schema an, denn die Werte sind URLs, und kodiere reservierte Zeichen im Passwort als URL, damit ein At-Zeichen den Wert nicht zerlegt.

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

Mit npm config list siehst du, welche Datei welchen effektiven Wert geliefert hat. Ein Shell-Export wie npm_config_proxy kann die Datei überschreiben, und eine .npmrc auf Projektebene mit persönlichem Passwort gehört nie ins Repository. Lass dir den Quellpfad zusammen mit dem Wert ausgeben.

Lass strict-ssl aktiviert. Ein Proxy, der TLS inspiziert, kann das Unternehmens-CA im Truststore verlangen; die Verifikation abzuschalten, um den Fehler zu umgehen, verdeckt das eigentliche Vertrauensproblem.

Maven trennt Proxys von Mirrors

Maven liest Proxys und Mirrors aus der Benutzer-Settings-Datei, nicht aus dem Projekt-pom. Netzwerkspezifische Proxys und interne Repository-Mirrors gehören in ~/.m2/settings.xml, öffentliche Repository-Deklarationen bleiben im Projekt, wo sie hingehören.

Der Proxy-Block braucht eine id, ein Aktiv-Flag, das Protokoll, Host und Port sowie einen nonProxyHosts-Eintrag für das interne Repository. Diese Felder gehören in die Benutzer-Settings-Datei, nicht ins Projekt-pom, damit eine Netzwerkänderung nicht den Build für das ganze Team umschreibt. Ein Mirror-Eintrag ist getrennt und zeigt Maven auf das interne Repository.

Nimm das interne Repository in nonProxyHosts auf, damit Maven es direkt erreicht. Ohne diesen Eintrag wird der Proxy zu einem unnötigen Zwischenschritt, und der Fehler sieht wie ein Repository-Ausfall aus. Ein Mirror-Eintrag zeigt auf das interne Repository; er ersetzt nicht die Proxy-Einstellung.

Wer zwischen Netzen wechselt, kann eine Settings-Datei pro Netz pflegen und beim Start der Shell die richtige Kopie auswählen. Eine einzige Datei bei jedem Wechsel von Hand zu bearbeiten, macht aus einem funktionierenden Laptop ein Support-Ticket.

VS Code und Dev-Container haben getrennte Namensräume

VS Code liest http.proxy aus den Benutzer- oder Workspace-Einstellungen, einschließlich Schema und Port. Das deckt die Anfragen des Editors an Erweiterungen und den Marketplace ab, konfiguriert aber weder ein Terminal noch einen aus dem Editor gestarteten Container. Prüfe den Gültigkeitsbereich der Einstellung ebenso wie den Wert. Eine Workspace-Einstellung kann die Benutzereinstellung für ein Projekt überschreiben.

Ein Dev-Container hat seinen eigenen Netzwerk-Namensraum. Er erbt weder die Proxy-Variablen des Hosts noch dessen VPN-Route, weshalb ein Marketplace-Aufruf im Container scheitern kann, während derselbe Aufruf auf dem Host funktioniert.

Gib dem Container diese Variablen, oder gib ihm einen eigenen Resolver und eine eigene Route. Wenn Namen darin aufgelöst werden, der Proxy aber nie antwortet, fehlt meist der Pfad, nicht die Adresse.

Bypass-Listen und Vorrang der Umgebung

Nimm das VPN-Gateway, interne Registries und private DNS-Suffixe in die Bypass-Liste auf. Wenn der Client das VPN-Gateway über den Proxy erreichen will, bevor der Tunnel existiert, scheitert die Verbindung so, dass es wie ein Proxy-Ausfall aussieht. Teste diesen Bypass bei getrenntem Tunnel.

Umgebungsvariablen und Dateien können sich widersprechen. Führe den Konfigurationsdump des Werkzeugs aus, nicht den der Shell, und vergleiche die gemeldeten Werte. Eine doppelte Variable in Kleinschreibung, ein veralteter Wert in einer übergeordneten Shell oder eine Projektdatei können die gerade geänderte Einstellung überstimmen.

In CI übergibst du den Proxy als geheime Variable und testest eine Paketinstallation im selben Image. Ein 407 in einem Container heißt oft, dass die Variable dort schlicht fehlt, während die Host-Shell sie hat.

Halte Proxy-Host, Port, Bypass-Suffixe und die Datei oder Variable, die sie liefert, für jedes Werkzeug fest. Wenn ein Client 407 zurückgibt und ein anderer arbeitet, wird aus diesem Protokoll ein kurzer Vergleich statt eines Vergleichs von vier verschiedenen Konfigurationen.