Proxy w Dockerze: konfiguracja przez kontener, sieć i zmienne środowiskowe — przewodnik krok po kroku

Docker od dawna jest standardem przy uruchamianiu parserów, botów, automatyzacji reklamowych i mniejszych serwisów. Kontenery mają jednak pewną cechę: żyją w odizolowanym środowisku i nic nie wiedzą o proxy, które ustawiłeś na swoim komputerze. W efekcie skrypt wewnątrz kontenera wychodzi do internetu z Twojego rzeczywistego IP, a Ty myślisz, że pracujesz przez mobilne proxy. Ten przewodnik raz na zawsze zamyka tę lukę.

Wprowadzenie: co zyskasz i dla kogo jest ten przewodnik

Po przejściu instrukcji będziesz umiał konfigurować proxy w Dockerze na wszystkich trzech poziomach, na których jest to w ogóle możliwe: dla pojedynczego kontenera przez zmienne środowiskowe, dla całego klienta i demona Docker przez pliki konfiguracyjne, a także na poziomie sieci przez osobny kontener-bramę. Zrozumiesz, czym te poziomy się różnią, kiedy którego używać i jak upewnić się, że ruch naprawdę idzie przez proxy, a nie obok niego.

Dla kogo jest ten przewodnik krok po kroku

• Marketerzy i specjaliści SMM, którzy uruchamiają w Dockerze serwisy do automatycznego postowania, analityki lub monitoringu i chcą, aby każde narzędzie pracowało ze swoim mobilnym IP.
• Arbitrażyści, którzy mają dziesiątki kontenerów z trackerami, parserami ofert i serwisami szpiegującymi, a każdy potrzebuje osobnego geo.
• Programiści, którzy muszą przetestować aplikację z innego regionu albo przepuścić testy integracyjne przez proxy.
• Właściciele firm, których pracownicy lub podwykonawcy wdrażają infrastrukturę w kontenerach, i trzeba rozumieć, jak działa tam obsługa proxy.

Co trzeba wiedzieć wcześniej

Nie zakładamy głębokiej wiedzy. Wystarczy, że umiesz otworzyć terminal, skopiować komendę i przeczytać, co zwróciła. Jeśli nigdy nie pracowałeś z Dockerem, nie martw się: w sekcji z podstawowymi pojęciami wyjaśnimy wszystkie terminy prostym językiem. Kubernetes, orkiestrację klastrów i platformy chmurowe świadomie pomijamy: to osobny temat, a tutaj trzymamy się ściśle poziomu Dockera.

Ile czasu to zajmie

Pełne przejście z weryfikacjami zajmie od 60 do 120 minut. Jeśli potrzebujesz tylko jednego scenariusza, na przykład proxy dla jednego kontenera, wystarczy 15 minut. Jeśli Docker nie jest jeszcze zainstalowany, dodaj 20–30 minut na instalację.

Przygotowanie wstępne: narzędzia, dostępy i wymagania systemowe

Zanim zaczniesz konfigurować proxy w Dockerze, zbierz wszystko, co potrzebne. Dzięki temu nie będziesz się rozpraszać szukaniem loginu albo instalowaniem narzędzi w trakcie.

Co będzie potrzebne

1. Komputer lub serwer z Dockerem. Wystarczy Linux (Ubuntu 22.04 lub 24.04, Debian 12), macOS z Docker Desktop albo Windows 10/11 z Docker Desktop i WSL2. W 2026 roku aktualne są Docker Engine w wersji 27 i wyższej oraz Docker Compose v2, wywoływany komendą docker compose (ze spacją, bez myślnika).
2. Dane mobilnego proxy. Potrzebujesz czterech rzeczy: adresu hosta (IP lub nazwy domenowej), portu, loginu i hasła. Znajdziesz je w panelu klienta u dostawcy. Ustal też, jaki protokół jest dostępny: HTTP czy SOCKS5. Większość dostawców mobilnych proxy, w tym mobileproxy.space, oferuje oba warianty na różnych portach.
3. Terminal. Na Linuksie i macOS jest wbudowany. W Windows użyj PowerShell albo terminala WSL2 (drugi wariant jest wygodniejszy, bo komendy będą identyczne jak na Linuksie).
4. Edytor tekstu. Dowolny: nano, vim, VS Code, Notepad++. Potrzebny do edycji plików konfiguracyjnych.
5. Narzędzie curl. Zwykle jest już zainstalowane. Pomoże sprawdzać, z jakiego IP wychodzi ruch.

Wymagania systemowe

• Minimum 2 GB pamięci RAM i 10 GB wolnego miejsca na dysku dla Dockera i obrazów.
• Uprawnienia administratora: na Linuksie dostęp do sudo, w Windows i macOS konto administratora do instalacji Docker Desktop.
• Stabilne połączenie internetowe do pobierania obrazów.

Kopie zapasowe

W trakcie będziemy edytować pliki konfiguracyjne Dockera. Błąd w nich może sprawić, że Docker się nie uruchomi. Dlatego przed edycją dowolnego pliku zrób kopię. Na Linuksie to jedna komenda:

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

Analogicznie dla pliku ~/.docker/config.json. Jeśli pliku jeszcze nie ma, kopii zapasowej nie trzeba robić, ale zapisz sobie, że utworzyłeś go od zera: wtedy do wycofania wystarczy go po prostu usunąć.

Wskazówka: Załóż plik tekstowy z szablonem danych proxy w formacie protocol://login:password@host:port. Będziesz wklejać ten ciąg wiele razy, a gotowy szablon uchroni Cię od literówek.

Podstawowe pojęcia: jak zbudowany jest Docker i gdzie w nim mieszka proxy

Żeby konfiguracja proxy w Dockerze nie zamieniła się w magię, uporządkujmy terminy. Jeśli już pewnie pracujesz z kontenerami, przejrzyj tę sekcję szybko, ale zwróć uwagę na podsekcję o trzech poziomach proxy: właśnie tam kryje się większość błędów.

Kluczowe terminy prostym językiem

• Obraz (image) — to szablon, „zamrożony” zestaw plików i programów. Na przykład obraz z Pythonem albo obraz z przeglądarką.
• Kontener (container) — uruchomiona kopia obrazu. Z jednego obrazu możesz uruchomić dowolnie wiele kontenerów i każdy będzie odizolowany od pozostałych.
• Demon Dockera (daemon, dockerd) — usługa działająca w tle, która tworzy kontenery, pobiera obrazy i zarządza sieciami. To właśnie demon wychodzi do internetu po obrazy, kiedy wpisujesz docker pull.
• Klient Dockera (docker CLI) — komenda docker w terminalu. Wysyła Twoje polecenia do demona.
• Zmienne środowiskowe (environment variables) — nazwane wartości dostępne dla programów wewnątrz kontenera. Na przykład HTTP_PROXY=http://user:pass@host:port. Wiele programów automatycznie czyta takie zmienne i zaczyna chodzić przez wskazane proxy.
• Sieć Dockera (network) — wirtualna sieć łącząca kontenery. Kontenery w tej samej sieci użytkownika widzą się po nazwach.
• Docker Compose — narzędzie, które opisuje kilka kontenerów, ich zmienne i sieci w jednym pliku YAML i uruchamia je jedną komendą.

