Tools Diagnostik #

Mendiagnosis masalah Nginx dan jaringan pendukungnya secara efektif membutuhkan pemahaman yang mendalam terhadap alat bantu (tools) yang tepat. Beberapa perkakas diagnostik ini sudah terpasang secara bawaan di hampir setiap distribusi sistem operasi Linux, sementara sebagian lainnya merupakan utilitas pihak ketiga yang dapat kita pasang sesuai kebutuhan.

Mengenal kegunaan masing-masing perkakas, memahami parameter perintahnya, serta mengetahui kapan harus menggunakannya adalah keterampilan penting yang setara nilainya dengan memahami sintaksis konfigurasi Nginx itu sendiri. Di artikel ini, kita akan membahas cara menggunakan berbagai perkakas diagnostik untuk menganalisis koneksi HTTP, menginspeksi SSL, memantau socket jaringan, melakukan pelacakan system call, hingga menyusun monitoring berkelanjutan.

Korelasi Tools Diagnostik pada Siklus Request-Response #

Dalam mengisolasi masalah, kita harus melacak pada titik mana kegagalan terjadi di sepanjang siklus permintaan dan respons. Berikut adalah diagram alur yang menunjukkan korelasi perkakas diagnostik pada setiap lapisan komunikasi Nginx:

flowchart LR
    Klien["1. Klien Browser / App"] -->|"curl -v / openssl s_client"| NginxSSL["2. Nginx SSL Termination"]
    NginxSSL -->|"ss -tlnp / netstat"| NginxSocket["3. TCP Sockets"]
    NginxSocket -->|"strace / sysctl"| NginxOS["4. OS Kernel / Syscalls"]
    NginxOS -->|"GoAccess / access.log"| Backend["5. Backend Server (Node.js/PHP)"]

    classDef default fill:#f9f9f9,stroke:#d1d5db,stroke-width:1px,color:#111827;
    classDef toolStyle fill:#fffbeb,stroke:#d97706,stroke-width:2px,color:#78350f;
    class Klien,NginxSSL,NginxSocket,NginxOS,Backend toolStyle;

curl: Swiss Army Knife HTTP #

Perkakas pertama yang wajib kita gunakan saat terjadi kendala akses web adalah curl. Utilitas CLI ini memungkinkan kita melakukan permintaan HTTP/HTTPS secara presisi tanpa terpengaruh oleh penyimpanan cache atau JavaScript browser lokal.

1. Request Dasar dengan Verbose Output #

Gunakan flag -v (verbose) untuk melihat seluruh percakapan HTTP antara klien dan Nginx, termasuk proses DNS resolution, handshake TLS, header permintaan yang dikirim browser, dan header respons dari server.

curl -v https://app.unisbadri.com/

2. Membaca Header Respons Saja #

Gunakan flag -I (Capital i) untuk melakukan request HEAD guna melihat ringkasan header respons tanpa mengunduh seluruh isi body halaman (sangat berguna untuk memeriksa Cache-Control, Server tokens, atau Security Headers):

curl -I https://app.unisbadri.com/

3. Menguji Domain Tanpa Perubahan DNS (DNS Spoofing) #

Jika kita baru mendeploy konfigurasi virtual host HTTPS baru di server dan domain belum mengarah ke IP server kita secara publik, kita dapat memaksa curl mengabaikan DNS global dan langsung menembak IP server kita untuk domain tersebut menggunakan flag --resolve:

# Format: --resolve DOMAIN:PORT:IP_SERVER
curl -v --resolve app.unisbadri.com:443:203.0.113.10 https://app.unisbadri.com/

4. Melacak Waktu Pemrosesan HTTP (Profiling) #

Kita dapat membuat skrip profil internal untuk memetakan berapa milidetik yang dihabiskan untuk lookup DNS, koneksi TCP, negosiasi SSL, waktu tunggu respons pertama (TTFB), dan total waktu unduhan:

curl -o /dev/null -s -w \
    "DNS Lookup: %{time_namelookup}s\nTCP Connect: %{time_connect}s\nSSL Handshake: %{time_appconnect}s\nTTFB (First Byte): %{time_starttransfer}s\nTotal Time: %{time_total}s\n" \
    https://app.unisbadri.com/

openssl s_client: Debug SSL/TLS #

Ketika curl mengembalikan galat koneksi SSL (seperti SSL_ERROR_SYSCALL), kita harus beralih menggunakan utilitas openssl s_client untuk melakukan inspeksi mendalam di tingkat protokol enkripsi.

