Makale içeriği

Docker uzun zamandır parser'lar, bot'lar, reklam otomasyonları ve küçük servisler için standart haline geldi. Ancak konteynerlerin bir özelliği var: izole bir ortamda yaşarlar ve bilgisayarınızda yapılandırdığınız proxy'ler hakkında hiçbir şey bilmezler. Sonuç olarak konteyner içindeki script, sizin gerçek IP'nizle internete çıkar ve siz mobil proxy üzerinden çalıştığınızı sanırsınız. Bu kılavuz bu boşluğu sonsuza dek kapatıyor.

Giriş: Ne elde edeceksiniz ve bu kılavuz kimlere hitap ediyor?

Kılavuzu tamamladıktan sonra, Docker'da proxy'yi mümkün olan üç seviyede de yapılandırmayı öğreneceksiniz: ortam değişkenleri aracılığıyla tek bir konteyner için, yapılandırma dosyaları aracılığıyla tüm Docker istemcisi ve daemon'ı için ve ayrıca ayrı bir ağ geçidi konteyneri aracılığıyla ağ düzeyinde. Bu seviyelerin nasıl farklılaştığını, hangisinin ne zaman kullanılacağını ve trafiğin gerçekten proxy üzerinden gidip gitmediğini nasıl doğrulayacağınızı anlayacaksınız.

Bu adım adım kılavuz kimler için?

  • Pazarlamacılar ve SMM uzmanları: Docker'da otomatik gönderi, analitik veya izleme servisleri çalıştıran ve her aracın kendi mobil IP'siyle çalışmasını isteyenler.
  • Arbitrajcılar: onlarca tracker, teklif parser'ı ve casus servis konteynerine sahip olanlar ve her birinin ayrı bir coğrafyaya ihtiyacı olanlar.
  • Geliştiriciler: uygulamayı başka bir bölgeden test etmesi veya entegrasyon testlerini proxy üzerinden çalıştırması gerekenler.
  • İşletme sahipleri: çalışanları veya yüklenicileri altyapıyı konteynerlerde kuranlar ve orada proxy ile çalışmanın nasıl olduğunu anlaması gerekenler.

Önceden bilmeniz gerekenler

Derin bilgi varsaymıyoruz. Terminali açmayı, bir komutu kopyalamayı ve çıktısını okumayı biliyorsanız yeterli. Docker ile hiç çalışmadıysanız korkmayın: temel kavramlar bölümünde tüm terimleri basit bir dille açıklayacağız. Kubernetes, küme orkestrasyonu ve bulut platformlarına bilinçli olarak değinmiyoruz: bu ayrı bir konu ve burada kesinlikle Docker düzeyinde kalıyoruz.

Ne kadar zaman gerekecek?

Kontrollerle birlikte tam kılavuz 60 ila 120 dakika sürecek. Yalnızca bir senaryoya ihtiyacınız varsa, örneğin tek bir konteyner için proxy, 15 dakika yeterli. Docker henüz kurulu değilse 20-30 dakika kurulum ekleyin.

Ön hazırlık: araçlar, erişimler ve sistem gereksinimleri

Docker'da proxy'yi yapılandırmadan önce her şeyi toplayın. Böylece süreç ortasında kullanıcı adı aramak veya araç kurmakla oyalanmazsınız.

Neye ihtiyacınız olacak?

  1. Docker'lı bir bilgisayar veya sunucu. Linux (Ubuntu 22.04 veya 24.04, Debian 12), macOS'ta Docker Desktop veya Windows 10/11'de Docker Desktop ve WSL2 uygundur. 2026'da Docker Engine sürüm 27 ve üzeri ile docker compose komutuyla (boşluklu, tiresiz) çağrılan Docker Compose v2 günceldir.
  2. Mobil proxy verileri. Dört şeye ihtiyacınız var: ana bilgisayar adresi (IP veya alan adı), port, kullanıcı adı ve şifre. Bunları sağlayıcının kontrol panelinde bulacaksınız. Ayrıca hangi protokolün mevcut olduğunu netleştirin: HTTP veya SOCKS5. mobileproxy.space dahil çoğu mobil proxy sağlayıcısında farklı portlarda her iki seçenek de var.
  3. Terminal. Linux ve macOS'ta yerleşiktir. Windows'ta PowerShell veya WSL2 terminalini kullanın (ikinci seçenek daha uygun çünkü komutlar Linux ile aynı olacak).
  4. Metin düzenleyici. Herhangi biri: nano, vim, VS Code, Notepad++. Yapılandırma dosyalarını düzenlemek için gerekli.
  5. curl aracı. Genellikle zaten kuruludur. Hangi IP üzerinden çıktığınızı kontrol etmenize yardımcı olur.

Sistem gereksinimleri

  • Docker ve imajlar için en az 2 GB RAM ve 10 GB boş disk alanı.
  • Yönetici hakları: Linux'ta sudo erişimi, Windows ve macOS'ta Docker Desktop kurulumu için yönetici hesabı.
  • İmajları indirmek için kararlı internet bağlantısı.

Yedekler

Süreçte Docker yapılandırma dosyalarını düzenleyeceğiz. İçlerindeki bir hata Docker'ın başlamamasına neden olabilir. Bu nedenle herhangi bir dosyayı düzenlemeden önce kopyasını alın. Linux'ta tek komut:

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

Aynı şekilde ~/.docker/config.json dosyası için de. Dosya henüz yoksa yedek almanıza gerek yok, ancak sıfırdan oluşturduğunuzu not edin: o zaman geri almak için silmeniz yeterlidir.

İpucu: Proxy verilerinizin protocol://login:password@host:port formatındaki şablonunu içeren bir metin dosyası oluşturun. Bu satırı birçok kez yapıştıracaksınız ve hazır şablon yazım hatalarını önler.

Temel kavramlar: Docker nasıl çalışır ve proxy nerede bulunur?

Docker'da proxy kurulumunun sihire dönüşmemesi için terimleri anlayalım. Konteynerlerle zaten güvenle çalışıyorsanız bölümü hızlıca gözden geçirin, ancak üç proxy seviyesi alt bölümüne dikkat edin: çoğu hata tam orada gizli.

Anahtar terimler basit bir dille

  • İmaj (image) — bir şablon, "dondurulmuş" dosya ve program kümesi. Örneğin Python içeren bir imaj veya tarayıcı içeren bir imaj.
  • Konteyner (container) — bir imajın çalışan kopyası. Bir imajdan istediğiniz kadar konteyner başlatabilirsiniz ve her biri diğerlerinden izole olur.
  • Docker daemon (daemon, dockerd) — konteynerleri oluşturan, imajları indiren ve ağları yöneten arka plan hizmeti. docker pull yazdığınızda imajlar için internete giden tam da bu daemon'dır.
  • Docker istemcisi (docker CLI) — terminaldeki docker komutu. Emirlerinizi daemon'a iletir.
  • Ortam değişkenleri (environment variables) — konteyner içindeki programların erişebildiği adlandırılmış değerler. Örneğin HTTP_PROXY=http://user:pass@host:port. Birçok program bu tür değişkenleri otomatik okur ve belirtilen proxy üzerinden gitmeye başlar.
  • Docker ağı (network) — konteynerleri birbirine bağlayan sanal ağ. Aynı kullanıcı tanımlı ağdaki konteynerler birbirlerini isimleriyle görür.
  • Docker Compose — birden fazla konteyneri, değişkenlerini ve ağlarını tek bir YAML dosyasında tanımlayan ve tek komutla başlatan araç.

