Proxy-Einrichtung im Linux-Terminal und CI: Schritt-für-Schritt-Anleitung für HTTP_PROXY, HTTPS_PROXY, NO_PROXY

Stell dir vor: Du öffnest das Terminal, gibst einen Befehl zur Paketinstallation ein, und als Antwort kommt Stille oder eine Verbindungsfehlermeldung. Oft liegt es daran, dass der Netzwerkzugriff nur über einen Proxy-Server erfolgt, die Systeme das aber nicht wissen. Dieser Leitfaden zeigt dir, wie du überall dort den Proxy einrichtest, wo es unter Linux und in CI nötig ist.

Einleitung: Was du bekommst und für wen dieser Leitfaden ist

Am Ende dieser Anleitung wirst du selbstbewusst Proxy-Einstellungen im Linux-Terminal und in Continuous-Integration-Systemen vornehmen. Du verstehst, wie Umgebungsvariablen funktionieren, wie man einen korrekten Proxy-URL zusammenbaut und wie man alle wichtigen Entwickler-Tools dazu bringt, über den Proxy zu arbeiten.

Was du konkret bekommst:

• Eine funktionierende Proxy-Einrichtung in der aktuellen Terminalsitzung.
• Eine dauerhafte Einrichtung, die einen Neustart überlebt.
• Die richtige Konfiguration für apt, dnf, git, npm, pip, curl, wget, Docker.
• Funktionierende CI-Pipelines in GitHub Actions und GitLab Runner.
• Verständnis, wie du prüfst, ob der Traffic wirklich über den Proxy läuft.
• Fähigkeiten zur sicheren Aufbewahrung des Proxy-Passworts.

Für wen dieser Leitfaden ist: Für angehende Systemadministratoren, Entwickler und DevOps-Ingenieure, die in einer Umgebung mit firmeneigenem Proxy arbeiten. Es gibt auch Elemente für Fortgeschrittene: Feinheiten von systemd, ProxyCommand für SSH und das Ausblenden von Geheimnissen in CI.

Was du vorher wissen solltest: Du solltest ein Terminal öffnen, Befehle eingeben und verstehen können, was eine Datei und ein Ordner sind. Alles andere wird im Laufe der Anleitung einfach erklärt.

Wie viel Zeit du einplanen solltest: Die grundlegende Einrichtung dauert etwa 15 Minuten. Der vollständige Durchlauf mit der Einrichtung aller Tools und CI dauert etwa 60–90 Minuten. Nimm dir Zeit und arbeite lieber gründlich.

Tipp: Halte diesen Leitfaden in einem separaten Fenster offen und führe die Befehle nacheinander aus. So verpasst du garantiert keinen wichtigen Schritt.

Vorbereitung: Adresse, Port, Login und korrekte Proxy-URL

Bevor du etwas einrichtest, musst du die Daten deines Proxy-Servers sammeln. Ohne sie geht es nicht weiter.

Woher bekommst du die Proxy-Daten?

In der Regel wird der Proxy von einer der folgenden Seiten bereitgestellt:

• Systemadministrator des Unternehmens – wenn du in einem Firmennetzwerk arbeitest. Frage ihn nach Adresse, Port und Anmeldedaten.
• Proxy-Dienstleister – im Kundenbereich findest du normalerweise einen Block mit Zugangseinstellungen.
• Dein eigener Server – wenn du den Proxy selbst eingerichtet hast, kennst du die Daten.

Du benötigst vier Elemente: Adresse (Host), Port, Benutzername (Username) und Passwort. Manchmal sind Benutzername und Passwort nicht erforderlich – dann handelt es sich um einen Proxy ohne Authentifizierung.

Wie baust du einen Proxy-URL zusammen?

Der Proxy wird als eine einzige Zeichenfolge – eine URL – angegeben. Das allgemeine Format ist:

schema://benutzername:passwort@adresse:port

Schauen wir uns ein Beispiel an. Angenommen, die Proxy-Adresse ist proxy.example.com, der Port 3128, der Benutzername ivan und das Passwort secret123. Dann sieht die URL so aus:

http://ivan:secret123@proxy.example.com:3128

Wenn keine Authentifizierung erforderlich ist, ist die URL einfacher:

http://proxy.example.com:3128

Zum Schema: Meistens wird das Schema http verwendet, selbst für den Zugriff auf HTTPS-Websites. Das ist normal – das Schema bezeichnet hier das Protokoll zur Kommunikation mit dem Proxy selbst, nicht mit der Zielseite. Gelegentlich gibt es Proxys mit dem Schema https oder socks5.

Warum Sonderzeichen im Passwort kodiert werden müssen

Dies ist eine der häufigsten Ursachen für rätselhafte Fehler. Wenn im Passwort Sonderzeichen wie @, :, /, #, ? vorkommen, stören sie die Analyse der URL. Beispielsweise trennt das Zeichen @ die Anmeldedaten von der Adresse. Wenn es im Passwort auftaucht, wird das System verwirrt und weiß nicht, wo das Passwort aufhört und die Adresse beginnt.

Die Lösung ist Percent-Encoding (prozentuale Kodierung). Jedes problematische Zeichen wird durch ein Prozentzeichen und seinen hexadezimalen Code ersetzt.

Die wichtigsten Ersetzungen:

• Das Zeichen @ wird zu %40
• Das Zeichen : wird zu %3A
• Das Zeichen / wird zu %2F
• Das Zeichen # wird zu %23
• Das Zeichen ? wird zu %3F
• Das Leerzeichen wird zu %20
• Das Zeichen % wird zu %25

