Inhalt des Artikels

Docker ist längst zum Standard für Parser, Bots, Werbeautomatisierungen und kleine Services geworden. Container haben aber eine Besonderheit: Sie leben in einer isolierten Umgebung und wissen nichts von den Proxys, die du auf deinem Computer eingerichtet hast. Das Ergebnis: Ein Skript im Container geht mit deiner echten IP online, während du glaubst, über einen mobilen Proxy zu arbeiten. Diese Anleitung schließt diese Lücke ein für alle Mal.

Einführung: Was du bekommst und für wen dieser Guide geeignet ist

Nach dieser Anleitung kannst du Proxys in Docker auf allen drei Ebenen einrichten, auf denen das überhaupt möglich ist: für einen einzelnen Container über Umgebungsvariablen, für den gesamten Docker-Client und -Daemon über Konfigurationsdateien sowie auf Netzwerkebene über einen separaten Gateway-Container. Du verstehst, worin sich diese Ebenen unterscheiden, wann welche zum Einsatz kommt und wie du sicherstellst, dass der Traffic wirklich über den Proxy läuft und nicht daran vorbei.

Für wen diese Schritt-für-Schritt-Anleitung gedacht ist

  • Marketing- und SMM-Spezialisten, die in Docker Dienste für Autoposting, Analytics oder Monitoring betreiben und möchten, dass jedes Tool mit einer eigenen mobilen IP arbeitet.
  • Media-Buyer, die Dutzende Container mit Trackern, Offer-Parsern und Spy-Tools betreiben und für jeden ein eigenes Geo benötigen.
  • Entwickler, die eine Anwendung aus einer anderen Region testen oder Integrationstests über einen Proxy durchführen möchten.
  • Geschäftsinhaber, deren Mitarbeiter oder Auftragnehmer Infrastruktur in Containern betreiben und verstehen müssen, wie dort die Arbeit mit Proxys funktioniert.

Was du vorher wissen solltest

Wir setzen keine tiefgreifenden Kenntnisse voraus. Es reicht, wenn du ein Terminal öffnen, einen Befehl kopieren und lesen kannst, was er ausgegeben hat. Wenn du noch nie mit Docker gearbeitet hast, keine Sorge: Im Abschnitt mit den Grundbegriffen erklären wir alle Begriffe in einfacher Sprache. Kubernetes, Cluster-Orchestrierung und Cloud-Plattformen lassen wir bewusst außen vor: Das ist ein eigenes Thema, und hier bleiben wir strikt auf Docker-Ebene.

Wie viel Zeit du brauchst

Für die vollständige Durchführung mit Überprüfungen brauchst du 60 bis 120 Minuten. Wenn du nur ein Szenario brauchst, zum Beispiel einen Proxy für einen Container, reichen 15 Minuten. Falls Docker noch nicht installiert ist, rechne mit 20–30 Minuten zusätzlich für die Installation.

Vorbereitung: Tools, Zugänge und Systemanforderungen

Bevor du den Proxy in Docker einrichtest, sammle alles Nötige. So musst du nicht mitten im Prozess nach einem Login suchen oder Tools installieren.

Was du brauchst

  1. Computer oder Server mit Docker. Geeignet sind Linux (Ubuntu 22.04 oder 24.04, Debian 12), macOS mit Docker Desktop oder Windows 10/11 mit Docker Desktop und WSL2. Im Jahr 2026 sind Docker Engine ab Version 27 und Docker Compose v2 aktuell, aufgerufen mit dem Befehl docker compose (mit Leerzeichen, ohne Bindestrich).
  2. Daten deines mobilen Proxys. Du brauchst vier Dinge: Hostadresse (IP oder Domainname), Port, Login und Passwort. Diese findest du im Kundenbereich deines Anbieters. Kläre außerdem, welches Protokoll verfügbar ist: HTTP oder SOCKS5. Bei den meisten Anbietern mobiler Proxys, einschließlich mobileproxy.space, gibt es beide Varianten auf verschiedenen Ports.
  3. Terminal. Unter Linux und macOS ist es integriert. Unter Windows nutze PowerShell oder das WSL2-Terminal (letzteres ist praktischer, weil die Befehle identisch zu Linux sind).
  4. Texteditor. Beliebig: nano, vim, VS Code, Notepad++. Wird zum Bearbeiten der Konfigurationsdateien benötigt.
  5. Das Tool curl. Ist normalerweise bereits installiert. Damit kannst du überprüfen, über welche IP der Traffic läuft.

Systemanforderungen

  • Mindestens 2 GB Arbeitsspeicher und 10 GB freier Speicherplatz für Docker und Images.
  • Administratorrechte: Unter Linux Zugriff auf sudo, unter Windows und macOS ein Administratorkonto für die Installation von Docker Desktop.
  • Stabile Internetverbindung zum Herunterladen von Images.

Backups

Im Prozess bearbeiten wir die Docker-Konfigurationsdateien. Ein Fehler darin kann dazu führen, dass Docker nicht mehr startet. Erstelle daher vor jeder Änderung einer Datei eine Kopie. Unter Linux reicht ein Befehl:

sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak

Analog für die Datei ~/.docker/config.json. Falls die Datei noch nicht existiert, musst du kein Backup erstellen, aber notiere dir, dass du sie von Grund auf neu erstellt hast: Dann reicht zum Zurücksetzen einfach das Löschen.

Tipp: Lege eine Textdatei mit einer Vorlage deiner Proxy-Daten im Format protocol://login:password@host:port an. Du wirst diese Zeile oft einfügen, und eine fertige Vorlage erspart dir Tippfehler.

Grundbegriffe: Wie Docker aufgebaut ist und wo darin der Proxy lebt

Damit die Proxy-Einrichtung in Docker nicht zur Magie wird, klären wir die Begriffe. Wenn du bereits sicher mit Containern arbeitest, überfliege den Abschnitt schnell, aber achte auf den Unterabschnitt zu den drei Proxy-Ebenen: Dort stecken die meisten Fehler.

Wichtige Begriffe einfach erklärt

  • Image (Abbild) — eine Vorlage, ein „eingefrorenes“ Set aus Dateien und Programmen. Zum Beispiel ein Image mit Python oder ein Image mit einem Browser.
  • Container — eine gestartete Kopie eines Images. Aus einem Image kannst du beliebig viele Container starten, und jeder ist von den anderen isoliert.
  • Docker-Daemon (daemon, dockerd) — der Hintergrunddienst, der Container erstellt, Images herunterlädt und Netzwerke verwaltet. Genau der Daemon geht online, um Images zu holen, wenn du docker pull eingibst.
  • Docker-Client (docker CLI) — der Befehl docker im Terminal. Er sendet deine Anweisungen an den Daemon.
  • Umgebungsvariablen (environment variables) — benannte Werte, die Programmen innerhalb des Containers zur Verfügung stehen. Zum Beispiel HTTP_PROXY=http://user:pass@host:port. Viele Programme lesen solche Variablen automatisch und gehen dann über den angegebenen Proxy.
  • Docker-Netzwerk (network) — ein virtuelles Netzwerk, das Container verbindet. Container im selben benutzerdefinierten Netzwerk sehen sich gegenseitig über ihre Namen.
  • Docker Compose — ein Tool, das mehrere Container, ihre Variablen und Netzwerke in einer YAML-Datei beschreibt und sie mit einem Befehl startet.

Die drei Proxy-Ebenen in Docker

