Website Down, tetapi Server Dapat Dijangkau? Lacak Kegagalan dari DNS ke App

“SSH Bekerja, Situs Tidak” — Mulai dengan Pertanyaan yang Tepat

Alert mulai berbunyi, pengguna mengatakan situs mati, dan tes pertama Anda memberikan semacam kelegaan: SSH masih membiarkan Anda masuk. Momen itu terasa menenangkan karena server tidak hilang. Tetapi ini juga merupakan tempat di mana banyak troubleshooting yang buruk dimulai, karena “Saya masih bisa masuk” bukanlah hal yang sama dengan “situs web harus berfungsi.”

Pertanyaan yang berguna bukan “apa yang bisa saya restart terlebih dahulu?” Tetapi “layer mana yang gagal terlebih dahulu?” Sesi SSH yang berfungsi membuktikan mesin dapat dijangkau di port 22. Ini tidak membuktikan domain resolve dengan benar. Ini tidak membuktikan:

• port 80 dan 443 dapat dijangkau
• HTTPS sehat
• aplikasi di belakang web server menjawab

Panduan ini dibangun di sekitar perbedaan itu, dan tetap fokus pada diagnosis daripada mencoba menjadi manual nginx, DNS, TLS, Docker, atau database lengkap.

⚠️ Peringatan: Blindly restart nginx, Docker, PHP-FPM, atau seluruh VPS di menit-menit pertama insiden dapat menghapus petunjuk yang Anda butuhkan. Kumpulkan satu putaran bukti terlebih dahulu, kemudian ubah hanya layer yang benar-benar gagal.

Peta Triage Satu Menit

Sebelum Anda menggali lebih dalam, orientasikan diri Anda. Bentuk kegagalan sering kali memberi tahu Anda lapisan mana yang layak mendapat perhatian terlebih dahulu, bahkan ketika Anda belum mengetahui akar penyebabnya.

Perlakukan tabel berikut sebagai jalan pintas triage, bukan putusan final.

Yang penting adalah tahap pertama yang rusak. Jika DNS gagal, lapisan yang lebih dalam adalah kebisingan. Jika 443 menjawab tetapi TLS rusak, aplikasi bukan pertanyaan pertama Anda. Model mental di bawah ini adalah apa yang membuat urutan itu terasa logis daripada acak.

Mengapa SSH Tidak Membuktikan Website Berfungsi

SSH dan web traffic adalah jalur berbeda dengan pekerjaan berbeda. SSH pada port 22 membuktikan Anda dapat menjangkau mesin melalui pintu manajemen jarak jauhnya. Website bergantung pada port 80 dan 443, plus lapisan di baliknya. Ini adalah tes terpisah, jadi “server terjangkau” dan “website terjangkau” bukan pernyataan yang dapat dipertukarkan.

Cara termudah untuk membayangkannya adalah sebagai gedung kantor. DNS membantu pengunjung menemukan alamat gedung. Port 80 dan 443 adalah meja depan untuk pengunjung publik. Web server adalah resepsionis yang menerima permintaan dan memutuskan ke mana selanjutnya. Aplikasi adalah kantor yang melakukan pekerjaan sebenarnya. Database atau dependensi lain mungkin berada lebih dalam di gedung. SSH adalah pintu masuk yang berbeda sama sekali. Ini berguna untuk staf, tetapi tidak membuktikan bahwa meja depan terbuka atau bahwa penyerahan kantor berfungsi.

Browser
  ↓
DNS lookup
  ↓
IP address
  ↓
Port 80 / 443
  ↓
Web server
  ↓
App / upstream
  ↓
Database / dependency

Ketika orang mengatakan layanan “listening,” mereka berarti layanan tersebut benar-benar menerima koneksi pada endpoint yang diharapkan. Itulah perbedaan yang mengubah momen “server sedang aktif” yang samar menjadi jalur permintaan yang dapat dilacak.

Itu penting karena HTTPS dapat gagal sebelum aplikasi pernah menjawab, dan kegagalan proxy atau aplikasi dapat terjadi setelah frontend sudah terjangkau. Jadi langkah berikutnya selalu sama: lihat dari luar terlebih dahulu dan temukan tahap terakhir yang berhasil dari permintaan.

Langkah 1: Reproduksi Kegagalan dari Luar Server