1. Memeriksa Sertifikat dan Rantai Kepercayaan (Chain of Trust) #

Nginx harus mengembalikan sertifikat domain beserta sertifikat intermediate CA secara utuh. Kita dapat memverifikasinya menggunakan perintah:

echo | openssl s_client -connect app.unisbadri.com:443 -servername app.unisbadri.com -showcerts

Perhatikan daftar Certificate chain. Jika chain terputus, browser klien akan menampilkan warning tidak aman meskipun sertifikat domain kita valid.

2. Menguji Protokol TLS Tertentu #

Untuk memverifikasi apakah server Nginx kita sudah menonaktifkan protokol usang secara benar sesuai aturan pengerasan keamanan, kita dapat memaksa koneksi menggunakan versi TLS tertentu:

# Menguji apakah server menerima TLS 1.0 (Harus ditolak / Connection refused)
echo | openssl s_client -connect app.unisbadri.com:443 -tls1

# Menguji apakah server menerima TLS 1.2 (Harus diterima)
echo | openssl s_client -connect app.unisbadri.com:443 -tls1_2

# Menguji apakah server menerima TLS 1.3 (Harus diterima)
echo | openssl s_client -connect app.unisbadri.com:443 -tls1_3

ss dan netstat: Inspeksi Koneksi TCP #

Untuk mengetahui apakah masalah ada pada lapisan jaringan (seperti port yang diblokir, antrean socket penuh, atau kehabisan port lokal), kita menggunakan utilitas ss (pengganti modern dari netstat).

1. Memeriksa Semua Port yang Sedang Listen #

Langkah awal untuk mendeteksi konflik port adalah melihat proses apa saja yang sedang mendengarkan lalu lintas masuk:

sudo ss -tlnp
# -t: TCP, -l: Listening, -n: Numerik (tampilkan port angka), -p: Tampilkan nama proses

2. Menganalisis Distribusi State Koneksi TCP #

Lalu lintas socket TCP melewati berbagai tahapan siklus hidup. Kita bisa menghitung seberapa banyak koneksi Nginx kita yang berada di setiap state:

sudo ss -tn | awk '{print $1}' | sort | uniq -c

ESTABLISHED: Koneksi aktif yang sedang bertukar data.
TIME_WAIT: Koneksi yang telah ditutup oleh Nginx tetapi sistem operasi menahan socket tersebut selama beberapa menit sebelum dibersihkan (untuk memastikan sisa paket data jaringan di jalan tiba). Jika jumlah TIME_WAIT terlalu tinggi (puluhan ribu), ini tanda bahwa kita tidak menyalakan HTTP Keepalive pada server kita, sehingga setiap request memicu pembukaan dan penutupan socket TCP baru.
CLOSE_WAIT: Menandakan bahwa server backend aplikasi kita lambat menutup socket setelah koneksi selesai. Terlalu banyak CLOSE_WAIT merupakan indikasi kebocoran koneksi di sisi aplikasi backend.

strace: Debug Syscall Level Rendah #

Ketika Nginx mengembalikan galat aneh di log seperti Permission denied tetapi kita sudah memperbaiki chown/chmod berkas, kita dapat menggunakan strace untuk melihat apa yang terjadi di tingkat kernel Linux saat proses worker Nginx mencoba mengakses berkas.

strace memantau dan mencatat panggilan sistem (system calls / syscalls) yang dilakukan oleh proses berjalan.

# 1. Cari nomor PID dari salah satu worker process Nginx yang aktif
pgrep -x nginx

# 2. Lakukan trace syscall khusus untuk operasi file dan network pada PID tersebut
sudo strace -p <PID_WORKER> -e trace=file,network

Saat kita mengirimkan request dari browser, strace akan langsung memuntahkan baris syscall di terminal secara real-time:

openat(AT_FDCWD, "/var/www/html/secret.txt", O_RDONLY) = -1 EACCES (Permission denied)

Dari keluaran di atas, terlihat jelas syscall openat gagal dengan kode EACCES karena terhambat oleh kebijakan keamanan (seperti AppArmor atau SELinux), yang membuktikan bahwa masalah bukan terletak pada sintaksis Nginx, melainkan batasan keamanan sistem operasi.

tcpdump: Menganalisis Lalu Lintas Jaringan Tingkat Rendah #

Ketika Nginx mengembalikan galat koneksi yang terputus secara misterius (misalnya klien gagal mengirimkan request body besar atau koneksi upstream terputus di tengah jalan), dan strace tidak cukup memberikan informasi, kita harus turun ke tingkat paket jaringan menggunakan tcpdump.