Das ist der wichtigste Teil der Theorie. Wenn von „Proxy in Docker“ die Rede ist, können drei völlig verschiedene Dinge gemeint sein, die unterschiedlich eingerichtet werden.

  1. Proxy für den Daemon. Wird benötigt, damit Docker selbst Images über den Proxy herunterlädt. Das betrifft die Befehle docker pull und docker build, wenn sie Basis-Images ziehen. Auf den Traffic deiner Anwendungen in den Containern hat diese Ebene keinen Einfluss.
  2. Proxy für Container über Umgebungsvariablen. In den Container werden HTTP_PROXY, HTTPS_PROXY und NO_PROXY übergeben, und die Anwendung entscheidet selbst, ob sie diese nutzt oder nicht. Das ist die beliebteste und einfachste Methode, funktioniert aber nur mit Programmen, die diese Variablen beachten.
  3. Proxy auf Netzwerkebene. Der Traffic des Containers wird über einen anderen Gateway-Container oder über ein speziell konfiguriertes Netzwerk geleitet. Die Anwendung darin weiß möglicherweise gar nichts vom Proxy. Das ist zuverlässiger, erfordert aber mehr Konfiguration.

Was du vor dem Start verstehen solltest

Umgebungsvariablen mit Proxy sind nur eine Empfehlung für das Programm. Das Tool curl, der Paketmanager pip, die Bibliothek requests in Python, Node.js mit dem Paket global-agent, wget, apt — sie alle lesen HTTP_PROXY. Headless-Browser, einige Go-Anwendungen und viele Binär-Tools können die Variablen jedoch ignorieren. Überprüfe daher nach der Einrichtung immer die tatsächliche externe IP und verlass dich nicht darauf, dass die Variable gesetzt ist.

Ein weiterer Punkt ist die Groß-/Kleinschreibung. Historisch bedingt lesen manche Programme http_proxy in Kleinbuchstaben, andere HTTP_PROXY in Großbuchstaben. Die zuverlässige Praxis ist, beide Varianten gleichzeitig zu setzen. Die Variable NO_PROXY listet Adressen auf, für die kein Proxy verwendet werden soll: localhost, 127.0.0.1, interne Domains, Namen benachbarter Container.

Und schließlich das Format der Proxy-Adresse. Für einen HTTP-Proxy sieht die Zeile so aus: http://login:password@host:port. Für SOCKS5 — socks5://login:password@host:port oder socks5h://login:password@host:port. Das h am Ende bedeutet, dass auch DNS-Anfragen über den Proxy gehen, was bei mobilen Proxys normalerweise vorzuziehen ist: So sieht die Zielwebsite nicht den DNS-Resolver deines Anbieters.

Schritt 1: Docker prüfen und Proxy-Daten vorbereiten

Ziel dieser Etappe: sicherstellen, dass Docker läuft und deine Proxy-Daten korrekt und von diesem Computer aus erreichbar sind. Ohne diese Prüfung riskierst du, eine halbe Stunde nach einem Konfigurationsfehler zu suchen, obwohl das Problem ein Tippfehler im Passwort war.

Docker prüfen

  1. Öffne das Terminal.
  2. Gib den Befehl docker --version ein und drücke Enter. Du solltest eine Zeile wie Docker version 27.x.x sehen. Wenn das Terminal meldet, der Befehl sei nicht gefunden, ist Docker nicht installiert: Installiere Docker Desktop (Windows, macOS) oder Docker Engine (Linux) nach der offiziellen Dokumentation und komm hierher zurück.
  3. Gib docker compose version ein. Erwartete Ausgabe: Docker Compose version v2.x.x.
  4. Gib docker run --rm hello-world ein. Docker lädt ein winziges Test-Image herunter und gibt eine Begrüßung mit den Worten Hello from Docker aus. Das bedeutet, dass der Daemon läuft und du Rechte zum Starten von Containern hast.

Tipp: Wenn unter Linux der Befehl docker sudo erfordert, füge dich zur Gruppe docker hinzu: sudo usermod -aG docker $USER, dann melde dich ab und wieder an. Danach funktionieren alle Befehle in diesem Guide ohne sudo.

Proxy vom Host aus prüfen

Bevor wir den Proxy in den Container bringen, prüfen wir, ob er überhaupt antwortet. Setze deine Daten anstelle des Beispiels ein. In den Beispielen verwenden wir die Adresse 185.10.10.10, Port 1050 für HTTP und 1051 für SOCKS5, den Login user123 und das Passwort secret. Bei dir werden es natürlich eigene Werte sein.

  1. Ermittle zuerst deine normale IP ohne Proxy: curl -s ifconfig.me. Notiere oder merke dir das Ergebnis.
  2. Jetzt die Anfrage über den HTTP-Proxy: curl -s -x http://user123:secret@185.10.10.10:1050 ifconfig.me
  3. Falls du SOCKS5 hast: curl -s -x socks5h://user123:secret@185.10.10.10:1051 ifconfig.me
  4. Vergleiche das Ergebnis mit Schritt 1. Die IP sollte sich unterscheiden und zu einem Mobilfunkbetreiber gehören.

Sonderzeichen im Passwort

Wenn Login oder Passwort die Zeichen @, :, /, #, ? oder ein Leerzeichen enthalten, müssen sie URL-kodiert werden, sonst bricht die Proxy-Zeile. Das Zeichen @ wird zu %40, : zu %3A, / zu %2F, # zu %23, ? zu %3F, ein Leerzeichen zu %20. Zum Beispiel wird das Passwort pa@ss in der Proxy-Zeile als pa%40ss geschrieben.

✅ Prüfung: Der curl-Befehl über den Proxy hat eine IP zurückgegeben, die von deiner Heim-IP abweicht, und die Antwort kam in ein bis drei Sekunden. Bei einem Fehler 407 prüfe Login und Passwort. Bei Connection refused oder Timeout — prüfe Host, Port und ob deine aktuelle IP in der Whitelist im Kundenbereich des Anbieters eingetragen ist (bei manchen Tarifen ist die IP-Autorisierung standardmäßig aktiviert).

Schritt 2: Proxy für einen einzelnen Container über Umgebungsvariablen einrichten

Ziel dieser Etappe: einen Container starten, dessen gesamter HTTP-Traffic über einen mobilen Proxy läuft, und dies anhand der externen IP überprüfen. Das ist das Basisszenario, mit dem alle beginnen sollten: Es berührt keine Systemeinstellungen und lässt sich leicht rückgängig machen.

Start mit dem Flag -e

Das Flag -e (oder --env) des Befehls docker run übergibt eine Umgebungsvariable in den Container. Wir übergeben gleich vier Variablen: Proxy für HTTP, für HTTPS und Ausnahmen, jede in zwei Schreibweisen.

  1. Kopiere den Befehl unten in einen Editor und ersetze die Proxy-Daten durch deine eigenen.
  2. Führe den Befehl im Terminal aus. Er startet einen temporären Container mit curl, der eine Anfrage stellt und sich beendet.
docker run --rm -e HTTP_PROXY=http://user123:secret@185.10.10.10:1050 -e HTTPS_PROXY=http://user123:secret@185.10.10.10:1050 -e http_proxy=http://user123:secret@185.10.10.10:1050 -e https_proxy=http://user123:secret@185.10.10.10:1050 -e NO_PROXY=localhost,127.0.0.1 -e no_proxy=localhost,127.0.0.1 curlimages/curl -s ifconfig.me

Beachte: Für HTTPS_PROXY geben wir ebenfalls http:// am Anfang an. Das ist kein Fehler. So wird der Proxy festgelegt, über den HTTPS-Anfragen laufen, während die Verbindung zum Proxy-Server selbst normal ist. Das Schema https:// im Wert von HTTPS_PROXY würde bedeuten, dass man sich mit dem Proxy selbst über TLS verbinden muss, was die meisten Anbieter nicht unterstützen.

Datei mit Variablen statt langem Befehl