Trzy poziomy proxy w Dockerze

To najważniejsza część teorii. Kiedy mówi się „proxy w Dockerze”, może chodzić o trzy zupełnie różne rzeczy, a konfiguruje się je inaczej.

1. Proxy dla demona. Potrzebne, żeby sam Docker pobierał obrazy przez proxy. Chodzi o komendy docker pull i docker build, kiedy ciągną obrazy bazowe. Na ruch Twoich aplikacji wewnątrz kontenerów ten poziom nie wpływa.
2. Proxy dla kontenerów przez zmienne środowiskowe. Do kontenera przekazywane są HTTP_PROXY, HTTPS_PROXY i NO_PROXY, a aplikacja sama decyduje, czy ich użyć. To najpopularniejszy i najprostszy sposób, ale działa tylko z programami, które respektują te zmienne.
3. Proxy na poziomie sieci. Ruch kontenera jest kierowany przez inny kontener-bramę albo przez specjalnie skonfigurowaną sieć. Aplikacja w środku może w ogóle nie wiedzieć o proxy. To niezawodniejsze, ale wymaga więcej konfiguracji.

Co ważne przed startem

Zmienne środowiskowe z proxy to tylko sugestia dla programu. Narzędzie curl, menedżer pakietów pip, biblioteka requests w Pythonie, Node.js z pakietem global-agent, wget, apt — wszystkie czytają HTTP_PROXY. Ale przeglądarki w trybie headless, niektóre aplikacje Go i wiele narzędzi binarnych może te zmienne ignorować. Dlatego po konfiguracji zawsze sprawdzaj faktyczne zewnętrzne IP, a nie polegaj na tym, że zmienna jest ustawiona.

Jeszcze jeden niuans — wielkość liter. Historycznie część programów czyta http_proxy małymi literami, część HTTP_PROXY wielkimi. Bezpieczna praktyka to ustawiać oba warianty jednocześnie. Zmienna NO_PROXY wymienia adresy, dla których nie należy używać proxy: localhost, 127.0.0.1, domeny wewnętrzne, nazwy sąsiednich kontenerów.

Wreszcie format adresu proxy. Dla proxy HTTP ciąg wygląda tak: http://login:password@host:port. Dla SOCKS5 — socks5://login:password@host:port albo socks5h://login:password@host:port. Litera h na końcu oznacza, że zapytania DNS też idą przez proxy, co przy mobilnych proxy jest zwykle korzystniejsze: tak docelowa strona nie zobaczy resolvera DNS Twojego dostawcy.

Krok 1: Sprawdzamy Dockera i przygotowujemy dane proxy

Cel etapu: upewnić się, że Docker działa, a Twoje dane proxy są poprawne i dostępne z tego komputera. Bez tej weryfikacji ryzykujesz pół godziny szukania błędu w konfiguracji, gdy problem był w literówce w haśle.

Weryfikacja Dockera

1. Otwórz terminal.
2. Wpisz komendę docker --version i naciśnij Enter. Powinieneś zobaczyć ciąg typu Docker version 27.x.x. Jeśli terminal pisze, że komenda nie została znaleziona, Docker nie jest zainstalowany: zainstaluj Docker Desktop (Windows, macOS) albo Docker Engine (Linux) zgodnie z oficjalną dokumentacją i wróć tutaj.
3. Wpisz docker compose version. Oczekiwany wynik: Docker Compose version v2.x.x.
4. Wpisz docker run --rm hello-world. Docker pobierze malutki obraz testowy i wyświetli powitanie ze słowami Hello from Docker. To znaczy, że demon działa i masz uprawnienia do uruchamiania kontenerów.

Wskazówka: Jeśli na Linuksie komenda docker wymaga sudo, dodaj się do grupy docker: sudo usermod -aG docker $USER, następnie wyloguj się i zaloguj ponownie. Dalej wszystkie komendy w przewodniku będą działać bez sudo.

Weryfikacja proxy z hosta

Zanim zaniesiemy proxy do kontenera, sprawdźmy, czy w ogóle odpowiada. Podmień dane na swoje. W przykładach będziemy używać adresu 185.10.10.10, portu 1050 dla HTTP i 1051 dla SOCKS5, loginu user123 i hasła secret. U Ciebie oczywiście będą inne wartości.

1. Najpierw sprawdź swoje zwykłe IP bez proxy: curl -s ifconfig.me. Zapisz albo zapamiętaj wynik.
2. Teraz zapytanie przez proxy HTTP: curl -s -x http://user123:secret@185.10.10.10:1050 ifconfig.me
3. Jeśli masz SOCKS5: curl -s -x socks5h://user123:secret@185.10.10.10:1051 ifconfig.me
4. Porównaj wynik z krokiem 1. IP powinno się różnić i należeć do operatora mobilnego.

Znaki specjalne w haśle

Jeśli w loginie lub haśle są znaki @, :, /, #, ? albo spacja, trzeba je zakodować w formacie URL, inaczej ciąg proxy się zepsuje. Znak @ zamienia się w %40, : w %3A, / w %2F, # w %23, ? w %3F, spacja w %20. Na przykład hasło pa@ss w ciągu proxy zapisuje się jako pa%40ss.

✅ Weryfikacja: Komenda curl przez proxy zwróciła IP inne niż Twoje domowe, a odpowiedź przyszła w ciągu jednej–trzech sekund. Jeśli dostałeś błąd 407, sprawdź login i hasło. Jeśli Connection refused albo timeout — sprawdź host, port i to, czy Twoje aktualne IP jest dodane do białej listy w panelu klienta u dostawcy (w niektórych taryfach autoryzacja po IP jest włączona domyślnie).

Krok 2: Konfigurujemy proxy dla jednego kontenera przez zmienne środowiskowe

Cel etapu: uruchomić kontener, którego cały ruch HTTP idzie przez mobilne proxy, i potwierdzić to po zewnętrznym IP. To podstawowy scenariusz, od którego warto zacząć: nie rusza ustawień systemowych i łatwo go cofnąć.

Uruchomienie z flagą -e

