Prüfen Sie zuerst die Yarn-Version im betroffenen Projekt:

yarn --version

Eine im Projekt gewählte Version kann sich von einem anderen Checkout oder Terminal unterscheiden. Verwenden Sie das dazu passende Konfigurationsformat.

Yarn Classic verwendet die ältere Form von .yarnrc:

proxy "http://203.0.113.10:8080"
https-proxy "http://203.0.113.10:8080"

Modern Yarn verwendet camelCase-Schlüssel in .yarnrc.yml:

httpProxy: "http://203.0.113.10:8080"
httpsProxy: "http://203.0.113.10:8080"

Ersetzen Sie den Dokumentationsendpunkt durch einen HTTP-Proxy aus Ihrem Dienst oder der HTTP-Proxy-Liste. Dies sind unterschiedliche Formate, keine austauschbaren Namen in einer einzigen universellen Datei. Ein mit Bindestrich geschriebener Classic-Schlüssel, der in modernes YAML eingefügt wird, kann bereits bei der Konfiguration scheitern, bevor der Proxy getestet wird.

Ermitteln Sie die Datei, die die gewählte Version liest, einschließlich der Suchregeln für das Projekt und das umgebende bzw. das Home-Verzeichnis. Eine spezifischere Hostnamen-Einstellung kann ebenfalls eine andere Route wählen. Die Registry bleibt die Quelle der Paketmetadaten; sie durch eine Proxy-IP zu ersetzen, konfiguriert keine Weiterleitung.

Beobachten Sie nach der Korrektur von Datei/Schlüssel einen Vorgang, der tatsächlich Netzwerkzugriff benötigt. Ein zwischengespeichertes Ergebnis kann eine ungültige Route verbergen. Entscheiden Sie anhand des tatsächlich fehlschlagenden Hostnamens und Fehlers, ob das nächste Problem Routing, Authentifizierung oder Zertifikatsvertrauen ist.

Ähnliche Artikel