Pada episode ini kita akan membedah jalur yang dilalui wget sebelum sampai ke server: proxy HTTP dan HTTPS lewat variabel environment, autentikasi proxy, pemaksaan IPv4 atau IPv6, bind address, serta peran DNS terhadap kecepatan dan keandalan download.

Di episode 11 kalian memirror seluruh situs — wget menelusuri tautan, menyalin struktur direktori, dan menghasilkan replika lokal yang utuh. Tapi sepanjang episode itu ada satu asumsi yang tidak pernah kita pertanyakan: jalur yang dilalui wget selalu langsung menembus ke server. Di dunia nyata, asumsi ini sering salah. Kantor korporat, kampus, dan bahkan beberapa ISP memaksa semua lalu lintas melewati sebuah gerbang bernama proxy — dan jika kalian tidak tahu cara berbicara dengannya, download kalian akan menggantung dalam kesunyian.
Episode 12 membuka kap mesin lapisan jaringan: bagaimana wget menemukan jalannya menuju server, lewat proxy atau tidak, lewat IPv4 atau IPv6, dari alamat mana ia keluar, dan bagaimana DNS ikut menentukan pengalaman download kalian.
Bayangkan kantor dengan satu resepsionis. Semua paket yang masuk dan keluar harus lewat meja resepsionis; resepsionis yang memutuskan paket mana yang boleh keluar, ke mana, dan kadang menyimpan salinannya agar tidak perlu dipesan dua kali. Proxy bekerja persis seperti itu: sebuah perantara yang menerima permintaan kalian, mewakilkan ke server tujuan, lalu meneruskan balasan. Ia dipakai untuk filtering (memblokir domain tertentu), caching (menyimpan salinan agar bandwidth hemat), dan audit (mencatat semua akses).
Karena wget non-interaktif dan sering berjalan otomatis, memahami cara mengonfigurasi proxy bukan pelengkap — ia prasyarat. Tanpa konfigurasi yang benar, semua download di balik firewall korporat akan gagal dengan pesan yang tidak membantu.
wget tidak membaca proxy dari file konfigurasi khusus — ia membaca variabel environment, persis seperti yang dipakai kebanyakan tool jaringan. Tiga variabel yang paling penting: http_proxy untuk lalu lintas HTTP, https_proxy untuk HTTPS, dan no_proxy untuk daftar host yang harus diakses langsung.
export http_proxy="http://proxy.contoh.local:8080"
export https_proxy="http://proxy.contoh.local:8080"
export no_proxy="localhost,127.0.0.1,.internal.example.com"
wget https://docs.example.com/Begitu variabel terdefinisi, wget otomatis mengarahkan koneksinya lewat proxy — tidak perlu flag tambahan. Perhatikan pola no_proxy: host dipisahkan koma, dan awalan titik berarti "termasuk semua subdomain". Ini membuat permintaan ke server internal tidak berputar-putar lewat gerbang yang sebenarnya tidak tahu arah.
Tip
Variabel environment biasanya ditulis huruf kecil (http_proxy), dan wget juga menghormati bentuk huruf besarnya. Yang lebih penting: karena variabel ini diwariskan ke semua proses turunan, mendefinisikannya di satu file profile membuat seluruh tool jaringan — bukan hanya wget — ikut mematuhinya.
--proxy=off dan --no-proxyTerkadang kalian ingin menonaktifkan proxy hanya untuk satu perintah — misalnya karena proxy sedang bermasalah, atau karena kalian tahu jaringan lokal tidak membutuhkannya. Dua opsi membedakan kasusnya:
wget --proxy=off https://docs.example.com/--proxy=off mematikan proxy sepenuhnya untuk invocation ini, tanpa menyentuh variabel environment. Ini analog dengan mengambil jalan kecil untuk menghindari gerbang tol yang macet — sekali saja, tanpa mengubah rute default.
wget --no-proxy='localhost,127.0.0.1' https://internal.example.com/Sebaliknya, --no-proxy=host-list tetap memakai proxy secara umum, tapi mengecualikan host tertentu — fungsinya mirip variabel no_proxy, namun diterapkan per-invocation. Gunakan ketika hanya segelintir host yang harus diakses langsung.
Banyak proxy korporat tidak membiarkan siapa pun lewat — mereka meminta bukti identitas. Ketika proxy menuntut autentikasi, ia menjawab dengan status 407 Proxy Authentication Required, dan wget akan meminta kredensial. Ada dua cara memberikannya:
wget --proxy-user=budi --proxy-password=rahasia \
https://cdn.example.com/file.tar.gzwget "http://budi:rahasia@proxy.contoh.local:8080" \
https://cdn.example.com/file.tar.gzCara kedua menyelipkan kredensial langsung ke URL proxy. Keduanya sah, tapi cara kedua punya dua kelemahan: kredensial terlihat di command line (dan tersimpan di shell history), serta menuntut kalian menulisnya ulang setiap kali. Untuk skrip yang dijalankan otomatis, --proxy-user dan --proxy-password yang dibaca dari environment jauh lebih bersih — dan jangan pernah menulis --proxy-password literal di file yang masuk ke git. Kita akan membahas penyimpanan kredensial yang benar di episode 14.
Internet sekarang berjalan di dua alamat sekaligus: IPv4 dan IPv6. wget mencoba memilih yang paling masuk akal secara otomatis, tapi kadang pilihan itu salah — misalnya jaringan kalian memiliki IPv6 yang rusak sebagian, atau server tujuan hanya punya alamat IPv4. Dua opsi memberi kalian kendali penuh:
wget -4 https://example.com/wget -6 https://example.com/-4 (alias --inet4-only) dan -6 (alias --inet6-only) mengunci protokol yang dipakai. Ini seperti memilih jalur tol mana yang akan dimasuki saat ada dua gerbang: satu jalur mungkin lebih dekat, tapi yang lain lebih andal. Jika sebuah download sering gagal dengan koneksi yang tertunda hanya di satu jaringan, coba paksa -4 — seperempat masalah koneksi misterius selesai di sini.
Pada mesin dengan banyak alamat IP — server, workstation dengan beberapa koneksi — wget biasanya memilih alamat keluar secara otomatis. Opsi --bind-address menetapkan alamat lokal yang dipakai:
wget --bind-address=10.0.1.20 https://cdn.example.com/file.tar.gzKegunaan praktisnya: mengarahkan egress melalui interface tertentu — misalnya memaksa download lewat jaringan dengan bandwidth besar, atau lewat IP yang terdaftar di allowlist server tujuan. Pada wget versi baru, --bind-interface=eth0 melakukan hal yang sama dengan menyebut nama interface. Pilihan ini jarang dipakai di laptop, tapi menjadi pembeda di lingkungan produksi dengan routing yang rumit.
Sebelum satu byte pun berpindah, wget harus menerjemahkan nama domain menjadi alamat IP — pekerjaan DNS (Domain Name System). Tahap ini menentukan kecepatan dan keandalan lebih dari yang kalian kira: resolver yang lambat berarti setiap koneksi baru menunggu; resolusi yang gagal berarti download berakhir sebelum mulai, dengan pesan "Unable to resolve host address".
Dua perilaku wget yang perlu dikenal:
--no-dns-cache mematikannya, berguna ketika alamat IP sering berubah dan kalian butuh resolusi segar tiap request.--dns-timeout=10 membatasi lama tunggu resolver. Tanpa batas, resolusi yang menggantung bisa menahan skrip berjam-jam.wget --no-dns-cache --dns-timeout=10 https://example.com/Important
Jika sebuah situs punya banyak alamat (umum pada CDN), wget mencoba yang terbaik yang tersedia. Mengeluarkan DNS dari black box — resolver mana yang dipakai, seberapa cepat ia menjawab, dan bagaimana perilaku cache — adalah langkah pertama men-debug download yang lambat atau tidak stabil.
Episode 12 membedah lapisan jaringan yang selama ini diambil begitu saja: melewati proxy lewat variabel http_proxy, https_proxy, dan no_proxy, menonaktifkannya per-invocation dengan --proxy=off dan --no-proxy, mengautentikasi diri ke proxy dengan --proxy-user dan --proxy-password, mengunci protokol dengan -4 atau -6, memilih alamat keluar dengan --bind-address, serta memahami peran DNS terhadap kecepatan dan keandalan.
Inti yang perlu diingat: jalur jaringan bukan takdir — ia konfigurasi. Setiap lapisan antara wget dan server bisa dikendalikan, dan setiap lapisan yang tidak dikendalikan adalah titik kegagalan yang tidak terlihat.
Di episode 13 berikutnya kita naik satu lapisan ke atas: HTTPS, TLS, dan sertifikat — bagaimana wget memverifikasi identitas server, mengapa --no-check-certificate adalah keputusan yang mahal, serta bagaimana sertifikat klien dan HSTS memperkuat kepercayaan. Sampai jumpa!