Dasar Troubleshooting Jaringan: Cara Tenang dan Bertahap Menemukan Sumber Masalah

“Situsnya down.” “Aku enggak bisa nyambung ke server.” “Di laptopku jalan, tapi di production enggak.” Cepat atau lambat, setiap orang yang berurusan dengan server pasti mendengar salah satu kalimat ini — dan reaksi pertamanya biasanya langsung utak-atik asal sampai ada yang nyala. Itu hampir selalu berakhir buruk. Kamu mengubah tiga hal sekaligus, salah satunya tanpa sengaja memperbaikinya, dan kamu enggak tahu yang mana, jadi masalahnya balik lagi minggu depan dan kamu tersesat dari awal.

Ada cara yang lebih baik, dan ini bukan soal menghafal seratus perintah. Troubleshooting jaringan sebagian besar adalah soal pola pikir: kerja dari bawah ke atas, uji satu hal pada satu waktu, dan biarkan tiap hasil memberi tahu kamu harus melihat ke mana berikutnya. Artikel ini membahas pola pikir itu beserta sekumpulan kecil perintah universal yang menyertainya, supaya lain kali ada yang rusak kamu bisa tetap tenang dan benar-benar menemukan penyebabnya, bukan sekadar menebak.

Diagnosis berlapis, dari bawah ke atas

Satu ide paling berguna di seluruh dunia jaringan adalah bahwa koneksi terjadi dalam lapisan-lapisan yang bertumpuk satu di atas yang lain. Sebuah permintaan dari browser-mu ke server turun melewati lapisan-lapisan di mesinmu, menyeberangi kabel, lalu naik lagi lewat lapisan-lapisan di server. Kalau satu lapisan saja rusak, semua yang ada di atasnya ikut gagal — dan justru itulah kenapa menebak-nebak terasa menyiksa. Kamu mengutak-atik bagian atas (aplikasinya) padahal masalah sebenarnya ada tiga lapis di bawah.

Jadi balik logikanya. Mulai dari bawah dan naik perlahan. Tiap lapisan yang kamu pastikan sehat membuatmu bisa mencoret satu kategori penyebab sekaligus:

   ┌─────────────────────────────────────────┐
   │  5. Aplikasi    → service-nya sendiri     │   ← cek TERAKHIR
   │                   nyimak & menjawab?      │
   ├─────────────────────────────────────────┤
   │  4. Port / firewall → pintunya terbuka?   │
   ├─────────────────────────────────────────┤
   │  3. DNS         → namanya menerjemah ke    │
   │                   IP yang benar?          │
   ├─────────────────────────────────────────┤
   │  2. Routing     → paket bisa sampai ke    │
   │                   mesin lawan?            │
   ├─────────────────────────────────────────┤
   │  1. Link / lokal → interface-nya nyala?   │   ← cek PERTAMA
   │                    aku punya IP?          │
   └─────────────────────────────────────────┘

Kamu enggak selalu harus mulai dari dasar paling bawah — kalau kamu sudah bisa ping server lewat IP, berarti kamu sudah otomatis memastikan lapisan-lapisan bawah dan boleh loncat lebih jauh. Tapi waktu kamu benar-benar mentok, turun ke dasar paling bawah lalu naik perlahan itu enggak pernah bohong. Memang lambat dan metodis, tapi selalu menemukan jawabannya.

Lapisan 1: Mesinmu sendiri benar-benar terhubung ke jaringan?

Sebelum menyalahkan server, singkirkan dulu kemungkinan dari sisimu. Cukup banyak kasus “server-nya down” ternyata laptop yang nyambung ke Wi-Fi yang salah, atau VPN yang diam-diam putus.

Pertama, cek apakah interface jaringanmu nyala dan apakah kamu punya alamat IP sama sekali:

ip addr        # Linux: daftar interface beserta IP-nya
# (sistem lama pakai: ifconfig)

Yang kamu cari adalah interface yang bertuliskan UP dan punya IP asli di sebelah inet — kira-kira seperti inet 192.168.1.40. Kalau yang muncul cuma alamat loopback (127.0.0.1) dan tidak ada yang lain, berarti mesinmu enggak nyambung ke apa pun selain dirinya sendiri. Kalau kamu melihat alamat yang diawali 169.254. di kebanyakan sistem, itu alamat “self-assigned” yang artinya mesinmu sudah minta IP tapi enggak pernah dapat — biasanya masalah DHCP atau kabel/Wi-Fi.

