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.

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:

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 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.

Temporäre Einstellung über Umgebungsvariablen#

Der schnellste Weg ist, die Variablen für die laufende Sitzung zu setzen:

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 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.

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:

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.

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.

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 und in SOCKS und HTTP Proxy im Vergleich: was wählen?.

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:

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 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:

# 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 und 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 angegeben, kann die Sicherheitsrichtlinie diese Bitte ablehnen.

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.

// /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:

Acquire::http::Proxy::repo.ihrefirma.local "DIRECT";

Beim Dateinamen ist eines zu beachten: Laut dem apt.conf-Handbuch 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:

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:

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 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:

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 <Adresse>. 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: Kommandozeilenoptionen setzen Umgebungsvariablen außer Kraft, und diese wiederum die Konfigurationsdatei.

# 1) einmalig
pip install --proxy "http://user:pass@pr.proxynet.io:8000" requests

# 2) Umgebungsvariable; das Muster PIP_<OPTION> gilt fuer jede Option
export PIP_PROXY="http://user:pass@pr.proxynet.io:8000"

Für eine dauerhafte Einstellung nutzen Sie die Datei ~/.config/pip/pip.conf. Systemweit /etc/pip.conf und für eine einzelne virtuelle Umgebung $VIRTUAL_ENV/pip.conf akzeptieren dasselbe Format:

[global]
proxy = http://user:pass@pr.proxynet.io:8000

Wenn Sie nicht sicher sind, welche Datei gelesen wird, listet pip config debug alle Pfade und die gerade gültigen Werte auf. Zum Rückgängigmachen schreiben Sie pip config unset global.proxy oder löschen die Zeile aus der Datei.

npm-Proxy-Einstellung#

npm liest die .npmrc-Dateien in der Reihenfolge Projekt, Benutzer, global und eingebaut; die vordere setzt die hintere außer Kraft. Laut der npm-Dokumentation werden auch die Umgebungsvariablen HTTP_PROXY und HTTPS_PROXY berücksichtigt, und der Standardwert der Option noproxy ist die Variable NO_PROXY.

npm config set proxy "http://user:pass@pr.proxynet.io:8000"
npm config set https-proxy "http://user:pass@pr.proxynet.io:8000"
npm config set noproxy "localhost,127.0.0.1,registry.ihrefirma.local"

npm config delete proxy && npm config delete https-proxy   # rueckgaengig machen

Damit die Einstellung nur in einem einzelnen Repository gilt, hängen Sie --location=project an die Befehle; npm schreibt die Werte dann in die Datei .npmrc im Wurzelverzeichnis des Projekts. Geben Sie diese Datei nicht in die Versionsverwaltung, sie enthält ein Passwort.

Eine kleine Überraschung: Der Befehl npm config get https-proxy zeigt den Wert nicht an, sondern gibt die Warnung „protected" aus. Optionen mit Zugangsdaten sind für das Auslesen gesperrt. Um den Wert zu sehen, öffnen Sie die Datei .npmrc direkt.

Docker-Proxy-Einstellung#

In Docker gibt es keine einzelne Einstellung: Der Hintergrunddienst und die Container lesen sie aus zwei voneinander unabhängigen Orten, und dazu kommt die klassische Adressfalle. Daher rührt der größte Teil der Verwirrung.

1. Der Hintergrundprozess (Images herunterladen). docker pull und docker push erledigt dockerd, nicht Ihre Shell. Laut der Docker-Dokumentation wird die Einstellung in den Schlüssel proxies der Datei /etc/docker/daemon.json geschrieben:

{
  "proxies": {
    "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,.ihrefirma.local"
  }
}

Dieselbe Aufgabe lässt sich auch mit einer Fragmentdatei auf der systemd-Seite erledigen. In die Datei /etc/systemd/system/docker.service.d/http-proxy.conf werden diese Zeilen geschrieben:

[Service]
Environment="HTTP_PROXY=http://user:pass@pr.proxynet.io:8000"
Environment="HTTPS_PROXY=http://user:pass@pr.proxynet.io:8000"
Environment="NO_PROXY=localhost,127.0.0.1,.ihrefirma.local"

Bei beiden Verfahren gilt die Einstellung erst nach sudo systemctl daemon-reload und sudo systemctl restart docker. Dieses Muster ist nicht auf Docker beschränkt: Jedem unter systemd laufenden Dienst wird ein Proxy auf diese Weise bekannt gemacht, denn der Dienst stammt nicht aus Ihrer Shell und liest Ihre ~/.bashrc nie.

