Satu Hostname Gagal Resolve, Semua Situs Ikut Mati

Suatu siang, semua situs yang saya host di satu VPS mati bersamaan. Bukan cuma satu aplikasi, semuanya sekaligus, selama sekitar 52 menit. Yang bikin saya bingung: database normal, PHP-FPM jalan, cache tidak bermasalah, tunnel juga sehat. Tidak ada satupun komponen inti yang error. Tapi begitu saya cek, nginx sama sekali tidak mau start.

Di log-nya ketemu satu baris yang jadi biang keladi: host not found in upstream, menunjuk ke satu nama host API pihak ketiga tertentu. Tes konfigurasi nginx gagal karena baris itu, dan karena gagal, service-nya menolak jalan sama sekali. Semua situs lain yang bahkan tidak berhubungan dengan API tersebut ikut jadi korban.

Root Cause: Resolver yang Ternyata Tidak Selalu Dipakai

Setelah ditelusuri, ternyata sumber masalahnya ada di satu konfigurasi situs yang meneruskan trafik ke sebuah API eksternal. Target proxy-nya ditulis langsung sebagai nama host literal di baris proxy_pass, bukan lewat variabel. Kira-kira bentuknya seperti ini (nilai asli sudah saya ganti placeholder):

location /api/ {
    resolver DNS_RESOLVER_ANDA valid=30s;
    proxy_pass https://HOSTNAME_API_EKSTERNAL/;
}

Sekilas ini terlihat aman karena sudah ada baris resolver khusus. Tapi ini jebakan klasik di nginx: resolver kustom itu baru benar-benar dipakai saat request masuk kalau target proxy-nya berupa variabel. Kalau ditulis literal seperti di atas, hostname itu justru cuma di-resolve sekali, yaitu saat nginx start atau reload, dan itupun pakai resolver sistem biasa, bukan resolver kustom yang sudah didefinisikan.

Kebetulan pas momen reload itu, ada gangguan DNS sesaat di level sistem. Resolusi hostname gagal, tes konfigurasi pun gagal. Dan karena nginx memperlakukan tes konfigurasi sebagai keputusan all-or-nothing untuk seluruh server, satu baris proxy yang bermasalah berhasil menjatuhkan semua server block lain yang sama sekali tidak terkait.

Solusi: Ubah Jadi Variabel, Bukan Restart Membabi Buta

Pemulihan darurat saat itu, saya akui, agak kasar: restart penuh VPS dari dashboard penyedia hosting. Setelah boot ulang, DNS di level sistem berhasil resolve lagi dan nginx bisa start normal. Tapi itu cuma menghilangkan gejala, bukan menyembuhkan penyakitnya.

Fix permanennya jauh lebih sederhana daripada restart: ubah target proxy jadi variabel, supaya resolver kustom benar-benar dipakai setiap request masuk.

location /api/ {
    resolver DNS_RESOLVER_ANDA valid=30s;
    set $upstream_api HOSTNAME_API_EKSTERNAL;
    proxy_pass https://$upstream_api/;
}

Dengan perubahan ini, DNS untuk host tersebut benar-benar di-resolve ulang tiap kali ada request, bukan cuma sekali saat start. Konsekuensinya jadi jauh lebih masuk akal: kalau suatu hari ada gangguan DNS lagi, yang error cuma proxy itu saja (nginx akan balas 502 untuk endpoint tersebut), bukan menjatuhkan seluruh server.

Sejak kejadian ini, kebiasaan saya berubah: selalu jalankan tes konfigurasi (nginx -t) sebelum reload, dan tidak pernah lagi asal restart service tanpa tahu akar masalahnya lebih dulu.

Bonus Temuan: Log Process Manager yang Membengkak Diam-diam

Waktu lagi menyelidiki insiden ini, saya ketemu masalah kedua yang tidak berhubungan langsung tapi sama pentingnya: satu file log dari process manager ternyata sudah membengkak sampai hampir 10GB. Awalnya saya kira ini gejala crash loop, tapi setelah dicek isinya cuma akumulasi catatan start/stop rutin selama berbulan-bulan, bukan error berulang.

Di VPS kecil dengan RAM cuma 2GB, log sebesar itu memakan porsi disk yang signifikan, dan diam-diam bisa jadi bom waktu kalau dibiarkan terus tumbuh. Setelah dibersihkan dan diatur rotasinya, pemakaian disk turun banyak dan servernya jadi lebih lega.

Takeaway

Pelajaran utamanya: satu konfigurasi proxy yang salah bisa jadi single point of failure untuk seluruh situs di server yang sama, bukan cuma untuk situs yang bersangkutan. Ini berlaku untuk setiap proxy yang menunjuk ke host eksternal mana pun, apalagi kalau ditulis literal tanpa variabel. Kalau ada resolver kustom, pastikan dipakai dengan benar, dan kalau ada gangguan, jangan langsung restart total, cari dulu akar masalahnya lewat log dan tes konfigurasi.