Docker'da üç proxy seviyesi

Bu teorinin en önemli kısmı. "Docker'da proxy" dendiğinde üç tamamen farklı şey kastedilebilir ve bunlar farklı şekillerde yapılandırılır.

  1. Daemon için proxy. Docker'ın kendisinin proxy üzerinden imaj indirmesi için gereklidir. Bu, docker pull ve docker build komutlarının temel imajları çekmesiyle ilgilidir. Konteynerlerinizdeki uygulamaların trafiğini bu seviye etkilemez.
  2. Ortam değişkenleri aracılığıyla konteynerler için proxy. Konteynerin içine HTTP_PROXY, HTTPS_PROXY ve NO_PROXY iletilir ve uygulama bunları kullanıp kullanmayacağına kendisi karar verir. En popüler ve basit yöntemdir, ancak yalnızca bu değişkenlere saygı duyan programlarla çalışır.
  3. Ağ düzeyinde proxy. Konteyner trafiği başka bir ağ geçidi konteyneri veya özel olarak yapılandırılmış bir ağ üzerinden yönlendirilir. İçerideki uygulama proxy'den tamamen habersiz olabilir. Bu daha güvenilirdir ancak daha fazla yapılandırma gerektirir.

Başlamadan önce anlaşılması gerekenler

Proxy'li ortam değişkenleri program için yalnızca bir öneridir. curl, pip paket yöneticisi, Python'daki requests kütüphanesi, global-agent paketli Node.js, wget, apt — hepsi HTTP_PROXY'yi okur. Ancak headless moddaki tarayıcılar, bazı Go uygulamaları ve birçok ikili araç değişkenleri görmezden gelebilir. Bu nedenle yapılandırma sonrası her zaman gerçek harici IP'yi kontrol edin, değişkenin ayarlandığına güvenmeyin.

Bir başka incelik de büyük/küçük harf duyarlılığıdır. Tarihsel olarak bazı programlar küçük harfli http_proxy'yi, bazıları büyük harfli HTTP_PROXY'yi okur. Güvenilir uygulama her ikisini aynı anda tanımlamaktır. NO_PROXY değişkeni, proxy kullanılmaması gereken adresleri listeler: localhost, 127.0.0.1, iç alan adları, komşu konteyner adları.

Son olarak proxy adresi formatı. HTTP proxy için satır http://login:password@host:port şeklindedir. SOCKS5 için — socks5://login:password@host:port veya socks5h://login:password@host:port. Sondaki h harfi DNS sorgularının da proxy üzerinden gittiği anlamına gelir ve mobil proxy'ler için genellikle tercih edilir: böylece hedef site sağlayıcınızın DNS çözümleyicisini görmez.

Adım 1: Docker'ı kontrol ediyoruz ve proxy verilerini hazırlıyoruz

Aşamanın amacı: Docker'ın çalıştığından ve proxy verilerinizin doğru ve bu bilgisayardan erişilebilir olduğundan emin olmak. Bu kontrol olmadan, sorun şifrede bir yazım hatasıyken yarım saat yapılandırmada hata arayabilirsiniz.

Docker kontrolü

  1. Terminali açın.
  2. docker --version komutunu girin ve Enter'a basın. Docker version 27.x.x gibi bir satır görmelisiniz. Terminal komutun bulunamadığını yazarsa Docker kurulu değildir: resmi belgelere göre Docker Desktop (Windows, macOS) veya Docker Engine (Linux) kurun ve buraya dönün.
  3. docker compose version komutunu girin. Beklenen çıktı: Docker Compose version v2.x.x.
  4. docker run --rm hello-world komutunu girin. Docker küçük bir test imajı indirecek ve Hello from Docker kelimelerini içeren bir karşılama yazacaktır. Bu, daemon'ın çalıştığı ve konteyner başlatma izniniz olduğu anlamına gelir.

İpucu: Linux'ta docker komutu sudo gerektiriyorsa kendinizi docker grubuna ekleyin: sudo usermod -aG docker $USER, ardından oturumu kapatıp yeniden açın. Bundan sonra kılavuzdaki tüm komutlar sudo olmadan çalışacaktır.

Proxy'yi ana makineden kontrol etme

Proxy'yi konteynere taşımadan önce, yanıt verip vermediğini kontrol edelim. Örnek yerine kendi verilerinizi koyun. Örneklerde 185.10.10.10 adresini, HTTP için 1050 portunu, SOCKS5 için 1051 portunu, user123 kullanıcı adını ve secret şifresini kullanacağız. Sizde elbette kendi değerleriniz olacak.

  1. Önce normal IP'nizi proxy'siz öğrenin: curl -s ifconfig.me. Sonucu not edin veya aklınızda tutun.
  2. Şimdi HTTP proxy üzerinden sorgu: curl -s -x http://user123:secret@185.10.10.10:1050 ifconfig.me
  3. SOCKS5'iniz varsa: curl -s -x socks5h://user123:secret@185.10.10.10:1051 ifconfig.me
  4. Sonucu 1. adımla karşılaştırın. IP farklı olmalı ve bir mobil operatöre ait olmalı.

Şifredeki özel karakterler

Kullanıcı adında veya şifrede @, :, /, #, ? veya boşluk karakterleri varsa URL biçiminde kodlanmaları gerekir, aksi halde proxy satırı bozulur. @ işareti %40, : %3A, / %2F, # %23, ? %3F, boşluk %20 olur. Örneğin pa@ss şifresi proxy satırında pa%40ss olarak yazılır.

✅ Kontrol: Proxy üzerinden curl komutu ev IP'nizden farklı bir IP döndürdü ve yanıt bir-üç saniyede geldi. 407 hatası alırsanız kullanıcı adı ve şifreyi kontrol edin. Connection refused veya zaman aşımı — ana bilgisayar, portu ve sağlayıcı kontrol panelinde mevcut IP'nizin beyaz listeye eklenip eklenmediğini kontrol edin (bazı tarifelerde IP ile yetkilendirme varsayılan olarak açıktır).

Adım 2: Ortam değişkenleri aracılığıyla tek bir konteyner için proxy kurma

Aşamanın amacı: tüm HTTP trafiği mobil proxy üzerinden giden bir konteyner başlatmak ve harici IP'den bunu doğrulamak. Bu, herkesin başlaması gereken temel senaryodur: sistem ayarlarına dokunmaz ve kolayca geri alınır.

-e bayrağıyla başlatma

docker run komutunun -e (veya --env) bayrağı, ortam değişkenini konteynerin içine iletir. Hemen dört değişken ileteceğiz: HTTP için proxy, HTTPS için proxy ve istisnalar, her biri iki büyük/küçük harf biçiminde.

  1. Aşağıdaki komutu düzenleyiciye kopyalayın ve proxy verilerini kendinizinkiyle değiştirin.
  2. Komutu terminalde çalıştırın. Bu, curl içeren geçici bir konteyner başlatacak, bir sorgu yapacak ve sonlanacaktır.
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