2. Container und Builds. Dass die Anwendung im Container nach außen kommt, ist eine eigene Sache. Wie in der eigenen Dokumentation beschrieben, liest die Docker-CLI den Block proxies.default aus der Datei ~/.docker/config.json und gibt diese Werte als Umgebungsvariablen an neue Container und Builds weiter:

{
  "proxies": {
    "default": {
      "httpProxy": "http://user:pass@pr.proxynet.io:8000",
      "httpsProxy": "http://user:pass@pr.proxynet.io:8000",
      "noProxy": "localhost,127.0.0.1"
    }
  }
}

Die Einstellungen dieser Datei betreffen den Hintergrundprozess nicht; sie gehen nur in die Container- und Build-Umgebung und nur in neu erzeugte. Für den einmaligen Gebrauch leisten docker run --env HTTP_PROXY=... und docker build --build-arg HTTP_PROXY=... dasselbe.

3. Die Adressfalle. Läuft der Proxy auf der Maschine selbst, schreiben Sie im Container nicht http://127.0.0.1:8000. Der Container hat einen eigenen Netzwerkbereich, und 127.0.0.1 ist dort der Container selbst. Um den Host zu erreichen, verwenden Sie dessen Netzwerkadresse.

Warum betrifft die Einstellung auf dem Desktop das Terminal nicht?#

Unter Ubuntu wird die Angabe, die Sie unter Einstellungen > Netzwerk > Netzwerk-Proxy machen, in den eigenen Einstellungsspeicher von GNOME geschrieben und betrifft die Anwendungen, die diese Werte lesen: den Browser von GNOME, das Softwarezentrum, die meisten Desktop-Anwendungen. Die Shell, die Sie im Terminal öffnen, liest diesen Speicher nicht, curl und git sind also nicht betroffen. Möchten Sie dieselbe Einstellung von der Kommandozeile aus vornehmen, nutzen Sie gsettings set org.gnome.system.proxy mode 'manual' sowie die zugehörigen Schlüssel host und port, für die Terminalseite brauchen Sie aber trotzdem die Umgebungsvariable.

Das praktische Ergebnis: Gibt es auf dem Server keinen Desktop, überspringen Sie diesen Abschnitt komplett. Arbeiten Sie am Desktop, müssen Sie beide Einstellungen vornehmen. Die Entsprechungen in anderen Betriebssystemen finden Sie in Proxy-Einstellungen in Windows und Chrome einrichten, Proxy-Einstellungen auf dem Mac und in Safari und Proxy auf dem Android-Smartphone einrichten: So geht es.

Tabelle: Werkzeug, Datei und Rückgängigmachen#

Wie prüfen Sie, ob die Einstellung greift?#

Vier Schritte, der Reihe nach:

1. Die Variablen ansehen. Die Ausgabe von env | grep -i proxy sollte die erwarteten Werte und ihre großgeschriebenen Zwillinge zeigen.
2. Die Ausgangsadresse ansehen. Die von curl -s https://api.ipify.org zurückgegebene Adresse sollte die des Proxys sein.
3. Die Verbindung verfolgen. Suchen Sie in der Ausgabe von curl -v nach der Zeile Uses proxy env variable und nach einer Trying-Zeile, die statt zum Ziel zur Proxy-Adresse geht. Fehlen diese beiden Zeilen, geht die Anfrage gar nicht an den Proxy.
4. Jedes Werkzeug einzeln testen. Die Befehle sudo apt update, git ls-remote <Adresse>, pip download --no-deps six und npm view express version nutzen ihre eigene Konfiguration und müssen jeweils einzeln geprüft werden.

Die ausführlichen Schritte zur Messung und zur Prüfung des Standorts haben wir in Funktioniert mein Proxy? So testen Sie einen Proxy gesammelt.

Häufige Fehler#

