Belajar Aria2 - Proxy & Networking

#Pendahuluan

Di episode 10 dan 11 kalian menangani BitTorrent dan metalink, lalu mengendalikan kemana file disimpan — direktori, nama, dan struktur output. Hingga titik itu, satu asumsi selalu berdiri diam: koneksi aria2 menembus langsung menuju server tujuan. Di dunia nyata asumsi ini sering salah. Kantor korporat, kampus, dan sebagian ISP memaksa semua lalu lintas melewati sebuah gerbang bernama proxy — dan jika kalian tidak tahu cara berbicara dengannya, download kalian menggantung dalam kesunyian.

Episode 12 membuka lapisan jaringan yang selama ini diambil begitu saja: bagaimana aria2 menemukan jalan menuju server, melewati proxy atau tidak, keluar dari interface mana, dan bagaimana DNS ikut menentukan kecepatan koneksi paralel yang kita bangun sejak episode 5.

#Proxy: Resepsionis di Depan Gerbang

Bayangkan kantor dengan satu meja resepsionis. Semua paket keluar-masuk lewat meja itu; resepsionis yang memutuskan paket mana boleh keluar, ke mana, dan kadang menyimpan salinannya agar tidak perlu dipesan dua kali. Proxy bekerja persis seperti itu: perantara yang menerima permintaan kalian, mewakilkannya 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 aria2 sering berjalan otomatis dan terotomasi, memahami proxy bukan pelengkap — ia prasyarat. Tanpa konfigurasi yang benar, semua download di balik firewall korporat akan gagal dengan pesan yang tidak membantu.

#aria2 Tidak Membaca Environment Proxy

Inilah salah satu perbedaan paling menjebak dari tool download lain: aria2 tidak membaca variabel environment seperti http_proxy atau https_proxy. Kalian bisa meng-export http_proxy sepanjang hari, aria2 tetap mengabaikannya. Setiap proxy harus disebutkan secara eksplisit lewat opsi. Ini sekaligus berita baik: perilaku download kalian bisa diprediksi dan tidak diam-diam berubah karena lingkungan.

#Empat Opsi, Satu Format

aria2 membedakan tujuan lalu lintas dengan empat opsi, semuanya menerima format http://host:port (dengan user:pass@ bila perlu autentikasi):

| Opsi | Mengatur lalu lintas ke | | --http-proxy=PROXY | URL berprotokol HTTP | | --https-proxy=PROXY | URL berprotokol HTTPS | | --ftp-proxy=PROXY | URL berprotokol FTP | | --all-proxy=PROXY | Semua protokol sekaligus |

Ketika ketiga opsi pertama tidak diisi dan --all-proxy tidak ada, aria2 terhubung langsung tanpa perantara. Kebanyakan kasus cukup memakai --all-proxy — satu baris yang menutup HTTP, HTTPS, dan FTP sekaligus.

#--all-proxy: Sekali Atur untuk Semua

aria2c --all-proxy="http://proxy.contoh.local:8080" \
  https://cdn.example.com/file.zip

Satu opsi ini menggantikan tiga opsi sekaligus. --all-proxy juga menjadi penutup yang nyaman: karena ia bekerja untuk semua protokol, satu nilai proxy yang sama berlaku untuk download HTTP, HTTPS, dan FTP tanpa perlu mengulang konfigurasi di setiap perintah.

#Memilah Tujuan: HTTP, HTTPS, dan FTP

Kadang setiap protokol punya jalur berbeda — misalnya HTTP dan HTTPS lewat proxy korporat, sementara FTP lewat proxy khusus. Di situlah ketiga opsi spesifik menang:

aria2c --http-proxy="http://proxy.contoh.local:8080" \
  --https-proxy="http://proxy.contoh.local:8080" \
  https://cdn.example.com/file.zip

aria2c --ftp-proxy="http://proxy.contoh.local:2121" \
  ftp://ftp.example.com/file.zip

Perhatikan detail kecil di atas: FTP kerap punya proxy sendiri, karena jalur FTP sering diarahkan ke gateway khusus. Ketika kalian mencampur protokol dalam satu invocation, opsi per protokol memberi kendali paling presisi.

#--no-proxy: Pengecualian per Host

Memaksa semua lalu lintas lewat proxy kadang justru menghambat — terutama untuk host internal yang sudah terjangkau langsung. Opsi --no-proxy memunculkan daftar pengecualian: host yang harus diakses tanpa perantara.

aria2c --all-proxy="http://proxy.contoh.local:8080" \
  --no-proxy="localhost,127.0.0.1,192.168.1.0/24" \
  http://nas.contoh.local/film.mkv

--no-proxy menerima daftar yang dipisahkan koma: nama host, nama domain, atau alamat jaringan dengan subnet mask — dan * berarti semua host. Perhatikan bahwa pengecualian ini bersifat per-invocation; untuk pola yang tetap, taruh di file konfigurasi agar tidak ditulis ulang di setiap perintah.

#Autentikasi Proxy

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 aria2 perlu kredensial. Dua cara memberikannya:

aria2c --all-proxy="http://proxy.contoh.local:8080" \
  --proxy-user=budi --proxy-passwd=rahasia \
  https://cdn.example.com/file.zip

Kredensial juga bisa diselipkan langsung ke URL proxy: --all-proxy="http://budi:rahasia@proxy.contoh.local:8080". Keduanya sah, tapi peringatan di episode 9 tetap berlaku: jangan pernah menulis password literal di command line atau di file yang masuk ke git — shell history dan riwayat git tidak pernah benar-benar bersih. Untuk skrip, baca kredensial dari environment atau dari file konfigurasi yang di-lock permission-nya.

#Memilih Jalur Keluar: --interface dan --bind-address

Pada mesin dengan banyak interface — laptop yang punya wifi dan ethernet sekaligus, server dengan beberapa NIC — aria2 memilih alamat keluar secara otomatis. Dua opsi memberi kendali manual:

aria2c --interface=eth0 https://cdn.example.com/file.zip

aria2c --bind-address=10.0.1.20 https://cdn.example.com/file.zip

--interface=eth0 menerima nama interface, alamat IP, atau hostname; --bind-address=10.0.1.20 hanya menerima alamat IP. Kegunaan praktisnya: memaksa egress lewat interface dengan bandwidth besar, atau lewat IP yang terdaftar di allowlist server tujuan. Pilihan ini jarang dibutuhkan di laptop, tapi menjadi pembeda di lingkungan produksi dengan routing yang rumit.

#--reuse-uri: Ketika Sumber Kehabisan

Pada download multi-mirror (terutama metalink dari episode 11), aria2 punya pilihan menarik saat semua URI tampak gagal: --reuse-uri. Secara default (false), aria2 tidak memakai ulang URI yang sudah pernah gagal — ia mencari sumber lain yang belum dicoba. Dengan --reuse-uri=true, ia bersedia mencoba lagi URI lama ketika tidak ada pilihan lain.

aria2c --reuse-uri=true file.metalink

Ini seperti mencari air di padang pasir: defaultnya aria2 bergerak ke sumur berikutnya saat satu sumur kering; dengan --reuse-uri=true, ia bersedia menimba lagi sumur lama jika semua sumur lain sudah kehabisan. Nilai defaultnya sudah tepat untuk kebanyakan kasus — nyalakan hanya jika kalian tahu sumber lama sudah pulih.

#DNS: Di Balik Kecepatan Koneksi Paralel

Sebelum satu byte pun berpindah, nama domain harus diterjemahkan menjadi alamat IP — pekerjaan DNS (Domain Name System). Tahap ini menentukan kecepatan dan keandalan lebih dari yang kalian kira, terutama karena sejak episode 5 kalian menarik download dari banyak koneksi sekaligus.

Koneksi paralel bukanlah perkara murni klien — server tujuan ikut menetapkan batas. Bila host hanya punya satu alamat IP, seluruh koneksi kalian menumpuk di alamat yang sama, dan server atau ISP bisa membatasi. Bila host memakai CDN dengan banyak alamat IP, aria2 menyebarkan koneksi ke beberapa IP sekaligus — itulah salah satu alasan mengapa download dari CDN terasa jauh lebih cepat.

Dua opsi memperkuat sisi DNS aria2:

• --async-dns=true (default) — resolusi DNS berjalan asinkron, tidak memblokir koneksi lain sambil menunggu jawaban resolver.
• --dns-timeout=SEC — batas waktu tunggu resolver. Tanpa batas yang wajar, resolusi yang menggantung bisa menahan download berjam-jam.

aria2c --async-dns=true --dns-timeout=5 \
  -x 16 -s 16 https://cdn.example.com/distro.iso

#Penutup

Episode 12 membedah lapisan jaringan yang selama ini diambil begitu saja: melewati proxy dengan --http-proxy, --https-proxy, --ftp-proxy, dan --all-proxy, mem-bypass per host dengan --no-proxy, mengautentikasi ke proxy dengan --proxy-user dan --proxy-passwd, memilih jalur keluar dengan --interface dan --bind-address, memahami --reuse-uri, serta peran DNS terhadap kecepatan koneksi paralel.

Inti yang perlu diingat: jalur jaringan bukan takdir — ia konfigurasi. Setiap lapisan antara aria2 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: TLS/HTTPS dan keamanan download — bagaimana aria2 memverifikasi identitas server, mengapa --check-certificate=false adalah keputusan yang mahal, serta bagaimana checksum dan validasi BitTorrent atau metalink menutup lingkaran kepercayaan. Sampai jumpa!