Dikkat: HTTPS_PROXY için de başında http:// belirtiyoruz. Bu bir hata değil. Bu, HTTPS isteklerinin hangi proxy üzerinden gideceğini belirtir, proxy sunucusuyla bağlantının kendisi normaldir. HTTPS_PROXY değerinde https:// şeması, proxy'nin kendisine TLS üzerinden bağlanılması gerektiği anlamına gelirdi ki bu çoğu sağlayıcı tarafından desteklenmez.

Uzun komut yerine değişken dosyası

Komut hantal oldu. Docker, --env-file bayrağıyla değişkenleri dosyadan okumayı bilir. Bu daha kullanışlı ve daha güvenlidir: şifre terminal geçmişinde kalmaz.

  1. Çalışma klasöründe proxy.env dosyası oluşturun: nano proxy.env
  2. İçine satır başına bir değişken yazın, tırnaksız ve eşittir işareti etrafında boşluk olmadan:
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

Gerçek dosyada her değişken ayrı bir satırda olmalıdır. Dosyayı kaydedin (nano'da Ctrl+O, Enter, ardından Ctrl+X) ve konteyneri başlatın:

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

Çalışan konteynerin içinden kontrol

Genellikle uzun ömürlü bir konteynerin ne gördüğüne bakmak gerekir. Alpine Linux'u etkileşimli modda başlatalım ve değişkenleri kontrol edelim.

  1. docker run -it --rm --env-file proxy.env alpine sh komutunu çalıştırın. Konteynerin içinde olacaksınız, istem kare veya dolar işaretine dönüşecek.
  2. env | grep -i proxy yazın. Değişkenlerinizin listesini göreceksiniz.
  3. apk add --no-cache curl yazın. apk paket yöneticisi https_proxy'yi kendisi kullanacak ve paketi proxy üzerinden indirecek.
  4. curl -s ifconfig.me yazın ve IP'nin mobil olduğundan emin olun.
  5. Çıkmak için exit yazın. Konteyner --rm bayrağı sayesinde otomatik silinecek.

İpucu: IP kontrolü için ifconfig.me'nin yanı sıra ülke, şehir ve sağlayıcı hakkında JSON döndüren servisleri kullanmak uygundur. Böylece IP'nin sadece "başka bir" değil, doğru bölgedeki bir mobil operatöre ait olduğunu hemen görürsünüz.

✅ Kontrol: curl ile her iki başlatma da mobil proxy IP'sini döndürdü. Konteyner içindeki env komutu HTTP_PROXY ve HTTPS_PROXY değişkenlerini verilerinizle gösterdi.

Bu adımda olası sorunlar

  • IP değişmedi. Konteynerdeki uygulama proxy ortam değişkenlerini görmezden geliyor. curl için bu olmaz, bu nedenle curl mobil IP gösterirken uygulamanız göstermiyorsa 6. adımdaki ağ yöntemine geçin.
  • invalid reference format hatası. Genellikle komutta fazladan boşluk veya satır sonu vardır. Komutu tek satırda toplayın.
  • Değişkenler görünmüyor. env-file dosyasında değerlerin etrafında tırnak olmamalıdır: Docker bunları olduğu gibi iletir ve proxy adresi geçersiz hale gelir.

Adım 3: Değişkenlerin otomatik iletilmesi için Docker istemcisi için proxy kurma

Aşamanın amacı: her yeni konteynerin ve her imaj derlemesinin -e bayrağı olmadan proxy değişkenlerini otomatik almasını sağlamak. Aynı mobil proxy üzerinden sürekli farklı konteynerler başlatıyorsanız bu size zaman kazandırır.

Nasıl çalışır?

Docker istemcisi ~/.docker klasöründeki config.json dosyasını okur (Windows'ta bu, kullanıcı profilindeki .docker klasörüdür). İçinde proxies bölümü varsa istemci her docker run ve docker build sırasında belirtilen değişkenleri konteynere ekler. Daemon bundan etkilenmez, bu nedenle docker pull yine doğrudan gider.

Adım adım yapılandırma

  1. Dosyanın olup olmadığını kontrol edin: cat ~/.docker/config.json. Dosya varsa ve içinde zaten ayarlar varsa (örneğin kayıt defteri giriş bilgilerini içeren auths), kopyasını alın: cp ~/.docker/config.json ~/.docker/config.json.bak
  2. Dosyayı düzenleyicide açın: nano ~/.docker/config.json. Dosya yoksa düzenleyici oluşturacaktır.
  3. proxies bölümünü ekleyin. Dosya boşsa tamamı şu şekilde olacaktır:
{ "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" } } }

Dosyada başka anahtarlar varsa, mevcutları silmeden proxies'i virgülle ayrılmış başka bir üst düzey anahtar olarak ekleyin. Süslü parantezlerin ve tırnakların eşleşmesine dikkat edin: JSON eksik virgülü affetmez.

  1. Dosyayı kaydedin.
  2. Sözdizimini kontrol edin. Linux ve macOS'ta şöyle uygundur: python3 -m json.tool ~/.docker/config.json. Çıktı dosyanızı güzel biçimlendirilmiş olarak tekrarlıyorsa her şey yolundadır. Satır numarası içeren bir hata çıkarsa düzeltin.
  3. Herhangi bir bayrak olmadan test konteynerini başlatın: docker run --rm curlimages/curl -s ifconfig.me. IP mobil olmalıdır.
  4. Herhangi bir konteynerin değişkenlerini görün: docker run --rm alpine env. Çıktıda HTTP_PROXY, HTTPS_PROXY, NO_PROXY ve küçük harfli varyantları olacaktır: Docker her iki biçimi de kendisi ekler.

⚠ Dikkat: config.json'daki proxies bölümü, bu kullanıcıdan başlattığınız tüm konteynerleri etkiler; veritabanları, yerel web sunucuları ve diğer her şey dahil. Bir servis, proxy'niz üzerinden erişilemeyen bir harici API ile iletişim kuruyorsa bozulur. Bu tür adresleri noProxy'ye ekleyin veya bölümü geçici olarak kaldırın.

Farklı bağlantılar için farklı proxy'ler

default anahtarı daemon'a tüm bağlantılara uygulanır. Birden fazla Docker ana makinesini bağlamlar veya DOCKER_HOST değişkeni aracılığıyla yönetiyorsanız, default yerine belirli daemon adresini belirtebilirsiniz, örneğin tcp://192.168.1.50:2376, ve proxy yalnızca ona uygulanır. Yerel çalışma için default yeterlidir.

İmaj derlerken proxy

config.json'daki ayarlar docker build'e derleme argümanları olarak da iletilir. Bu, Dockerfile içindeki RUN apt-get install veya RUN pip install komutlarının proxy üzerinden gideceği anlamına gelir. Önemli nokta: bu değişkenler nihai imajda saklanmaz, bu güvenlik açısından iyidir: proxy şifresi imajı paylaştığınız kişilere sızmaz.

İpucu: Proxy'yi config.json'a dokunmadan yalnızca tek bir derleme için iletmek isterseniz, 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 . bayraklarını kullanın. Docker bu önceden tanımlı argümanları Dockerfile'da ARG bildirimi olmadan anlar.