• export vergessen. http_proxy=... allein lässt die Variable nur in der Shell und gibt sie nicht an das gestartete Programm weiter.
• Nur http_proxy setzen. Anfragen an HTTPS-Adressen schauen auf die Variable https_proxy; fehlt sie, versuchen sie den direkten Weg.
• Den Wert von https_proxy mit https:// beginnen. Solange Ihr Proxy kein TLS terminiert, beginnt der Wert mit http://.
• Das Passwort unkodiert schreiben. Das @ darin trennt die Adresse, das Ergebnis ist ein 407. Die übrigen Ursachen für 407 haben wir in HTTP-Statuscodes beim Web Scraping: 403, 407, 429, 503 aufgeführt.
• Einen Port in die no_proxy-Liste schreiben. Der Eintrag server:8080 passt auf nichts.
• Von einem Dienst die Shell-Einstellung erwarten. Ein systemd-Dienst liest ~/.bashrc nicht; es braucht eine Unit- oder Fragmentdatei.
• Die Konfigurationsdatei vergessen und die Umgebungsvariable beschuldigen. git config --get http.proxy, pip config debug und npm config list fördern einen alten Wert zutage.
• Im Container 127.0.0.1 schreiben. Der Container hat einen eigenen Netzwerkbereich.

Die Diagnose der Fälle, in denen die Verbindung gar nicht erst zustande kommt, haben wir einzeln in Proxy-Fehler: Was tun, wenn der Proxyserver nicht reagiert? behandelt.

Entscheidungshilfe#

Häufige Fragen#

Ich habe alles eingestellt, aber manche Programme gehen weiterhin direkt, warum?#

Umgebungsvariablen zu lesen ist keine Pflicht, sondern eine Gewohnheit. Manche in Go geschriebenen Werkzeuge suchen nur die großgeschriebene Form, manche Java-Anwendungen erwarten ihren eigenen Parameter -Dhttp.proxyHost. Schauen Sie in der Dokumentation des Programms unter dem Stichwort Proxy nach; hat es eine eigene Einstellung, setzt die Umgebungsvariable sie nicht außer Kraft.

Kann ich einen Proxy nutzen, ohne das Passwort in eine Datei zu schreiben?#

Ja. Wenn Sie im Proxy-Panel die Ausgangs-IP Ihres Servers freigeben, reduziert sich die Adresse auf http://pr.proxynet.io:8000 und in keiner Datei steht ein Passwort. Auf Servern mit fester IP ist das der sauberste Weg.

Kann ich mehrere Proxys gleichzeitig nutzen?#

Umgebungsvariablen halten eine einzige Adresse. Die Unterscheidung treffen Sie nach Protokoll (http_proxy und https_proxy unterschiedlich) oder nach Werkzeug (in git http.<Adresse>.proxy, in apt eine hostspezifische Zeile). Brauchen Sie pro Anfrage eine andere Ausgangsadresse, übernimmt ein Rotierender Proxy-Paket mit einer einzigen Adresse diese Arbeit für Sie.

Laufen auch meine SSH-Verbindungen über den Proxy?#

Nein. http_proxy und die verwandten Variablen betreffen den SSH-Client nicht. Um SSH über einen Proxy zu führen, wird in der Datei ~/.ssh/config die Zeile ProxyCommand definiert. Deshalb ignorieren auch Adressen der Form git clone git@... die Einstellung http.proxy.

Warum sehen meine cron-Jobs den Proxy nicht?#

cron startet die Jobs nicht aus Ihrer Login-Shell und liest Ihre ~/.bashrc nicht. Definieren Sie die Variablen entweder am Anfang der crontab-Datei oder setzen Sie sie mit export in den ersten Zeilen des Skripts.

apt ist über den Proxy langsamer geworden, ist das normal?#

Paket-Repositorys sind geografisch verteilt, und ein Proxy kann den Verkehr in ein anderes Land tragen. Den Proxy nur für externe Quellen zu nutzen und lokale Repository-Spiegel mit der Zeile Acquire::http::Proxy::<host> "DIRECT"; auszunehmen, reicht in den meisten Fällen.

Fazit#

Die Proxy-Einstellung unter Linux besteht aus drei Schichten: der Shell-Umgebung, der eigenen Konfigurationsdatei des Werkzeugs und der Dienst-Unit. Beginnen Sie im Terminal mit export, nutzen Sie für die Dauerhaftigkeit ~/.bashrc oder /etc/environment und konfigurieren Sie danach apt, git, pip, npm und Docker einzeln aus ihren eigenen Dateien. Prüfen Sie jeden Schritt mit curl -s https://api.ipify.org und vergessen Sie nicht, Ihr internes Netz in die no_proxy-Liste aufzunehmen. Für feste Aufgaben mit hohem Volumen auf dem Server werfen Sie einen Blick auf unsere Lösungen für Data Scraping oder direkt auf unsere Seite HTTPS-Proxy.