KodelokaUrutan Diagnosis yang Sistematis
1. Apakah namanya bisa diselesaikan? → dig / nslookup 2. Apakah hostnya hidup? → ping (bila ICMP diizinkan) 3. Apakah portnya terbuka? → nc -zv / telnet 4. Apakah aplikasinya menjawab? → curl -v 5. Apakah paketnya benar-benar sampai? → tcpdump
Mengikuti urutan ini mencegah Anda menghabiskan waktu memeriksa aplikasi padahal masalahnya ada di DNS.
DNS
dig api.contoh.com dig +short api.contoh.com dig @8.8.8.8 api.contoh.com # tanya resolver tertentu dig api.contoh.com MX dig +trace api.contoh.com # telusuri dari akar cat /etc/resolv.conf # resolver yang dipakai sistem getent hosts api.contoh.com # mengikuti /etc/nsswitch.conf
dig tidak membaca /etc/hostsdig berbicara langsung ke server DNS, sementara aplikasi Anda memakai resolver sistem yang juga memeriksa /etc/hosts. Akibatnya bisa membingungkan: dig mengembalikan satu alamat, aplikasi terhubung ke alamat lain. Gunakan getent hosts untuk melihat apa yang benar-benar dilihat aplikasi.
Memeriksa Port
ss -tulpn # port yang didengarkan di mesin ini ss -tan state established # koneksi yang sedang aktif ss -s # ringkasan statistik soket nc -zv api.contoh.com 443 # apakah port terbuka timeout 3 bash -c '</dev/tcp/api.contoh.com/443' && echo terbuka
ss -tulpn0.0.0.0:8080— mendengarkan di semua antarmuka, terjangkau dari luar.127.0.0.1:8080— hanya dari mesin itu sendiri.[::]:8080— semua antarmuka IPv6.
Layanan yang "tidak bisa dihubungi dari luar" sangat sering ternyata hanya mendengarkan di 127.0.0.1. Ini juga penyebab umum aplikasi di dalam kontainer tidak terjangkau — di kontainer, aplikasi harus mendengarkan 0.0.0.0, bukan localhost.
curl untuk Diagnosis
curl -v https://api.contoh.com/healthz # lihat seluruh jabat tangan
curl -I https://api.contoh.com # header saja
curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://api.contoh.com
# Rincian waktu — sangat berguna untuk menemukan tahap yang lambat
curl -s -o /dev/null -w '
dns : %{time_namelookup}s
koneksi : %{time_connect}s
tls : %{time_appconnect}s
byte 1 : %{time_starttransfer}s
total : %{time_total}s
' https://api.contoh.com
# Melewati DNS untuk menguji server tertentu
curl -v --resolve api.contoh.com:443:10.0.0.5 https://api.contoh.com
# Memeriksa sertifikat
echo | openssl s_client -connect api.contoh.com:443 -servername api.contoh.com 2>/dev/null \
| openssl x509 -noout -dates -subject -issuer
Bila time_namelookup besar, masalahnya DNS. Bila time_connect besar, jaringan atau firewall. Bila time_appconnect besar, negosiasi TLS. Bila hanya time_starttransfer yang besar, aplikasinya yang lambat. Satu perintah memisahkan empat kemungkinan.
Firewall
# ufw (Ubuntu/Debian) ufw status verbose ufw allow 22/tcp ufw allow from 10.0.0.0/8 to any port 5432 ufw enable # firewalld (RHEL/Fedora) firewall-cmd --list-all firewall-cmd --add-port=8080/tcp --permanent firewall-cmd --reload # iptables mentah iptables -L -n -v
Menjalankan ufw enable tanpa lebih dulu mengizinkan port 22 akan memutus sesi SSH Anda seketika, dan bila tidak ada akses konsol, server itu praktis hilang. Selalu izinkan SSH lebih dulu. Untuk perubahan firewall yang berisiko, pasang jaring pengaman:
# Batalkan otomatis dalam 5 menit bila Anda tidak membatalkannya echo "ufw disable" | at now + 5 minutes # ...uji koneksi baru... # bila berhasil: atrm <nomor-job>
Melihat Paket
tcpdump -i any -n port 8080 tcpdump -i any -n host 10.0.0.5 and port 5432 tcpdump -i any -n -A port 80 | head -50 # tampilkan isi ASCII tcpdump -i any -w tangkapan.pcap port 443 # simpan untuk Wireshark
Ketika semua lapisan di atas tampak benar tetapi koneksi tetap gagal, tcpdump menjawab pertanyaan yang tidak bisa dijawab alat lain: apakah paketnya benar-benar sampai? Melihat SYN terkirim tanpa SYN-ACK kembali langsung menunjuk ke firewall atau routing, bukan ke aplikasi.