✅ Kontrol: -e bayrağı olmadan başlatılan konteyner proxy IP'siyle internete çıkıyor. docker run --rm alpine env komutu proxy değişkenlerini gösteriyor.

Nasıl geri alınır?

config.json'dan proxies bölümünü silin veya dosyayı yedekten geri yükleyin: cp ~/.docker/config.json.bak ~/.docker/config.json. Yeniden başlatma gerekmez, değişiklikler bir sonraki konteyner başlatmada uygulanır.

Adım 4: İmajların proxy üzerinden indirilmesi için Docker daemon'ı için proxy kurma

Aşamanın amacı: Docker'ın kendisini (daemon) imajlar için proxy üzerinden gitmeye zorlamak. Bu, sunucunuzdan imaj kayıt defterine doğrudan erişim kurumsal politika tarafından kısıtlandığında, yavaş olduğunda veya sunucunun tüm ağ etkinliğinin tek bir kanaldan gitmesini istediğinizde gereklidir. Pazarlama görevleri için bu adım genellikle gerekli değildir, ancak bilmeye değer: daemon düzeyindeki hatalar düzenli olarak konteyner düzeyindeki hatalarla karıştırılır.

Yöntem 1: daemon.json dosyası (Linux, Docker 23 ve üzeri)

  1. Kopya alın: sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak (dosya yoksa komut hata verir, bu normaldir).
  2. Dosyayı açın: sudo nano /etc/docker/daemon.json
  3. proxies bölümünü ekleyin:
{ "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" } }

Burada anahtarların tireli ve küçük harfli yazıldığına dikkat edin: bu, istemcinin config.json'undan farklıdır, orada anahtarlar httpProxy tarzındadır. Bunları karıştırmak klasik bir hatadır.

  1. Dosyayı kaydedin ve daemon'ı yeniden başlatın: sudo systemctl restart docker
  2. Daemon'ın başladığını kontrol edin: sudo systemctl status docker. Çıktıda active (running) olmalıdır.
  3. Uygulandığını kontrol edin: docker info | grep -i proxy. HTTP Proxy ve HTTPS Proxy satırlarını adresinizle göreceksiniz, ancak şifre çıktıda yıldızlarla gizlenir.

Yöntem 2: systemd drop-in dosyası (Linux, her sürüm)

Bu, eski Docker sürümlerinde bile çalışan klasik yöntemdir.

  1. Klasör oluşturun: sudo mkdir -p /etc/systemd/system/docker.service.d
  2. Dosya oluşturun: sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf
  3. İçeriği yazın, her direktif kendi satırında:
[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. Kaydedin, ardından systemd yapılandırmasını yeniden okuyun: sudo systemctl daemon-reload
  2. Docker'ı yeniden başlatın: sudo systemctl restart docker
  3. Kontrol edin: sudo systemctl show --property=Environment docker. Çıktıda değişkenleriniz olacaktır.

⚠ Dikkat: Daemon proxy'sini aynı anda iki yöntemle yapılandırmayın. Hem daemon.json hem systemd dosyası farklı adresler içeriyorsa davranış öngörülemez hale gelir ve hata ayıklama işkenceye dönüşür. Bir yöntem seçin ve ona bağlı kalın.

Yöntem 3: Docker Desktop (Windows ve macOS)

  1. Docker Desktop'ı açın, sağ üst köşedeki dişli simgesine tıklayın.
  2. Sol menüden Resources, ardından Proxies'i seçin.
  3. Manual proxy configuration anahtarını açık konuma getirin.
  4. Web Server (HTTP) ve Secure Web Server (HTTPS) alanlarına proxy adresini http://user123:secret@185.10.10.10:1050 biçiminde yapıştırın.
  5. Bypass proxy settings for these hosts alanına localhost,127.0.0.1 yazın.
  6. Apply and restart'a tıklayın. Docker Desktop yeniden başlayacak, bu 30-60 saniye sürer.

Docker Desktop bu ayarları hem daemon'a hem konteynerlere aynı anda uygular, bu nedenle masaüstü sistemlerde ayrı config.json düzenlemesi genellikle gerekli değildir.

Sonucu kontrol etme

  1. Varsa küçük bir imajı silin: docker rmi alpine
  2. Yeniden indirin: docker pull alpine. İndirme başarılı olmalıdır.
  3. Proxy tarafında trafik istatistikleri varsa (mobileproxy.space kontrol panelinde var), tüketilen trafik hacminin birkaç megabayt arttığını göreceksiniz.

✅ Kontrol: docker info proxy adresini gösteriyor, docker pull imajları hatasız indiriyor, docker servisi active durumunda.

Olası sorunlar

  • daemon.json düzenlemesinden sonra Docker başlamıyor. Neredeyse her zaman suçlu JSON sözdizimidir. Dosyayı python3 -m json.tool /etc/docker/daemon.json komutuyla kontrol edin veya kopyayı geri yükleyin.
  • docker pull takılıyor. Proxy, kayıt defterine bağlantılara izin vermiyor veya tarifedeki trafik limiti aşıldı. Proxy'yi 1. adımdaki gibi ana makineden curl ile kontrol edin.
  • x509 certificate hatası. Proxy sertifikaları değiştiriyor (kurumsal proxy'ler için geçerlidir, mobil proxy'ler için bu nadirdir). Sağlayıcınıza danışın.

Adım 5: Docker Compose'da proxy kurma

Aşamanın amacı: proxy'yi compose.yaml dosyasında tanımlamak, böylece bir konteyner grubunun tek komutla gerekli ayarlarla başlatılması ve farklı servislerin farklı mobil proxy'ler kullanabilmesi. Bu senaryo en çok arbitrajcılar ve pazarlamacılar tarafından istenir: bir parser Moskova proxy'si üzerinden çalışır, ikincisi Kazan proxy'si üzerinden, veritabanı ise proxy'siz.

Projeyi hazırlama

  1. Proje klasörünü oluşturun ve içine girin: mkdir proxy-demo, ardından cd proxy-demo
  2. Gizli bilgileri saklamak için .env dosyası (başında nokta ile) oluşturun: nano .env
  3. Değişkenleri satır başına bir tane yazın:
PROXY_MSK=http://user123:secret@185.10.10.10:1050 PROXY_KZN=http://user456:secret2@185.10.10.20:1050

Compose .env dosyasını otomatik okur ve içindeki değerler compose.yaml'a ${İSİM} sözdizimiyle yerleştirilebilir. Proje sürüm kontrolü altındaysa .env'yi .gitignore'a ekleyin: şifreler depoya girmemelidir.

compose.yaml dosyası

compose.yaml dosyasını oluşturun (nano compose.yaml) ve üç servisi tanımlayın. YAML'da girintiler önemlidir: seviye başına iki boşluk kullanın, sekme değil.

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

Burada gerçek dosyada her satır doğru girintilerle ayrı ayrı durur: services sıfır düzeyinde, servis adları iki boşluk girintili, parametreleri dört, ortam değişkenleri altı boşluk girintili. NO_PROXY'deki db adına dikkat edin: böylece parser'lar veritabanına Docker iç ağı üzerinden doğrudan erişecek, mobil proxy üzerinden ulaşmaya çalışmayacak, ki bu kesinlikle işe yaramaz.

Başlatma ve kontrol

  1. Compose'un değişkenleri nasıl yerleştirdiğini kontrol edin: docker compose config. Komut, değerleri açılmış nihai dosyayı gösterecektir. ${PROXY_MSK} yerine gerçek adresin olduğundan emin olun.
  2. Başlatın: docker compose up. Compose imajları indirecek ve üç servisi de başlatacak, loglarını terminale yazacaktır.
  3. Loglarda parser-msk-1 | 91.xxx.xxx.xxx ve parser-kzn-1 | 176.xxx.xxx.xxx gibi satırlar göreceksiniz: iki farklı proxy'den iki farklı IP. Postgres başlayacak ve bağlantıları bekleyecektir.
  4. Ctrl+C ile hepsini durdurun, ardından konteynerleri silin: docker compose down

Alternatif: her servis için env_file

Çok sayıda değişken varsa, environment bloğu yerine dosya belirtmek daha uygundur:

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

proxy-msk.env dosyası bu durumda 2. adımdaki proxy.env ile aynı altı satırı içerir. Böylece her proxy kendi dosyasında durur ve compose.yaml'ı açmadan değiştirebilirsiniz.

Compose'da derleme sırasında proxy

Servis hazır yerine Dockerfile'dan derleniyorsa, proxy'yi build.args aracılığıyla derlemeye iletin:

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

Böylece Dockerfile içindeki pip, npm veya apt proxy üzerinden çalışır ve değerler nihai imaja girmez.

İpucu: Compose birden fazla dosyayı destekler. Proxy'siz temel compose.yaml'ı tutun, compose.proxy.yaml'da yalnızca environment bloklarını tanımlayın. Proxy gerektiğinde docker compose -f compose.yaml -f compose.proxy.yaml up, gerekmediğinde sadece docker compose up çalıştırın. Hata ayıklarken kullanışlıdır: bir saniyede modlar arasında geçiş yaparsınız.

✅ Kontrol: docker compose config yerleştirilmiş proxy adreslerini gösteriyor ve docker compose up loglarında farklı proxy'li servisler farklı IP'ler yazdırıyor.

Adım 6: Ağ geçidi konteyneri aracılığıyla ağ düzeyinde proxy kurma

Aşamanın amacı: Docker ağındaki komşulardan bağlantı kabul eden ve bunları mobil proxy'ye yönlendiren ayrı bir konteyner başlatmak. Diğer konteynerler ağ geçidine isimle erişir ve kendi içlerinde kullanıcı adı ve şifre tutmaz. Bu aynı anda üç sorunu çözer: proxy yönetimini merkezileştirir, şifreleri onlarca yapılandırmadan kaldırır ve çalışan konteynerleri yeniden başlatmadan proxy'yi değiştirmenize olanak tanır.

Değişkenler varken neden ağ geçidi gerekli?

Yirmi parser konteyneriniz olduğunu ve sağlayıcının yeni bir port verdiğini düşünün. Ortam değişkenleriyle yirmi yapılandırmayı düzeltip hepsini yeniden başlatmanız gerekir. Ağ geçidiyle tek bir yerde tek bir satırı değiştirirsiniz. Ayrıca bazı uygulamalar proxy'de kullanıcı adı ve şifreyle yetkilendirmeyi desteklemez, ancak yetkilendirmesiz proxy ile mükemmel çalışır. Kapalı Docker ağı içindeki ağ geçidi yetkilendirme gerektirmez ve kendisi mobil proxy'ye zaten sizin verilerinizle bağlanır.

Ağ oluşturma

  1. Kullanıcı tanımlı ağ oluşturun: docker network create proxynet
  2. Oluştuğunu doğrulayın: docker network ls. Listede bridge sürücülü proxynet olacaktır.

Kullanıcı tanımlı ağ gerekir çünkü isim çözümlemesi yalnızca onda çalışır: konteyner ağ geçidine her yeniden başlatmada değişen IP yerine gateway adıyla erişebilir.

Ağ geçidini başlatma

Ağ geçidi olarak, bir protokolde bağlantı kabul edip yetkilendirmeyle başka bir protokole yönlendirebilen kompakt proxy sunucusu gost'u kullanacağız. İmaj, genel kayıt defterinde gogost/gost adıyla mevcuttur.

  1. Ağ geçidi konteynerini başlatın:
docker run -d --name gateway --network proxynet --restart unless-stopped gogost/gost -L=http://:8118 -F=http://user123:secret@185.10.10.10:1050

Parametreleri inceleyelim. -d bayrağı konteyneri arka planda başlatır. --name gateway bayrağı komşuların ona erişeceği adı belirler. --network proxynet bayrağı onu ağımıza bağlar. --restart unless-stopped bayrağı sunucu yeniden başlatıldıktan sonra ağ geçidini ayağa kaldırır. -L=http://:8118 parametresi gost'a 8118 portunda yetkilendirmesiz HTTP proxy bağlantıları kabul etmesini söyler. -F parametresi nereye yönlendireceğini belirtir: kullanıcı adı ve şifreli mobil proxy'nize.

  1. Ağ geçidinin çalıştığını kontrol edin: docker logs gateway. Logda sunucunun 8118 portunu dinlediğine dair hatasız bir satır olmalıdır.

⚠ Dikkat: Doğrudan gerekli değilse ağ geçidi portunu -p bayrağıyla dışarı açmayın. Ağ geçidi yetkilendirmesiz çalışır ve genel bir sunucuda açık 8118 portu, internetteki herkesin mobil proxy'nizi kullanabileceği ve trafiğinizi tüketebileceği anlamına gelir. proxynet ağı içinde yalnızca konteynerlerinize erişilebilir ve bu yeterlidir.

Çalışan konteynerleri bağlama

  1. Aynı ağda, ağ geçidini proxy olarak belirterek test konteynerini başlatın:
docker run --rm --network proxynet -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 curlimages/curl -s ifconfig.me
  1. Mobil proxy IP'sini görmelisiniz. Dikkat edin: değişkenlerde ne kullanıcı adı ne şifre ne de gerçek proxy adresi var. Tüm bunları yalnızca ağ geçidi bilir.

Aynısı Compose'da

Kalıcı çalışma için ağ geçidini ve çalışan servisleri tek compose.yaml'da tanımlayın:

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

depends_on direktifi ağ geçidinin worker'dan önce başlamasını garanti eder. PROXY_MSK değeri 5. adımdaki gibi .env dosyasından alınır.

Birden fazla coğrafya için birden fazla ağ geçidi

Farklı konteyner grupları için farklı proxy'ler mi istiyorsunuz? Birkaç ağ geçidi başlatın: gateway-msk, gateway-kzn, gateway-spb, her biri kendi -F'siyle. Çalışan konteynerler HTTP_PROXY'de sadece gerekli adı belirtir. Daha ileri gidip her coğrafya için ayrı ağ oluşturabilirsiniz, o zaman Moskova grubundaki konteynerler fiziksel olarak kazara Kazan ağ geçidine giremez.

İzolasyon: doğrudan internet erişimi olmayan konteyner

En katı seçenek — çalışan konteynerin ağ geçidi dışında herhangi bir internet erişimini yasaklamak. Bunun için --internal bayrağıyla iç ağ oluşturun: docker network create --internal isolated. Böyle bir ağdaki konteynerlerin dışarıya rotası yoktur. Ağ geçidini aynı anda iki ağa bağlayın (isolated ve normal proxynet), worker'ları ise yalnızca isolated'a bağlayın. Artık uygulama proxy değişkenlerini görmezden gelse bile doğrudan internete çıkamaz ve gerçek IP sızıntısı olmaz.

  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. Kontrol için aynı konteyneri proxy değişkenleri olmadan çalıştırın: docker run --rm --network isolated curlimages/curl -s -m 5 ifconfig.me. Sorgu zaman aşımıyla sonuçlanmalıdır: doğrudan çıkış yok.

İpucu: İç ağ ve ağ geçidi kombinasyonu, çoklu hesap çalışmasında sızıntılara karşı en iyi güvencedir. Geliştirici yeni bir servise proxy yazmayı unutsa bile, o servis sunucunun IP'sini gösteremez: ya ağ geçidinden gider ya da hiçbir yere gitmez.

✅ Kontrol: proxynet ağındaki konteyner HTTP_PROXY=http://gateway:8118 değişkeniyle mobil proxy IP'sini gösteriyor. İç ağdaki konteyner proxy'siz internete hiç çıkamıyor.

Olası sorunlar

  • Could not resolve host: gateway. Çalışan konteyner yanlış ağda veya isimlerin çözümlenmediği varsayılan ağda başlatılmış. --network bayrağını kontrol edin.
  • Ağ geçidi yeniden başlıyor. -F satırında hata: şifrede yazım hatası veya yanlış port. docker logs gateway'e bakın.
  • Yavaş. Mobil proxy'ler doğası gereği veri merkezi proxy'lerinden yavaştır, ancak gecikme onlarca saniyeyle ölçülüyorsa DNS'in baypas edilip edilmediğini kontrol edin: sağlayıcı SOCKS5 veriyorsa -F satırında socks5 yerine socks5h kullanın.

Sonucu kontrol etme: çalışan Docker proxy'si için kontrol listesi

Listeyi gözden geçirin. Her madde işaretliyse, Docker'da proxy kurulumunu pratikte tamamen öğrenmişsiniz demektir.

Kontrol listesi

  • Ana makineden proxy üzerinden curl mobil IP döndürüyor.
  • --env-file proxy.env bayraklı konteyner mobil IP döndürüyor.
  • config.json yapılandırmasından sonra bayraksız konteyner mobil IP döndürüyor (3. adımı yaptıysanız).
  • docker info proxy adresini gösteriyor ve docker pull çalışıyor (4. adımı yaptıysanız).
  • docker compose up servisleri başlatıyor ve loglarda farklı proxy'ler için farklı IP'ler görünüyor.
  • Ağ geçidi konteyneri çalışıyor, komşular onun üzerinden kullanıcı adı ve şifre olmadan çıkıyor.
  • İç ağdaki konteyner proxy'siz internete çıkamıyor.

Baştan sona nasıl test edilir?

  1. Uzun ömürlü bir konteyner başlatın: docker run -d --name test --network proxynet -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 alpine sleep 3600
  2. İçine girin: docker exec -it test sh
  3. curl'ü kurun: apk add --no-cache curl. Kurulum proxy üzerinden gerçekleşmelidir.
  4. Art arda beş sorgu yapın: for i in 1 2 3 4 5; do curl -s ifconfig.me; echo; done. Beşi de mobil IP döndürmelidir. Proxy'nizde otomatik rotasyon açıksa, IP'ler sorgular arasında farklı olabilir, bu normaldir.
  5. Çıkın (exit) ve konteyneri silin: docker rm -f test

Başarı göstergeleri

Başarılı yapılandırma, üç soruyu bir saniyede yanıtlayabildiğiniz anlamına gelir: belirli bir konteyner hangi IP üzerinden çıkıyor, proxy şifresi nerede saklanıyor ve bir konteyneri başka bir proxy'ye geçirmek için neyi değiştirmek gerekiyor. Her sorunun yanıtı açıksa hedefe ulaşılmıştır.

Docker'da proxy kurarken sık yapılan hatalar ve çözümleri

Hata 1: Değişkenler ayarlanmış olmasına rağmen IP değişmiyor

Neden: Konteyner içindeki uygulama proxy ortam değişkenlerini okumuyor. Bu, headless tarayıcılar, bazı Go programları ve kendi ağ yığınlarını kullanan araçlar için tipiktir.

Çözüm: Uygulamanın belgelerinde kendi proxy bayrağını olup olmadığını kontrol edin (tarayıcılarda genellikle --proxy-server'dır). Bayrak yoksa 6. adımdaki ağ geçidi ve iç ağı kullanın veya ileri düzey bölümündeki şeffaf proxy'yi kullanın.

Hata 2: 407 Proxy Authentication Required

Neden: Yanlış kullanıcı adı veya şifre ya da bunlardaki özel karakterler kodlanmamış ya da proxy'de IP yetkilendirmesi açık ve sunucu IP'si beyaz listede değil.

Çözüm: Verileri ana makineden curl ile kontrol edin. Özel karakterleri kodlayın. Sunucu IP'sini kontrol panelindeki beyaz listeye ekleyin veya proxy'yi kullanıcı adı ve şifre yetkilendirmesine geçirin.

Hata 3: daemon.json düzenlemesinden sonra Docker başlamıyor

Neden: JSON'da sözdizimi hatası: fazladan virgül, eksik tırnak, daemon.json tarzı yerine config.json tarzı anahtarlar.

Çözüm: Günlüğe bakın: sudo journalctl -u docker -n 50. Hatanın olduğu satır belirtilecektir. Düzeltin veya yedek kopyayı geri yükleyip servisi yeniden başlatın.

Hata 4: Konteynerler birbirini göremez oldu

Neden: config.json'daki global proxy yapılandırmasından sonra komşu konteynerlere yapılan istekler de mobil proxy üzerinden gitti ve proxy db veya redis'in ne olduğunu bilmiyor.

Çözüm: Servis adlarını ve iç alt ağları NO_PROXY'ye ekleyin: localhost,127.0.0.1,db,redis,172.16.0.0/12. Alt ağ maskelerini tüm programların anlamadığını unutmayın, bu nedenle adları açıkça listelemek daha güvenilirdir.

Hata 5: docker build apt-get veya pip'te başarısız oluyor

Neden: Derleme proxy'siz gidiyor çünkü değişkenler derleme için değil konteynerler için ayarlanmış veya daemon proxy'si yapılandırılmış ama RUN adımlarını etkilemiyor.

Çözüm: --build-arg HTTP_PROXY ve HTTPS_PROXY iletin veya istemcinin config.json'undaki proxies bölümünü yapılandırın: derlemeye de yayılır.

Hata 6: Proxy şifresi docker inspect ve loglarda görünüyor

Neden: Ortam değişkenleri konteyner meta verilerinde açıkça saklanır ve Docker'a erişimi olan herkes bunları docker inspect ile görebilir.

Çözüm: Ağ geçidini kullanın: çalışan konteynerler yalnızca gateway:8118 adresini bilir. Şifre tek bir konteynerde ve kısıtlı izinli .env dosyasında kalır (chmod 600 .env).

Hata 7: Sunucu yeniden başlatıldıktan sonra proxy çalışmayı durdurdu

Neden: Ağ geçidi konteyneri yeniden başlatma politikasıyla başlatılmadı veya mobil proxy'nin ana bilgisayar IP adresi değişti.

Çözüm: Ağ geçidine --restart unless-stopped ekleyin. Sağlayıcı sağlıyorsa proxy IP'si yerine alan adını kullanın. docker ps -a kontrol edin: ağ geçidi Exited durumundaysa loglarına bakın.

Hata 8: HTTPS siteleri açılmıyor ama HTTP çalışıyor

Neden: Yalnızca HTTP_PROXY ayarlanmış, HTTPS_PROXY boş ya da HTTPS_PROXY'de https:// yerine http:// şeması belirtilmiş.

Çözüm: Her zaman her iki değişkeni de aynı değer ve http:// şemasıyla ayarlayın.

İleri düzey kullanıcılar için ek olanaklar: şeffaf proxy, IP rotasyonu ve güvenlik

Bu bölüm, temel adımları tamamlayan ve Docker ile mobil proxy kombinasyonundan maksimum verim almak isteyenler için. Burada daha az adım adım liste, daha çok anahtar komutlarla fikirler var.

Şeffaf proxy: uygulama proxy'den tamamen habersizken

Proxy ile hiçbir şekilde çalışamayan bir uygulamanız varsa, tüm TCP trafiğini ağ yığını düzeyinde yönlendirebilirsiniz. Fikir şu: çalışan konteyner network_mode: service:gateway (Compose'da) veya --network container:gateway (docker run'da) parametresiyle başlatılır. Böylece ağ geçidi konteynerinin ağ yığınını bir bütün olarak kullanır: aynı IP, aynı arayüzler, aynı yönlendirme kuralları.

Ağ geçidinde ise redsocks gibi bir program yerel portu dinler ve bağlantıları SOCKS5 proxy'ye yönlendirir, iptables kuralları da tüm giden TCP trafiğini bu porta yönlendirir. Ağ geçidinin bunun için izinlere ihtiyacı vardır: cap_add: NET_ADMIN. Çalışan konteynerdeki uygulama siteye normal bir istek yapar, çekirdek onu yakalar ve redsocks'a, o da mobil proxy'ye yönlendirir. Hiçbir ortam değişkeni yok. Yapılandırma özen gerektirir: yanlış bir iptables kuralı trafiği döngüye sokabilir, bu nedenle ayrı bir makinede test edin. Ayrıca network_mode: service ile çalışan konteynerin kendi portlarını ve diğer ağlara bağlantılarını kaybettiğini unutmayın, tüm bunlar ağ geçidinde tanımlanmalıdır.

Konteynerden IP rotasyonu

Mobil proxy'lerin, alınma nedenleri olan bir özelliği vardır: IP istek üzerine değiştirilebilir. Sağlayıcılar, modemin yeniden bağlanması için açılması yeterli olan özel bir IP değiştirme bağlantısı sağlar. Konteynerden bunu aynı curl ile yapabilirsiniz. Faydalı bir kalıp: Compose'da rotasyon bağlantısını programa göre çeken ayrı küçük bir servis. Proxy üzerinden gitmemelidir (aksi halde IP değiştikten sonra kendisi bağlantıyı kaybeder), bu nedenle onu proxy değişkenleri olmadan veya açıkça boş HTTP_PROXY ile başlatın. IP değişiminden sonra çalışan konteynerlerin aktif bağlantılarının kopacağını unutmayın: parser'lara yeniden deneme mekanizmaları ekleyin.

Ağ geçidi sağlığı: healthcheck

Compose'a ağ geçidinin gerçekten proxy yapıp yapmadığını, sadece çalışıp çalışmadığını kontrol eden bir kontrol ekleyin:

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

Bu, süreç canlılığının minimum kontrolüdür. Gerçek internet çıkışını kontrol etmek için dakikada bir ağ geçidi üzerinden istek yapan ve sonucu loga yazan veya bildirim gönderen ayrı bir izleyici konteyner daha iyidir. IP aniden sunucu IP'si olursa bu alarmdır: ağ geçidi düştü ve konteynerler doğrudan gitmeye başladı. 6. adımdaki iç ağ tam da bu senaryoya karşı korur.

Güvenli şifre saklama

.env dosyası yerel çalışma için iyidir, ancak birden fazla kullanıcısı olan bir sunucuda korunmalıdır: chmod 600 .env, sahibi Compose'un başlatıldığı kullanıcı olmalıdır. Compose ayrıca secrets direktifi aracılığıyla sırları destekler, bunlar konteynere ortam değişkeni yerine /run/secrets/ altında dosya olarak bağlanır. Gost şifreyi doğrudan dosyadan okumaz, ancak başlangıçta sır dosyasından -F satırını birleştiren küçük bir sarmalayıcı script yazabilirsiniz. Böylece şifre ne docker inspect'e ne de docker compose config çıktısına girer.

Birden fazla proje ve tek proxy altyapısı

Birden fazla Compose projeniz varsa ve proxy'ler ortaksa, ağ geçitlerini harici ağlı ayrı bir projeye taşıyın: içinde name: proxynet parametreli networks tanımlayın, diğer projelerde ise external: true olarak bağlanın. O zaman ağ geçitleri bağımsız yaşar ve çalışan projeleri proxy'lere dokunmadan istediğiniz kadar yeniden başlatabilirsiniz.

Trafik sınırlama

Mobil trafik genellikle ücretlendirilir ve kontrolden çıkan bir parser bir gecede onlarca gigabayt indirebilir. Docker düzeyinde trafik için katı kotalar yoktur, ancak dolaylı önlemler vardır: uygulamanın kendisinde istek hızı sınırlaması, başlatma komutunda timeout ile konteyner yaşam süresi sınırı ve her konteyner için NET I/O'yu gerçek zamanlı gösteren docker stats aracılığıyla izleme. Bu rakamları düzenli olarak sağlayıcının kontrol panelindeki istatistiklerle karşılaştırın.

Sırsız loglar

Birçok uygulama başlangıçta ortam değişkenlerini loga yazdırır, buna şifreli HTTP_PROXY dahildir. Loglar merkezi bir sisteme gidiyorsa şifre oraya sızar. Ağ geçidi bu sorunu da çözer: çalışan konteynerlerin loglarında yalnızca gateway:8118 olur.

İpucu: Üç ayda bir proxy şifrelerini yenileyin ve .env'yi güncelleyin. Ağ geçidiyle bu bir dakika sürer: tek satırı düzeltin, docker compose up -d gateway yapın ve tüm worker'lar yeniden başlatılmadan çalışmaya devam eder.

SSS: Docker'da proxy kurulumu hakkında sık sorulan sorular

Yeni proxy değişkenlerini uygulamak için konteyneri yeniden başlatmak gerekli mi?

Evet. Ortam değişkenleri konteyner oluşturulma anında ayarlanır ve çalışan bir konteynerde değiştirilemez. Durdurun, silin ve konteyneri yeniden oluşturun (Compose'da bu docker compose up -d --force-recreate servis_adı). Yeniden başlatmalar sorun yaratıyorsa ağ geçidini kullanın: ayarları bağımsız olarak değiştirilebilir.

docker pull için proxy yapılandırması ile konteynerdeki uygulama için proxy arasındaki fark nedir?

Bunlar iki farklı seviyedir. docker pull'u daemon yürütür ve onun için proxy daemon.json'da veya systemd üzerinden ayarlanır. Konteynerdeki uygulama kendi ortamına sahip ayrı bir süreçtir, onun için proxy ortam değişkenleri, istemci config.json'u veya ağ ile ayarlanır. Biri diğerinin yerini tutmaz.

Ortam değişkenlerinde HTTP proxy yerine SOCKS5 kullanılabilir mi?

Uygulama SOCKS'i destekliyorsa kullanılabilir. curl, Python requests (PySocks paketi kuruluysa), git destekler. apt ve diğerleri desteklemez. Evrensel çıkış yolu: girişte HTTP kabul edip çıkışta SOCKS5'e gönderen gost ağ geçidi: -L=http://:8118 -F=socks5://user:pass@host:port.

Çalışan bir konteynerin hangi proxy'yi kullandığını nasıl kontrol ederim?

docker inspect -f '{{.Config.Env}}' konteyner_adı komutunu çalıştırın. Tüm ortam değişkenlerini göreceksiniz. Gerçek IP'yi kontrol etmek için konteynerde curl varsa docker exec konteyner_adı curl -s ifconfig.me veya wget -qO- ifconfig.me kullanın.

Docker Desktop'ta proxy çalışıyor ama Linux sunucuda aynı ayarlar çalışmıyor, neden?

Docker Desktop, Proxies penceresindeki ayarları hem daemon'a hem konteynerlere aynı anda uygular. Linux'ta bu iki ayrı yerdir: daemon için daemon.json ve konteynerler için ~/.docker/config.json. Her ikisi de gerekiyorsa ikisini de yapılandırdığınızdan emin olun.

Proxy'yi yalnızca bir alan adı için ayarlayıp gerisini doğrudan bırakmak nasıl olur?

Ortam değişkenleri bunu yapamaz: "NO_PROXY hariç her şey proxy üzerinden" ilkesiyle çalışırlar. Ters mantık gerekiyorsa uygulama tarafında PAC dosyası kullanın (tarayıcılar destekler) veya trafiği alan adlarına göre farklı giden kanallara yönlendirebilen gost'ta yönlendirme kuralları kullanın.

Proxy şifresini compose.yaml'da saklamak güvenli mi?

Daha iyisi saklamamaktır. 600 izinli .env'de saklayın ve ${İSİM} aracılığıyla yerleştirin. .env'yi depoya commit etmeyin. Sunucular için ağ geçidini kullanın, böylece şifre tek bir yerde olur.

Mobil proxy IP değiştirirse ve konteynerlerdeki bağlantılar koparsa ne yapmalı?

Bu rotasyon sırasında normal davranıştır. Uygulama istekleri yeniden deneyebilmelidir. Rotasyon sağlayıcının programına göre gerçekleşiyorsa aralığı öğrenin ve ağır işlemleri onunla senkronize edin. Rotasyon sizin bağlantınızla oluyorsa görev paketleri arasında çağırın, ortasında değil.

Bu ayarlar WSL2 olmadan Windows'ta çalışır mı?

Windows'ta Docker Desktop arka planda WSL2 veya Hyper-V kullanır ve tüm docker run ve docker compose komutları PowerShell'den aynı şekilde çalışır. Yalnızca yollar farklıdır: config.json dosyası C:\Users\KullanıcıAdı\.docker\config.json'da bulunur ve daemon ayarları elle daemon.json yerine Docker Desktop penceresinden yapılır.

Bir mobil proxy üzerinden kaç konteyner çalıştırılabilir?

Teknik olarak sınırsız, sınır yalnızca mobil kanalın bant genişliği ve tarife limitleridir. Pratikte hesaplı görevler için mantıksal bir varlık (hesap, proje, bölge) başına bir proxy tutmak makuldür, böylece davranış doğal görünür ve bir konteynerdeki hata diğerlerini etkilemez.

Sonuç: Ne yaptınız ve bundan sonra nereye?

Özetleyelim. Proxy'nin ana makineden çalışıp çalışmadığını kontrol ettiniz ve bağlantı dizesi biçimini anladınız. Tek bir konteyner için proxy'yi ortam değişkenleri ve env-file aracılığıyla yapılandırdınız. Değişkenlerin istemci config.json'u aracılığıyla otomatik iletilmesini sağladınız. Docker daemon'ının kendisi için proxy'yi üç yöntemle nasıl ve neden yapılandıracağınızı anladınız. Docker Compose'da farklı mobil proxy'lerle birkaç servisi tanımladınız ve sırları .env'ye taşıdınız. Ve son olarak, uygulama değişkenleri görmezden gelse bile gerçek IP sızıntısına karşı koruyan, üretim için en güvenilir çözüm olan izole ağlı ağ geçidi konteynerini kurdunuz.

Artık Docker'da proxy sizin için kara bir kutu değil, net sınırları olan üç anlaşılır seviye: daemon, konteyner, ağ. IP aniden farklı çıkarsa sorunun nerede aranacağını biliyorsunuz ve bunu tek komutla kontrol edebiliyorsunuz.

Bundan sonra ne yapmalı?

  1. Çalışma projelerinizi ağ geçidi ve iç ağ şemasına taşıyın. Kritik olmayan bir servisle başlayın, her şeyin çalıştığından emin olun, sonra ölçeklendirin.
  2. Dakikada bir ağ geçidi üzerinden harici IP'yi kontrol eden ve sunucu IP'siyle eşleşirse sinyal veren bir izleyici konteyner ekleyin.
  3. IP rotasyonunu görevlerinize göre programlayın ve uygulamalara bağlantı kopmasını atlatmayı öğretin.
  4. Sırları düzene sokun: 600 izinli .env, compose.yaml ve Dockerfile'da hiç şifre olmasın.

Nereye gelişmeli?

Bir sonraki mantıklı adım — Docker'ı antidetect tarayıcılar ve her profile bir konteyner ve bir mobil proxy karşılık gelen çoklu hesap araçlarıyla ilişkilendirmek. Diğer bir yön — sağlayıcının API'si aracılığıyla otomasyon: proxy listesini almak, durumlarını kontrol etmek ve doğrudan servislerinizden rotasyon yapmak. Her iki konu da bu kılavuzun kapsamı dışında, ancak şimdi attığınız temel onları çok daha kolay hale getiriyor. Başarılı çalıştırmalar ve istikrarlı IP'ler!

Yazar Hakkında

Roman Melnikov

Roman Melnikov

Technical Writer and System Administrator

İş Deneyimi: 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.
Eğitim: Bauman Moscow State Technical University. Information Systems and Technologies
Uzmanlık:
Technical Documentation DevOps System Administration Linux Docker and Kubernetes CI/CD Infrastructure Automation Cloud Technologies System Monitoring Bash and Python Scripting

Makaleyi paylaşın: