502 Bad Gateway di Nginx? Baca Lognya Dulu, Jangan Restart

Situs balas 502. Restart PHP-FPM, situs hidup lagi. Besok kejadian lagi.

Restart emang sering nolong, dan itu justru masalahnya: dia ngilangin gejala sekaligus buktinya. Padahal 502 selalu ninggalin jejak yang cukup buat nunjuk penyebabnya.

Yang sebenarnya dibilang 502

Nginx maupun Apache di depan aplikasi cuma perantara. 502 artinya: perantaranya berhasil nyambung ke aplikasi, tapi jawabannya nggak bisa dipakai — atau koneksinya putus di tengah jalan.

Bedain dulu dari tetangganya, karena penanganannya beda total:

Kalau yang muncul 504, jangan nyari proses yang mati — nggak ada yang mati. Yang perlu dicari kenapa lambat.

Lognya di dua tempat, dan yang berguna bukan yang pertama dibuka

Kebanyakan orang buka log akses dulu. Di situ cuma keliatan 502 dan alamatnya — nggak nambah apa pun.

Yang berguna log error:

• Nginx: /var/log/nginx/error.log
• Apache: /var/log/apache2/error.log

Baris yang dicari nyebut upstream atau proxy_fcgi. Isinya biasanya udah nyebut sebabnya langsung:

• connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) — PHP-FPM nggak jalan, atau nama socketnya beda sama yang ditulis di konfigurasi. Sering kejadian sesudah upgrade versi PHP: soketnya jadi php8.3-fpm.sock sementara konfigurasi masih nunjuk php8.2-fpm.sock.
• connect() ... failed (13: Permission denied) — soketnya ada, tapi user web server nggak boleh baca. Cek listen.owner dan listen.group di pool PHP-FPM.
• upstream prematurely closed connection — prosesnya mati di tengah nanganin permintaan. Hampir selalu kehabisan memori, atau kena memory_limit.
• no live upstreams — semua backend ditandai gagal. Nginx bakal nyoba lagi sendiri setelah beberapa detik.

Kalau munculnya cuma pas ramai

502 yang datang dan pergi mengikuti jam sibuk biasanya bukan proses mati, tapi antrean penuh.

PHP-FPM punya batas jumlah proses anak (pm.max_children). Begitu semuanya sibuk, permintaan berikutnya ngantre; kalau antreannya penuh juga, jawabannya 502.

Kelihatan di log PHP-FPM sebagai peringatan yang jelas banget:

WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

Naikin angkanya boleh, tapi jangan asal: tiap proses makan memori, dan naikin kekgedean bikin server kehabisan RAM — yang gejalanya balik lagi jadi 502, kali ini beneran karena proses dibunuh kernel.

Hitung kasarnya: memori yang tersedia buat PHP dibagi pemakaian rata-rata satu proses.

Urutan mriksa yang hemat waktu

1. systemctl status php8.3-fpm — jalan atau nggak
2. Baca sepuluh baris terakhir log error web server
3. Cocokin jalur socket di konfigurasi sama yang beneran ada di /run/php/
4. dmesg | tail — cari Out of memory dan nama proses yang dibunuh
5. Baru liat log aplikasi

Empat langkah pertama biasanya udah cukup.

Cegah biar nggak balik lagi

• Nyalain pm.status_path di PHP-FPM biar antreannya keliatan sebelum penuh.
• Set fastcgi_read_timeout sesuai kenyataan aplikasi Anda, jangan dibiarkan bawaan.
• Pastiin restart otomatis nyala di unit systemd-nya, jadi proses yang mati bangun sendiri sambil Anda nyari sebabnya.

Generator Konfigurasi Nginx dan Apache nyusun virtual host yang jalur socket, timeout, dan blok HTTPS-nya udah bener sejak awal — termasuk penutup berkas .env yang sering kelupaan.

Bacaan lanjutan: Permission denied padahal sudah chmod 777 buat kasus izin yang mirip tapi beda akar, dan Cron tidak jalan padahal perintahnya benar.