Der Befehl ist recht sperrig geworden. Docker kann Variablen über das Flag --env-file aus einer Datei lesen. Das ist bequemer und sicherer: Das Passwort bleibt nicht in der Terminal-Historie.

  1. Erstelle die Datei proxy.env im Arbeitsordner: nano proxy.env
  2. Schreibe die Zeilen hinein, eine Variable pro Zeile, ohne Anführungszeichen und ohne Leerzeichen um das Gleichheitszeichen:
HTTP_PROXY=http://user123:secret@185.10.10.10:1050 HTTPS_PROXY=http://user123:secret@185.10.10.10:1050 http_proxy=http://user123:secret@185.10.10.10:1050 https_proxy=http://user123:secret@185.10.10.10:1050 NO_PROXY=localhost,127.0.0.1 no_proxy=localhost,127.0.0.1

In der echten Datei muss jede Variable in einer eigenen Zeile stehen. Speichere die Datei (in nano mit Ctrl+O, Enter, dann Ctrl+X) und starte den Container:

docker run --rm --env-file proxy.env curlimages/curl -s ifconfig.me

Prüfung von innen aus einem laufenden Container

Oft muss man sehen, was ein langlebiger Container sieht. Starten wir Alpine Linux im interaktiven Modus und prüfen die Variablen.

  1. Führe docker run -it --rm --env-file proxy.env alpine sh aus. Du bist nun im Container, die Eingabeaufforderung wechselt zu einer Raute oder einem Dollarzeichen.
  2. Gib env | grep -i proxy ein. Du siehst die Liste deiner Variablen.
  3. Gib apk add --no-cache curl ein. Der Paketmanager apk greift selbst auf https_proxy zu und lädt das Paket über den Proxy herunter.
  4. Gib curl -s ifconfig.me ein und überzeuge dich, dass die IP mobil ist.
  5. Tippe exit, um zu beenden. Der Container wird dank des Flags --rm automatisch gelöscht.

Tipp: Zur IP-Prüfung ist neben ifconfig.me auch ein Dienst praktisch, der JSON mit Informationen zu Land, Stadt und Anbieter ausgibt. So siehst du sofort, dass die IP zu einem Mobilfunkbetreiber in der gewünschten Region gehört und nicht einfach „eine andere“ ist.

✅ Prüfung: Beide Starts mit curl haben die IP des mobilen Proxys zurückgegeben. Der Befehl env im Container hat die Variablen HTTP_PROXY und HTTPS_PROXY mit deinen Daten gezeigt.

Mögliche Probleme in diesem Schritt

  • IP hat sich nicht geändert. Die Anwendung im Container ignoriert die Variablen. Bei curl passiert das nicht, wenn also curl die mobile IP zeigt, deine Anwendung aber nicht, wechsle zur Netzwerkmethode aus Schritt 6.
  • Fehler invalid reference format. Meist ein überflüssiges Leerzeichen oder ein Zeilenumbruch im Befehl. Setze den Befehl in eine Zeile.
  • Variablen sind nicht sichtbar. In der env-file dürfen keine Anführungszeichen um die Werte stehen: Docker übergibt sie wörtlich, und die Proxy-Adresse wird ungültig.

Schritt 3: Proxy für den Docker-Client einrichten, damit Variablen automatisch übergeben werden

Ziel dieser Etappe: erreichen, dass jeder neue Container und jeder Image-Build automatisch die Proxy-Variablen erhalten, ohne die Flags -e. Das spart Zeit, wenn du ständig verschiedene Container über denselben mobilen Proxy startest.

Wie das funktioniert

Der Docker-Client liest die Datei config.json im Ordner ~/.docker (unter Windows ist das der Ordner .docker im Benutzerprofil). Wenn darin ein Abschnitt proxies vorhanden ist, fügt der Client bei jedem docker run und docker build die angegebenen Variablen in den Container ein. Der Daemon wird dabei nicht berührt, daher geht docker pull weiterhin direkt.

Schritt-für-Schritt-Einrichtung

  1. Prüfe, ob die Datei existiert: cat ~/.docker/config.json. Wenn die Datei existiert und bereits Einstellungen enthält (zum Beispiel auths mit Anmeldedaten für eine Registry), erstelle eine Kopie: cp ~/.docker/config.json ~/.docker/config.json.bak
  2. Öffne die Datei im Editor: nano ~/.docker/config.json. Falls die Datei nicht existiert, legt der Editor sie an.
  3. Füge den Abschnitt proxies hinzu. Wenn die Datei leer war, sieht ihr gesamter Inhalt so aus:
{ "proxies": { "default": { "httpProxy": "http://user123:secret@185.10.10.10:1050", "httpsProxy": "http://user123:secret@185.10.10.10:1050", "noProxy": "localhost,127.0.0.1,*.local" } } }

Wenn die Datei bereits andere Schlüssel enthält, füge proxies als weiteren Schlüssel auf oberster Ebene mit Komma hinzu, ohne bestehende zu löschen. Achte auf die Paarigkeit von geschweiften Klammern und Anführungszeichen: JSON verzeiht kein fehlendes Komma.

  1. Speichere die Datei.
  2. Prüfe die Syntax. Unter Linux und macOS geht das so: python3 -m json.tool ~/.docker/config.json. Wenn die Ausgabe deine Datei schön formatiert wiedergibt, ist alles in Ordnung. Erscheint ein Fehler mit Zeilennummer, korrigiere ihn.
  3. Starte einen Testcontainer ohne jegliche Flags: docker run --rm curlimages/curl -s ifconfig.me. Die IP sollte mobil sein.
  4. Schau dir die Variablen eines beliebigen Containers an: docker run --rm alpine env. In der Ausgabe stehen HTTP_PROXY, HTTPS_PROXY, NO_PROXY und ihre Kleinschreibungsvarianten: Docker fügt beide Schreibweisen selbst hinzu.

⚠ Achtung: Der Abschnitt proxies in config.json wirkt auf alle Container, die du unter diesem Benutzer startest, einschließlich Datenbanken, lokaler Webserver und allem anderen. Wenn ein Dienst mit einer externen API kommuniziert, die über deinen Proxy nicht erreichbar ist, bricht er zusammen. Füge solche Adressen zu noProxy hinzu oder entferne den Abschnitt vorübergehend.

Verschiedene Proxys für verschiedene Verbindungen

Der Schlüssel default gilt für alle Verbindungen zum Daemon. Wenn du mehrere Docker-Hosts über Kontexte oder die Variable DOCKER_HOST verwaltest, kannst du statt default die Adresse eines konkreten Daemons angeben, zum Beispiel tcp://192.168.1.50:2376, und der Proxy gilt dann nur für diesen. Für die lokale Arbeit reicht default.

Proxy beim Erstellen von Images

Die Einstellungen aus config.json werden auch an docker build als Build-Argumente übergeben. Das bedeutet, dass Befehle wie RUN apt-get install oder RUN pip install im Dockerfile über den Proxy laufen. Wichtig: Diese Variablen werden nicht im fertigen Image gespeichert, was aus Sicherheitssicht gut ist: Das Proxy-Passwort gelangt nicht zu denen, denen du das Image weitergibst.

Tipp: Wenn du den Proxy nur für einen einzelnen Build übergeben möchtest, ohne config.json zu ändern, nutze die Flags docker build --build-arg HTTP_PROXY=http://user123:secret@185.10.10.10:1050 --build-arg HTTPS_PROXY=http://user123:secret@185.10.10.10:1050 . Docker versteht diese vordefinierten Argumente ohne ARG-Deklaration im Dockerfile.

✅ Prüfung: Ein ohne -e gestarteter Container geht mit der Proxy-IP online. Der Befehl docker run --rm alpine env zeigt die Proxy-Variablen.

