In this Article
Die Arbeit mit GitHub innerhalb eines Unternehmensnetzwerks ist meist ein Konfigurationsproblem, das sich auf fünf Tools verteilt, die keine gemeinsamen Einstellungen verwenden. Ein Clone funktioniert, aber npm install schlägt fehl; npm funktioniert, aber Docker kann nichts abrufen; auf der Kommandozeile funktioniert alles, doch die IDE erreicht nichts.
Dieser Leitfaden zeigt, wo jedes Tool seine Proxy-Einstellungen ausliest, warum SSH sich anders verhält als HTTPS, wie du die vier Fehlertypen liest, die dir tatsächlich begegnen werden, und welche zwei Abkürzungen du besser ablehnst.
Wichtige Fakten
- Jedes Tool hat seine eigene Proxy-Konfiguration. Git, npm, pip, Docker und deine Shell lesen alle unterschiedliche Einstellungen. Deshalb bleiben die anderen defekt, wenn du nur eines korrigierst.
- SSH schlägt meist fehl, wo HTTPS funktioniert, weil die meisten Unternehmens-Proxys nur HTTP CONNECT über Standardports weiterleiten.
- Zertifikatsfehler bedeuten fast immer TLS-Inspektion, und die Lösung besteht darin, der Unternehmens-CA zu vertrauen, statt die Überprüfung zu deaktivieren.
- Deaktiviere niemals die Zertifikatsüberprüfung, damit ein Clone funktioniert. Dadurch wird aus einem sichtbaren Konfigurationsproblem ein unsichtbares Sicherheitsproblem.
- Zugangsdaten in einer Proxy-URL gelangen in Logs und in den Shell-Verlauf. Verwende stattdessen den Zugangsdatenspeicher des Tools.
Wo liest jedes Tool seine Proxy-Einstellungen?
Getrennt voneinander, und genau das ist die Ursache für den Großteil der Verwirrung. Wir nennen das das 4-teilige Toolchain-Modell.
| Tool | Wo es nachsieht | Häufige Lücke |
|---|---|---|
| 1. Git | Eigene Konfiguration, dann Umgebungsvariablen | HTTPS-Remotes funktionieren, während SSH-Remotes es nicht tun |
| 2. Paketmanager | Eigene Konfigurationsdateien, dann Umgebungsvariablen | Jeder muss separat konfiguriert werden; Registries können sich von GitHub unterscheiden |
| 3. Docker | Daemon-Konfiguration, nicht nur deine Shell | Shell-Variablen erreichen den Daemon nicht, der Images abruft |
| 4. IDEs und Editoren | Eigene Einstellungen, manchmal der Systemspeicher | Das Terminal funktioniert, integrierte Funktionen aber nicht |
Eine funktionierende github proxy-Einrichtung bedeutet daher fünf Konfigurationen, nicht eine. In der Praxis setzt du zuerst Umgebungsvariablen für die Shell, konfigurierst dann git, anschließend jeden Paketmanager und den Docker-Daemon und nimmst von Anfang an eine No-Proxy-Liste für interne Hosts auf. Wenn du den letzten Schritt auslässt, sind interne Dienste nach einer ansonsten erfolgreichen Einrichtung nicht erreichbar.
Warum schlägt SSH fehl, wenn HTTPS funktioniert?
Weil es unterschiedliche Protokolle auf unterschiedlichen Ports sind und die meisten Unternehmens-Proxys nur HTTP CONNECT zu einer kleinen Anzahl von Ports weiterleiten.
Git über HTTPS ist eine gewöhnliche Webanfrage, die ein Proxy nativ verarbeitet. Git über SSH verwendet Port 22, der durch den Proxy meist überhaupt nicht erlaubt ist. Das Ergebnis: Ein Repository lässt sich mit einem HTTPS-Remote problemlos clonen, während es mit einem SSH-Remote zu einem Timeout kommt, und die Fehlermeldung erklärt nur selten den Grund.
Drei praktische Lösungen in der Reihenfolge ihrer Empfehlung: Stelle das Remote mit einem Token auf HTTPS um, nutze SSH über den HTTPS-Port, wo GitHub dies unterstützt, oder bitte das Netzwerkteam, SSH zu bestimmten Hosts zu erlauben. Die erste Lösung funktioniert überall und ist die, bei der die meisten Teams bleiben.
Wie liest du die Fehler?
| Fehler | Nutze diese Lösung, wenn | Vermeide es, wenn |
|---|---|---|
| Zertifikatsüberprüfung fehlgeschlagen | Füge die Unternehmens-CA zum Vertrauensspeicher des Tools hinzu | Deaktiviere niemals die Überprüfung, denn das verbirgt ein echtes Risiko |
| Verbindung bei einem SSH-Remote abgelaufen | Wechsle zu HTTPS oder zu SSH über den HTTPS-Port | Erneut versuchen; der Port ist blockiert, nicht langsam |
| Proxy-Authentifizierung erforderlich | Konfiguriere die Zugangsdaten im Speicher des Tools | Sie in eine URL zu schreiben, denn das gelangt in Logs |
| Funktioniert im Terminal, schlägt in Docker fehl | Konfiguriere den Docker-Daemon und starte ihn dann neu | Weitere Shell-Variablen hinzuzufügen, die der Daemon nie ausliest |
| Interne Hosts sind nach der Einrichtung nicht erreichbar | Füge sie zur No-Proxy-Liste hinzu | Die Proxy-Konfiguration vollständig zu entfernen |
Bei der ersten Zeile lohnt es sich, konsequent zu sein. TLS-Inspektion bedeutet, dass eine Zwischenkomponente deine Verbindungen beendet und erneut signiert. Die richtige Reaktion ist, der CA der Organisation bewusst zu vertrauen. Wenn du die Überprüfung deaktivierst, verschwindet der Fehler, aber auch jede künftige Abfangaktion bleibt unsichtbar.
Wann ist ein externer Proxy das richtige Tool?
Bei diesem Problem selten, und das sollte klar sein.
Ein Unternehmens-Proxy ist Infrastruktur, die deine Organisation betreibt. Die Lösung für den GitHub-Zugriff dahinter ist Konfiguration, nicht ein zweiter Proxy. Einen Netzwerkkontrollmechanismus zu umgehen, den dein Arbeitgeber bewusst eingerichtet hat, ist zuerst eine Frage der Richtlinie und erst danach eine technische Frage.
Ein kommerzieller Proxy ist für andere Arbeiten tatsächlich sinnvoll, die zufällig GitHub einbeziehen: öffentliche Repository-Daten in großem Umfang sammeln, prüfen, wie eine öffentliche Seite aus einem anderen Land dargestellt wird, oder automatisierte Prüfungen aus mehreren Regionen ausführen. Speziell zum Sammeln von Repository-Daten ist die GitHub API mit einem Token zuerst die richtige Lösung, und sie ist großzügig genug, dass Scraping nur selten gerechtfertigt ist.
Wenn das Sammeln verteilte Ausgänge benötigt, deckt DataImpulse residential 195 Länder zu $1 pro GB ab. Verwandt: Proxys für Web Scraping, 403 Forbidden erklärt.
Häufig gestellte Fragen
Wie konfiguriere ich git für die Nutzung eines Proxy?
Setze den Proxy in der eigenen Konfiguration von git oder in den Standard-Umgebungsvariablen und füge gleichzeitig interne Hosts zu einer No-Proxy-Liste hinzu. Git liest seine eigene Konfiguration getrennt von npm, pip und Docker, daher muss jedes Tool einzeln konfiguriert werden.
Warum schlägt git clone über SSH hinter einem Proxy fehl?
Weil SSH Port 22 verwendet und die meisten Unternehmens-Proxys nur HTTP CONNECT zu Standard-Webports weiterleiten. HTTPS-Remotes funktionieren, weil sie gewöhnliche Webanfragen sind. Das Remote mit einem Token auf HTTPS umzustellen, ist die Lösung, die in den meisten Umgebungen funktioniert.
Was verursacht Zertifikatsfehler hinter einem Unternehmens-Proxy?
TLS-Inspektion: Eine Zwischenkomponente beendet deine Verbindungen und signiert sie mit der eigenen Zertifizierungsstelle der Organisation erneut. Die Lösung ist, diese CA zum Vertrauensspeicher jedes Tools hinzuzufügen. Das Deaktivieren der Zertifikatsüberprüfung beseitigt den Fehler und deine Möglichkeit, ein echtes Abfangen zu erkennen.
Warum schlägt Docker fehl, wenn mein Terminal funktioniert?
Weil der Docker-Daemon Images abruft, nicht deine Shell, und seine eigene Konfiguration statt deiner Umgebungsvariablen ausliest. Konfiguriere die Proxy-Einstellungen des Daemons und starte ihn neu.
Sollte ich bei der Arbeit einen kommerziellen Proxy verwenden, um GitHub zu erreichen?
Nein. Ein Unternehmens-Proxy ist Infrastruktur, die deine Organisation bewusst betreibt, und die Lösung ist Konfiguration. Kommerzielle Proxys eignen sich für andere Arbeiten, etwa das Sammeln öffentlicher Daten aus vielen Regionen. Selbst dann ist die GitHub API mit einem Token meist der bessere Weg.
Wenn es um Datensammlung geht, nicht um Konnektivität
Zu prüfen, wie öffentliche Seiten aus anderen Regionen dargestellt werden, oder öffentliche Daten in großem Umfang zu sammeln, ist ein anderes Problem als die Konfiguration eines Unternehmensnetzwerks. DataImpulse residential proxies decken 195 Länder zu $1 pro GB ab. Erstelle ein Konto, wenn das deine Aufgabe ist.
Verwandt: Proxys für Web Scraping · 403 Forbidden beim Scraping · Was ist ein Web-Proxy?.
Zuletzt aktualisiert: 17. September 2026.