Beispiel: Wenn das Passwort p@ss:word ist, muss es in der URL als p%40ss%3Aword erscheinen. Dann sieht die vollständige URL so aus:

http://ivan:p%40ss%3Aword@proxy.example.com:3128

Tipp: Um das Passwort schnell zu kodieren, verwende den Befehl python3 -c "import urllib.parse, sys; print(urllib.parse.quote(sys.argv[1], safe=''))" 'dein_passwort'. Er gibt dir eine gebrauchsfertige Zeichenfolge zum Einfügen in die URL.

⚠️ Achtung: Gib dein echtes Passwort niemals direkt in der Befehlszeile auf einem öffentlichen Computer ein – es landet im Verlauf. Über die sichere Eingabe sprechen wir später separat.

✅ Überprüfung: Du hast nun eine oder mehrere zusammengestellte Proxy-URLs, bei denen alle Sonderzeichen im Passwort kodiert sind. Notiere sie an einem sicheren Ort, am besten in einem Passwort-Manager.

Grundlegende Konzepte: Umgebungsvariablen, Groß-/Kleinschreibung und das NO_PROXY-Format

Damit die Einrichtung keine Zauberei ist, schauen wir uns drei grundlegende Konzepte an. Das dauert fünf Minuten, spart dir aber stundenlanges Debuggen.

Was sind Umgebungsvariablen?

Umgebungsvariablen sind benannte Werte, die das Betriebssystem im Speicher hält und an gestartete Programme weitergibt. Stell dir das wie einen Zettel vor, den das System jedem neuen Programm zeigt: Hier ist die Proxy-Adresse, benutze sie.

Viele Netzwerkdienstprogramme unter Linux lesen beim Start spezielle Variablen und leiten den Datenverkehr automatisch über den Proxy, wenn sie diese finden. Die wichtigsten sind:

• HTTP_PROXY – Proxy für unverschlüsselte HTTP-Anfragen.
• HTTPS_PROXY – Proxy für verschlüsselte HTTPS-Anfragen.
• NO_PROXY – Liste der Adressen, die direkt (ohne Proxy) erreicht werden sollen.
• FTP_PROXY – Proxy für das FTP-Protokoll, wird heute selten verwendet.
• ALL_PROXY – Proxy für alle Protokolle gleichzeitig, oft für Socks verwendet.

Unterschied zwischen http_proxy und HTTP_PROXY nach Groß-/Kleinschreibung

Das ist ein feiner, aber wichtiger Punkt. Linux unterscheidet zwischen Groß- und Kleinschreibung, daher sind http_proxy und HTTP_PROXY formal zwei verschiedene Variablen. Verschiedene Programme lesen unterschiedliche Varianten.

Historisch hat sich Folgendes etabliert:

• Das Dienstprogramm curl liest sowohl die kleingeschriebene als auch die großgeschriebene Version, aber bei der kleingeschriebenen http_proxy gibt es eine Sicherheitsbesonderheit – die großgeschriebene HTTP_PROXY ignoriert curl in einer CGI-Umgebung, um Angriffe zu vermeiden.
• Das Dienstprogramm wget bevorzugt traditionell kleingeschriebene Namen.
• Viele Programme in verschiedenen Sprachen lesen die großgeschriebenen Versionen.

Praktische Schlussfolgerung: Um nicht zu raten, setze beide Versionen – sowohl die kleingeschriebene als auch die großgeschriebene. Das ist die sicherste Strategie, die wir auch verwenden werden.

Das Format von NO_PROXY und warum es CIDR nicht versteht

Die Variable NO_PROXY enthält eine durch Kommata getrennte Liste von Adressen, die direkt erreicht werden sollen. Dies ist kritisch für interne Ressourcen: Datenbanken, lokale Dienste, Cloud-Metadaten.

Ein Beispiel für einen korrekten Wert:

localhost,127.0.0.1,.example.com,.internal,169.254.169.254

Beachte den Punkt vor example.com. Der Punkt bedeutet, dass alle Subdomains unter die Regel fallen: api.example.com, git.example.com usw.

⚠️ Achtung: NO_PROXY versteht in der Regel keine CIDR-Notation und keine Subnetzmasken. Der Eintrag 10.0.0.0/8 wird in den meisten Tools nicht funktionieren. Einige moderne Bibliotheken unterstützen dies zwar, aber du solltest dich nicht darauf verlassen. Gib konkrete Adressen und Domain-Suffixe explizit an.

Außerdem unterstützt NO_PROXY normalerweise keine Sternchen als universelle Platzhalter. Schreibe nicht *.example.com – verwende stattdessen einen Punkt am Anfang: .example.com.

Tipp: Füge immer die Adressen localhost und 127.0.0.1 zu NO_PROXY hinzu. Andernfalls werden lokale Anfragen über den Proxy geleitet und höchstwahrscheinlich fehlschlagen.

✅ Überprüfung: Du verstehst, wofür HTTP_PROXY, HTTPS_PROXY und NO_PROXY benötigt werden, kennst den Unterschied in der Groß-/Kleinschreibung und weißt, dass NO_PROXY CIDR nicht mag. Jetzt geht es an die Praxis.

Schritt 1: Proxy in der aktuellen Sitzung aktivieren und mit curl testen

Ziel dieses Schritts: Lerne, wie du den Proxy schnell in einem geöffneten Terminal aktivierst und prüfst, ob er funktioniert. Diese Einstellungen bleiben nur bis zum Schließen des Terminalfensters bestehen – ideal für Tests.

Variablen per export setzen