Wie du rückgängig machst

Lösche den Abschnitt proxies aus config.json oder stelle die Datei aus der Sicherung wieder her: cp ~/.docker/config.json.bak ~/.docker/config.json. Ein Neustart ist nicht nötig, die Änderungen wirken beim nächsten Containerstart.

Schritt 4: Proxy für den Docker-Daemon einrichten, damit Images über den Proxy geladen werden

Ziel dieser Etappe: Docker selbst (den Daemon) dazu bringen, Images über den Proxy zu beziehen. Das ist nötig, wenn der direkte Zugriff auf die Image-Registry von deinem Server aus durch Unternehmensrichtlinien eingeschränkt oder langsam ist oder wenn du möchtest, dass die gesamte Netzwerkaktivität des Servers über einen Kanal läuft. Für Marketing-Aufgaben ist dieser Schritt oft nicht nötig, aber du solltest ihn kennen: Fehler auf Daemon-Ebene werden regelmäßig mit Fehlern auf Container-Ebene verwechselt.

Methode 1: Datei daemon.json (Linux, Docker 23 und neuer)

  1. Erstelle eine Kopie: sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak (falls die Datei nicht existiert, meldet der Befehl einen Fehler, das ist normal).
  2. Öffne die Datei: sudo nano /etc/docker/daemon.json
  3. Füge den Abschnitt proxies hinzu:
{ "proxies": { "http-proxy": "http://user123:secret@185.10.10.10:1050", "https-proxy": "http://user123:secret@185.10.10.10:1050", "no-proxy": "localhost,127.0.0.1" } }

Beachte, dass die Schlüssel hier mit Bindestrich und in Kleinbuchstaben geschrieben werden: Das unterscheidet sich von config.json des Clients, wo die Schlüssel im Stil httpProxy sind. Sie zu verwechseln ist ein klassischer Fehler.

  1. Speichere die Datei und starte den Daemon neu: sudo systemctl restart docker
  2. Prüfe, dass der Daemon hochgefahren ist: sudo systemctl status docker. In der Ausgabe muss active (running) stehen.
  3. Prüfe die Anwendung: docker info | grep -i proxy. Du siehst die Zeilen HTTP Proxy und HTTPS Proxy mit deiner Adresse, wobei das Passwort in der Ausgabe mit Sternchen verdeckt wird.

Methode 2: Systemd-Drop-in-Datei (Linux, jede Version)

Das ist die klassische Methode, die auch bei älteren Docker-Versionen funktioniert.

  1. Erstelle den Ordner: sudo mkdir -p /etc/systemd/system/docker.service.d
  2. Erstelle die Datei: sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf
  3. Schreibe den Inhalt hinein, jede Direktive in einer eigenen Zeile:
[Service] Environment="HTTP_PROXY=http://user123:secret@185.10.10.10:1050" Environment="HTTPS_PROXY=http://user123:secret@185.10.10.10:1050" Environment="NO_PROXY=localhost,127.0.0.1"
  1. Speichere und lies dann die systemd-Konfiguration neu ein: sudo systemctl daemon-reload
  2. Starte Docker neu: sudo systemctl restart docker
  3. Prüfe: sudo systemctl show --property=Environment docker. In der Ausgabe stehen deine Variablen.

⚠ Achtung: Konfiguriere den Daemon-Proxy nicht gleichzeitig auf zwei Wegen. Wenn sowohl daemon.json als auch die systemd-Datei unterschiedliche Adressen enthalten, wird das Verhalten unvorhersehbar und die Fehlersuche mühsam. Wähle eine Methode und bleib dabei.

Methode 3: Docker Desktop (Windows und macOS)

  1. Öffne Docker Desktop und klicke auf das Zahnrad-Symbol oben rechts.
  2. Wähle im linken Menü Resources, dann Proxies.
  3. Schalte den Schalter Manual proxy configuration ein.
  4. In die Felder Web Server (HTTP) und Secure Web Server (HTTPS) füge die Proxy-Adresse im Format http://user123:secret@185.10.10.10:1050 ein.
  5. In das Feld Bypass proxy settings for these hosts schreibe localhost,127.0.0.1.
  6. Klicke auf Apply and restart. Docker Desktop startet neu, das dauert 30–60 Sekunden.

Docker Desktop wendet diese Einstellungen gleichzeitig auf den Daemon und die Container an, daher ist eine separate Bearbeitung von config.json auf Desktop-Systemen oft nicht nötig.

Ergebnis prüfen

  1. Lösche ein kleines Image, falls vorhanden: docker rmi alpine
  2. Lade es erneut herunter: docker pull alpine. Der Download sollte erfolgreich durchlaufen.
  3. Wenn auf der Proxy-Seite Traffic-Statistiken verfügbar sind (im Kundenbereich von mobileproxy.space gibt es sie), siehst du, dass der verbrauchte Traffic um einige Megabyte gestiegen ist.

✅ Prüfung: docker info zeigt die Proxy-Adresse, docker pull lädt Images ohne Fehler, der Dienst docker befindet sich im Zustand active.

Mögliche Probleme

  • Docker startet nach der Bearbeitung von daemon.json nicht. Fast immer ist die JSON-Syntax schuld. Prüfe die Datei mit python3 -m json.tool /etc/docker/daemon.json oder stelle die Kopie wieder her.
  • docker pull hängt. Der Proxy lässt keine Verbindungen zur Registry durch oder das Traffic-Limit des Tarifs ist erreicht. Prüfe den Proxy vom Host aus mit curl, wie in Schritt 1.
  • Fehler x509 certificate. Der Proxy ersetzt Zertifikate (relevant für Unternehmens-Proxys, bei mobilen Proxys selten). Frage beim Anbieter nach.

Schritt 5: Proxy in Docker Compose einrichten

Ziel dieser Etappe: den Proxy in der Datei compose.yaml so beschreiben, dass eine Gruppe von Containern mit einem Befehl und den nötigen Einstellungen gestartet wird und verschiedene Dienste verschiedene mobile Proxys nutzen können. Genau dieses Szenario brauchen Media-Buyer und Marketer am häufigsten: Ein Parser arbeitet über einen Proxy in Moskau, der zweite über einen in Kasan, und die Datenbank läuft ganz ohne Proxy.

Projekt vorbereiten

  1. Erstelle einen Projektordner und wechsle hinein: mkdir proxy-demo, dann cd proxy-demo
  2. Erstelle die Datei .env (genau mit Punkt am Anfang) zur Speicherung der Geheimnisse: nano .env
  3. Schreibe die Variablen hinein, eine pro Zeile:
PROXY_MSK=http://user123:secret@185.10.10.10:1050 PROXY_KZN=http://user456:secret2@185.10.10.20:1050

Die Datei .env liest Compose automatisch, und ihre Werte kannst du in compose.yaml über die Syntax ${NAME} einsetzen. Füge .env zu .gitignore hinzu, wenn das Projekt unter Versionskontrolle steht: Passwörter dürfen nicht ins Repository gelangen.

Die Datei compose.yaml

Erstelle die Datei compose.yaml (nano compose.yaml) und beschreibe drei Dienste. In YAML sind die Einrückungen wichtig: Nutze zwei Leerzeichen pro Ebene, keine Tabulatoren.

services: parser-msk: image: curlimages/curl command: -s ifconfig.me environment: HTTP_PROXY: ${PROXY_MSK} HTTPS_PROXY: ${PROXY_MSK} http_proxy: ${PROXY_MSK} https_proxy: ${PROXY_MSK} NO_PROXY: localhost,127.0.0.1,db no_proxy: localhost,127.0.0.1,db parser-kzn: image: curlimages/curl command: -s ifconfig.me environment: HTTP_PROXY: ${PROXY_KZN} HTTPS_PROXY: ${PROXY_KZN} http_proxy: ${PROXY_KZN} https_proxy: ${PROXY_KZN} NO_PROXY: localhost,127.0.0.1,db no_proxy: localhost,127.0.0.1,db db: image: postgres:16-alpine environment: POSTGRES_PASSWORD: example