Mulai dari sisi klien, bukan dari dalam VPS. Jika memungkinkan, uji dari jaringan atau perangkat lain terlebih dahulu sehingga Anda tidak membingungkan cache DNS lokal, entri /etc/hosts lama, atau masalah firewall/VPN lokal dengan pemadaman server yang sebenarnya.

Gunakan permintaan eksternal yang verbose sehingga Anda dapat melihat seberapa jauh permintaan berjalan sebelum gagal:

curl -v --connect-timeout 5 --max-time 15 https://example.com/

curl -v bukan alat khusus ahli di sini. Bacanya sebagai jejak kemajuan. Jika tidak pernah menyelesaikan nama, Anda berada di cabang DNS. Jika terhubung dan kemudian mengatakan Connection refused, host menjawab tetapi tidak ada yang berguna menerima lalu lintas di sana. Jika tergantung sampai timeout, pikirkan penyaringan, perutean, atau hang yang lebih dalam nanti di jalur permintaan. Jika Anda menerima respons HTTP, bahkan halaman kesalahan, Anda sudah melampaui lapisan koneksi dan masuk ke cabang yang lebih tinggi.

💡 Tip: Bandingkan IPv4 dan IPv6 lebih awal. Catatan AAAA yang terlupakan dapat membuat pemadaman terlihat tidak konsisten karena beberapa klien lebih suka IPv6 terlebih dahulu dan yang lain tidak.

Jalankan tes yang sama sekali per keluarga protokol ketika dual stack sedang dimainkan:

curl -4 -v --connect-timeout 5 --max-time 15 https://example.com/
curl -6 -v --connect-timeout 5 --max-time 15 https://example.com/

Jika IPv4 berfungsi dan IPv6 gagal, atau sebaliknya, Anda sudah mempersempit insiden lebih cepat daripada restart layanan yang pernah ada. Jika kegagalan dimulai pada resolusi nama atau pilihan tujuan, DNS adalah cabang bersih berikutnya untuk diperiksa.

Langkah 2: Periksa DNS dan Konfirmasi Tujuan yang Benar

Sebelum Anda men-debug nginx, konfirmasi bahwa domain benar-benar mengirim pengunjung ke server yang Anda pikir. Hal ini sangat penting setelah migrasi, perubahan IP, penyesuaian CDN, atau pengeditan catatan sebagian.

Periksa catatan publik terlebih dahulu:

dig +short A example.com
dig +short AAAA example.com

Dua baris ini menjawab pertanyaan yang sangat praktis: di mana internet percaya example.com berada sekarang? Satu bentuk kegagalan umum adalah SSH berdasarkan IP mencapai VPS baru, tetapi domain masih menunjuk ke alamat lama. Yang lain adalah bahwa catatan A diperbarui, tetapi catatan AAAA masih menunjuk ke tempat yang sudah usang. Dalam hal itu, hanya sebagian dari lalu lintas Anda yang gagal.

📝 Catatan: curl --resolve lebih aman daripada mengubah DNS publik di tengah insiden. Ini memungkinkan Anda menguji asal yang Anda maksudkan sambil menjaga nama host dan SNI tetap utuh.

Gunakan curl --resolve untuk memaksa pengujian terhadap IP yang Anda harapkan tanpa menyentuh catatan publik:

curl --resolve example.com:443:203.0.113.10 https://example.com/

Jika itu berfungsi sementara domain publik masih gagal, server mungkin baik-baik saja dan DNS mungkin masih menjadi lapisan yang rusak. Satu catatan CDN terbatas layak diingat di sini. Jika asal Anda dikunci untuk menerima lalu lintas hanya dari rentang IP CDN, pengujian asal langsung mungkin gagal hanya karena asal mengharapkan lalu lintas edge, bukan permintaan publik arbitrer. Setelah tujuan dikonfirmasi, pertanyaan berikutnya adalah apakah ada yang berguna menjawab pada 80 atau 443 di sana.

Langkah 3: Verifikasi Apa yang Mendengarkan pada 80/443

Sekarang beralih ke server dan ajukan pertanyaan yang spesifik: apakah ada yang benar-benar menerima koneksi web pada port yang diharapkan? Mesin dapat hidup, SSH dapat bekerja, dan nginx bahkan dapat diinstal. Namun port web publik masih dapat tidak memiliki listener yang berguna.