Flaga -e (albo --env) komendy docker run przekazuje zmienną środowiskową do wnętrza kontenera. Przekażemy od razu cztery zmienne: proxy dla HTTP, dla HTTPS i wyjątki, każdą w dwóch wariantach wielkości liter.

1. Skopiuj komendę poniżej do edytora i zamień dane proxy na swoje.
2. Wykonaj komendę w terminalu. Uruchomi tymczasowy kontener z curlem, który wykona zapytanie i zakończy pracę.

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

Zwróć uwagę: dla HTTPS_PROXY też podajemy http:// na początku. To nie błąd. Tak określa się proxy, przez które pójdą zapytania HTTPS, a samo połączenie z serwerem proxy jest przy tym zwykłe. Schemat https:// w wartości HTTPS_PROXY oznaczałby, że do samego proxy trzeba się łączyć po TLS, czego większość dostawców nie obsługuje.

Plik ze zmiennymi zamiast długiej komendy

Komenda wyszła nieporęczna. Docker umie czytać zmienne z pliku przez flagę --env-file. Tak jest wygodniej i bezpieczniej: hasło nie zostaje w historii terminala.

1. Utwórz plik proxy.env w katalogu roboczym: nano proxy.env
2. Wpisz w nim linie, po jednej zmiennej na linię, bez cudzysłowów i bez spacji wokół znaku równości:

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

W prawdziwym pliku każda zmienna powinna być w osobnej linii. Zapisz plik (w nano to Ctrl+O, Enter, potem Ctrl+X) i uruchom kontener:

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

Weryfikacja z wnętrza działającego kontenera

Często trzeba zobaczyć, co widzi kontener działający długotrwale. Uruchommy Alpine Linux w trybie interaktywnym i sprawdźmy zmienne.

1. Wykonaj docker run -it --rm --env-file proxy.env alpine sh. Znajdziesz się wewnątrz kontenera, znak zachęty zmieni się na krzyżyk albo znak dolara.
2. Wpisz env | grep -i proxy. Zobaczysz listę swoich zmiennych.
3. Wpisz apk add --no-cache curl. Menedżer pakietów apk sam podchwyci https_proxy i pobierze pakiet przez proxy.
4. Wpisz curl -s ifconfig.me i upewnij się, że IP jest mobilne.
5. Wpisz exit, żeby wyjść. Kontener usunie się automatycznie dzięki fladze --rm.

Wskazówka: Do sprawdzania IP oprócz ifconfig.me warto używać serwisów zwracających JSON z informacją o kraju, mieście i operatorze. Wtedy od razu zobaczysz, że IP należy do operatora mobilnego z właściwego regionu, a nie po prostu „jakiegoś innego”.

✅ Weryfikacja: Oba uruchomienia z curlem zwróciły IP mobilnego proxy. Komenda env wewnątrz kontenera pokazała zmienne HTTP_PROXY i HTTPS_PROXY z Twoimi danymi.

Możliwe problemy na tym etapie

• IP się nie zmieniło. Aplikacja w kontenerze ignoruje zmienne. W przypadku curla to się nie zdarza, więc jeśli curl pokazuje mobilne IP, a Twoja aplikacja nie — przejdź do sposobu sieciowego z kroku 6.
• Błąd invalid reference format. Zwykle to zbędna spacja albo złamanie linii w komendzie. Złóż komendę w jedną linię.
• Zmienne nie są widoczne. W pliku env-file nie powinno być cudzysłowów wokół wartości: Docker przekazałby je dosłownie i adres proxy stałby się niepoprawny.

Krok 3: Konfigurujemy proxy dla klienta Docker, żeby zmienne były przekazywane automatycznie

Cel etapu: sprawić, żeby każdy nowy kontener i każde budowanie obrazu automatycznie dostawały zmienne proxy bez flag -e. Oszczędza to czas, jeśli ciągle uruchamiasz różne kontenery przez jedno i to samo mobilne proxy.

Jak to działa

Klient Docker czyta plik config.json w katalogu ~/.docker (w Windows to katalog .docker w profilu użytkownika). Jeśli jest w nim sekcja proxies, klient przy każdym docker run i docker build dodaje wskazane zmienne do kontenera. Demon pozostaje przy tym nietknięty, więc docker pull nadal pójdzie bezpośrednio.

Konfiguracja krok po kroku

1. Sprawdź, czy plik istnieje: cat ~/.docker/config.json. Jeśli plik istnieje i są w nim już ustawienia (na przykład auths z danymi logowania do rejestru), zrób kopię: cp ~/.docker/config.json ~/.docker/config.json.bak
2. Otwórz plik w edytorze: nano ~/.docker/config.json. Jeśli pliku nie ma, edytor go utworzy.
3. Dodaj sekcję proxies. Jeśli plik był pusty, jego zawartość będzie w całości taka:

{ "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" } } }

Jeśli w pliku były już inne klucze, dodaj proxies jako kolejny klucz najwyższego poziomu po przecinku, nie usuwając istniejących. Pilnuj parzystości nawiasów klamrowych i cudzysłowów: JSON nie wybacza brakującego przecinka.

1. Zapisz plik.
2. Sprawdź składnię. Na Linuksie i macOS wygodnie tak: python3 -m json.tool ~/.docker/config.json. Jeśli wynik powtarza Twój plik ładnie sformatowany, wszystko w porządku. Jeśli pojawił się błąd z numerem linii, popraw go.
3. Uruchom kontener kontrolny bez żadnych flag: docker run --rm curlimages/curl -s ifconfig.me. IP powinno być mobilne.
4. Zobacz zmienne dowolnego kontenera: docker run --rm alpine env. W wyniku będą HTTP_PROXY, HTTPS_PROXY, NO_PROXY i ich warianty małymi literami: Docker sam dodaje oba warianty.

⚠ Uwaga: Sekcja proxies w config.json wpływa na wszystkie kontenery, które uruchamiasz z tego użytkownika, w tym bazy danych, lokalne serwery WWW i wszystko inne. Jeśli jakiś serwis komunikuje się z zewnętrznym API, które jest niedostępne przez Twoje proxy, się zepsuje. Dodaj takie adresy do noProxy albo tymczasowo usuń sekcję.

Różne proxy dla różnych połączeń

Klucz default stosuje się do wszystkich połączeń z demonem. Jeśli zarządzasz kilkoma hostami Dockera przez konteksty albo zmienną DOCKER_HOST, zamiast default możesz wskazać adres konkretnego demona, na przykład tcp://192.168.1.50:2376, i proxy będzie stosowane tylko do niego. Do pracy lokalnej wystarczy default.

Proxy przy budowaniu obrazów