tcpdump merekam paket TCP/IP yang melintasi kartu jaringan (network interface) server kita.

Menangkap Paket TCP pada Port Tertentu (Port 80/443):

# Tangkap paket di interface eth0 yang menuju atau berasal dari port 443
sudo tcpdump -i eth0 port 443 -vv -XX
# -i: interface, -vv: sangat verbose, -XX: tampilkan data dalam format heksadesimal dan ASCII

Menyimpan Hasil Tangkapan untuk Wireshark: Membaca baris paket di terminal sangatlah rumit. Praktik terbaiknya adalah merekam paket ke dalam berkas .pcap lalu menganalisisnya menggunakan aplikasi visual Wireshark di komputer lokal kita:
```
# Tangkap 1000 paket pertama pada port 443 dan simpan ke file dump
sudo tcpdump -i any port 443 -c 1000 -w /tmp/ssl_handshake.pcap
```
Mendeteksi TCP Reset (RST): Dalam kasus debugging connection reset, kita dapat memfilter paket tcpdump untuk hanya mencari bendera (flags) TCP RST yang dikirim oleh Nginx atau backend:
```
sudo tcpdump -i any 'tcp[tcpflags] & tcp-rst != 0' -nn
```
Jika kita melihat aliran paket RST segera setelah TLS Client Hello dikirim, berarti ada ketidakcocokan cipher suite TLS di level network.

Mendiagnosis Kebocoran File Descriptor (FD) #

Nginx mengonsumsi satu File Descriptor (FD) untuk setiap file statik yang dibuka, file log yang ditulis, dan setiap koneksi socket TCP aktif (klien dan upstream). Jika server Nginx kita mengalami trafik tinggi dan tiba-tiba menolak koneksi dengan pesan log socket() failed (24: Too many open files), berarti Nginx telah mencapai batas maksimum file descriptor yang diizinkan oleh kernel Linux.

Kita dapat mendiagnosis kendala ini menggunakan perintah berikut:

Periksa Limit Proses Nginx Aktif: Kita dapat melihat batas limit soft dan hard file descriptor yang sedang berlaku pada proses master Nginx kita:

# Dapatkan PID master Nginx
PID=$(cat /run/nginx.pid)

# Tampilkan limits file descriptor (Max open files)
cat /proc/$PID/limits | grep "Max open files"
# Output standard biasanya: Soft Limit 1024, Hard Limit 4096

Hitung FD yang Sedang Digunakan: Kita dapat menghitung berapa banyak FD yang sedang aktif dibuka oleh seluruh worker process Nginx saat ini:
```
# Hitung jumlah file descriptor terbuka di /proc
sudo lsof -c nginx | wc -l
```
Melacak Jenis FD yang Terbuka: Gunakan perintah lsof untuk melihat detail file atau koneksi socket apa saja yang sedang digenggam oleh Nginx:
```
sudo lsof -p $PID
# Output akan menampilkan tipe FD: REG (berkas reguler), IPv4/IPv6 (socket TCP), atau FIFO (pipe)
```
Jika kita melihat ribuan socket dalam status can't identify protocol, itu mengindikasikan backend upstream mengalami hang dan koneksi socket tertahan menggantung di memory (descriptor leak).

ab dan wrk: Load Testing Stabilitas #

Sebelum mempublikasikan konfigurasi optimasi performa baru ke lingkungan produksi, kita wajib menguji batas ketahanan server menggunakan perkakas pengujian beban (load testing).

1. Penggunaan Apache Benchmark (ab) #

ab sangat praktis untuk pengujian konkurensi cepat:

# Kirim total 5000 request dengan 50 koneksi simultan secara persisten (keepalive)
ab -n 5000 -c 50 -k https://app.unisbadri.com/

2. Penggunaan wrk (Berbasis Multi-Thread) #

wrk jauh lebih modern dan mampu menyimulasikan beban trafik yang masif karena berjalan secara multi-thread memanfaatkan seluruh core CPU laptop kita:

# Jalankan uji beban selama 30 detik menggunakan 4 thread dan 100 koneksi simultan
wrk -t4 -c100 -d30s https://app.unisbadri.com/

Output wrk akan menampilkan metrik rata-rata latensi (Latency) dan throughput request per detik (Requests/sec). Jika kita melihat persentase error yang tinggi, berarti konfigurasi batas file descriptor atau upstream buffer di Nginx kita perlu disesuaikan.

GoAccess: Analisis Log Real-Time Visual #

