Belajar Wget - Troubleshooting & Debugging

#Pendahuluan

Di episode 17 kalian sudah melihat wget bekerja sebagai perekam arsip web lewat WARC — alat yang tampak "tidak terlihat" sampai tiba-tiba sebuah download gagal di server produksi pada tengah malam. Nah, saat itulah debugging menjadi pembeda antara praktisi yang menebak-nebak dan praktisi yang membaca bukti.

Masalahnya, wget itu pendiam. Ketika download gagal, ia hanya keluar dengan sebuah exit code dan mungkin satu baris pesan error — tanpa penjelasan di mana tepatnya kegagalan itu terjadi. Seperti mobil yang mogok di tengah jalan tanpa lampu indikator: kalian tahu ada yang salah, tapi tidak tahu di sistem mana. Episode 18 ini akan memasang "dashboard lengkap" pada wget: mode debug, tampilan header respons server, kamus status code dan exit code, serta solusi untuk error yang paling sering muncul di dunia nyata.

#Debug -d: Melihat Semua yang Terjadi

Opsi -d (debug) membuat wget membuka pintu mesin dan menceritakan setiap langkah yang ia lakukan — termasuk request yang dikirim dan respons yang diterima, lengkap dengan seluruh header. Ini opsi pertama yang harus kalian nyalakan setiap kali sesuatu terasa aneh.

wget -d https://example.com/

Outputnya panjang dan berisik, tapi informasinya terstruktur. Berikut contoh bentuknya:

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.25.0 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: example.com
Connection: Keep-Alive
---request end---
HTTP/1.1 200 OK
...

Kunci membacanya ada di dua marka: ---request begin--- sampai ---request end--- menampilkan persis apa yang wget kirim ke server, dan baris-baris setelahnya adalah respons yang datang kembali. Dengan pola ini kalian langsung tahu titik kegagalan: jika tidak ada baris respons sama sekali, koneksi-nya yang gagal. Jika header respons muncul tapi file tidak pernah selesai, masalahnya ada di tengah transfer — bukan di awal koneksi.

#-S: Melihat Header Respons Server

-d menampilkan segalanya, tapi kadang kalian hanya butuh satu hal: header yang dikirim server sebagai balasan. Opsi -S (server-response) mencetak status line beserta seluruh header respons sebelum body-nya. Kombinasikan dengan -O - untuk menulis body ke terminal, sehingga kalian melihat keduanya dalam satu layar:

wget -S -O - https://example.com/

Baris pertama yang keluar adalah status line, misalnya HTTP/1.1 200 OK. Di situlah kalian mulai membaca kesehatan server. Berikut peta status code yang paling sering ditemui:

#Exit Code: Bahasa antara wget dan Skrip

Ketika wget selesai, ia keluar dengan sebuah exit code. Angka ini adalah bahasa yang dipahami oleh skrip — bukan sekadar "gagal", tapi kategori kegagalannya. Di dalam skrip kalian bisa memeriksanya secara eksplisit:

wget -q https://example.com/file.iso
echo "exit code: $?"

Satu aturan yang wajib diingat: kecuali untuk kode 0 dan 1, exit code bernomor kecil mengambil prioritas atas yang bernomor besar ketika beberapa jenis error terjadi bersamaan. Artinya, jika download gagal karena koneksi (4) dan sertifikat (5) sekaligus, wget melaporkan 4 — bukan 5.

#Error Umum dan Solusinya

Sekarang kita petakan error yang paling sering muncul ke akar masalahnya. Ingat prinsip dari episode 9: jangan menebak, lihat bukti.

#robots.txt Memblokir Crawl

Ketika wget bekerja secara rekursif, ia menghormati Robots Exclusion Standard — server akan diminta mengirim robots.txt, dan path yang di-deny di sana tidak akan diunduh. Gejalanya: crawl berjalan, tapi banyak URL dilewati diam-diam, atau muncul baris Loading robots.txt; please ignore errors. di log. Ini bukan bug — ini kebijakan server yang sedang ditaati wget.

wget -r -l 2 -e robots=off https://example.com/docs/

Jika kalian punya izin untuk mengambil path yang diblokir (misalnya site milik kalian sendiri), nonaktifkan dengan -e robots=off. Perhatikan: ini bukan "cheat", melainkan keputusan etis. Server melarang sesuatu dengan alasan; memaksanya tanpa izin adalah pelanggaran.

#403 Forbidden

Status 403 berarti server menolak akses — dan penyebab paling umum untuk wget adalah pemblokiran User-Agent. Banyak server, WAF, dan CDN membeda-bedakan identitas client. User-Agent default wget (Wget/1.25.0) mudah dikenali dan sering diblokir oleh situs yang ingin menolak crawler.

wget --user-agent="Mozilla/5.0 (X11; Linux x86_64)" \
  https://example.com/resource/file.zip

Jika 403 tetap muncul setelah mengganti User-Agent, periksa otorisasi — beberapa resource butuh kredensial (episode 14). Wget menandai respons 4xx/5xx dengan exit code 8.

#SSL Certificate Problem

Error ini muncul saat verifikasi TLS gagal, dan wget keluar dengan kode 5. Penyebabnya bermacam-macam: sertifikat kedaluwarsa, hostname tidak cocok, CA tidak dikenal sistem, atau tanggal sistem kalian yang salah. Anehnya, tanggal mesin yang melenceng adalah penyebab yang paling sering diabaikan — sertifikat punya masa berlaku, dan jika jam lokal kalian jauh dari waktu sebenarnya, verifikasi langsung gagal.

date

Jika tanggal benar, coba arahkan wget ke bundle CA yang eksplisit — terkadang default sistem belum diperbarui:

wget --ca-certificate=/etc/ssl/certs/ca-certificates.crt \
  https://example.com/file.zip

#Connection Refused

Pesan failed: Connection refused berarti server menolak koneksi TCP — biasanya karena tidak ada service yang mendengarkan di port tersebut, atau firewall menolak secara eksplisit. Exit code-nya 4. Jika service sedang restart atau baru dideploy, wget bisa langsung diperintahkan untuk mencoba lagi:

wget --retry-connrefused --tries=10 --wait=5 \
  https://example.com/file.zip

Periksa juga bahwa kalian menuju host dan port yang benar. Kombinasi host benar tapi port salah (misalnya 80 untuk HTTPS) adalah penyebab yang paling membingungkan — dan selalu terlihat seperti "server rusak" padahal URL-nya yang salah.

#No Such File or Directory (FTP)

Di FTP, error ini muncul saat file atau direktori yang diminta tidak ditemukan — bisa karena path salah ketik, atau karena login berhasil tapi kalian mengarah ke direktori yang salah. Berbeda dengan HTTP, wget di FTP harus melewati perintah change directory sebelum mengambil file; jika direktori tidak ada, inilah pesan yang keluar.

wget --spider ftp://ftp.example.com/pub/archive/file.tar.gz

Gunakan --spider untuk mengecek keberadaan file tanpa mengunduh isinya. Pastikan juga path-nya relatif terhadap direktori home akun FTP, dan perhatikan mode koneksi: wget memakai passive mode secara default; jika server FTP kalian bermasalah dengan itu, coba aktifkan active mode dengan --no-passive-ftp.

#Rate Limiting

Status 429 atau 503 berulang-ulang berarti kalian terlalu cepat atau server sedang kewalahan. Memaksa terus hanya akan memperparah — dan berisiko membuat IP kalian diblokir permanen. Solusinya adalah memperlambat diri secara terencana: tambahkan jeda antar-request, batasi kecepatan, dan batasi jumlah percobaan.

wget --wait=5 --random-wait --limit-rate=100k --tries=5 \
  --retry-on-http-error=429,503 -r -l 2 https://example.com/

--wait=5 memberi jeda lima detik antar-request, --random-wait mengacaknya agar tidak membentuk pola (pola yang kaku justru mudah dikenali sebagai bot), dan --limit-rate=100k membatasi bandwidth. --retry-on-http-error=429,503 membuat wget memperlakukan 429 dan 503 sebagai error sementara yang layak dicoba ulang — bukan kegagalan final.

#Urutan Diagnosis yang Benar

Kunci debugging wget adalah membangun tangga yang konsisten, dari yang paling cepat ke yang paling dalam:

1. Cek exit code — kategori masalahnya apa: network (4), SSL (5), atau server (8)?
2. Lihat status code dengan -S — apakah server menjawab, dan bagaimana ia menjawab?
3. Buka log -d — di fase mana percakapan berhenti?
4. Perbaiki akar masalah — bukan menutupinya dengan flag permissive.

Urutan ini mencegah kalian membuang waktu: jika gagal di SSL (kode 5), jangan ubah-ubah User-Agent. Jika server mengembalikan 403 (kode 8), jangan panik mengubah port. Setiap lapisan bukti menunjuk ke lapisan berikutnya.

#Penutup

Episode 18 membekali kalian dengan perangkat diagnostik yang lengkap: membaca log -d untuk melihat request dan respons mentah, menampilkan header server dengan -S, menerjemahkan status code HTTP dan exit code wget dari kode 1 hingga 8, serta memetakan error umum — robots.txt, 403, sertifikat, koneksi ditolak, FTP, dan rate limiting — beserta akar masalahnya.

Yang paling berharga bukan alatnya, melainkan kebiasaannya: debugging bukan menebak, tapi membaca bukti secara berurutan. Mulailah dari exit code, turun ke status code, lalu buka log debug-nya.

Di episode 19 berikutnya kita akan melirik ke masa depan: Wget vs Wget2 & fitur modern — mengenal penerus wget yang berbasis libwget, perbandingan opsi CLI, dan fitur-fitur mutakhir di Wget 1.x yang stabil. Sampai jumpa!