Der Befehl export erzeugt eine Umgebungsvariable in der aktuellen Sitzung. Führe die folgenden Befehle aus und ersetze sie durch deine Proxy-URL.

1. Öffne ein Terminal.
2. Gib den Befehl für HTTP ein: export http_proxy="http://ivan:secret123@proxy.example.com:3128"
3. Gib den Befehl für HTTPS ein: export https_proxy="http://ivan:secret123@proxy.example.com:3128"
4. Wiederhole in Großbuchstaben: export HTTP_PROXY="$http_proxy"
5. Und noch einmal: export HTTPS_PROXY="$https_proxy"
6. Setze die Ausnahmen: export no_proxy="localhost,127.0.0.1,.example.com"
7. Wiederhole: export NO_PROXY="$no_proxy"

Die Konstruktion "$http_proxy" setzt den Wert der bereits definierten kleingeschriebenen Variablen ein, damit du die URL nicht erneut eingeben musst.

Tipp: Beachte, dass die gesamte URL in doppelte Anführungszeichen gesetzt ist. Das schützt vor falscher Interpretation von Sonderzeichen durch deine Bash-Shell.

Mit curl überprüfen

Jetzt prüfen wir, ob die Variablen gelesen werden. Das Dienstprogramm curl eignet sich hervorragend dafür.

1. Prüfe, ob die Variable gesetzt ist: echo $http_proxy – du solltest deine URL sehen.
2. Führe eine Anfrage mit detaillierter Ausgabe durch: curl -v http://example.com
3. Suche in der Ausgabe nach einer Zeile, die Connected to proxy.example.com erwähnt – das bedeutet, dass curl über den Proxy gegangen ist.

Wenn die Authentifizierung korrekt ist und der Proxy erreichbar ist, erhältst du als Antwort eine HTML-Seite. Wenn du einen Fehler 407 siehst, liegt das Problem am Login oder Passwort – kehre zum Abschnitt über die Passwortkodierung zurück.

Tipp: Der Schalter -v (verbose) zeigt Details der Verbindung an. Dies ist dein wichtigstes Werkzeug zum Debuggen von Proxys. Ohne ihn siehst du nicht, wohin die Anfrage tatsächlich geht.

Um den Proxy in der aktuellen Sitzung zu deaktivieren, verwende den Befehl unset: unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY no_proxy NO_PROXY. Alle Variablen verschwinden.

✅ Überprüfung: Der Befehl curl -v http://example.com zeigt eine Verbindung zu deinem Proxy-Server an und gibt den Inhalt der Seite zurück. Wenn das der Fall ist, ist der erste Schritt erfolgreich abgeschlossen.

Schritt 2: Einrichtung dauerhaft machen

Ziel dieses Schritts: Stelle sicher, dass der Proxy bei jedem Systemstart automatisch aktiviert wird und einen Neustart überlebt. Es gibt mehrere Ebenen – wähle die passende aus.

Variante A: Nur für deinen Benutzer über ~/.bashrc

Die Datei ~/.bashrc wird jedes Mal ausgeführt, wenn du ein interaktives Terminal unter deinem Benutzer öffnest. Das ist die sicherste Variante – du greifst nicht in die Konfiguration anderer Benutzer ein.

1. Öffne die Datei mit einem Editor: nano ~/.bashrc
2. Scrolle ganz nach unten.
3. Füge dieselben export-Befehle wie in Schritt 1 ein.
4. Speichere die Datei: Drücke Strg+O, dann Enter, dann Strg+X zum Beenden.
5. Wende die Änderungen ohne Neustart an: source ~/.bashrc

Tipp: Erstelle vor dem Bearbeiten eine Sicherungskopie mit dem Befehl cp ~/.bashrc ~/.bashrc.backup. Falls etwas schiefgeht, kannst du das Original leicht wiederherstellen.

Variante B: Systemweit über /etc/environment

Die Datei /etc/environment setzt Variablen für alle Benutzer und funktioniert auch außerhalb von bash. Das Format ist hier besonders: ohne das Wort export, einfach NAME=wert.

1. Öffne die Datei mit Administratorrechten: sudo nano /etc/environment
2. Füge Zeilen ohne export hinzu, z. B.: http_proxy="http://ivan:secret123@proxy.example.com:3128"
3. Füge analog https_proxy, HTTP_PROXY, HTTPS_PROXY, no_proxy, NO_PROXY hinzu.
4. Speichere und schließe die Datei.
5. Melde dich ab und wieder an oder starte neu, um die Änderungen zu übernehmen.

Variante C: Über /etc/profile.d

Eine flexiblere systemweite Methode ist das Erstellen eines separaten Skripts im Ordner /etc/profile.d. Alle .sh-Dateien dort werden beim Anmelden ausgeführt.

1. Erstelle eine Datei: sudo nano /etc/profile.d/proxy.sh
2. Verwende darin die üblichen export-Befehle wie in Schritt 1.
3. Speichere die Datei.
4. Mache sie ausführbar: sudo chmod +x /etc/profile.d/proxy.sh

Diese Methode ist praktischer als /etc/environment, da sie die vollständige Syntax der Shell unterstützt.

Variante D: Für Systemdienste über systemd drop-in

Achtung, das ist ein wichtiger Punkt. Hintergrunddienste, die von systemd verwaltet werden, lesen nicht deine ~/.bashrc und ignorieren oft /etc/environment. Für sie benötigst du einen separaten Ansatz – eine drop-in-Datei.

Angenommen, du möchtest, dass ein bestimmter Dienst (z. B. some-service) über den Proxy arbeitet.