Ustawienia z config.json są też przekazywane do docker build jako argumenty budowania. To znaczy, że komendy RUN apt-get install albo RUN pip install wewnątrz Dockerfile pójdą przez proxy. Ważny szczegół: te zmienne nie są zapisywane w gotowym obrazie, co jest dobre z punktu widzenia bezpieczeństwa: hasło do proxy nie wycieknie do tych, którym przekażesz obraz.

Wskazówka: Jeśli chcesz przekazać proxy tylko do jednego budowania, nie ruszając config.json, użyj flag 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 rozumie te predefiniowane argumenty bez deklarowania ARG w Dockerfile.

✅ Weryfikacja: Kontener uruchomiony bez flag -e wychodzi do internetu z IP proxy. Komenda docker run --rm alpine env pokazuje zmienne proxy.

Jak wycofać zmiany

Usuń sekcję proxies z config.json albo przywróć plik z kopii zapasowej: cp ~/.docker/config.json.bak ~/.docker/config.json. Restart nie jest potrzebny, zmiany zadziałają przy następnym uruchomieniu kontenera.

Krok 4: Konfigurujemy proxy dla demona Docker, żeby obrazy pobierały się przez proxy

Cel etapu: zmusić sam Docker (demon) do chodzenia po obrazy przez proxy. To potrzebne, gdy bezpośredni dostęp do rejestru obrazów z Twojego serwera jest ograniczony polityką firmową, wolny albo gdy chcesz, żeby cała aktywność sieciowa serwera szła jednym kanałem. Do zadań marketingowych ten krok często nie jest potrzebny, ale warto go znać: błędy na poziomie demona regularnie myli się z błędami na poziomie kontenera.

Sposób 1: plik daemon.json (Linux, Docker 23 i nowszy)

1. Zrób kopię: sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak (jeśli pliku nie ma, komenda zwróci błąd, to normalne).
2. Otwórz plik: sudo nano /etc/docker/daemon.json
3. Dodaj sekcję proxies:

{ "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" } }

Zwróć uwagę, że klucze piszemy tu z myślnikami i małymi literami: to różni się od config.json klienta, gdzie klucze są w stylu httpProxy. Mylenie ich to klasyczny błąd.

1. Zapisz plik i zrestartuj demon: sudo systemctl restart docker
2. Sprawdź, czy demon wstał: sudo systemctl status docker. W wyniku powinno być active (running).
3. Sprawdź zastosowanie: docker info | grep -i proxy. Zobaczysz linie HTTP Proxy i HTTPS Proxy z Twoim adresem, a hasło w wyniku będzie ukryte gwiazdkami.

Sposób 2: plik drop-in systemd (Linux, dowolna wersja)

To klasyczny sposób, który działa nawet na starszych wersjach Dockera.

1. Utwórz katalog: sudo mkdir -p /etc/systemd/system/docker.service.d
2. Utwórz plik: sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf
3. Wpisz zawartość, każda dyrektywa w osobnej linii:

