Debugging Masalah Jaringan dengan curl, dig, dan traceroute

Salah satu kesalahan paling umum yang saya lihat, baik dari developer junior maupun yang sudah cukup senior, adalah langsung menuduh "servernya down" atau "aplikasinya error" begitu sebuah request gagal. Padahal jalur dari browser atau curl sampai ke aplikasi itu melewati beberapa lapisan: resolusi nama domain, koneksi jaringan, lalu baru proses di aplikasi. Kalau kita tidak tahu di lapisan mana masalahnya, kita bisa habis waktu berjam-jam mengotak-atik kode padahal masalahnya di DNS, atau sebaliknya, restart server berkali-kali padahal masalahnya di resolver DNS client. Sebagai orang yang sehari-hari pegang infrastruktur untuk sistem klinik dan rumah sakit, di mana downtime berarti antrian pasien tertahan, saya jadi terbiasa punya urutan diagnosis yang konsisten sebelum menyimpulkan apa-apa. Tulisan ini saya susun sebagai alur praktis itu.

Langkah 1: Pastikan DNS-nya benar dengan dig

Sebelum menyalahkan aplikasi, cek dulu apakah nama domain diterjemahkan ke IP yang benar. Tool dig lebih informatif daripada nslookup karena menunjukkan detail seperti TTL dan server mana yang menjawab.

dig pujamalca.my.id +short
dig pujamalca.my.id A
dig pujamalca.my.id @8.8.8.8

Kalau dig +short tidak mengembalikan IP sama sekali, berarti masalahnya di DNS, bukan di server aplikasi. Trik yang sering saya pakai: bandingkan hasil dig lewat resolver default sistem dengan hasil lewat resolver publik seperti @8.8.8.8 atau @1.1.1.1. Kalau hasilnya beda, kemungkinan besar ada masalah propagasi DNS atau cache resolver lokal yang basi. Untuk kasus yang lebih rumit, seperti curiga ada masalah di rantai NS atau CNAME, saya juga sering pakai dig +trace supaya bisa melihat resolusi dari root server ke bawah, step demi step.

Langkah 2: Cek jalur jaringan dengan traceroute

Kalau DNS sudah benar tapi koneksi tetap gagal atau lambat, langkah berikutnya adalah melihat jalur paket menuju server. Di sinilah traceroute (atau mtr yang menurut saya lebih enak dibaca karena menampilkan statistik per-hop secara live) berguna.

traceroute pujamalca.my.id
mtr pujamalca.my.id

Yang saya perhatikan dari output ini bukan cuma apakah paket sampai, tapi di hop mana mulai ada packet loss atau lonjakan latensi yang tidak wajar. Kalau loss-nya terjadi di beberapa hop awal, biasanya itu masalah jaringan lokal atau ISP. Kalau loss-nya baru muncul di hop-hop terakhir, dekat dengan IP tujuan, kemungkinan besar itu firewall di sisi server yang men-drop paket icmp tanpa reply, atau memang ada masalah di jaringan penyedia hosting. Perlu diingat, tidak semua server merespons traceroute dengan baik karena ICMP sering dibatasi firewall, jadi hop terakhir yang "timeout" tidak selalu berarti server itu benar-benar tidak bisa dijangkau lewat protokol lain seperti HTTP.

Langkah 3: Uji koneksi dan respons aplikasi dengan curl

Setelah yakin DNS beres dan jalur jaringan bisa dilalui, baru masuk ke lapisan aplikasi. Di sini curl adalah tool andalan saya, karena bisa mengukur waktu di tiap fase request secara terpisah.

curl -v https://pujamalca.my.id
curl -I https://medcoder.pujamalca.my.id
curl -o /dev/null -s -w 'dns: %{time_namelookup}s connect: %{time_connect}s ttfb: %{time_starttransfer}s total: %{time_total}s\n' https://pujamalca.my.id

curl -v menampilkan detail proses TLS handshake, header request dan response, yang sangat membantu kalau curiga masalahnya di sertifikat SSL atau konfigurasi reverse proxy. Sedangkan format -w di atas memisahkan waktu resolusi DNS, waktu koneksi TCP, dan waktu sampai byte pertama diterima (time to first byte). Kalau time_connect sudah lambat, itu murni masalah jaringan/infrastruktur. Kalau time_connect cepat tapi time_starttransfer lambat, artinya koneksi sudah tersambung tapi aplikasi di belakangnya (misalnya proses PHP-FPM yang antre, atau query database yang lambat) yang jadi bottleneck. Pemisahan ini penting supaya kita tidak salah kirim tiket ke tim yang salah, atau salah restart komponen yang salah.

Menyusun jadi satu alur

Kalau digabung, urutan yang saya pakai kira-kira begini: dig dulu untuk memastikan nama domain menunjuk ke IP yang benar, lalu traceroute/mtr untuk memastikan paket bisa sampai ke IP itu, baru curl untuk melihat bagaimana aplikasi di baliknya merespons. Tiga lapisan ini, DNS, jaringan, dan aplikasi, sengaja saya urutkan dari yang paling luar ke paling dalam, karena kalau lapisan luar sudah bermasalah, semua percobaan di lapisan dalam akan menyesatkan. Kebiasaan ini juga membantu saat berkoordinasi dengan tim lain: alih-alih bilang "internetnya kayaknya lemot", saya bisa langsung tunjukkan angka dari curl -w atau hasil mtr yang lebih konkret dan bisa didiskusikan bersama.

Takeaway singkat: setiap kali ada laporan "situsnya nggak bisa diakses", jangan langsung masuk ke kode. Cek DNS-nya dengan dig, cek jalur jaringannya dengan traceroute atau mtr, baru cek respons aplikasinya dengan curl. Urutan bertahap ini jauh lebih cepat menemukan akar masalah dibanding menebak-nebak, dan tiga tool ini sudah cukup untuk sebagian besar kasus troubleshooting jaringan sehari-hari.