Periksa listener terlebih dahulu:

sudo ss -ltnp

Output kosong untuk :80 atau :443 berarti tidak ada yang berguna mendengarkan di sana. Listener pada 127.0.0.1 berarti layanan hanya menerima koneksi dari mesin lokal. Listener pada 0.0.0.0 berarti terikat pada antarmuka IPv4. [::] biasanya berarti antarmuka IPv6. Jangan asumsikan binding IPv6 secara otomatis menjamin jalur IPv4 yang Anda butuhkan.

Kemudian gunakan bundle kesehatan nginx kecil sebelum mengubah apa pun:

sudo systemctl status nginx --no-pager -l
sudo nginx -t
sudo journalctl -u nginx --since '-30 minutes' --no-pager

• Jika systemctl mengatakan active (running), itu hanya membuktikan proses layanan ada
• nginx -t memberi tahu Anda apakah konfignya valid
• journalctl menunjukkan apakah reload terakhir gagal, file sertifikat hilang, atau vhost rusak saat startup.

Untuk pembaca Apache, sintaks pemeriksaan yang setara adalah apachectl configtest. Setelah Anda tahu sesuatu sedang mendengarkan, bukti berikutnya lebih spesifik: apakah situs yang benar menjawab secara lokal ketika Anda menghilangkan jaringan luar dari persamaan?

💡 Tip: Uji konfigurasi terlebih dahulu, kemudian lebih suka reload daripada restart buta jika sesuai. Reload memvalidasi konfigurasi baru dan menjaga worker lama jika konfigurasi baru buruk; restart buta jauh lebih kasar di tengah insiden.

Langkah 4: Uji Situs Secara Lokal dengan Host dan SNI yang Benar

Ini adalah percabangan paling penting dalam seluruh investigasi. curl 127.0.0.1 biasa dapat menyesatkan. Banyak server yang menampung beberapa situs dan memilih respons berdasarkan header Host atau, untuk HTTPS, SNI. Anda tidak menanyakan apakah sesuatu merespons secara lokal. Anda menanyakan apakah jalur situs yang benar merespons secara lokal.

Gunakan tes lokal yang mempertahankan logika nama host:

curl -I http://127.0.0.1/ -H 'Host: example.com'
curl -v --resolve example.com:443:127.0.0.1 https://example.com/

# Only as a one-off diagnostic if you already know the cert is bad:
curl -vk --resolve example.com:443:127.0.0.1 https://example.com/

Kesuksesan yang bermakna adalah halaman yang diharapkan, pengalihan yang diharapkan, atau respons aplikasi yang diharapkan dari situs yang benar. Bukan host nginx default, sertifikat yang salah, atau “itu mengembalikan HTML” generik. Dari sini ada tiga hasil yang jelas: kesuksesan lokal, perilaku situs yang salah atau sertifikat default lokal, atau kegagalan/timeout lokal. Hasil lokal yang baik menunjuk ke luar ke pemeriksaan firewall, penyedia, CDN, atau perutean. Hasil lokal yang buruk membuat Anda tetap berada di dalam stack, di cabang upstream atau TLS.

Langkah 5: Jika Berfungsi Secara Lokal tetapi Tidak Eksternal, Lacak Jalur Jaringan

Setelah tes lokal berhasil, berhenti meragukan nginx untuk saat ini. Stack situs kemungkinan besar aktif di server, dan bagian yang hilang biasanya berada di suatu tempat antara pengunjung dan layanan lokal yang berfungsi. Mulai dengan firewall host karena itu adalah batas eksternal terdekat yang Anda kontrol.

Periksa aturan sisi host dengan alat yang benar-benar digunakan sistem Anda, dan lakukan satu pemeriksaan kewarasan cepat untuk pemblokiran yang disebabkan sendiri saat Anda berada di sana:

sudo nft list ruleset

# Or, on systems still using iptables directly:
sudo iptables-save
sudo ip6tables-save

# Fast sanity check for self-inflicted blocking:
sudo fail2ban-client status