Membaca berkas teks log Nginx secara manual menggunakan perintah tail atau grep sangat membantu untuk satu kasus, tetapi sulit digunakan untuk melihat pola tren lalu lintas secara keseluruhan.

GoAccess adalah penganalisis log interaktif yang membaca berkas log access Nginx secara langsung dan menampilkannya sebagai dashboard visual yang indah di dalam terminal atau mengekspornya sebagai halaman HTML dinamis.

# Jalankan analisis log real-time interaktif di terminal
sudo goaccess /var/log/nginx/access.log --log-format=COMBINED

# Generate dashboard visual dalam format berkas HTML sekali jalan
sudo goaccess /var/log/nginx/access.log --log-format=COMBINED -o /var/www/html/report.html

Dashboard HTML GoAccess akan memperbarui visualisasi secara otomatis setiap kali ada baris log baru masuk. Kita bisa memantau IP pengunjung teraktif, rute API yang paling sering lambat, hingga sebaran status code (2xx, 3xx, 4xx, 5xx) secara instan.

Prometheus + Grafana: Monitoring Berkelanjutan #

Untuk memantau kesehatan server Nginx secara jangka panjang, kita tidak bisa mengandalkan perintah manual. Kita harus menyusun metrik pemantauan otomatis menggunakan Prometheus dan memvisualisasikannya di Grafana.

1. Aktifkan stub_status di Nginx #

Prometheus membutuhkan endpoint metrik mentah untuk ditarik. Kita mengaktifkan modul status bawaan Nginx:

server {
    listen 127.0.0.1:8080;
    server_name localhost;

    location /nginx_status {
        stub_status on;
        access_log off;
        allow 127.0.0.1;
        deny all;
    }
}

2. Jalankan nginx-prometheus-exporter #

Exporter akan membaca halaman /nginx_status Nginx lokal dan menerjemahkannya ke format metrik yang dipahami Prometheus:

# Jalankan exporter menggunakan Docker container
docker run -d \
    -p 9113:9113 \
    nginx/nginx-prometheus-exporter:latest \
    -nginx.scrape-uri=http://localhost:8080/nginx_status

3. Konfigurasikan Scrape Target di Prometheus #

Tambahkan target exporter pada file konfigurasi prometheus.yml:

scrape_configs:
  - job_name: 'nginx_exporter'
    static_configs:
      - targets: ['localhost:9113']

Melalui Grafana, kita dapat memetakan grafik historis metrik krusial seperti:

nginx_connections_active: Jumlah koneksi aktif yang sedang ditangani Nginx.
nginx_connections_waiting: Koneksi keepalive yang sedang idle menunggu request berikutnya.
nginx_http_requests_total: Total akumulasi request yang masuk ke server kita.

Checklist Diagnostik Cepat #

Berikut adalah langkah-langkah darurat yang wajib kita eksekusi saat server Nginx mengalami kendala:

# 1. Pastikan proses Nginx sedang berjalan aktif
sudo systemctl status nginx

# 2. Verifikasi kebersihan sintaksis konfigurasi
sudo nginx -t

# 3. Cek apakah port 80 dan 443 sudah berstatus listen
sudo ss -tlnp | grep nginx

# 4. Tampilkan 50 baris error terbaru untuk mencari pesan emerg/error
sudo tail -n 50 /var/log/nginx/error.log

# 5. Uji respon backend secara langsung tanpa melewati Nginx
curl -I http://localhost:3000/health

# 6. Pastikan request benar-benar sampai ke Nginx
sudo tail -f /var/log/nginx/access.log

# 7. Cek apakah resolusi DNS mengarah ke IP server yang benar
dig +short app.unisbadri.com

# 8. Pastikan firewall tidak memblokir akses port luar
sudo ufw status || sudo iptables -L -n

Ringkasan #

curl -v: Langkah awal wajib untuk memeriksa alur percakapan HTTP, TLS handshake, dan data header respons.
openssl s_client: Gunakan khusus untuk memecahkan galat SSL, memvalidasi masa berlaku sertifikat, dan menguji TLS protocol compatibility.
ss -tn: Pantau distribusi TCP states untuk mendeteksi penumpukan socket idle (TIME_WAIT) akibat ketiadaan keepalive.
strace: Trace panggilan sistem di tingkat kernel OS untuk mendiagnosis kendala perizinan file tersembunyi.
GoAccess: Solusi analisis visual real-time cepat tanpa perlu membangun infrastruktur ELK Stack yang kompleks.

← Sebelumnya: Debug Konfigurasi Berikutnya: Best Practices →