1. Erstelle das drop-in-Verzeichnis und die Datei mit dem Befehl: sudo systemctl edit some-service
2. Es öffnet sich ein Editor. Füge den Konfigurationsblock ein.
3. Füge im Abschnitt [Service] Zeilen wie Environment="HTTP_PROXY=http://ivan:secret123@proxy.example.com:3128" hinzu.
4. Füge analoge Environment-Zeilen für HTTPS_PROXY und NO_PROXY hinzu.
5. Speichere die Datei.
6. Lade die Konfiguration neu: sudo systemctl daemon-reload
7. Starte den Dienst neu: sudo systemctl restart some-service

Die Direktive Environment setzt die Variable genau für diesen Dienst. Das ist der einzig korrekte Weg für systemd-Dienste.

⚠️ Achtung: Auf RHEL, CentOS, Fedora und AlmaLinux sind die Pfade und Werkzeuge dieselben – systemd funktioniert gleich. Unterschiede ergeben sich später im Abschnitt über Paketmanager.

✅ Überprüfung: Öffne ein neues Terminal (nicht das, in dem du manuell export eingegeben hast) und führe echo $http_proxy aus. Wenn du deine URL siehst, funktioniert die dauerhafte Einrichtung.

Schritt 3: Paketmanager und Dienstprogramme einzeln konfigurieren

Ziel dieses Schritts: Viele Tools lesen keine Umgebungsvariablen oder haben eigene Konfigurationsdateien. Wir konfigurieren jedes einzeln, damit nichts ausfällt.

apt unter Ubuntu und Debian

Der Paketmanager apt wird oft mit sudo ausgeführt und sieht deine Variablen möglicherweise nicht. Sicherer ist es, den Proxy in seiner eigenen Konfigurationsdatei festzulegen.

1. Erstelle eine Datei: sudo nano /etc/apt/apt.conf.d/95proxies
2. Füge die Zeile hinzu: Acquire::http::Proxy "http://ivan:secret123@proxy.example.com:3128";
3. Füge die Zeile für HTTPS hinzu: Acquire::https::Proxy "http://ivan:secret123@proxy.example.com:3128";
4. Speichere die Datei.
5. Überprüfe: sudo apt update

Beachte das Semikolon am Ende jeder Zeile – es ist ein obligatorisches Syntaxelement von apt.

dnf und yum auf RHEL, Fedora, AlmaLinux

Auf Systemen der RHEL-Familie werden dnf und yum anstelle von apt verwendet. Der Proxy wird in der Hauptkonfigurationsdatei festgelegt.

1. Öffne die Datei: sudo nano /etc/dnf/dnf.conf (für ältere Systeme /etc/yum.conf)
2. Füge im Abschnitt [main] die Zeile hinzu: proxy=http://proxy.example.com:3128
3. Wenn eine Authentifizierung erforderlich ist, füge separate Zeilen hinzu: proxy_username=ivan und proxy_password=secret123
4. Speichere die Datei.
5. Überprüfe: sudo dnf makecache

In dnf ist es praktischer, Login und Passwort mit separaten Direktiven anzugeben, anstatt sie in die URL zu packen.

npm über .npmrc

1. Setze den Proxy mit dem Befehl: npm config set proxy "http://ivan:secret123@proxy.example.com:3128"
2. Setze den für HTTPS: npm config set https-proxy "http://ivan:secret123@proxy.example.com:3128"
3. Die Einstellungen werden automatisch in die Datei ~/.npmrc geschrieben.
4. Überprüfe: npm config get proxy

pip über pip.conf

1. Erstelle das Verzeichnis: mkdir -p ~/.config/pip
2. Öffne die Datei: nano ~/.config/pip/pip.conf
3. Füge den Abschnitt [global] und die Zeile proxy = http://ivan:secret123@proxy.example.com:3128 hinzu.
4. Speichere die Datei.
5. Überprüfe durch Installation eines beliebigen Pakets: pip install requests

Alternativ kannst du den Proxy direkt im Befehl angeben: pip install requests --proxy http://proxy.example.com:3128

git über http.proxy

1. Setze global: git config --global http.proxy "http://ivan:secret123@proxy.example.com:3128"
2. Falls nötig, getrennt für HTTPS: git config --global https.proxy "http://ivan:secret123@proxy.example.com:3128"
3. Überprüfe: git config --global --get http.proxy

Zum Entfernen der Einstellung: git config --global --unset http.proxy

git per SSH über ProxyCommand

Wenn du Repositories per SSH klonst (Adresse wie git@github.com), hilft die Einstellung http.proxy nicht – SSH ist ein anderes Protokoll. Hier ist ProxyCommand erforderlich.

1. Öffne die Datei: nano ~/.ssh/config
2. Füge einen Block für den gewünschten Host hinzu: Zeile Host github.com, dann mit Einrückung die Zeile ProxyCommand nc -X connect -x proxy.example.com:3128 %h %p
3. Speichere die Datei.
4. Installiere das Dienstprogramm netcat, falls nicht vorhanden: sudo apt install netcat-openbsd auf Ubuntu, sudo dnf install nmap-ncat auf RHEL.

Hier werden %h und %p automatisch durch den Zielhost und -port ersetzt. Der Schalter -X connect weist netcat an, das HTTP-Proxy zu verwenden.

curl über .curlrc

1. Öffne die Datei: nano ~/.curlrc
2. Füge die Zeile hinzu: proxy = "http://ivan:secret123@proxy.example.com:3128"
3. Speichere die Datei.

Jetzt verwendet curl den Proxy immer, auch ohne Umgebungsvariablen.

wget über .wgetrc

1. Öffne die Datei: nano ~/.wgetrc
2. Füge die Zeilen hinzu: http_proxy = http://proxy.example.com:3128 und https_proxy = http://proxy.example.com:3128
3. Füge use_proxy = on hinzu
4. Speichere die Datei.

composer für PHP

Composer liest die Umgebungsvariable HTTP_PROXY, daher ist oft keine separate Einrichtung erforderlich. Wenn du es explizit angeben möchtest, verwende die Variable beim Start: HTTP_PROXY=http://proxy.example.com:3128 composer install

Go und GOPROXY: Eine wichtige Warnung

⚠️ Achtung: Die Variable GOPROXY ist NICHT der Proxy-Server im herkömmlichen Sinne. Man darf sie nicht verwechseln. GOPROXY verweist auf ein Go-Modul-Spiegelbild – einen Dienst, von dem Bibliotheken heruntergeladen werden. Es ist eine Repository-Adresse, kein Netzwerk-Proxy.

Damit Go über deinen normalen Proxy ins Internet geht, verwende die Standardvariablen HTTP_PROXY und HTTPS_PROXY. Lass GOPROXY auf dem Standardwert, es sei denn, du hast eine separate Aufgabe, das Modulspiegelbild zu ändern.

Tipp: Merke dir die Regel: Wenn im Variablennamen das Wort PROXY vorkommt, bedeutet das noch lange nicht, dass es sich um deinen Netzwerk-Proxy handelt. GOPROXY, npm registry und ähnliche beziehen sich auf Paketquellen.

✅ Überprüfung: Führe mit jedem konfigurierten Tool einen Testvorgang durch: sudo apt update, npm install, git ls-remote usw. Alle sollten erfolgreich auf das Netzwerk zugreifen können.

Schritt 4: Docker und Kubernetes konfigurieren

Ziel dieses Schritts: Docker ist ein Sonderfall. Es gibt drei verschiedene Orte, um den Proxy zu konfigurieren, und sie zu verwechseln ist ein typischer Fehler. Schauen wir uns jeden an.

Ort 1: Docker-Daemon über systemd drop-in

Diese Einstellung ist erforderlich, damit Docker selbst Images aus der Registry herunterladen kann. Der Docker-Daemon wird von systemd verwaltet, daher verwenden wir den bereits bekannten Mechanismus drop-in.

1. Erstelle das Verzeichnis: sudo mkdir -p /etc/systemd/system/docker.service.d
2. Erstelle die Datei: sudo nano /etc/systemd/system/docker.service.d/proxy.conf
3. Füge den Abschnitt [Service] hinzu.
4. Füge die Zeile Environment="HTTP_PROXY=http://proxy.example.com:3128" hinzu.
5. Füge analoge Zeilen für HTTPS_PROXY und NO_PROXY hinzu.
6. Lade die Konfiguration neu: sudo systemctl daemon-reload
7. Starte Docker neu: sudo systemctl restart docker

Überprüfen kannst du mit: sudo systemctl show --property=Environment docker

Ort 2: Image-Build über build-arg

Beim Bau eines Images werden die Befehle in der Dockerfile (z. B. apt install) in einer isolierten Umgebung ausgeführt, die den Proxy des Hosts nicht sieht. Der Proxy muss explizit übergeben werden.

1. Füge in der Dockerfile vor den RUN-Befehlen die Anweisungen ARG http_proxy und ARG https_proxy hinzu.
2. Baue das Image mit Übergabe der Argumente: docker build --build-arg http_proxy=http://proxy.example.com:3128 --build-arg https_proxy=http://proxy.example.com:3128 -t myimage .

⚠️ Achtung: Schreibe das Proxy-Passwort nicht direkt per ENV-Anweisung in die Dockerfile. Es bleibt in den Image-Layern erhalten, und jeder, der das Image erhält, sieht das Passwort. Verwende stattdessen build-arg, oder noch besser, einen Proxy ohne Passwort für den Build.

Ort 3: Container beim Start über ~/.docker/config.json

Damit gestartete Container automatisch die Proxy-Variablen erhalten, konfiguriere die Docker-Client-Konfigurationsdatei.

1. Öffne die Datei: nano ~/.docker/config.json
2. Füge den proxies-Block mit dem Abschnitt default hinzu.
3. Gib darin httpProxy, httpsProxy und noProxy mit deinen Werten an.
4. Speichere die Datei.

Ab sofort werden die Variablen bei jedem docker run automatisch in den Container weitergegeben.

Variablen im Kubernetes-Manifest

In Kubernetes wird der Proxy über Umgebungsvariablen in der Containerspezifikation festgelegt. Füge im Abschnitt env des Pod- oder Deployment-Manifests Elemente mit den Namen HTTP_PROXY, HTTPS_PROXY, NO_PROXY und entsprechenden Werten hinzu.

Tipp: Vertrauliche Werte in Kubernetes speicherst du in einem Secret-Objekt und bindest sie über valueFrom ein, anstatt das Passwort direkt in das Manifest zu schreiben. So gelangt das Passwort nicht in die Versionsverwaltung.

✅ Überprüfung: Führe docker pull hello-world aus – das Image sollte heruntergeladen werden. Führe dann docker run --rm alpine env | grep -i proxy aus – du solltest die weitergegebenen Variablen im Container sehen.

Schritt 5: Proxy in CI einrichten – GitHub Actions und GitLab Runner

Ziel dieses Schritts: Pipeline-Pipelines in CI dazu bringen, über den Proxy zu arbeiten, dabei den Zugang sicher zu speichern und das Passwort nicht in den Logs preiszugeben.

Zugangsdaten in Secrets speichern

Die goldene Regel in CI: Schreibe das Proxy-Passwort niemals direkt in die YAML-Datei der Pipeline. Die Datei liegt im Repository, und das Passwort wäre für alle sichtbar. Verwende den Mechanismus der Secrets.

In GitHub Actions werden Secrets in den Repository-Einstellungen hinzugefügt: Abschnitt Settings, dann Secrets and variables, dann Actions. Erstelle ein Secret mit dem Namen PROXY_URL und füge die vollständige Proxy-URL ein.

In GitLab heißen Secrets CI/CD-Variablen. Sie werden unter Settings, dann CI/CD, dann Variables hinzugefügt. Aktiviere unbedingt die Optionen Masked und Protected für sensible Werte.

Einrichtung von GitHub Actions

1. Füge in der Pipeline-Datei .github/workflows auf Job-Ebene den Block env hinzu.
2. Setze HTTP_PROXY auf den Wert aus dem Secret mit der Syntax der doppelten geschweiften Klammern und secrets.PROXY_URL.
3. Setze analog HTTPS_PROXY und NO_PROXY.
4. Diese Variablen stehen dann allen Schritten des Jobs zur Verfügung.

Einrichtung von GitLab Runner

In GitLab gibt es zwei Ebenen. Du kannst die Variablen in der Datei .gitlab-ci.yml über den Block variables setzen oder auf Runner-Ebene in dessen Konfigurationsdatei config.toml über den Abschnitt environment.

1. Für das Projekt: Füge in .gitlab-ci.yml den Block variables mit Verweisen auf geschützte Variablen hinzu.
2. Für alle Projekte des Runners: Öffne die config.toml des Runners und füge im Abschnitt [[runners]] den Parameter environment mit der Liste der benötigten Variablen hinzu.

Passwort in Logs ausblenden

Selbst mit Secrets kann das Passwort versehentlich in einem Log auftauchen, wenn ein Befehl es ausgibt. GitHub Actions blendet die Werte von Secrets automatisch mit Sternchen aus. In GitLab übernimmt das die Option Masked – aber sie funktioniert nur, wenn der Wert bestimmte Anforderungen erfüllt (keine bestimmten Sonderzeichen und ausreichende Länge).

⚠️ Achtung: Vermeide Befehle mit dem Schalter -v oder echo, die die vollständige Proxy-URL im Log ausgeben. Auch mit Maskierung ist es besser, kein Risiko einzugehen. Gib zum Debuggen nur Adresse und Port ohne Login und Passwort aus.

Tipp: Speichere die Proxy-URL ohne eingebautes Passwort und Login und Passwort als separate Secrets. So lassen sie sich leichter ausblenden und rotieren.

✅ Überprüfung: Starte die Pipeline manuell. Ein Schritt, der eine Netzwerkanfrage ausführt (z. B. das Installieren von Abhängigkeiten), sollte erfolgreich abgeschlossen werden. Das Passwort sollte in den Logs nicht sichtbar sein.

Überprüfung des Ergebnisses: Sicherstellen, dass der Traffic wirklich über den Proxy läuft

Einrichten ist das eine – du musst nachweisen, dass der Traffic tatsächlich über den Proxy und nicht direkt läuft. Hier ist eine Checkliste.

Checkliste: Was funktionieren sollte

• Der Befehl echo $http_proxy in einem neuen Terminal zeigt deine URL.
• curl -v http://example.com zeigt die Zeile Connected to Proxy.
• sudo apt update aktualisiert die Paketlisten erfolgreich.
• git ls-remote zu einem entfernten Repository funktioniert.
• docker pull lädt ein Image herunter.
• Die CI-Pipeline wird grün.

Wie du zuverlässig testest

Der ehrlichste Weg ist, herauszufinden, welche externe IP-Adresse der Zielserver sieht. Führe eine Anfrage an einen Dienst aus, der deine IP anzeigt. Wenn du über den Proxy gehst, siehst du die IP-Adresse des Proxy-Servers, nicht deine eigene.

1. Führe eine Anfrage ohne Proxy aus: env -u http_proxy -u https_proxy curl -s http://ifconfig.me – du siehst deine echte IP.
2. Führe eine Anfrage mit Proxy aus: curl -s http://ifconfig.me – du siehst die IP des Proxys.
3. Wenn sich die beiden IPs unterscheiden, funktioniert der Proxy.

Eine weitere Möglichkeit ist, die Logs des Proxy-Servers selbst anzusehen, wenn du Zugriff darauf hast. Deine Anfragen sollten dort auftauchen.

Tipp: Der Befehl env -u entfernt die Variable nur für einen einzelnen Befehl, ohne die Sitzung zu beeinflussen. Praktisch, um das Verhalten mit und ohne Proxy zu vergleichen.

✅ Überprüfung: Die IP-Adresse mit Proxy unterscheidet sich von der direkten. Das ist der hundertprozentige Beweis, dass der Traffic über den Proxy läuft.

Typische Fehler und deren Lösungen

Schauen wir uns häufige Probleme an. Einfaches Format: Problem, Ursache, Lösung.

Problem 1: sudo übernimmt keine Variablen

Ursache: sudo löscht standardmäßig die Umgebung aus Sicherheitsgründen. Deine export-Befehle erreichen den Befehl unter sudo nicht.

Lösung: Verwende den Schalter -E, um die Umgebung zu erhalten: sudo -E apt update. Oder konfiguriere die dauerhafte Übernahme über die sudoers-Datei. Führe sudo visudo aus und füge die Zeile Defaults env_keep += "http_proxy https_proxy HTTP_PROXY HTTPS_PROXY no_proxy NO_PROXY" hinzu. Danach gibt sudo diese Variablen immer weiter.

Problem 2: Zertifikatsfehler

Ursache: Manche Unternehmensproxys fangen HTTPS ab und ersetzen Zertifikate durch ihr eigenes Root-Zertifikat. Das System kennt es nicht und beschwert sich über eine nicht vertrauenswürdige Verbindung.

Lösung: Besorge dir das Root-Zertifikat des Proxys vom Administrator. Kopiere es unter Ubuntu und Debian nach /usr/local/share/ca-certificates mit der Erweiterung .crt und führe sudo update-ca-certificates aus. Unter RHEL lege es in /etc/pki/ca-trust/source/anchors ab und führe sudo update-ca-trust aus. Danach vertrauen alle Tools dem Proxy.

Problem 3: curl funktioniert, apt nicht

Ursache: curl liest die Umgebungsvariablen, aber apt unter sudo sieht sie nicht und hat keine eigene Proxy-Konfiguration.

Lösung: Konfiguriere den Proxy in /etc/apt/apt.conf.d wie in Schritt 3 beschrieben. Dies ist eine separate Einstellung, die apt benötigt.

Problem 4: Passwort mit Sonderzeichen

Ursache: Zeichen wie @, :, / im unkodierten Passwort stören die URL-Analyse.

Lösung: Wende Percent-Encoding aus dem Vorbereitungsabschnitt an. Ersetze @ durch %40, : durch %3A usw.

Problem 5: Fehler 407 Proxy Authentication Required

Ursache: Falscher Login oder Passwort, oder der Proxy erfordert eine Authentifizierung, die du nicht angegeben hast.

Lösung: Überprüfe Login und Passwort. Stelle sicher, dass die Anmeldedaten in der URL enthalten sind. Prüfe die Kodierung der Sonderzeichen.

Problem 6: Interne Ressourcen nicht erreichbar

Ursache: Anfragen an lokale und interne Adressen laufen über den Proxy, der sie nicht kennt.

Lösung: Füge diese Adressen zu NO_PROXY hinzu. Vergiss nicht localhost, 127.0.0.1 und interne Domains mit einem Punkt am Anfang.

Problem 7: Docker-Daemon sieht den Proxy nicht

Ursache: Du hast die Variablen in der bashrc gesetzt, aber der Docker-Daemon wird von systemd verwaltet und liest sie nicht.

Lösung: Verwende das systemd drop-in aus Schritt 4, vergiss nicht daemon-reload und restart docker.

Problem 8: Einstellungen wurden nicht übernommen

Ursache: Du hast die bashrc bearbeitet, aber das Terminal nicht neu gestartet.

Lösung: Führe source ~/.bashrc aus oder öffne ein neues Terminalfenster.

Zusätzliche Möglichkeiten und fortgeschrittene Einstellungen

Wenn die Basiseinrichtung funktioniert, kannst du den Komfort und die Flexibilität verbessern.

Proxy-Umschaltfunktionen

Es ist praktisch, in ~/.bashrc zwei Funktionen einzurichten: proxy_on zum Aktivieren und proxy_off zum Deaktivieren. In proxy_on platzierst du die export-Befehle, in proxy_off die unset-Befehle. Dann kannst du mit einem einzigen Befehl umschalten.

Verschiedene Proxys für verschiedene Aufgaben

Du kannst den Proxy nur für einen einzelnen Befehl festlegen, ohne die gesamte Umgebung zu ändern. Beispiel: https_proxy=http://other:3128 curl https://example.com. Die Variable gilt nur für diesen Befehl.

SOCKS-Proxy

Wenn du einen Proxy vom Typ SOCKS5 hast, verwende das Schema socks5 in der URL und die Variable ALL_PROXY. Für curl gibt es den Schalter --socks5. Beachte, dass nicht alle Dienstprogramme mit SOCKS umgehen können.

Tipp: Für Tools, die überhaupt keinen Proxy unterstützen, gibt es Wrapper wie proxychains. Verwende sie aber bewusst, da sie das Verhalten der Netzwerkaufrufe des Programms ändern.

Übersichtstabelle der Einstellungen

Halte diese Übersicht griffbereit. Format: Tool – Konfigurationsdatei – Variable oder Direktive.

• Shell-Sitzung – temporär im Speicher – export http_proxy und HTTP_PROXY.
• Benutzer – ~/.bashrc – export der Variablen.
• Systemweit – /etc/environment – http_proxy ohne export.
• Systemweit – /etc/profile.d/proxy.sh – export der Variablen.
• systemd-Dienst – drop-in via systemctl edit – Direktive Environment.
• apt (Ubuntu, Debian) – /etc/apt/apt.conf.d/95proxies – Acquire::http::Proxy.
• dnf, yum (RHEL) – /etc/dnf/dnf.conf – proxy, proxy_username, proxy_password.
• npm – ~/.npmrc – proxy und https-proxy.
• pip – ~/.config/pip/pip.conf – proxy im Abschnitt global.
• git per HTTPS – globale git-Konfiguration – http.proxy.
• git per SSH – ~/.ssh/config – ProxyCommand.
• curl – ~/.curlrc – proxy.
• wget – ~/.wgetrc – http_proxy, https_proxy, use_proxy.
• composer – Umgebung – HTTP_PROXY.
• Docker-Daemon – /etc/systemd/system/docker.service.d/proxy.conf – Environment.
• Docker-Build – build-Befehl – build-arg http_proxy.
• Docker-Container – ~/.docker/config.json – proxies-Block.
• Kubernetes – Pod-Manifest – env mit HTTP_PROXY.
• GitHub Actions – Workflow-Datei – env-Block mit secrets.
• GitLab – .gitlab-ci.yml oder config.toml – variables oder environment.

FAQ: Häufige Fragen zur Proxy-Einrichtung

Muss ich sowohl die klein- als auch die großgeschriebenen Variablen setzen?

Ja, das ist die sicherste Strategie. Verschiedene Programme lesen unterschiedliche Schreibweisen, daher vermeidet das Setzen beider Versionen Überraschungen.

Warum sieht curl den Proxy, aber apt nicht?

Weil apt unter sudo die Umgebungsvariablen nicht erbt und eine eigene Konfigurationsdatei hat. Konfiguriere apt separat über die Datei in /etc/apt/apt.conf.d.

Wie kann ich den Proxy für einen einzelnen Befehl vorübergehend deaktivieren?

Verwende env -u http_proxy -u https_proxy vor dem Befehl. Dadurch werden die Variablen nur für diesen Aufruf entfernt.

Kann ich in NO_PROXY ein Subnetz angeben?

In der Regel nein. NO_PROXY versteht CIDR-Notation nicht zuverlässig. Gib konkrete Adressen und Domain-Suffixe mit einem Punkt am Anfang an.

Ist GOPROXY mein Proxy-Server?

Nein. GOPROXY verweist auf ein Go-Modul-Spiegelbild, nicht auf einen Netzwerk-Proxy. Verwende für den Netzwerk-Proxy in Go HTTP_PROXY und HTTPS_PROXY.

Wie bewahre ich das Proxy-Passwort sicher auf?

In CI verwende Secrets. Lokal verwende eine .netrc-Datei mit Berechtigung 600 oder einen Passwort-Manager. Vermeide, das Passwort in den Befehlsverlauf gelangen zu lassen.

Warum geht git per SSH nicht über http.proxy?

Weil SSH ein separates Protokoll ist. Konfiguriere ProxyCommand in der Datei ~/.ssh/config für den gewünschten Host.

Was tun bei Zertifikatsfehlern über den Proxy?

Installiere das Root-Zertifikat des Proxys im systemweiten Vertrauensspeicher und aktualisiere es mit dem Befehl update-ca-certificates auf Debian oder update-ca-trust auf RHEL.

Warum funktionieren die Einstellungen in der bashrc nicht in einer neuen Sitzung?

Möglicherweise hast du die falsche Datei bearbeitet, die Änderungen nicht gespeichert oder kein neues Terminal geöffnet. Überprüfe mit echo und source.

Wie kann ich sicherstellen, dass der Traffic wirklich über den Proxy läuft?

Vergleiche die externe IP mit und ohne Proxy mit einem curl-Befehl zu einem IP-Ermittlungsdienst. Unterschiedliche IPs bestätigen die Funktion des Proxys.

Fazit: Was du gelernt hast und wie es weitergeht

Herzlichen Glückwunsch, du hast einen langen Weg hinter dir. Fassen wir zusammen, was du jetzt kannst.

Du hast gelernt, eine korrekte Proxy-URL zu erstellen und Sonderzeichen im Passwort zu kodieren. Du kennst dich mit den Variablen HTTP_PROXY, HTTPS_PROXY und NO_PROXY aus, einschließlich der Feinheiten bei der Groß-/Kleinschreibung und dem Format der Ausnahmen. Du kannst den Proxy in einer Sitzung aktivieren und die Einrichtung dauerhaft machen – auf verschiedene Arten, einschließlich systemd drop-in für Dienste.

Du hast den Proxy für alle wichtigen Tools konfiguriert: apt und dnf, npm und pip, git per HTTPS und SSH, curl und wget, composer, und du verstehst den wichtigen Unterschied zu GOPROXY. Du hast die drei verschiedenen Orte der Docker-Konfiguration sowie die Variablen in Kubernetes kennengelernt. Schließlich hast du den Proxy in GitHub Actions und GitLab mit sicherer Secret-Verwaltung und Maskierung des Passworts eingerichtet.

Was du als Nächstes tun kannst: Festige dein Wissen durch Übung. Richte den Proxy auf einer Testmaschine von Grund auf neu ein, indem du dieser Anleitung folgst. Erstelle dir Umschaltfunktionen für mehr Komfort. Sieh dir die Logs deines Proxy-Servers an, um den Traffic mit eigenen Augen zu sehen.

Wie es weitergeht: Der nächste Schritt ist die Automatisierung der Einrichtung mit Konfigurationsmanagement-Tools wie Ansible, um den Proxy auf Dutzenden von Maschinen mit einem Befehl auszurollen. Es ist auch nützlich, sich tiefer mit der Arbeit mit Zertifikaten und verschiedenen Proxy-Typen zu befassen.

Tipp: Bewahre die Übersichtstabelle aus dieser Anleitung als Spickzettel auf. Sie spart dir jede Menge Zeit, wenn du schnell nachschlagen musst, wo der Proxy für ein bestimmtes Tool konfiguriert wird.

Du hast das großartig gemacht. Jetzt ist der Proxy im Linux-Terminal und in CI kein Rätsel mehr für dich. Viel Erfolg bei der Einrichtung und stabile Verbindungen!