Output tersebut hanya menunjukkan lapisan guest OS. Ini tidak menunjukkan penyaringan sisi penyedia, grup keamanan, atau aturan firewall tingkat panel yang berada di luar VPS itu sendiri. Pada VPS AlexHost, misalnya, firewall mesin dan kontrol jaringan tingkat panel apa pun adalah pertanyaan terpisah. Keduanya penting ketika tes lokal berfungsi tetapi pengunjung publik masih gagal.

⚠️ Peringatan: Jika Docker menerbitkan port di host, jangan asumsikan output UFW menceritakan seluruh kisah. Docker dapat merutekan lalu lintas kontainer yang diterbitkan melalui NAT sebelum rantai biasa UFW. Itu berarti “UFW terlihat baik” tidak selalu berarti jalur paket baik-baik saja.

CDN dan load balancer layak mendapatkan cabang mereka sendiri di sini juga. Asal mungkin sehat dan masih tidak dapat dijangkau secara langsung karena hanya rentang IP tepi yang diizinkan untuk berbicara dengannya. Ketika Anda membutuhkan bukti apakah paket tiba sama sekali, gunakan tcpdump sebagai alat ya-atau-tidak:

📝 Catatan: Tes asal langsung yang gagal di belakang daftar izin CDN biasanya menunjuk ke kebijakan tepi, bukan ke asal yang mati. Dalam pengaturan itu, asal dirancang untuk mempercayai jalur CDN, bukan setiap pengunjung langsung.

sudo tcpdump -ni any 'tcp port 80 or tcp port 443'

Jika Anda tidak melihat paket SYN sama sekali, lalu lintas tidak mencapai server. Jika SYN tiba dan tidak ada SYN-ACK yang keluar, jalur server atau firewall masih memblokir penyerahan. Jika tidak ada pola yang tampak menjadi pemblokir, kegagalan yang tersisa biasanya duduk di belakang frontend dalam penyerahan hulu.

Langkah 6: Jika Frontend Menjawab tetapi Situs Masih Rusak, Ikuti Upstream

Di cabang ini, web server dapat dijangkau, tetapi hop berikutnya di belakangnya tidak cukup sehat untuk menyelesaikan permintaan. Di sini, “upstream” berarti layanan yang nginx serahkan permintaannya selanjutnya: proses aplikasi, runtime yang didukung soket, kontainer, atau ketergantungan internal lainnya.

Halaman statis berfungsi sementara login, pencarian, checkout, atau rute API gagal adalah petunjuk kuat bahwa frontend ada dan kegagalan dimulai pada penyerahan di belakangnya.

📝 Catatan: Perlakukan 502 sebagai “hop berikutnya menjawab dengan buruk” dan 504 sebagai “hop berikutnya menjawab terlalu lambat.” Keduanya adalah tanda untuk mengikuti jalur upstream daripada berhenti di frontend.

Periksa penyerahan aktif, kemudian uji upstream secara langsung:

sudo nginx -T

# Direct HTTP upstream example
curl -i http://127.0.0.1:3000/

# Unix-socket-backed HTTP example
curl --unix-socket /run/app.sock http://localhost/

Dalam output nginx, cari direktif seperti proxy_pass, fastcgi_pass, atau uwsgi_pass. Anda memeriksa apakah nginx menunjuk ke target yang benar, melalui protokol yang benar, pada port atau soket yang benar. Jika kontainer terlibat, tambahkan pemeriksaan kesehatan kontainer singkat alih-alih menebak:

docker ps
docker logs --tail 50 <container_name>
docker inspect --format '{{json .State.Health}}' <container_name>
docker port <container_name>

Jika tes aplikasi langsung gagal, masalahnya ada di belakang web server. Jika berfungsi langsung tetapi gagal melalui nginx, konfigurasi penyerahan adalah cabang yang harus diperiksa. Jangkauan database hanya penting sebagai pemeriksaan ketergantungan di sini, bukan sebagai penggalian mendalam terpisah. Jika pola kegagalan upstream ini terus berulang, itulah saat yang tepat untuk beralih ke panduan pemecahan masalah khusus alih-alih meregangkan satu insiden menjadi tebakan.

Step 7: Isolate TLS and Certificate Failures

Cabang ini lebih sempit: sesuatu menjawab di 443, tetapi browser masih tidak dapat menyelesaikan sesi HTTPS yang bersih dan dapat dipercaya. Koneksi TCP yang berhasil ke port 443 tidak membuktikan sertifikat, kecocokan hostname, atau jalur handshake sehat.

