Skip to content
Artikel / 2 menit baca

Konfigurasi Proxy Docker dan SOCKS5: Daemon, Build, Container, dan Bridge

Docker tidak memiliki satu sakelar proxy. Daemon, proses build, dan setiap container membaca pengaturan proxy di tempat yang berbeda — dan SOCKS5 sama sekali tidak didukung oleh daemon. Berikut cara mengonfigurasi setiap lapisan dan memverifikasi bahwa itu berfungsi.

Konfigurasi Proxy Docker dan SOCKS5: Daemon, Build, Container, dan Bridge

Jika Anda mencari 'socks5 configurator' karena penarikan Docker terus timeout, Anda tidak sendirian. Docker memiliki setidaknya tiga lapisan proxy, dan semuanya tidak berbagi pengaturan. Proxy yang berfungsi untuk docker pull mungkin tidak membantu apt-get di dalam build, dan SOCKS5 — umum di banyak layanan proxy — tidak diterima oleh variabel proxy daemon Docker. Panduan ini membahas setiap lapisan dengan konfigurasi copy-paste dan langkah verifikasi, sehingga Anda dapat merutekan hanya apa yang perlu dirutekan dan menghindari kebocoran DNS atau kredensial.

Tiga lapisan proxy Docker (dan di mana masing-masing berlaku)

Lapisan Apa yang dipengaruhi Di mana Anda mengaturnya Dukungan protokol
Daemon docker pull, docker push, autentikasi registry systemd drop-in (Linux) atau pengaturan Docker Desktop URL proxy HTTP/HTTPS
Build Perintah RUN selama docker build (apt, pip, npm) --build-arg + ARG di Dockerfile URL proxy HTTP/HTTPS
Runtime container Lalu lintas dari aplikasi Anda di dalam container flag -e atau environment Compose Tergantung aplikasi (HTTP, HTTPS, SOCKS5 jika aplikasi mendukungnya)

Tempat keempat yang orang lupakan: package manager dan tools milik host sendiri. Jika Anda tidak dapat menjangkau registry Docker, biasanya Anda juga tidak dapat menjangkau apt atau pip di host. Setel proxy tingkat host terlebih dahulu, lalu konfigurasikan Docker. Untuk perutean per aplikasi di host, lihat panduan konfigurator SOCKS5 kami untuk browser, SSH, curl, git, dan Python.

Proxy tingkat daemon: untuk menarik image dan berkomunikasi dengan registry

Daemon Docker membaca variabel lingkungan proxy standar dari layanan systemd-nya. Buat file drop-in:

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf > /dev/null <<'EOF'
[Service]
Environment=HTTP_PROXY=http://user:[email protected]:3128
Environment=HTTPS_PROXY=http://user:[email protected]:3128
Environment=NO_PROXY=localhost,127.0.0.1,::1,.internal.example,registry.internal.example
EOF
sudo systemctl daemon-reload
sudo systemctl restart docker

Catatan:

  • Nilainya adalah URL proxy. Untuk proxy HTTP standar yang mendukung CONNECT, gunakan http://. Jika endpoint proxy Anda sendiri dibungkus TLS, gunakan https://.
  • NO_PROXY harus menyertakan registry internal atau host apa pun yang tidak ingin Anda proksikan. Titik di awal .internal.example mencocokkan subdomain di banyak implementasi, tetapi perilakunya bervariasi.
  • Kredensial di file systemd terlihat oleh root. Untuk mesin bersama, pertimbangkan forwarder lokal yang tidak memerlukan kredensial di lingkungan.

Verifikasi:

docker info | grep -i -A2 'Proxy'

Anda akan melihat baris HTTP Proxy, HTTPS Proxy, dan No Proxy. Jika kosong, daemon tidak mengambil drop-in tersebut.

Lalu uji pull:

docker pull alpine:latest

Jika masih gagal, periksa log daemon:

journalctl -u docker.service --no-pager -n 50

Docker Desktop (macOS/Windows) memiliki pengaturan proxy GUI di bawah Settings, Resources, Proxies. Ini menulis variabel yang sama untuk daemon.

Proxy saat build: ketika pull berhasil tetapi RUN apt-get tidak

Proxy daemon tidak otomatis berlaku untuk container build. Anda harus meneruskan argumen proxy dan mendeklarasikannya di Dockerfile.

FROM debian:bookworm-slim

ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

RUN apt-get update && apt-get install -y --no-install-recommends curl ca-certificates && rm -rf /var/lib/apt/lists/*

Build:

docker build --build-arg HTTP_PROXY=http://user:[email protected]:3128 --build-arg HTTPS_PROXY=http://user:[email protected]:3128 --build-arg NO_PROXY=localhost,127.0.0.1 -t myapp .

Penting: nilai --build-arg dapat terlihat di riwayat image dan log build. Jangan pernah menanamkan kredensial ke image final. Gunakan multi-stage build dan hapus setel argumen sebelum tahap final, atau gunakan secret mount BuildKit untuk kredensial.

Proxy per-container: menyetel variabel lingkungan saat runtime

Untuk aplikasi yang membaca env var proxy, setel saat Anda menjalankan container:

docker run --rm -e HTTP_PROXY=http://proxy.example:3128 -e HTTPS_PROXY=http://proxy.example:3128 -e NO_PROXY=localhost,127.0.0.1 myapp

Di Docker Compose:

services:
  app:
    image: myapp
    environment:
      HTTP_PROXY: http://proxy.example:3128
      HTTPS_PROXY: http://proxy.example:3128
      NO_PROXY: localhost,127.0.0.1,.internal.example

Tidak semua aplikasi mematuhi variabel ini. Beberapa hanya membaca http_proxy huruf kecil, beberapa mengabaikan NO_PROXY sepenuhnya, dan beberapa memiliki file konfigurasi sendiri. Selalu periksa dokumentasi aplikasi.

SOCKS5: mengapa variabel proxy Docker tidak menerimanya

Daemon Docker dan variabel proxy --build-arg mengharapkan URL proxy HTTP atau HTTPS. socks5:// bukan skema yang didukung untuk daemon. Jika layanan proxy Anda hanya memberi Anda endpoint SOCKS5, Anda memiliki tiga opsi praktis:

  1. Jalankan bridge HTTP-ke-SOCKS5 lokal. Sebuah forwarder kecil mendengarkan di 127.0.0.1:3128 dan meneruskan ke proxy SOCKS5 Anda. Lalu arahkan HTTP_PROXY Docker ke bridge tersebut. Ini menjaga kredensial SOCKS5 tetap keluar dari lingkungan Docker.
  2. Gunakan penerusan dinamis SSH plus bridge. ssh -D 1080 memberi Anda proxy SOCKS5 lokal; bridge mengubahnya menjadi HTTP untuk Docker. Ini bekerja dengan baik ketika Anda sudah memiliki akses SSH ke host jarak jauh.
  3. Konfigurasikan aplikasi di dalam container untuk menggunakan SOCKS5 secara langsung. Banyak alat (curl, requests, git) mendukung socks5h:// secara native. Ini melewati pengaturan proxy Docker sepenuhnya dan hanya memengaruhi aplikasi tersebut.

Contoh: menguji SOCKS5 dari dalam container tanpa bridge, menggunakan curl. Di Linux, tambahkan --add-host=host.docker.internal:host-gateway agar container dapat menjangkau proxy yang berjalan di host.

docker run --rm --add-host=host.docker.internal:host-gateway curlimages/curl:latest --socks5-hostname host.docker.internal:1080 https://ifconfig.me

--socks5-hostname mengirim hostname ke proxy untuk resolusi DNS, yang menghindari kebocoran DNS. Jika Anda menggunakan --socks5, curl menyelesaikan DNS secara lokal dan hanya menerowongkan koneksi TCP — sumber umum geolokasi yang salah dan kebocoran.

Untuk kode aplikasi, skema socks5h seringkali lebih jelas:

curl --proxy socks5h://user:[email protected]:1080 https://ifconfig.me

Memverifikasi proxy benar-benar digunakan (dan menangkap kebocoran)

Setelah konfigurasi, verifikasi di setiap lapisan:

  • Daemon: docker info | grep -i proxy menunjukkan variabelnya. Lalu docker pull harus mengenai proxy. Anda juga dapat memeriksa log proxy sendiri untuk permintaan CONNECT ke registry-1.docker.io:443.
  • Build: Tambahkan langkah RUN yang mencetak IP yang terlihat: RUN curl -s https://ifconfig.me || true. Jika IP-nya adalah IP asli Anda, build tidak melalui proxy. Hapus baris ini sebelum merilis.
  • Container: docker exec -it <container> sh -c 'curl -s https://ifconfig.me' dan bandingkan dengan IP asli Anda.
  • DNS: Proxy HTTP biasanya menyelesaikan DNS di sisi proxy untuk HTTPS (melalui CONNECT), tetapi permintaan HTTP biasa dapat membocorkan DNS jika klien menyelesaikan secara lokal. SOCKS5 dengan socks5h selalu menyelesaikan dari jarak jauh. Jika DNS penting, uji dengan pemeriksa kebocoran DNS atau periksa log proxy.

Jebakan umum dengan Docker dan proxy

  • NO_PROXY tidak otomatis. Jika registry internal Anda atau layanan di host diproksikan tanpa perlu, tambahkan ke NO_PROXY. Sertakan localhost, 127.0.0.1, dan domain internal apa pun.
  • Huruf besar vs huruf kecil. Beberapa alat membaca HTTP_PROXY, yang lain http_proxy. Setel keduanya jika tidak yakin. Di Dockerfile, ARG HTTP_PROXY cukup untuk membuat proses build membaca varian huruf besar; tambahkan ARG http_proxy jika alat tertentu memerlukan huruf kecil.
  • Kredensial di riwayat build. Nilai --build-arg dapat muncul di docker history. Gunakan secret mount BuildKit (--mount=type=secret) untuk token dan kata sandi.
  • Docker Desktop vs daemon Linux. Di Linux Anda mengedit systemd; di Docker Desktop Anda menggunakan GUI atau settings.json. Jangan menganggap tutorial Linux berlaku untuk Docker Desktop.
  • IPv6 dan dual-stack. Jika proxy Anda hanya mendukung IPv4, paksa container atau daemon untuk memilih IPv4. Beberapa alat memerlukan flag eksplisit.

Alur kerja praktis untuk jaringan terbatas atau terfilter

Jika Anda bekerja dari jaringan tempat akses registry lambat, dibatasi, atau difilter — umum di beberapa jaringan perusahaan dan nasional — mulailah dengan proxy daemon agar penarikan image berhasil. Lalu tambahkan argumen saat build untuk package manager. Terakhir, setel env var runtime hanya untuk container yang memerlukan egress melalui proxy. Jika satu-satunya endpoint proxy Anda adalah SOCKS5, jalankan bridge lokal dan arahkan variabel proxy HTTP Docker ke bridge tersebut, atau simpan SOCKS5 di dalam container untuk aplikasi yang mendukungnya secara langsung.

Pendekatan berlapis ini menghindari pengiriman semua lalu lintas container melalui proxy ketika hanya penarikan image dan langkah build yang memerlukannya. Ini juga menjaga kredensial di lebih sedikit tempat.

Intisari

Konfigurasi proxy Docker bukanlah satu pengaturan; itu adalah pengaturan daemon, argumen saat build, dan variabel lingkungan per-container. SOCKS5 hanya didukung di tempat aplikasi mendukungnya — daemon Docker tidak. Dengan mengonfigurasi setiap lapisan secara sengaja dan memverifikasi dengan docker info, pull uji, dan pemeriksaan IP di dalam container, Anda dapat menjaga build tetap berfungsi tanpa membocorkan DNS atau menanamkan kredensial ke dalam image.