Kalau interface-nya nyala dan punya IP, cek paling sederhana adalah mengajak bicara router atau gateway-mu sendiri:

ping 192.168.1.1     # gateway-mu — pintu keluar dari jaringan lokalmu

Kalau ini gagal, masalahnya murni lokal: kabel, Wi-Fi, atau gateway-mu. Belum perlu repot melihat server jauh. Kalau berhasil, jaringan lokalmu baik-baik saja dan kamu boleh naik ke lapisan berikutnya.

Lapisan 2: Paket benar-benar bisa sampai ke mesin lawan?

Sekarang uji apakah mesinmu bisa menjangkau tujuan sama sekali. Alat klasiknya adalah ping, yang mengirim paket kecil lalu menunggu balasan. Dia menjawab satu pertanyaan saja: apakah ujung sana terjangkau, dan berapa lama perjalanan bolak-baliknya?

ping 93.184.216.34       # ping sebuah server lewat alamat IP-nya

Ada tiga kemungkinan yang bisa terjadi, dan masing-masing menceritakan hal berbeda:

• Balasan datang — mesinnya terjangkau dan paket mengalir dua arah. Bagus. Lapisan-lapisan bawah sehat; naik.
• “Request timed out” atau packet loss 100% — paket berangkat tapi tidak ada yang kembali. Host-nya mungkin mati, tidak terjangkau, atau (sangat sering) memang sengaja disetel mengabaikan ping. Jangan terlalu percaya yang satu ini (lihat callout).
• “Destination host unreachable” / “no route to host” — mesinmu bahkan tidak tahu cara sampai ke sana. Itu masalah routing, dan sering lebih dekat ke rumah daripada yang kamu kira.

Saat ping menjangkau sesuatu tapi jalurnya terasa lambat atau labil, traceroute memperlihatkan rutenya lompatan demi lompatan — tiap router yang dilewati paketmu dalam perjalanan ke tujuan:

traceroute example.com    # Linux/macOS
# padanan di Windows: tracert example.com

Tiap baris adalah satu lompatan (hop). Kalau trace-nya sampai separuh jalan lalu tiap hop tersisa menampilkan * * *, kira-kira di situlah semuanya berhenti — sebuah router di jalur itu membuang paketmu atau tidak merespons. Kamu enggak selalu bisa memperbaiki hop yang bukan milikmu, tapi mengetahui di mana sebuah jalur mati itu sangat berharga saat kamu bicara dengan penyedia host atau jaringan.

Lapisan 3: Namanya menerjemah ke alamat yang benar?

Ini mode kegagalan yang terus-menerus mengelabui pemula: server-nya nyala, jaringan baik-baik saja, tapi namanya enggak diterjemahkan ke alamat IP yang benar. Tiap kali kamu mengetik sebuah hostname seperti example.com, mesinmu lebih dulu bertanya ke DNS untuk mengubah nama itu jadi IP. Kalau DNS memberi jawaban yang salah — atau enggak menjawab sama sekali — semua yang ada di belakangnya ikut gagal, dan kelihatannya seperti server-nya rusak padahal enggak.

Untuk menguji penerjemahan nama secara langsung, tanyakan sendiri ke DNS:

nslookup example.com
# atau, lebih rinci:
dig example.com

Kamu ingin melihat hostname memetakan ke alamat IP yang kamu harapkan. Dua kejutan yang sering muncul:

• Tidak ada jawaban / “server can’t find” / NXDOMAIN — namanya enggak diterjemah sama sekali. Mungkin salah ketik, domain kedaluwarsa, record DNS yang hilang, atau resolver DNS-mu sendiri yang rusak. Coba terjemahkan nama yang sudah pasti benar seperti google.com: kalau itu juga gagal, berarti resolver-mu yang bermasalah, bukan domainnya.
• Diterjemah, tapi ke IP yang salah — klasik setelah kamu memindahkan situs ke server baru. DNS masih menunjuk ke alamat lama, sering karena record yang ter-cache belum kedaluwarsa. Solusinya kesabaran (atau membetulkan record-nya), bukan me-restart server.

Trik praktis: kalau penerjemahan nama rusak tapi kamu tahu IP yang benar, ping atau sambungi IP-nya langsung. Kalau IP-nya jalan tapi namanya enggak, kamu baru saja membuktikan masalahnya ada di DNS, bukan di server. Satu pengujian itu bisa menghemat berjam-jam. (DNS punya banyak hal yang bekerja di balik layar — kalau lapisan ini sering menggigitmu, pembahasan DNS mendalam layak kamu luangkan.)

Lapisan 4: Port tertentunya terbuka dan terjangkau?

Menjangkau sebuah mesin itu beda dengan menjangkau service di dalamnya. Sebuah web server menyimak di port tertentu — biasanya 80 untuk HTTP atau 443 untuk HTTPS — dan database, mail server, atau SSH masing-masing punya port sendiri. Mesinnya bisa nyala sempurna sementara satu port yang kamu butuhkan justru tertutup, diblokir firewall, atau enggak ada yang menyimak di belakangnya.

Untuk menguji apakah kamu benar-benar bisa membuka koneksi ke sebuah port, alat paling universal adalah nc (netcat):

nc -zv example.com 443     # coba sambung ke port 443; -z = scan saja, -v = verbose

Pesan “succeeded” atau “open” berarti jalur sampai ke port itu bersih dan ada yang menyimak. “Connection refused” berarti kamu sampai ke mesinnya tapi tidak ada yang menyimak di port itu — service-nya kemungkinan mati atau ter-bind ke alamat yang salah. “Timeout” (cuma menggantung) biasanya menandakan firewall yang diam-diam membuang paketmu, bukan menolaknya.

Perbedaan itu benar-benar berguna:

   refused   → sampai ke host, tapi port-nya tertutup / service mati
   timeout   → ada sesuatu (biasanya firewall) menelan paket diam-diam
   open      → pintunya terbuka; masalahnya lebih ke atas (aplikasinya)

Khusus untuk web server, kamu bisa langsung ke protokol aslinya dengan curl, yang benar-benar berbicara HTTP dan menunjukkan apa yang dijawab server:

curl -v https://example.com

Output verbose-nya menelusuri seluruh proses jabat tangan: lookup DNS, koneksi TCP, negosiasi TLS, dan akhirnya baris status HTTP yang dikirim balik oleh server. Kalau curl dapat 200 OK, berarti service-nya bekerja dan masalahmu ada di tempat lain (client, browser, sebuah proxy). Kalau dia tersendat di “Trying…” berarti kamu kembali ke urusan koneksi atau firewall. curl sering jadi cara tercepat menguji sebuah web service dari ujung ke ujung. (Kalau port yang tertutup ternyata memang firewall yang disengaja, artikel soal firewall menjelaskan bagaimana aturan-aturan itu menentukan apa yang boleh lewat.)

Lapisan 5: Service-nya sendiri benar-benar menyimak?

Kalau kamu sudah memastikan semua lapisan di bawah dan port-nya tetap menolak koneksi, berarti masalahnya ada di service — dia crash, enggak pernah jalan, atau menyimak di alamat yang salah. Sekarang kamu cek dari sisi server-nya sendiri (lewat SSH kalau dia remote). Pertanyaannya jadi: benar-benar ada yang menyimak di port yang kuharapkan?

ss -tlnp        # tampilkan port TCP yang sedang DISIMAK oleh mesin
# (sistem lama: netstat -tlnp)

Tiap baris adalah socket yang sedang disimak oleh mesin. Cari port-mu di daftar itu. Dua temuan klasik:

• Port-nya enggak ada di daftar sama sekali — service-nya enggak jalan. Jalankan (atau cek log-nya untuk lihat kenapa dia mati saat start). “Connection refused” dari luar tadi pas banget dengan kondisi ini.
• Dia menyimak di 127.0.0.1:PORT bukannya 0.0.0.0:PORT — ini yang licik. Ter-bind ke 127.0.0.1 (loopback), service-nya cuma menjawab permintaan dari mesin yang sama dan diam-diam mengabaikan semua orang di jaringan. “Jalan di lokal” tapi enggak bisa dijangkau dari luar. Solusinya adalah mem-bind-nya ke 0.0.0.0 (semua interface) atau ke alamat jaringan yang benar.

Perbedaan 127.0.0.1 versus 0.0.0.0 itu ada di balik sangat banyak misteri “di laptopku jalan, di production enggak”. Layak banget kamu hafalkan kuat-kuat.

Contoh nyata: merangkai semua lapisan

Bayangkan seseorang di ACY Partner Indonesia melaporkan bahwa dashboard internal perusahaan di dashboard.example.com “down”. Alih-alih panik, John Doe menyusuri tangganya:

1. ping gateway            → balas         ✓ jaringanku oke
2. nslookup dashboard...    → resolve ke 10.0.5.20   ✓ DNS oke
3. ping 10.0.5.20           → request timed out       ?  (bisa jadi ICMP diblokir)
4. nc -zv 10.0.5.20 443     → connection refused       → sampai host, port tertutup!
5. (ssh masuk) ss -tlnp     → enggak ada di :443       → web service-nya enggak jalan
   → cek log service        → "failed to start: config error on line 12"

Dalam lima langkah yang cepat dan disengaja, dia berangkat dari “down” yang samar menuju penyebab yang presisi: salah ketik di sebuah file config menghentikan web service dari proses start. Tanpa me-restart hal acak, tanpa menebak — tiap perintah mempersempit pencarian sampai penyebabnya enggak punya tempat sembunyi lagi. Itulah inti permainannya.

Kotak perkakas troubleshooting yang ringkas

Kamu enggak butuh banyak. Perintah-perintah ini mencakup mayoritas besar masalah jaringan sehari-hari, dan kebanyakan sudah tersedia bawaan sistem:

• ip addr — aku punya interface yang berfungsi dan sebuah IP? (Lapisan 1)
• ping — aku bisa menjangkau mesin itu sama sekali? (Lapisan 2)
• traceroute / tracert — di titik mana sepanjang jalur paketnya mati? (Lapisan 2)
• nslookup / dig — namanya menerjemah ke IP yang benar? (Lapisan 3)
• nc -zv host port — port tertentu itu terjangkau? (Lapisan 4)
• curl -v url — web service-nya benar-benar menjawab, dari ujung ke ujung? (Lapisan 4)
• ss -tlnp / netstat — service-nya menyimak, dan di alamat yang mana? (Lapisan 5)

Tahu kapan harus meraih masing-masing itu jauh lebih penting daripada menghafal tiap flag. Model lapisan tadi yang memberi tahu kapannya. (Sudah nyaman dengan perintah-perintah ini tapi masih goyah dengan shell-nya sendiri? Dasar command line bakal bikin semua ini terasa jauh lebih akrab.)

Penutup

Lain kali jaringan bermasalah, ini seluruh pendekatannya dalam satu tempat:

• Diagnosis berlapis, dari bawah ke atas. Pastikan tiap lapisan sehat sebelum naik ke berikutnya; lapisan yang rusak merusak semua yang ada di atasnya.
• Lapisan 1 — lokal: interface-mu sendiri nyala dan kamu punya IP? Ping gateway-mu lebih dulu.
• Lapisan 2 — keterjangkauan: ping dan traceroute memberi tahu apakah (dan di mana) paket sampai ke tujuan.
• Lapisan 3 — DNS: nslookup/dig memastikan namanya menerjemah ke IP yang benar. Uji IP-nya langsung untuk mengisolasi DNS.
• Lapisan 4 — port: nc dan curl menguji apakah port dan service tertentu terjangkau. Refused vs timeout vs open masing-masing berarti hal berbeda.
• Lapisan 5 — service-nya: ss/netstat menunjukkan apakah ada yang menyimak, dan di alamat yang mana. Awasi 127.0.0.1 vs 0.0.0.0.
• Ubah satu hal pada satu waktu, dan baca log-nya. Itu yang mengubah menebak jadi mendiagnosis.

Begitu kamu nyaman dengan tangga ini, “server-nya down” berhenti jadi momen mencekam dan berubah jadi penyelidikan singkat yang malah terasa memuaskan. Perkakasnya sederhana; disiplin memakainya secara berurutan itulah yang membuatmu cepat.