Hier steht in der echten Datei jede Zeile einzeln mit den richtigen Einrückungen: services auf der nullten Ebene, Dienstnamen mit zwei Leerzeichen Einrückung, ihre Parameter mit vier, Umgebungsvariablen mit sechs. Beachte den Namen db in NO_PROXY: So greifen die Parser direkt über das interne Docker-Netzwerk auf die Datenbank zu und versuchen nicht, sie über den mobilen Proxy zu erreichen, was ohnehin nicht funktionieren würde.

Starten und prüfen

  1. Prüfe, wie Compose die Variablen eingesetzt hat: docker compose config. Der Befehl gibt die endgültige Datei mit aufgelösten Werten aus. Stelle sicher, dass statt ${PROXY_MSK} eine echte Adresse steht.
  2. Starte: docker compose up. Compose lädt die Images und startet alle drei Dienste, wobei die Logs im Terminal ausgegeben werden.
  3. In den Logs siehst du Zeilen wie parser-msk-1 | 91.xxx.xxx.xxx und parser-kzn-1 | 176.xxx.xxx.xxx: zwei verschiedene IPs von zwei verschiedenen Proxys. Postgres startet und wartet auf Verbindungen.
  4. Stoppe alles mit Ctrl+C und entferne dann die Container: docker compose down

Alternative: env_file pro Dienst

Wenn es viele Variablen gibt, ist statt des Blocks environment eine Datei praktischer:

services: parser-msk: image: curlimages/curl command: -s ifconfig.me env_file: - proxy-msk.env

Die Datei proxy-msk.env enthält dabei dieselben sechs Zeilen wie proxy.env aus Schritt 2. So liegt jeder Proxy in einer eigenen Datei, und du kannst sie ersetzen, ohne compose.yaml zu öffnen.

Proxy beim Build in Compose

Wenn ein Dienst aus einem Dockerfile gebaut und nicht als fertiges Image bezogen wird, übergib den Proxy über build.args:

services: app: build: context: . args: HTTP_PROXY: ${PROXY_MSK} HTTPS_PROXY: ${PROXY_MSK}

So arbeiten pip, npm oder apt im Dockerfile über den Proxy, und die Werte landen nicht im fertigen Image.

Tipp: Compose unterstützt mehrere Dateien. Halte eine Basis-compose.yaml ohne Proxy und beschreibe in compose.proxy.yaml nur die environment-Blöcke. Starte mit docker compose -f compose.yaml -f compose.proxy.yaml up, wenn ein Proxy nötig ist, und einfach mit docker compose up, wenn nicht. Das ist praktisch beim Debuggen: Du wechselst in einer Sekunde zwischen den Modi.

✅ Prüfung: docker compose config zeigt die eingesetzten Proxy-Adressen, und in den Logs von docker compose up geben die Dienste mit verschiedenen Proxys verschiedene IPs aus.

Schritt 6: Proxy auf Netzwerkebene über einen Gateway-Container einrichten

Ziel dieser Etappe: einen separaten Container hochfahren, der Verbindungen von Nachbarn im Docker-Netzwerk annimmt und an den mobilen Proxy weiterleitet. Die übrigen Container sprechen das Gateway über den Namen an und speichern Login und Passwort nicht selbst. Das löst drei Aufgaben auf einmal: Es zentralisiert die Proxy-Verwaltung, entfernt Passwörter aus Dutzenden von Konfigurationen und ermöglicht den Wechsel des Proxys, ohne Arbeitscontainer neu zu starten.

Warum ein Gateway nötig ist, wenn es Variablen gibt

Stell dir vor, du hast zwanzig Container mit Parsern und der Anbieter gibt einen neuen Port heraus. Mit Umgebungsvariablen musst du zwanzig Konfigurationen bearbeiten und alles neu starten. Mit dem Gateway änderst du eine Zeile an einer Stelle. Außerdem unterstützen manche Anwendungen keine Proxy-Autorisierung per Login und Passwort, funktionieren aber bestens mit einem Proxy ohne Autorisierung. Das Gateway im geschlossenen Docker-Netzwerk benötigt keine Autorisierung und verbindet sich selbst mit dem mobilen Proxy bereits mit deinen Daten.

Netzwerk anlegen

  1. Erstelle ein benutzerdefiniertes Netzwerk: docker network create proxynet
  2. Prüfe, dass es erschienen ist: docker network ls. In der Liste steht proxynet mit dem Treiber bridge.

Ein benutzerdefiniertes Netzwerk ist nötig, weil nur dort die Namensauflösung funktioniert: Der Container kann das Gateway über den Namen gateway ansprechen und nicht über die IP, die sich bei jedem Neustart ändert.

Gateway starten

Als Gateway nutzen wir gost — einen kompakten Proxy-Server, der Verbindungen auf einem Protokoll annehmen und mit Autorisierung auf ein anderes weiterleiten kann. Das Image ist in der öffentlichen Registry unter dem Namen gogost/gost verfügbar.

  1. Starte den Gateway-Container:
docker run -d --name gateway --network proxynet --restart unless-stopped gogost/gost -L=http://:8118 -F=http://user123:secret@185.10.10.10:1050

Erläutern wir die Parameter. Das Flag -d startet den Container im Hintergrund. Das Flag --name gateway legt den Namen fest, über den Nachbarn ihn ansprechen. Das Flag --network proxynet verbindet ihn mit unserem Netzwerk. Das Flag --restart unless-stopped hebt das Gateway nach einem Serverneustart wieder hoch. Der Parameter -L=http://:8118 weist gost an, HTTP-Proxy-Verbindungen auf Port 8118 ohne Autorisierung anzunehmen. Der Parameter -F gibt an, wohin weitergeleitet wird: an deinen mobilen Proxy mit Login und Passwort.

  1. Prüfe, dass das Gateway läuft: docker logs gateway. Im Log sollte eine Zeile stehen, dass der Server auf Port 8118 lauscht, ohne Fehler.

⚠ Achtung: Veröffentliche den Gateway-Port nicht mit dem Flag -p nach außen, wenn es dafür keinen zwingenden Grund gibt. Das Gateway arbeitet ohne Autorisierung, und ein offener Port 8118 auf einem öffentlichen Server bedeutet, dass jeder im Internet deinen mobilen Proxy nutzen und deinen Traffic verbrauchen kann. Innerhalb des Netzwerks proxynet ist er nur für deine Container erreichbar, und das reicht.

Arbeitscontainer anbinden

  1. Starte einen Testcontainer im selben Netzwerk und gib das Gateway als Proxy an:
docker run --rm --network proxynet -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 curlimages/curl -s ifconfig.me
  1. Du solltest die IP des mobilen Proxys sehen. Beachte: In den Variablen steht weder Login noch Passwort noch die echte Proxy-Adresse. All das kennt nur das Gateway.

Dasselbe in Compose

Für den Dauerbetrieb beschreibe das Gateway und die Arbeitsdienste in einer compose.yaml:

services: gateway: image: gogost/gost command: -L=http://:8118 -F=${PROXY_MSK} restart: unless-stopped networks: - proxynet worker: image: curlimages/curl command: -s ifconfig.me environment: HTTP_PROXY: http://gateway:8118 HTTPS_PROXY: http://gateway:8118 NO_PROXY: localhost,127.0.0.1 depends_on: - gateway networks: - proxynet networks: proxynet: driver: bridge

Die Direktive depends_on stellt sicher, dass das Gateway vor dem Worker startet. Der Wert PROXY_MSK stammt aus der Datei .env, wie in Schritt 5.

Mehrere Gateways für mehrere Geos

Du möchtest verschiedene Proxys für verschiedene Containergruppen? Starte mehrere Gateways: gateway-msk, gateway-kzn, gateway-spb, jedes mit eigenem -F. Die Arbeitscontainer geben einfach den gewünschten Namen in HTTP_PROXY an. Du kannst sogar weiter gehen und ein separates Netzwerk pro Geo anlegen, dann können Container aus der Moskau-Gruppe physisch nicht versehentlich ins Kasan-Gateway gelangen.

Isolation: Container ohne direkten Internetzugang

Die strengste Variante ist, dem Arbeitscontainer jeden Internetzugang außer über das Gateway zu verbieten. Erstelle dafür ein internes Netzwerk mit dem Flag --internal: docker network create --internal isolated. Container in einem solchen Netzwerk haben keine Route nach außen. Verbinde das Gateway gleichzeitig mit zwei Netzwerken (isolated und dem normalen proxynet), die Worker aber nur mit isolated. Selbst wenn die Anwendung die Proxy-Variablen ignoriert, kann sie nun nicht direkt ins Internet und es kommt zu keinem Leck der echten IP.

  1. docker network create --internal isolated
  2. docker network connect isolated gateway
  3. docker run --rm --network isolated -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 curlimages/curl -s ifconfig.me
  4. Starte zur Kontrolle denselben Container ohne Proxy-Variablen: docker run --rm --network isolated curlimages/curl -s -m 5 ifconfig.me. Die Anfrage sollte in einen Timeout laufen: Es gibt keinen direkten Ausgang.

Tipp: Die Kombination aus internem Netzwerk und Gateway ist die beste Absicherung gegen Lecks bei Multi-Account-Arbeit. Selbst wenn ein Entwickler vergessen hat, den Proxy im neuen Dienst einzutragen, kann dieser die Server-IP nicht verraten: Er geht entweder über das Gateway oder gar nicht.

✅ Prüfung: Ein Container im Netzwerk proxynet mit der Variable HTTP_PROXY=http://gateway:8118 zeigt die IP des mobilen Proxys. Ein Container im internen Netzwerk ohne Proxy kann überhaupt nicht ins Internet.

Mögliche Probleme

  • Could not resolve host: gateway. Der Arbeitscontainer ist nicht im richtigen Netzwerk oder läuft im Standardnetzwerk, in dem Namen nicht aufgelöst werden. Prüfe das Flag --network.
  • Das Gateway startet neu. Fehler in der Zeile -F: Tippfehler im Passwort oder falscher Port. Schau in docker logs gateway.
  • Langsam. Mobile Proxys sind von Natur aus langsamer als Rechenzentrums-Proxys, aber wenn die Verzögerung zig Sekunden beträgt, prüfe, ob DNS daran vorbeiläuft: Verwende socks5h statt socks5 in der -F-Zeile, wenn der Anbieter SOCKS5 bereitstellt.

Ergebnis prüfen: Checkliste für einen funktionierenden Proxy in Docker

Geh die Liste durch. Wenn jeder Punkt abgehakt ist, hast du die Proxy-Einrichtung in Docker vollständig in der Praxis gemeistert.

Checkliste

  • curl vom Host über den Proxy gibt eine mobile IP zurück.
  • Ein Container mit dem Flag --env-file proxy.env gibt eine mobile IP zurück.
  • Ein Container ohne Flags gibt nach der Einrichtung von config.json eine mobile IP zurück (falls du Schritt 3 gemacht hast).
  • docker info zeigt die Proxy-Adresse, und docker pull funktioniert (falls du Schritt 4 gemacht hast).
  • docker compose up startet die Dienste, und in den Logs sind unterschiedliche IPs für verschiedene Proxys sichtbar.
  • Der Gateway-Container läuft, und die Nachbarn gehen ohne Login und Passwort über ihn.
  • Ein Container im internen Netzwerk ohne Proxy kann nicht ins Internet.

Wie du alles komplett testest

  1. Starte einen langlebigen Container: docker run -d --name test --network proxynet -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 alpine sleep 3600
  2. Geh hinein: docker exec -it test sh
  3. Installiere curl: apk add --no-cache curl. Die Installation sollte über den Proxy laufen.
  4. Stelle fünf Anfragen hintereinander: for i in 1 2 3 4 5; do curl -s ifconfig.me; echo; done. Alle fünf sollten die mobile IP zurückgeben. Wenn dein Proxy automatische Rotation aktiviert hat, können sich die IPs zwischen den Anfragen unterscheiden, das ist normal.
  5. Beende (exit) und entferne den Container: docker rm -f test

Erfolgsindikatoren

Eine erfolgreiche Einrichtung bedeutet, dass du in Sekundenschnelle drei Fragen beantworten kannst: Über welche IP geht ein bestimmter Container online, wo liegt das Proxy-Passwort und was muss geändert werden, um einen Container auf einen anderen Proxy umzustellen. Wenn die Antwort auf jede Frage offensichtlich ist, hast du das Ziel erreicht.

Typische Fehler bei der Proxy-Einrichtung in Docker und ihre Lösungen

Fehler 1: Die IP ändert sich nicht, obwohl die Variablen gesetzt sind

Ursache: Die Anwendung im Container liest die Proxy-Umgebungsvariablen nicht. Das ist typisch für Headless-Browser, manche Go-Programme und Tools, die eigene Netzwerk-Stacks verwenden.

Lösung: Prüfe die Dokumentation der Anwendung auf ein eigenes Proxy-Flag (bei Browsern ist das meist --proxy-server). Gibt es kein Flag, nutze das Gateway und das interne Netzwerk aus Schritt 6 oder die transparente Weiterleitung aus dem Abschnitt für Fortgeschrittene.

Fehler 2: 407 Proxy Authentication Required

Ursache: Falscher Login oder falsches Passwort, oder Sonderzeichen darin sind nicht kodiert, oder der Proxy nutzt IP-Autorisierung und die Server-IP steht nicht in der Whitelist.

Lösung: Prüfe die Daten vom Host über curl. Kodiere die Sonderzeichen. Füge die Server-IP in die Whitelist im Kundenbereich ein oder stelle den Proxy auf Autorisierung per Login und Passwort um.

Fehler 3: Docker startet nach der Bearbeitung von daemon.json nicht

Ursache: Ein Syntaxfehler im JSON: ein überflüssiges Komma, ein fehlendes Anführungszeichen, Schlüssel im config.json-Stil statt im daemon.json-Stil.

Lösung: Schau ins Journal: sudo journalctl -u docker -n 50. Dort steht die Zeile mit dem Fehler. Korrigiere sie oder stelle die Sicherung wieder her und starte den Dienst neu.

Fehler 4: Container sehen sich gegenseitig nicht mehr

Ursache: Nach der globalen Proxy-Einrichtung in config.json liefen auch Anfragen an benachbarte Container über den mobilen Proxy, der nicht weiß, was db oder redis ist.

Lösung: Füge Dienstnamen und interne Subnetze zu NO_PROXY hinzu: localhost,127.0.0.1,db,redis,172.16.0.0/12. Beachte, dass Subnetzmasken nicht von allen Programmen verstanden werden, daher ist es zuverlässiger, die Namen ausdrücklich aufzulisten.

Fehler 5: docker build scheitert an apt-get oder pip

Ursache: Der Build läuft ohne Proxy, weil die Variablen für Container gesetzt sind, nicht für den Build, oder der Daemon-Proxy eingerichtet ist, aber die RUN-Schritte nicht beeinflusst.