Periksa sertifikat apa yang sebenarnya disajikan:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -brief

Di sinilah Anda menangkap bentuk kegagalan umum: hostname yang salah, sertifikat yang kedaluwarsa, rantai yang tidak lengkap, atau pembaruan yang tidak pernah selesai dengan bersih. Dalam bahasa biasa, SNI memberi tahu server hostname mana yang Anda maksudkan. -verify_hostname memeriksa apakah sertifikat yang disajikannya cocok dengan hostname tersebut. Setelah pemulihan, validasi jalur pembaruan sehingga ini tidak menjadi pemadaman berikutnya:

⚠️ Peringatan: Jika Anda mengandalkan validasi HTTP-01 untuk pembaruan sertifikat, port masuk 80 harus dapat dijangkau. Firewall atau aturan penyedia yang memblokir 80 dapat dengan diam-diam memecahkan pembaruan jauh sebelum pengguna melaporkan bahwa HTTPS terlihat mati.

sudo certbot renew --dry-run

Langkah 8: Periksa Tekanan Sumber Daya Sebelum Anda Menyebutnya Acak

Beberapa insiden sama sekali bukan kegagalan jangkauan. Jalurnya secara teknis utuh, tetapi server terlalu kelaparan, terblokir, atau kelebihan beban untuk menjawab tepat waktu. Itulah saat situs dapat terlihat “sebagian hidup” dari satu sudut dan masih terasa mati bagi pengguna.

Jalankan bundel sumber daya lintasan pertama kecil:

df -h
df -i
free -h
uptime
vmstat 1 5
sudo journalctl -k -g 'oom|out of memory|killed process'

Baca hasilnya dalam pola, bukan secara terpisah.

• df -h menunjukkan kehabisan disk biasa.
• df -i menangkap kehabisan inode, di mana ruang tampak ada tetapi filesystem tidak dapat membuat entri lagi.
• free -h paling penting ketika memori yang tersedia runtuh dan aktivitas swap meningkat.
• uptime dapat menunjukkan beban tinggi bahkan ketika CPU tidak penuh, yang sering berarti tugas menunggu tekanan disk atau memori daripada komputasi aktif.
• Baris log kernel tentang peristiwa OOM memberi tahu Anda apakah sistem mulai membunuh proses untuk bertahan.

Grafik penyedia dapat mengkonfirmasi garis waktu. Pada VPS AlexHost, grafik tersebut dapat berguna untuk memeriksa apakah lonjakan RAM, disk, atau I/O selaras dengan pemadaman. Tetapi bukti terminal harus tetap memimpin diagnosis. Bagian ini bukan panduan penyetelan; ini adalah cabang yang memberi tahu Anda situs mungkin gagal di bawah tekanan daripada gagal untuk merutekan.

Berpikir dalam Lapisan, Bukan dalam Kepanikan

Ketika SSH bekerja tetapi website tidak akan terbuka, jaga rantai tetap pendek dan dapat diulang:

1. reproduksi kegagalan secara eksternal
2. identifikasi tahap terakhir yang berhasil
3. konfirmasi DNS dan tujuan
4. verifikasi pendengar nyata pada 80/443
5. uji situs yang benar secara lokal
6. cabang ke jalur jaringan, upstream, TLS, atau sumber daya

💡 Tip: Jangan tutup sesi SSH terakhir Anda yang berfungsi sampai Anda telah mengkonfirmasi login segar masih berfungsi dan Anda masih memiliki jalur akses cadangan, seperti akses konsol penyedia. Selama insiden langsung, mempertahankan kontrol sama pentingnya dengan memperbaiki gejala pertama.

Jaga kebiasaan tetap ringan: pantau secara eksternal, simpan log, dan uji sertifikat dengan certbot renew –dry-run. Amankan akses dengan cadangan dan jalur konsol. Alat penyedia — firewall, grafik, konsol (termasuk AlexHost) — harus mendukung pemecahan masalah, bukan menggantinya. Fokus pada perbaikan lapisan pertama yang rusak sehingga setiap insiden ditangani dengan bukti yang lebih jelas dan kepanikan yang lebih sedikit.