--- title: "Linux-Proxy-Einstellungen: Terminal, apt, Docker und Git" description: "Unter Linux wird ein Proxy über Umgebungsvariablen temporär und über /etc/environment dauerhaft gesetzt; apt, git, pip, npm und Docker lesen ihre eigene Datei." url: https://proxynet.io/de/blog/linux-proxy-settings date: 2026-09-19 author: "Acar Diveroli" category: "Anleitungen, Integration" lang: de --- # Linux-Proxy-Einstellungen: Terminal, apt, Docker und Git Sie haben auf einem Linux-Server den Proxy eingetragen, `curl` funktioniert, und dann geht `sudo apt update` weiterhin an die alte Adresse, `git clone` bleibt hängen und `docker build` kommt gar nicht erst ins Netz. Das bedeutet nicht, dass Sie etwas falsch eingestellt haben. Unter Linux gibt es keinen zentralen „Proxy-Schalter": Die Umgebungsvariablen Ihrer Shell sind eine Schicht, die eigene Konfigurationsdatei jedes Werkzeugs ist die zweite, und Dienste unter systemd sind eine dritte, völlig eigenständige Schicht. Dieser Beitrag geht die drei Schichten der Reihe nach durch. Zuerst die temporäre und die dauerhafte Einstellung über Umgebungsvariablen, der Unterschied zwischen Groß- und Kleinschreibung, die Schreibregeln für `no_proxy` und der Grund, warum `sudo` Ihre Umgebung nicht mitnimmt. Danach die Konfiguration für apt, git, pip, npm und Docker im Einzelnen, warum die Einstellung der Desktop-Oberfläche das Terminal nicht betrifft, die Prüfschritte und für jede Einstellung die Zeile zum Rückgängigmachen. > **Hinweis: Kurzantwort** > > Für den temporären Gebrauch im Terminal genügen `export http_proxy=` und `export https_proxy=`. Soll es dauerhaft sein, schreiben Sie es für einen einzelnen Benutzer in `~/.bashrc` und systemweit in `/etc/environment`. Werkzeuge, die Umgebungsvariablen nicht lesen, verlangen ihre eigene Datei: `/etc/apt/apt.conf.d/` für apt, `git config http.proxy` für git, `pip.conf` für pip, `.npmrc` für npm, `/etc/docker/daemon.json` für den Docker-Hintergrunddienst. `sudo` ersetzt Ihre Umgebungsvariablen standardmäßig durch eine saubere Umgebung; mit `sudo -E` nehmen Sie sie mit. ## Warum lässt sich die Proxy-Einstellung unter Linux nicht an einer Stelle machen? Unter Windows und macOS führt das Betriebssystem einen System-Proxy-Eintrag, und die meisten Programme lesen ihn. Unter Linux gibt es einen solchen Eintrag nicht. Stattdessen gibt es eine Konvention aus den 1990er Jahren: Ein Programm schaut zur Laufzeit auf die Umgebungsvariablen `http_proxy`, `https_proxy`, `all_proxy` und `no_proxy` und nutzt sie, wenn sie gesetzt sind. Das ist kein Standard, sondern eine verbreitete Gewohnheit. Sie müssen für jedes Werkzeug einzeln wissen, ob es sich daran hält. Die drei Schichten auseinanderzuhalten löst die meisten Probleme: 1. **Die Shell-Umgebung.** Variablen, die Sie mit `export` setzen, werden an die Prozesse vererbt, die Sie aus dieser Shell starten. Mit dem Schließen des Terminals sind sie weg. 2. **Die eigene Konfiguration des Werkzeugs.** apt, git, pip, npm und Docker haben eigene Dateien. Diese Dateien arbeiten unabhängig von den Umgebungsvariablen und setzen sie meist außer Kraft. 3. **Die Dienstumgebung.** Ein von systemd gestarteter Dienst stammt nicht aus Ihrer Shell und sieht Ihre Variablen deshalb nie. Er liest aus seiner eigenen Unit-Datei. Um zu verstehen, warum eine Einstellung „nicht funktioniert", fragen Sie zuerst, auf welche Schicht dieses Werkzeug schaut. ## In welchem Format wird die Proxy-Adresse geschrieben? In allen folgenden Verfahren wird die Adresse gleich geschrieben: ```text http://user:pass@pr.proxynet.io:8000 ``` Das Schema `http://` ist das Protokoll der Verbindung zum Proxy und bleibt auch beim Aufruf von HTTPS-Adressen unverändert. Der Teil `user:pass@` wird nur benötigt, wenn Sie sich mit Benutzername und Passwort authentifizieren; wenn Sie im Panel die IP Ihres Servers freigegeben haben, lassen Sie diesen Teil ganz weg. Den Unterschied der beiden Verfahren haben wir in [Proxy-Authentifizierung: User:Pass oder IP-Whitelist](/de/blog/proxy-authentication-methods) beschrieben. Enthält Ihr Passwort `@`, `:`, `#` oder `/`, schreiben Sie diese Zeichen prozentkodiert in die Adresse: `%40` für `@`, `%23` für `#`. Ein nicht kodiertes `@` trennt die Adresse an der falschen Stelle, und das Ergebnis ist meist ein `407 Proxy Authentication Required`. Details zur Kodierung und die Unterschiede zwischen den Bibliotheken stehen im Abschnitt zu den Zugangsdaten in [Proxys in Node.js verwenden: Axios und node-fetch](/de/blog/nodejs-proxy). ## Temporäre Einstellung über Umgebungsvariablen Der schnellste Weg ist, die Variablen für die laufende Sitzung zu setzen: ```bash export http_proxy="http://user:pass@pr.proxynet.io:8000" export https_proxy="$http_proxy" export no_proxy="localhost,127.0.0.1,.ihrefirma.local" curl -s https://api.ipify.org; echo ``` Zeigt die Ausgabe nicht Ihre, sondern die IP-Adresse des Proxys, funktioniert die Einstellung. Zum Entfernen genügt `unset http_proxy https_proxy no_proxy`. Was diese Variablen sind, welche Werkzeuge sie lesen und wie sie sich zu Werkzeugdateien wie `.wgetrc` verhalten, haben wir ausführlich in [Proxy-Nutzung mit wget: Befehle und Beispiele](/de/blog/wget-proxy) beschrieben; hier wiederholen wir es nicht. Für die Optionen auf der cURL-Seite und die Nutzung von SOCKS5 lesen Sie [cURL mit Proxy verwenden: Befehle und Beispiele](/de/blog/curl-proxy). Zwei praktische Hinweise: Ohne `export` bleibt die Variable nur in der Shell selbst und wird nicht an die Programme weitergegeben, die Sie starten. Wenn Sie die Einstellung nur für einen einzelnen Befehl brauchen, schreiben Sie die Variable vor den Befehl, dann ist auch nur dieser Befehl betroffen: ```bash https_proxy="http://user:pass@pr.proxynet.io:8000" curl -s https://api.ipify.org ``` ## http_proxy und HTTP_PROXY: warum ist die Schreibweise wichtig? Unter Linux wird bei Namen von Umgebungsvariablen zwischen Groß- und Kleinschreibung unterschieden: `http_proxy` und `HTTP_PROXY` sind zwei verschiedene Variablen. Die Werkzeuge behandeln beide nicht gleich. cURL und alles, was libcurl verwendet, akzeptiert die Proxy-Variablen in Klein- und in Großschreibung und gibt der kleingeschriebenen Form den Vorrang. Die einzige Ausnahme ist `http_proxy`: cURL liest sie **nur in Kleinschreibung**. Der Grund ist die Sicherheit. Wenn ein CGI-Skript läuft, wandelt der Server die Header der eingehenden Anfrage in Umgebungsvariablen mit dem Präfix `HTTP_` um; ein aus der Ferne gesendeter `Proxy:`-Header kann also die Variable `HTTP_PROXY` füllen. Welche Sicherheitsprobleme dieses Verhalten in der Vergangenheit verursacht hat, steht in der [cURL-Dokumentation](https://everything.curl.dev/usingcurl/proxies/env.html). In der Praxis reichen zwei Regeln: - **Gehen Sie von der Kleinschreibung aus.** Schreiben Sie `http_proxy`, `https_proxy`, `no_proxy`. - **Setzen Sie beide.** Manche Java- und Go-Werkzeuge suchen nur die großgeschriebene Form. Beide Gruppen auf denselben Wert zu setzen ist der Weg mit den wenigsten Überraschungen. ```bash export http_proxy="http://user:pass@pr.proxynet.io:8000" export https_proxy="$http_proxy" export no_proxy="localhost,127.0.0.1" # auch die grossgeschriebenen Zwillinge setzen export HTTP_PROXY="$http_proxy" HTTPS_PROXY="$https_proxy" NO_PROXY="$no_proxy" ``` `all_proxy` ist der protokollunabhängige Standardwert; gibt es eine protokollspezifische Variable, hat diese Vorrang. Wenn Sie SOCKS5 nutzen, bevorzugen Sie die Form `all_proxy="socks5h://user:pass@pr.proxynet.io:1080"`. Beim Schema `socks5h` findet die Namensauflösung auf der Proxy-Seite statt. Die Unterschiede finden Sie auf unserer Seite [SOCKS5-Proxy](https://proxynet.io/de/socks5-proxy) und in [SOCKS und HTTP Proxy im Vergleich: was wählen?](/de/blog/socks-vs-http-proxy). ## Wie wird no_proxy geschrieben? `no_proxy` ist eine kommagetrennte Liste von Adressen, die nicht über den Proxy laufen sollen. Es gibt dafür keinen Standard, deshalb sehen Sie kleine Unterschiede zwischen den Werkzeugen. In unseren Tests mit cURL 8.21 verhält es sich so: | Schreibweise | Ergebnis | |---|---| | `example.com` | `example.com` und `www.example.com` laufen ohne Proxy, unabhängig vom Port | | `.example.com` | umfasst die Subdomains und die Domain selbst | | `sub.example.com` | nur diese Subdomain; `example.com` darüber läuft weiterhin über den Proxy | | `EXAMPLE.COM` | Groß- und Kleinschreibung spielt keine Rolle, es passt | | `example.com:80` | **passt nicht**, die Angabe eines Ports wird nicht unterstützt | | `10.0.0.0/8` | ab cURL 7.86 funktioniert die CIDR-Notation | | `*` | ein einzelner Stern nimmt alle Adressen vom Proxy aus | Es gibt zwei Fallen. Die erste ist die Portangabe: `no_proxy` ist eine Hostliste, und wenn Sie `server:port` schreiben, passt diese Zeile auf nichts und die Anfrage geht stillschweigend an den Proxy. Die zweite ist, dass CIDR nicht überall funktioniert; das Modul `urllib` von Python erkennt den Eintrag `10.0.0.0/8` in derselben Liste nicht und schickt die Adresse `10.1.2.3` an den Proxy. Wenn Sie auf der Python-Seite das interne Netz außen vor lassen wollen, schreiben Sie die Adressen einzeln oder mit dem Domainnamen. Nehmen Sie mindestens Folgendes in die Liste auf: `localhost`, `127.0.0.1`, falls vorhanden Ihre interne Domain und das Container-Netz. Sonst läuft auch die Anfrage an Ihren lokalen Entwicklungsserver über den Proxy und läuft in einen Timeout. ## Die Einstellung dauerhaft machen: ~/.bashrc und /etc/environment Wenn Sie das Terminal schließen, sind die `export`-Zeilen verloren. Für die Dauerhaftigkeit gibt es zwei Orte mit unterschiedlicher Reichweite. **`~/.bashrc` für einen einzelnen Benutzer.** Hängen Sie dieselben `export`-Zeilen ans Ende der Datei und lesen Sie sie mit `source ~/.bashrc` neu ein. Diese Datei wird in interaktiven Shells ausgeführt, gilt also, wenn Sie sich per SSH anmelden und Befehle eingeben. Mit Zsh entspricht das `~/.zshrc`, und die Zeilen gelten unverändert; mit fish heißt die Datei `~/.config/fish/config.fish` und die Schreibweise wird zu `set -gx http_proxy "…"`. **`/etc/environment` systemweit.** Diese Datei liest nicht die Shell, sondern das Modul `pam_env` von PAM. Die Variablen werden für jeden Benutzer gesetzt, der eine Sitzung öffnet. Das Format ist streng: ein `SCHLÜSSEL=WERT` pro Zeile, und das Schlüsselwort `export` wird [wie in der Dokumentation beschrieben](https://man7.org/linux/man-pages/man8/pam_env.8.html) aus Kompatibilitätsgründen akzeptiert, aber ignoriert; eine Shell-Expansion findet nicht statt. Eine Referenz wie `$http_proxy` funktioniert hier also nicht, Sie müssen den Wert ausschreiben: ```ini # Inhalt von /etc/environment, ohne Anfuehrungszeichen und schlicht http_proxy=http://user:pass@pr.proxynet.io:8000 https_proxy=http://user:pass@pr.proxynet.io:8000 no_proxy=localhost,127.0.0.1 ``` Die Änderung gilt für neue Sitzungen; um sie in Ihrer offenen SSH-Sitzung zu sehen, melden Sie sich ab und wieder an. Zum Rückgängigmachen löschen Sie die Zeilen und erneuern die Sitzung. In beiden Dateien steht das Passwort im Klartext. Gibt es auf dem Server mehrere Benutzer, bevorzugen Sie die Benutzerdatei gegenüber `/etc/environment`, oder geben Sie im Panel die IP des Servers frei und arbeiten ganz ohne Passwort. Für dieses Szenario mit fester Ausgangsadresse eignen sich die Pakete [ISP-Proxy](https://proxynet.io/de/static-isp-residential-proxy) und [Datacenter-Proxy](https://proxynet.io/de/datacenter-proxy). ## Warum sieht sudo Ihre Proxy-Einstellung nicht? Wenn `sudo apt update` den Proxy ignoriert, liegt es meist daran: sudo ersetzt aus Sicherheitsgründen die meisten Umgebungsvariablen des aufrufenden Benutzers durch eine saubere Umgebung. Dass Sie die Umgebung des Benutzers erhalten möchten, teilen Sie mit der Option `-E` mit; wie im [sudo-Handbuch](https://www.sudo.ws/docs/man/sudo.man/) angegeben, kann die Sicherheitsrichtlinie diese Bitte ablehnen. ```bash sudo -E apt update ``` Nutzt der Befehl den Proxy weiterhin nicht, bleiben zwei Möglichkeiten: Entweder erlaubt die sudoers-Konfiguration die Weitergabe dieser Variablen nicht, oder das Werkzeug schaut ohnehin nicht auf die Umgebungsvariable, sondern auf seine eigene Datei. Für apt ist Letzteres die robustere Lösung und das Thema des nächsten Abschnitts. ## apt-Proxy-Einstellung apt liest auch Umgebungsvariablen, sein eigentlicher Ort ist aber das Verzeichnis `/etc/apt/apt.conf.d/`. Eine Fragmentdatei, die Sie dort ablegen, löst sowohl das `sudo`-Problem als auch die per cron laufenden Aktualisierungen. ```text // /etc/apt/apt.conf.d/95proxy Acquire::http::Proxy "http://user:pass@pr.proxynet.io:8000"; Acquire::https::Proxy "http://user:pass@pr.proxynet.io:8000"; ``` Das Semikolon am Zeilenende ist Pflicht. Um einen bestimmten Server vom Proxy auszunehmen, schreiben Sie für diesen Host eine eigene Zeile mit dem Schlüsselwort `DIRECT`: ```text Acquire::http::Proxy::repo.ihrefirma.local "DIRECT"; ``` Beim Dateinamen ist eines zu beachten: Laut dem [apt.conf-Handbuch](https://manpages.debian.org/bookworm/apt/apt.conf.5.en.html) werden von den Fragmenten in diesem Verzeichnis nur jene gelesen, die keine Erweiterung oder die Erweiterung `conf` haben und in deren Namen nur Buchstaben, Ziffern, Bindestriche, Unterstriche und Punkte vorkommen. `95proxy` und `95proxy.conf` sind also gültig; `95proxy.bak` wird ignoriert, und apt teilt das mit einem Hinweis mit. Zum Rückgängigmachen löschen Sie die Datei oder verschieben sie aus dem Verzeichnis, ein weiterer Befehl ist nicht nötig. ## git-Proxy-Einstellung git nutzt für HTTP- und HTTPS-Adressen libcurl und liest daher die Variablen `http_proxy` und `https_proxy` ohnehin. Wenn Sie eine dauerhafte und explizite Einstellung möchten, schreiben Sie sie in die eigene Konfiguration: ```bash git config --global http.proxy "http://user:pass@pr.proxynet.io:8000" git config --global --get http.proxy # pruefen git config --global --unset http.proxy # rueckgaengig machen ``` Soll sie nur für einen bestimmten Server gelten, können Sie sie an die Adresse knüpfen. So gehen Sie direkt zu Ihrem internen git-Server und über den Proxy nach außen: ```bash git config --global http.https://github.com.proxy "http://user:pass@pr.proxynet.io:8000" ``` Ein Detail aus unserem Test sorgt in der Praxis häufig für Ärger. Der Standardwert der git-Einstellung `http.proxyAuthMethod` ist `anyauth`, und laut der [git-config-Dokumentation](https://git-scm.com/docs/git-config) setzt dieser Modus voraus, dass der Proxy auf eine Anfrage ohne Zugangsdaten mit einem `407` und einem `Proxy-Authenticate`-Header antwortet. Bei Proxys, die diese Erkundungsrunde nicht abschließen, bricht git mit dem Fehler `Proxy CONNECT aborted` ab. Derselbe Befehl läuft mit `basic` schon im ersten Anlauf durch: ```bash git config --global http.proxyAuthMethod basic ``` Wollen Sie die Einstellung nur für einen Befehl ausprobieren, rührt die Option `-c` die Konfiguration überhaupt nicht an: `git -c http.proxy=... ls-remote `. Wenn Sie über SSH abrufen, greift keine dieser Einstellungen; für SSH braucht es die Zeile `ProxyCommand` in `~/.ssh/config`. ## pip-Proxy-Einstellung pip kennt drei Wege, und die Rangfolge steht in der [pip-Dokumentation](https://pip.pypa.io/en/stable/topics/configuration/): Kommandozeilenoptionen setzen Umgebungsvariablen außer Kraft, und diese wiederum die Konfigurationsdatei. ```bash # 1) einmalig pip install --proxy "http://user:pass@pr.proxynet.io:8000" requests # 2) Umgebungsvariable; das Muster PIP_