Lösung: Übergib --build-arg HTTP_PROXY und HTTPS_PROXY oder richte den Abschnitt proxies in der config.json des Clients ein: Er gilt auch für den Build.

Fehler 6: Das Proxy-Passwort ist in docker inspect und Logs sichtbar

Ursache: Umgebungsvariablen werden in den Metadaten des Containers im Klartext gespeichert, und jeder mit Docker-Zugriff sieht sie über docker inspect.

Lösung: Nutze das Gateway: Die Arbeitscontainer kennen nur die Adresse gateway:8118. Das Passwort bleibt in einem Container und in der Datei .env mit eingeschränkten Rechten (chmod 600 .env).

Fehler 7: Nach dem Serverneustart funktioniert der Proxy nicht mehr

Ursache: Der Gateway-Container wurde nicht mit einer Neustart-Richtlinie gestartet, oder die IP-Adresse des Hosts beim mobilen Proxy hat sich geändert.

Lösung: Füge dem Gateway --restart unless-stopped hinzu. Verwende den Domainnamen des Proxys statt der IP, wenn der Anbieter einen bereitstellt. Prüfe docker ps -a: Wenn das Gateway im Status Exited steht, schau in seine Logs.

Fehler 8: HTTPS-Seiten öffnen sich nicht, HTTP funktioniert aber

Ursache: Es ist nur HTTP_PROXY gesetzt, HTTPS_PROXY aber leer, oder in HTTPS_PROXY steht das Schema https:// statt http://.

Lösung: Setze immer beide Variablen mit demselben Wert und dem Schema http://.

Zusätzliche Möglichkeiten für Fortgeschrittene: transparente Weiterleitung, IP-Rotation und Sicherheit

Dieser Abschnitt ist für diejenigen, die die Grundschritte gemeistert haben und das Maximum aus der Kombination von Docker und mobilen Proxys herausholen möchten. Hier gibt es weniger Schritt-für-Schritt-Listen und mehr Ideen mit den wichtigsten Befehlen.

Transparente Weiterleitung: wenn die Anwendung gar nichts vom Proxy weiß

Wenn du eine Anwendung hast, die überhaupt nicht mit Proxys umgehen kann, kannst du ihren gesamten TCP-Traffic auf Ebene des Netzwerk-Stacks umleiten. Die Idee: Der Arbeitscontainer wird mit dem Parameter network_mode: service:gateway (in Compose) oder --network container:gateway (bei docker run) gestartet. So nutzt er den Netzwerk-Stack des Gateway-Containers vollständig: dieselbe IP, dieselben Schnittstellen, dieselben Routing-Regeln.

Im Gateway läuft dabei ein Programm wie redsocks, das auf einem lokalen Port lauscht und Verbindungen an einen SOCKS5-Proxy weiterleitet, während iptables-Regeln den gesamten ausgehenden TCP-Traffic auf diesen Port umleiten. Das Gateway braucht dafür Rechte: cap_add: NET_ADMIN. Die Anwendung im Arbeitscontainer stellt eine normale Anfrage an die Website, der Kernel fängt sie ab und leitet sie an redsocks, und der wiederum an den mobilen Proxy. Keine Umgebungsvariablen nötig. Die Einrichtung erfordert Sorgfalt: Eine falsche iptables-Regel kann den Traffic in einer Schleife drehen, teste daher auf einer separaten Maschine. Beachte außerdem, dass der Arbeitscontainer bei network_mode: service seine eigenen Ports und Verbindungen zu anderen Netzwerken verliert; all das muss am Gateway beschrieben werden.

IP-Rotation aus dem Container

Mobile Proxys haben eine Besonderheit, wegen der sie überhaupt genutzt werden: Die IP lässt sich auf Anfrage wechseln. Anbieter stellen einen speziellen Rotations-Link bereit, den man nur öffnen muss, damit das Modem sich neu verbindet. Aus dem Container heraus geschieht das mit demselben curl. Ein nützliches Muster: ein kleiner eigener Dienst in Compose, der den Rotations-Link nach Zeitplan aufruft. Er darf nicht über den Proxy gehen (sonst verliert er nach dem IP-Wechsel selbst die Verbindung), also starte ihn ohne Proxy-Variablen oder explizit mit leeren HTTP_PROXY. Beachte, dass nach dem IP-Wechsel aktive Verbindungen der Arbeitscontainer abbrechen: Baue in die Parser Wiederholungsversuche ein.

Gateway-Gesundheit: healthcheck

Füge in Compose eine Prüfung hinzu, dass das Gateway tatsächlich weiterleitet und nicht nur läuft:

healthcheck: test: ["CMD", "gost", "-V"] interval: 30s timeout: 10s retries: 3

Das ist eine minimale Prüfung der Prozess-Lebendigkeit. Für die Prüfung des tatsächlichen Internetzugangs ist ein separater Monitor-Container besser, der einmal pro Minute eine Anfrage über das Gateway stellt und das Ergebnis in ein Log schreibt oder eine Benachrichtigung sendet. Wenn die IP plötzlich zur Server-IP wird, ist Alarm angesagt: Das Gateway ist ausgefallen und die Container gehen direkt raus. Das interne Netzwerk aus Schritt 6 schützt genau vor diesem Szenario.

Sichere Speicherung von Passwörtern

Die Datei .env ist gut für die lokale Arbeit, aber auf einem Server mit mehreren Benutzern sollte man sie schützen: chmod 600 .env, Eigentümer ist der Benutzer, von dem Compose gestartet wird. Compose unterstützt auch Geheimnisse über die Direktive secrets, die als Datei nach /run/secrets/ in den Container eingebunden werden statt als Umgebungsvariable. Gost liest das Passwort nicht direkt aus der Datei, aber du kannst ein kleines Wrapper-Skript schreiben, das die Zeile -F beim Start aus der Geheimnisdatei zusammensetzt. So landet das Passwort weder in docker inspect noch in der Ausgabe von docker compose config.

Mehrere Projekte und eine Proxy-Infrastruktur

Wenn du mehrere Compose-Projekte hast und die Proxys gemeinsam genutzt werden, lagere die Gateways in ein separates Projekt mit externem Netzwerk aus: Deklariere darin networks mit dem Parameter name: proxynet, und in den übrigen Projekten verbinde dich damit als external: true. Dann leben die Gateways unabhängig, und die Arbeitsprojekte kannst du beliebig oft neu starten, ohne die Proxys anzurühren.

Traffic begrenzen

Mobiler Traffic wird üblicherweise abgerechnet, und ein außer Kontrolle geratener Parser kann über Nacht Dutzende Gigabyte herunterladen. Auf Docker-Ebene gibt es keine harten Traffic-Quoten, aber indirekte Maßnahmen: Begrenzung der Anfragefrequenz in der Anwendung selbst, Begrenzung der Container-Lebensdauer über timeout im Startbefehl und Monitoring über docker stats, das NET I/O pro Container in Echtzeit anzeigt. Vergleiche diese Zahlen regelmäßig mit den Statistiken im Kundenbereich des Anbieters.

Logs ohne Geheimnisse

Viele Anwendungen geben beim Start die Umgebungsvariablen ins Log aus, einschließlich HTTP_PROXY mit Passwort. Wenn die Logs in ein zentrales System gehen, gelangt das Passwort dorthin. Das Gateway löst auch dieses Problem: In den Logs der Arbeitscontainer steht nur gateway:8118.

Tipp: Erneuere die Proxy-Passwörter einmal im Quartal und aktualisiere .env. Mit dem Gateway dauert das eine Minute: eine Zeile ändern, docker compose up -d gateway ausführen, und alle Worker arbeiten ohne Neustart weiter.