[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. Zapisz, a następnie przeładuj konfigurację systemd: sudo systemctl daemon-reload
2. Zrestartuj Docker: sudo systemctl restart docker
3. Sprawdź: sudo systemctl show --property=Environment docker. W wyniku będą Twoje zmienne.

⚠ Uwaga: Nie konfiguruj proxy demona dwoma sposobami jednocześnie. Jeśli i daemon.json, i plik systemd zawierają różne adresy, zachowanie stanie się nieprzewidywalne, a debugowanie — męczące. Wybierz jeden sposób i się go trzymaj.

Sposób 3: Docker Desktop (Windows i macOS)

1. Otwórz Docker Desktop, kliknij ikonę zębatki w prawym górnym rogu.
2. W lewym menu wybierz Resources, a potem Proxies.
3. Przełącz przełącznik Manual proxy configuration w pozycję włączoną.
4. W pola Web Server (HTTP) i Secure Web Server (HTTPS) wklej adres proxy w formacie http://user123:secret@185.10.10.10:1050.
5. W polu Bypass proxy settings for these hosts wpisz localhost,127.0.0.1.
6. Kliknij Apply and restart. Docker Desktop zrestartuje się, zajmie to 30–60 sekund.

Docker Desktop stosuje te ustawienia jednocześnie do demona i do kontenerów, dlatego osobna edycja config.json w systemach desktopowych często nie jest potrzebna.

Weryfikacja wyniku

1. Usuń jakiś mały obraz, jeśli go masz: docker rmi alpine
2. Pobierz go ponownie: docker pull alpine. Pobieranie powinno przejść pomyślnie.
3. Jeśli po stronie proxy jest statystyka ruchu (w panelu mobileproxy.space jest), zobaczysz, że zużycie ruchu wzrosło o kilka megabajtów.

✅ Weryfikacja: docker info pokazuje adres proxy, docker pull pobiera obrazy bez błędów, usługa docker jest w stanie active.

Możliwe problemy

• Docker nie startuje po edycji daemon.json. Prawie zawsze winna jest składnia JSON. Sprawdź plik komendą python3 -m json.tool /etc/docker/daemon.json albo przywróć kopię.
• docker pull się zawiesza. Proxy nie przepuszcza połączeń do rejestru albo przekroczono limit ruchu w taryfie. Sprawdź proxy z hosta przez curl, jak w kroku 1.
• Błąd x509 certificate. Proxy podmiienia certyfikaty (dotyczy proxy firmowych, przy mobilnych proxy to rzadkość). Dopytaj u dostawcy.

Krok 5: Konfigurujemy proxy w Docker Compose

Cel etapu: opisać proxy w pliku compose.yaml tak, żeby grupa kontenerów uruchamiała się jedną komendą z właściwymi ustawieniami, a różne serwisy mogły używać różnych mobilnych proxy. Właśnie ten scenariusz najczęściej potrzebny jest arbitrażystom i marketerom: jeden parser pracuje przez proxy Moskwy, drugi — przez proxy Kazania, a baza danych — bez proxy.

Przygotowanie projektu

1. Utwórz katalog projektu i przejdź do niego: mkdir proxy-demo, potem cd proxy-demo
2. Utwórz plik .env (właśnie z kropką na początku) do przechowywania sekretów: nano .env
3. Wpisz zmienne, po jednej w linii:

PROXY_MSK=http://user123:secret@185.10.10.10:1050 PROXY_KZN=http://user456:secret2@185.10.10.20:1050

Plik .env Compose czyta automatycznie, a wartości z niego można podstawiać w compose.yaml składnią ${NAZWA}. Dodaj .env do .gitignore, jeśli projekt jest pod kontrolą wersji: hasła nie powinny trafiać do repozytorium.

Plik compose.yaml

Utwórz plik compose.yaml (nano compose.yaml) i opisz trzy serwisy. W YAML wcięcia są ważne: używaj dwóch spacji na poziom, nie tabulatora.

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

Tutaj w prawdziwym pliku każda linia stoi osobno z właściwymi wcięciami: services na poziomie zerowym, nazwy serwisów z wcięciem dwóch spacji, ich parametry — czterech, zmienne środowiskowe — sześciu. Zwróć uwagę na nazwę db w NO_PROXY: tak parsery będą odwoływać się do bazy danych bezpośrednio przez wewnętrzną sieć Dockera, a nie próbować dotrzeć do niej przez mobilne proxy, co z góry nie zadziała.

Uruchomienie i weryfikacja

1. Sprawdź, jak Compose podstawił zmienne: docker compose config. Komenda wypisze gotowy plik z rozwiniętymi wartościami. Upewnij się, że zamiast ${PROXY_MSK} stoi realny adres.
2. Uruchom: docker compose up. Compose pobierze obrazy i uruchomi wszystkie trzy serwisy, wypisując ich logi w terminalu.
3. W logach zobaczysz linie typu parser-msk-1 | 91.xxx.xxx.xxx i parser-kzn-1 | 176.xxx.xxx.xxx: dwa różne IP z dwóch różnych proxy. Postgres wystartuje i będzie czekał na połączenia.
4. Zatrzymaj wszystko skrótem Ctrl+C, potem usuń kontenery: docker compose down

Alternatywa: env_file dla każdego serwisu

Jeśli zmiennych jest dużo, zamiast bloku environment wygodniej wskazać plik:

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

Plik proxy-msk.env zawiera przy tym te same sześć linii co proxy.env z kroku 2. Tak każde proxy leży w swoim pliku i można je podmienić, nie otwierając compose.yaml.

Proxy przy budowaniu w Compose

Jeśli serwis jest budowany z Dockerfile, a nie brany jako gotowy, przekaż proxy do budowania przez build.args:

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

Tak pip, npm albo apt wewnątrz Dockerfile będą pracować przez proxy, a do gotowego obrazu wartości nie trafią.

Wskazówka: Compose obsługuje kilka plików. Trzymaj bazowy compose.yaml bez proxy, a w compose.proxy.yaml opisz tylko bloki environment. Uruchamiaj docker compose -f compose.yaml -f compose.proxy.yaml up, kiedy proxy jest potrzebne, i po prostu docker compose up, kiedy nie. To wygodne przy debugowaniu: w sekundę przełączasz się między trybami.

✅ Weryfikacja: docker compose config pokazuje podstawione adresy proxy, a w logach docker compose up serwisy z różnymi proxy wypisują różne IP.

Krok 6: Konfigurujemy proxy na poziomie sieci przez kontener-bramę

Cel etapu: postawić osobny kontener, który przyjmuje połączenia od sąsiadów w sieci Dockera i przekierowuje je do mobilnego proxy. Pozostałe kontenery odwołują się do bramy po nazwie i nie trzymają u siebie loginu ani hasła. To rozwiązuje trzy zadania naraz: centralizuje zarządzanie proxy, usuwa hasła z dziesiątek konfiguracji i pozwala zmieniać proxy bez restartowania działających kontenerów.

Po co brama, jeśli są zmienne

Wyobraź sobie, że masz dwadzieścia kontenerów z parserami, a dostawca wydał nowy port. Przy zmiennych środowiskowych będziesz poprawiać dwadzieścia konfiguracji i restartować wszystko. Z bramą zmieniasz jedną linię w jednym miejscu. Poza tym niektóre aplikacje nie obsługują autoryzacji w proxy po loginie i haśle, ale świetnie działają z proxy bez autoryzacji. Brama w zamkniętej sieci Dockera autoryzacji nie wymaga, a sama łączy się z mobilnym proxy już z Twoimi danymi.

Tworzymy sieć

1. Utwórz sieć użytkownika: docker network create proxynet
2. Upewnij się, że się pojawiła: docker network ls. Na liście będzie proxynet z driverem bridge.

Sieć użytkownika jest potrzebna, bo tylko w niej działa rozwiązywanie nazw: kontener może odwołać się do bramy po nazwie gateway, a nie po IP, które zmienia się przy każdym restarcie.

Uruchamiamy bramę

Jako bramę użyjemy gost — kompaktowego serwera proxy, który umie przyjmować połączenia na jednym protokole i przekazywać je dalej na inny z autoryzacją. Obraz jest dostępny w publicznym rejestrze pod nazwą gogost/gost.

1. Uruchom kontener-bramę:

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

Rozbierzmy parametry. Flaga -d uruchamia kontener w tle. Flaga --name gateway nadaje nazwę, po której będą się do niego odwoływać sąsiedzi. Flaga --network proxynet podłącza go do naszej sieci. Flaga --restart unless-stopped podnosi bramę po restarcie serwera. Parametr -L=http://:8118 mówi gostowi przyjmować połączenia proxy HTTP na porcie 8118 bez autoryzacji. Parametr -F wskazuje, dokąd przekazywać: do Twojego mobilnego proxy z loginem i hasłem.

1. Sprawdź, że brama działa: docker logs gateway. W logu powinna być linia, że serwer nasłuchuje na porcie 8118, bez błędów.

⚠ Uwaga: Nie publikuj portu bramy na zewnątrz flagą -p, jeśli nie ma wyraźnej potrzeby. Brama działa bez autoryzacji, a otwarty port 8118 na publicznym serwerze oznacza, że ktokolwiek w internecie będzie mógł korzystać z Twojego mobilnego proxy i zużywać Twój ruch. Wewnątrz sieci proxynet jest dostępna tylko dla Twoich kontenerów i to wystarczy.

Podłączamy kontenery robocze

1. Uruchom kontener kontrolny w tej samej sieci, wskazując bramę jako proxy:

docker run --rm --network proxynet -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 curlimages/curl -s ifconfig.me

1. Powinieneś zobaczyć IP mobilnego proxy. Zauważ: w zmiennych nie ma ani loginu, ani hasła, ani realnego adresu proxy. Wszystko to zna tylko brama.

To samo w Compose

Do stałej pracy opisz bramę i serwisy robocze w jednym 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

Dyrektywa depends_on gwarantuje, że brama wystartuje przed workerem. Wartość PROXY_MSK pochodzi z pliku .env, jak w kroku 5.

Kilka bram dla kilku geo

Chcesz różne proxy dla różnych grup kontenerów? Postaw kilka bram: gateway-msk, gateway-kzn, gateway-spb, każdą ze swoim -F. Kontenery robocze po prostu wskazują odpowiednią nazwę w HTTP_PROXY. Można pójść dalej i utworzyć osobną sieć dla każdego geo, wtedy kontenery z grupy Moskwy fizycznie nie będą mogły przypadkiem trafić do bramy Kazania.

Izolacja: kontener bez bezpośredniego wyjścia do internetu

Najostrzejszy wariant — zabronić kontenerowi roboczemu jakiegokolwiek wyjścia do internetu poza bramą. W tym celu utwórz sieć wewnętrzną flagą --internal: docker network create --internal isolated. Kontenery w takiej sieci nie mają trasy na zewnątrz. Podłącz bramę do dwóch sieci naraz (isolated i zwykłej proxynet), a workery — tylko do isolated. Teraz nawet jeśli aplikacja zignoruje zmienne proxy, po prostu nie będzie mogła wyjść do internetu bezpośrednio i nie dojdzie do wycieku rzeczywistego 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. Dla kontroli uruchom ten sam kontener bez zmiennych proxy: docker run --rm --network isolated curlimages/curl -s -m 5 ifconfig.me. Zapytanie powinno zakończyć się timeoutem: nie ma bezpośredniego wyjścia.

Wskazówka: Połączenie sieci wewnętrznej i bramy to najlepsze zabezpieczenie przed wyciekami przy pracy na wielu kontach. Nawet jeśli programista zapomniał wpisać proxy w nowym serwisie, ten nie będzie mógł ujawnić IP serwera: albo pójdzie przez bramę, albo nie pójdzie nigdzie.

✅ Weryfikacja: Kontener w sieci proxynet ze zmienną HTTP_PROXY=http://gateway:8118 pokazuje IP mobilnego proxy. Kontener w sieci wewnętrznej bez proxy nie może w ogóle wyjść do internetu.

Możliwe problemy

• Could not resolve host: gateway. Kontener roboczy nie jest w tej sieci albo jest uruchomiony w sieci domyślnej, gdzie nazwy się nie rozwiązują. Sprawdź flagę --network.
• Brama restartuje się. Błąd w ciągu -F: literówka w haśle albo nieprawidłowy port. Zobacz docker logs gateway.
• Wolno. Mobilne proxy z natury są wolniejsze niż data center, ale jeśli opóźnienie liczy się w dziesiątkach sekund, sprawdź, czy DNS nie idzie obok: użyj socks5h zamiast socks5 w ciągu -F, jeśli dostawca daje SOCKS5.

Weryfikacja wyniku: lista kontrolna działającego proxy w Dockerze

Przejdź przez listę. Jeśli każdy punkt odhaczony, w pełni opanowałeś konfigurację proxy w Dockerze w praktyce.

Lista kontrolna

• curl z hosta przez proxy zwraca mobilne IP.
• Kontener z flagą --env-file proxy.env zwraca mobilne IP.
• Kontener bez flag po konfiguracji config.json zwraca mobilne IP (jeśli robiłeś krok 3).
• docker info pokazuje adres proxy, a docker pull działa (jeśli robiłeś krok 4).
• docker compose up uruchamia serwisy, a w logach widać różne IP dla różnych proxy.
• Kontener-brama działa, sąsiedzi wychodzą przez nią bez loginu i hasła.
• Kontener w sieci wewnętrznej bez proxy nie może wyjść do internetu.

Jak przetestować całość

1. Uruchom kontener działający długotrwale: docker run -d --name test --network proxynet -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 alpine sleep 3600
2. Wejdź do niego: docker exec -it test sh
3. Zainstaluj curl: apk add --no-cache curl. Instalacja powinna przejść przez proxy.
4. Wykonaj pięć zapytań pod rząd: for i in 1 2 3 4 5; do curl -s ifconfig.me; echo; done. Wszystkie pięć powinny zwrócić mobilne IP. Jeśli Twoje proxy ma włączoną automatyczną rotację, IP mogą się różnić między zapytaniami, to normalne.
5. Wyjdź (exit) i usuń kontener: docker rm -f test

Wskaźniki sukcesu

Udana konfiguracja oznacza, że potrafisz w sekundę odpowiedzieć na trzy pytania: przez jakie IP wychodzi konkretny kontener, gdzie jest przechowywane hasło do proxy i co trzeba zmienić, żeby przełączyć kontener na inne proxy. Jeśli odpowiedź na każde pytanie jest oczywista — cel osiągnięty.

Typowe błędy przy konfiguracji proxy w Dockerze i ich rozwiązania

Błąd 1: IP się nie zmienia, choć zmienne są ustawione

Przyczyna: aplikacja w kontenerze nie czyta zmiennych środowiskowych proxy. To typowe dla przeglądarek headless, niektórych programów Go i narzędzi, które używają własnych stosów sieciowych.

Rozwiązanie: sprawdź dokumentację aplikacji pod kątem własnej flagi proxy (w przeglądarkach to zwykle --proxy-server). Jeśli flagi nie ma, użyj bramy i sieci wewnętrznej z kroku 6 albo przezroczystego proxy z sekcji dla zaawansowanych.

Błąd 2: 407 Proxy Authentication Required

Przyczyna: błędny login lub hasło, albo znaki specjalne w nich nie są zakodowane, albo proxy ma włączoną autoryzację po IP, a IP serwera nie jest na białej liście.

Rozwiązanie: sprawdź dane z hosta przez curl. Zakoduj znaki specjalne. Dodaj IP serwera do białej listy w panelu klienta albo przełącz proxy na autoryzację po loginie i haśle.

Błąd 3: Docker nie startuje po edycji daemon.json

Przyczyna: błąd składni w JSON: zbędny przecinek, brakujący cudzysłów, klucze w stylu config.json zamiast stylu daemon.json.

Rozwiązanie: zobacz dziennik: sudo journalctl -u docker -n 50. Tam będzie wskazana linia z błędem. Popraw albo przywróć kopię zapasową i zrestartuj usługę.

Błąd 4: kontenery przestały się widzieć

Przyczyna: po globalnej konfiguracji proxy w config.json zapytania do sąsiednich kontenerów też poszły przez mobilne proxy, które nie wie, co to db albo redis.

Rozwiązanie: dodaj nazwy serwisów i podsieci wewnętrzne do NO_PROXY: localhost,127.0.0.1,db,redis,172.16.0.0/12. Pamiętaj, że maski podsieci rozumieją nie wszystkie programy, dlatego pewniej wymieniać nazwy jawnie.

Błąd 5: docker build pada na apt-get albo pip

Przyczyna: budowanie idzie bez proxy, bo zmienne są ustawione dla kontenerów, a nie dla budowania, albo proxy demona jest skonfigurowane, ale nie wpływa na kroki RUN.

Rozwiązanie: przekaż --build-arg HTTP_PROXY i HTTPS_PROXY albo skonfiguruj sekcję proxies w config.json klienta: ona rozciąga się też na budowanie.

Błąd 6: hasło do proxy jest widoczne w docker inspect i logach

Przyczyna: zmienne środowiskowe są przechowywane w metadanych kontenera w otwartej postaci i każdy, kto ma dostęp do Dockera, zobaczy je przez docker inspect.

Rozwiązanie: użyj bramy: kontenery robocze znają tylko adres gateway:8118. Hasło zostaje w jednym kontenerze i w pliku .env z ograniczonymi prawami (chmod 600 .env).

Błąd 7: po restarcie serwera proxy przestało działać

Przyczyna: kontener-brama nie został uruchomiony z polityką restartu albo u mobilnego proxy zmienił się adres IP hosta.

Rozwiązanie: dodaj --restart unless-stopped do bramy. Używaj nazwy domenowej proxy zamiast IP, jeśli dostawca ją udostępnia. Sprawdź docker ps -a: jeśli brama ma status Exited, zobacz jej logi.

Błąd 8: strony HTTPS nie otwierają się, a HTTP działa

Przyczyna: ustawiona jest tylko HTTP_PROXY, a HTTPS_PROXY jest pusta, albo w HTTPS_PROXY podano schemat https:// zamiast http://.

Rozwiązanie: zawsze ustawiaj obie zmienne z tą samą wartością i schematem http://.

Dodatkowe możliwości dla zaawansowanych: przezroczyste proxy, rotacja IP i bezpieczeństwo

Ta sekcja jest dla tych, którzy przeszli podstawowe kroki i chcą wycisnąć z połączenia Dockera i mobilnych proxy maksimum. Tu mniej list kroków, a więcej pomysłów z kluczowymi komendami.

Przezroczyste proxy: gdy aplikacja w ogóle nie wie o proxy

Jeśli masz aplikację, która nie umie pracować z proxy w żaden sposób, możesz zawinąć cały jej ruch TCP na poziomie stosu sieciowego. Pomysł jest taki: kontener roboczy uruchamiasz z parametrem network_mode: service:gateway (w Compose) albo --network container:gateway (w docker run). Tak używa on stosu sieciowego kontenera-bramy w całości: ten sam IP, te same interfejsy, te same reguły routingu.

W bramie działa przy tym program w rodzaju redsocks, który nasłuchuje na lokalnym porcie i przekierowuje połączenia do proxy SOCKS5, a reguły iptables przekierowują na ten port cały wychodzący ruch TCP. Brama potrzebuje do tego uprawnień: cap_add: NET_ADMIN. Aplikacja w kontenerze roboczym wykonuje zwykłe zapytanie do strony, jądro je przechwytuje i kieruje do redsocks, a ten — do mobilnego proxy. Żadnych zmiennych środowiskowych. Konfiguracja wymaga staranności: błędna reguła iptables może zapętlić ruch, dlatego testuj na osobnym komputerze. Pamiętaj też, że przy network_mode: service kontener roboczy traci własne porty i połączenia z innymi sieciami, wszystko to trzeba opisać na bramie.

Rotacja IP z kontenera

Mobilne proxy mają cechę, dla której właśnie się je bierze: IP można zmienić na żądanie. Dostawcy udostępniają specjalny link do zmiany IP, który wystarczy otworzyć, żeby modem przełączył się ponownie. Z kontenera robi się to tym samym curlem. Przydatny wzorzec: osobny mały serwis w Compose, który według harmonogramu szarpie link rotacji. Nie powinien chodzić przez proxy (inaczej po zmianie IP sam straci połączenie), więc uruchamiaj go bez zmiennych proxy albo jawnie z pustymi HTTP_PROXY. Pamiętaj, że po zmianie IP aktywne połączenia kontenerów roboczych się zerwą: zakładaj w parserach ponowne próby.

Zdrowie bramy: healthcheck

Dodaj w Compose sprawdzenie, że brama naprawdę proxuje, a nie tylko działa:

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

To minimalne sprawdzenie żywotności procesu. Do sprawdzenia realnego wyjścia do internetu lepszy jest osobny kontener-monitor, który raz na minutę wykonuje zapytanie przez bramę i zapisuje wynik do logu albo wysyła powiadomienie. Jeśli IP nagle stało się IP serwera, to alarm: brama padła, a kontenery poszły bezpośrednio. Sieć wewnętrzna z kroku 6 właśnie chroni przed takim scenariuszem.

Bezpieczne przechowywanie haseł

Plik .env jest dobry do pracy lokalnej, ale na serwerze z kilkoma użytkownikami warto go zabezpieczyć: chmod 600 .env, właściciel — ten użytkownik, z którego uruchamiany jest Compose. Compose obsługuje też sekrety przez dyrektywę secrets, które są montowane do kontenera jako plik w /run/secrets/, a nie zmienna środowiskowa. Gost nie czyta hasła z pliku bezpośrednio, ale możesz napisać mały skrypt-opakowanie, który składa ciąg -F z pliku sekretu przy starcie. Tak hasło nie trafi ani do docker inspect, ani do wyniku docker compose config.

Kilka projektów i jedna infrastruktura proxy

Jeśli masz kilka projektów Compose, a proxy są wspólne, wynieś bramy do osobnego projektu z siecią zewnętrzną: zadeklaruj w nim networks z parametrem name: proxynet, a w pozostałych projektach podłączaj się do niej jako external: true. Wtedy bramy żyją niezależnie, a projekty robocze możesz restartować do woli, nie ruszając proxy.

Ograniczanie ruchu

Mobilny ruch jest zwykle rozliczany, a jeden wymykający się parser może przez noc wyciągnąć dziesiątki gigabajtów. Na poziomie Dockera twardych kwot na ruch nie ma, ale są środki pośrednie: ograniczenie częstotliwości zapytań w samej aplikacji, limit czasu życia kontenera przez timeout w komendzie uruchomienia i monitoring przez docker stats, który pokazuje NET I/O dla każdego kontenera w czasie rzeczywistym. Regularnie porównuj te liczby ze statystykami w panelu dostawcy.

Logi bez sekretów

Wiele aplikacji przy starcie wypisuje zmienne środowiskowe do logu, w tym HTTP_PROXY z hasłem. Jeśli logi trafiają do scentralizowanego systemu, hasło tam wycieknie. Brama rozwiązuje i ten problem: w logach kontenerów roboczych będzie tylko gateway:8118.

Wskazówka: Raz na kwartał odnawiaj hasła proxy i aktualizuj .env. Z bramą zajmuje to minutę: poprawiasz jedną linię, robisz docker compose up -d gateway i wszystkie workery pracują dalej bez restartu.

FAQ: częste pytania o konfigurację proxy w Dockerze

Czy trzeba restartować kontener, żeby zastosować nowe zmienne proxy?

Tak. Zmienne środowiskowe ustawia się w momencie tworzenia kontenera i nie można ich zmienić w działającym. Zatrzymaj, usuń i utwórz kontener od nowa (w Compose to docker compose up -d --force-recreate nazwa_serwisu). Jeśli restarty przeszkadzają, użyj bramy: jej ustawienia można zmieniać niezależnie.

Czym różni się konfiguracja proxy dla docker pull od proxy dla aplikacji w kontenerze?

To dwa różne poziomy. docker pull wykonuje demon i dla niego proxy ustawia się w daemon.json albo przez systemd. Aplikacja w kontenerze — osobny proces z własnym środowiskiem, dla niego proxy ustawia się zmiennymi, config.json klienta albo siecią. Jedno nie zastępuje drugiego.

Czy można używać SOCKS5 zamiast proxy HTTP w zmiennych środowiskowych?

Można, jeśli aplikacja obsługuje SOCKS. curl, Python requests (z zainstalowanym pakietem PySocks), git obsługują. apt i wiele innych — nie. Uniwersalne wyjście: brama gost, która przyjmuje HTTP na wejściu i wysyła do SOCKS5 na wyjściu: -L=http://:8118 -F=socks5://user:pass@host:port.

Jak sprawdzić, jakiego proxy używa już uruchomiony kontener?

Wykonaj docker inspect -f '{{.Config.Env}}' nazwa_kontenera. Zobaczysz wszystkie zmienne środowiskowe. Do sprawdzenia faktycznego IP użyj docker exec nazwa_kontenera curl -s ifconfig.me, jeśli w kontenerze jest curl, albo wget -qO- ifconfig.me.

Dlaczego w Docker Desktop proxy działa, a na serwerze Linux te same ustawienia nie działają?

Docker Desktop stosuje ustawienia z okna Proxies jednocześnie do demona i do kontenerów. Na Linuksie to dwa osobne miejsca: daemon.json dla demona i ~/.docker/config.json dla kontenerów. Sprawdź, czy skonfigurowałeś oba, jeśli potrzebujesz obu.

Jak ustawić proxy tylko dla jednej domeny, a resztę puścić bezpośrednio?

Zmienne środowiskowe tak nie umieją: działają według zasady „wszystko przez proxy, oprócz NO_PROXY”. Jeśli potrzebna jest odwrotna logika, użyj pliku PAC po stronie aplikacji (obsługują go przeglądarki) albo reguł routingu w gost, który umie kierować ruch na różne kanały wyjściowe po domenach.

Czy bezpiecznie jest trzymać hasło do proxy w compose.yaml?

Lepiej nie. Trzymaj je w .env z prawami 600 i podstawiaj przez ${NAZWA}. Nie commituj .env do repozytorium. Na serwerach używaj bramy, żeby hasło było w jednym miejscu.

Co robić, jeśli mobilne proxy zmieniło IP i połączenia w kontenerach się zerwały?

To normalne zachowanie przy rotacji. Aplikacja powinna umieć powtarzać zapytania. Jeśli rotacja odbywa się według harmonogramu dostawcy, dowiedz się, jaki jest interwał, i zsynchronizuj z nim ciężkie operacje. Jeśli rotacja odbywa się przez Twój link, wywołuj go między paczkami zadań, a nie w ich trakcie.

Czy te ustawienia działają w Windows bez WSL2?

Docker Desktop w Windows używa pod spodem WSL2 albo Hyper-V i wszystkie komendy docker run oraz docker compose działają tak samo z PowerShell. Różnią się tylko ścieżki: plik config.json leży w C:\Users\NazwaUzytkownika\.docker\config.json, a ustawienia demona robi się przez okno Docker Desktop, a nie ręcznie w daemon.json.

Ile kontenerów można puścić przez jedno mobilne proxy?

Technicznie — ile chcesz, ograniczeniem jest tylko przepustowość kanału mobilnego i limity taryfy. Praktycznie w zadaniach z kontami rozsądnie jest trzymać jedno proxy na jedną logiczną jednostkę (konto, projekt, region), żeby zachowanie wyglądało naturalnie i błąd w jednym kontenerze nie wpływał na pozostałe.

Zakończenie: co zrobiłeś i dokąd iść dalej

Podsumujmy. Sprawdziłeś działanie proxy z hosta i ogarnąłeś format ciągu połączenia. Skonfigurowałeś proxy dla pojedynczego kontenera przez zmienne środowiskowe i plik env-file. Zrobiłeś automatyczne przekazywanie zmiennych przez config.json klienta. Rozgryzłeś, jak i po co konfigurować proxy dla samego demona Docker trzema sposobami. Opisałeś kilka serwisów z różnymi mobilnymi proxy w Docker Compose, wynosząc sekrety do .env. I wreszcie zbudowałeś kontener-bramę z izolowaną siecią — najniezawodniejsze rozwiązanie dla produkcji, które chroni przed wyciekami rzeczywistego IP, nawet jeśli aplikacja ignoruje zmienne.

Teraz proxy w Dockerze to dla Ciebie nie czarna skrzynka, a trzy zrozumiałe poziomy z jasnymi granicami: demon, kontener, sieć. Wiesz, gdzie szukać problemu, jeśli IP nagle okazało się nie to, i umiesz to sprawdzić jedną komendą.

Co robić dalej

1. Przenieś swoje projekty robocze na schemat z bramą i siecią wewnętrzną. Zacznij od jednego niekrytycznego serwisu, upewnij się, że wszystko działa, potem skaluj.
2. Dodaj kontener-monitor, który raz na minutę sprawdza zewnętrzne IP przez bramę i sygnalizuje, jeśli zbiegło się z IP serwera.
3. Skonfiguruj rotację IP według harmonogramu pod swoje zadania i naucz aplikacje przeżywać zerwanie połączenia.
4. Zapanuj nad sekretami: .env z prawami 600, żadnych haseł w compose.yaml i Dockerfile.

Dokąd się rozwijać

Następny logiczny krok to połączenie Dockera z przeglądarkami antydetekcyjnymi i narzędziami do multiaccountingu, gdzie każdemu profilowi odpowiada osobny kontener i osobne mobilne proxy. Inny kierunek to automatyzacja przez API dostawcy: pobieranie listy proxy, sprawdzanie ich statusu i rotacja prosto z Twoich serwisów. Oba tematy wykraczają poza ten przewodnik, ale fundament, który właśnie położyłeś, czyni je znacznie prostszymi. Udanych uruchomień i stabilnych IP!