FAQ: Häufige Fragen zur Proxy-Einrichtung in Docker

Muss ich den Container neu starten, um neue Proxy-Variablen anzuwenden?

Ja. Umgebungsvariablen werden beim Erstellen des Containers festgelegt und können bei einem laufenden nicht geändert werden. Stoppe, lösche und erstelle den Container neu (in Compose ist das docker compose up -d --force-recreate dienstname). Wenn Neustarts stören, nutze das Gateway: Seine Einstellungen lassen sich unabhängig ändern.

Worin unterscheidet sich die Proxy-Einrichtung für docker pull von der für die Anwendung im Container?

Das sind zwei verschiedene Ebenen. docker pull führt der Daemon aus, und für ihn wird der Proxy in daemon.json oder über systemd festgelegt. Die Anwendung im Container ist ein eigener Prozess mit eigener Umgebung, für sie wird der Proxy über Variablen, die config.json des Clients oder das Netzwerk festgelegt. Das eine ersetzt das andere nicht.

Kann ich SOCKS5 statt eines HTTP-Proxys in den Umgebungsvariablen verwenden?

Ja, wenn die Anwendung SOCKS unterstützt. curl, Python requests (mit installiertem Paket PySocks), git unterstützen es. apt und viele andere nicht. Der universelle Ausweg ist das Gateway gost, das am Eingang HTTP annimmt und am Ausgang an SOCKS5 sendet: -L=http://:8118 -F=socks5://user:pass@host:port.

Wie prüfe ich, welchen Proxy ein bereits laufender Container nutzt?

Führe docker inspect -f '{{.Config.Env}}' containername aus. Du siehst alle Umgebungsvariablen. Für die Prüfung der tatsächlichen IP nutze docker exec containername curl -s ifconfig.me, falls curl im Container vorhanden ist, oder wget -qO- ifconfig.me.

Warum funktioniert der Proxy in Docker Desktop, aber auf einem Linux-Server funktionieren dieselben Einstellungen nicht?

Docker Desktop wendet die Einstellungen aus dem Fenster Proxies gleichzeitig auf den Daemon und die Container an. Unter Linux sind das zwei getrennte Stellen: daemon.json für den Daemon und ~/.docker/config.json für die Container. Prüfe, dass du beide eingerichtet hast, wenn du beide brauchst.

Wie lege ich den Proxy nur für eine Domain fest und lasse den Rest direkt laufen?

Umgebungsvariablen können das nicht: Sie arbeiten nach dem Prinzip „alles über den Proxy, außer NO_PROXY“. Brauchst du die umgekehrte Logik, nutze eine PAC-Datei auf Seiten der Anwendung (Browser unterstützen das) oder Routing-Regeln in gost, das Traffic nach Domains auf verschiedene ausgehende Kanäle leiten kann.

Ist es sicher, das Proxy-Passwort in compose.yaml zu speichern?

Besser nicht. Bewahre es in .env mit Rechten 600 auf und setze es über ${NAME} ein. Committe .env nicht ins Repository. Nutze für Server das Gateway, damit das Passwort an einer Stelle liegt.

Was tun, wenn der mobile Proxy die IP gewechselt hat und die Verbindungen in den Containern abgebrochen sind?

Das ist normales Verhalten bei der Rotation. Die Anwendung sollte Anfragen wiederholen können. Wenn die Rotation nach Zeitplan des Anbieters erfolgt, finde das Intervall heraus und synchronisiere schwere Operationen damit. Erfolgt die Rotation über deinen Link, rufe ihn zwischen Aufgabenpaketen auf, nicht mittendrin.

Funktionieren diese Einstellungen unter Windows ohne WSL2?

Docker Desktop unter Windows nutzt unter der Haube WSL2 oder Hyper-V, und alle Befehle docker run und docker compose funktionieren aus PowerShell gleich. Unterschiedlich sind nur die Pfade: Die Datei config.json liegt in C:\Users\Benutzername\.docker\config.json, und die Daemon-Einstellungen erfolgen über das Fenster von Docker Desktop statt manuell über daemon.json.

Wie viele Container kann ich über einen mobilen Proxy laufen lassen?

Technisch beliebig viele, begrenzt nur durch die Bandbreite des Mobilfunkkanals und die Limits des Tarifs. In der Praxis ist es für Aufgaben mit Accounts sinnvoll, einen Proxy pro logischer Einheit (Account, Projekt, Region) zu halten, damit das Verhalten natürlich wirkt und ein Fehler in einem Container die übrigen nicht beeinflusst.

Fazit: Was du gemacht hast und wie es weitergeht

Fassen wir zusammen. Du hast die Funktionsfähigkeit des Proxys vom Host aus geprüft und das Format der Verbindungszeichenfolge geklärt. Du hast den Proxy für einen einzelnen Container über Umgebungsvariablen und die env-file eingerichtet. Du hast die Übergabe der Variablen über die config.json des Clients automatisiert. Du hast verstanden, wie und warum man den Proxy für den Docker-Daemon auf drei Wegen einrichtet. Du hast mehrere Dienste mit verschiedenen mobilen Proxys in Docker Compose beschrieben und die Geheimnisse in .env ausgelagert. Und schließlich hast du einen Gateway-Container mit isoliertem Netzwerk gebaut — die zuverlässigste Lösung für den Produktivbetrieb, die vor Lecks der echten IP schützt, selbst wenn die Anwendung die Variablen ignoriert.

Jetzt ist der Proxy in Docker für dich keine Blackbox mehr, sondern drei verständliche Ebenen mit klaren Grenzen: Daemon, Container, Netzwerk. Du weißt, wo du das Problem suchst, wenn die IP plötzlich nicht stimmt, und kannst das mit einem Befehl überprüfen.

Wie es weitergeht

  1. Stelle deine Arbeitsprojekte auf das Schema mit Gateway und internem Netzwerk um. Beginne mit einem unkritischen Dienst, überzeuge dich, dass alles läuft, und skaliere dann.
  2. Füge einen Monitor-Container hinzu, der einmal pro Minute die externe IP über das Gateway prüft und Alarm schlägt, wenn sie mit der Server-IP übereinstimmt.
  3. Richte die IP-Rotation nach Zeitplan passend zu deinen Aufgaben ein und bringe den Anwendungen bei, einen Verbindungsabbruch zu überstehen.
  4. Bring Ordnung in die Geheimnisse: .env mit Rechten 600, keine Passwörter in compose.yaml und Dockerfile.

Wohin du dich entwickeln kannst

Der nächste logische Schritt ist, Docker mit Antidetect-Browsern und Multi-Accounting-Tools zu verbinden, bei denen jedem Profil ein eigener Container und ein eigener mobiler Proxy entspricht. Eine andere Richtung ist die Automatisierung über die API des Anbieters: Abrufen der Proxy-Liste, Prüfen ihres Status und Rotation direkt aus deinen Diensten heraus. Beide Themen sprengen diesen Guide, aber das Fundament, das du jetzt gelegt hast, macht sie deutlich einfacher. Viel Erfolg beim Start und stabile IPs!

Über den Autor

Roman Melnikov

Roman Melnikov

Technical Writer and System Administrator

Berufserfahrung: Technical writer and DevOps engineer with 9 years of experience. Created over 50 detailed guides on system configuration and administration. His instructions helped thousands of professionals successfully solve technical tasks. Popular author on Habr and YouTube.
Ausbildung: Bauman Moscow State Technical University. Information Systems and Technologies
Expertise:
Technical Documentation DevOps System Administration Linux Docker and Kubernetes CI/CD Infrastructure Automation Cloud Technologies System Monitoring Bash and Python Scripting

Diesen Artikel teilen: