Situs WordPress Anda menampilkan 503 Service Temporarily Unavailable, dan tidak seperti 504 yang berarti server lambat, 503 berarti Nginx langsung menolak: upstream-nya — biasanya PHP-FPM — tidak menerima permintaan saat ini. Penyebabnya ada tiga: PHP-FPM mati total, pool worker-nya penuh, atau Nginx menunjuk ke soket/port yang salah.
Daftar Isi
Jawaban Singkat
Periksa status PHP-FPM dulu, lalu log-nya. Jika layanan mati, hidupkan dan cari penyebab matinya di log. Jika layanan hidup tetapi log mencatat server reached pm.max_children, pool worker penuh: naikkan pm.max_children hanya bila RAM masih cukup, atau kurangi beban yang menahan worker (skrip lambat, bot, cache yang tidak jalan). Jika log Nginx mencatat connect() to unix:... failed (2: No such file or directory), soket PHP-FPM tidak ada di jalur yang ditunjuk Nginx — samakan jalur soket di kedua konfigurasi. Jangan menaikkan max_children tanpa menghitung memori: setiap worker memakai RAM, dan pool yang terlalu besar justru memicu OOM killer.
Membedakan Tiga Penyebab 503
| Tanda di log | Artinya | Perbaikan pertama |
|---|---|---|
| PHP-FPM inactive/dead | Layanan mati total | Hidupkan layanan, baca log penyebab matinya |
| server reached pm.max_children | Pool penuh, antrean penuh | Naikkan max_children bila RAM cukup, atau kurangi beban |
| connect() to unix socket failed | Nginx menunjuk ke soket yang tidak ada | Samakan jalur soket fastcgi_pass dengan listen pool |
Persiapan
- Buat backup konfigurasi pool PHP-FPM (
/etc/php/8.x/fpm/pool.d/www.conf, sesuaikan versi PHP) dan server block Nginx. - Catat pemakaian memori saat ini (
free -h) dan memori per worker PHP sebelum menaikkan batas apa pun. - Periksa versi PHP yang aktif: jalur soket mengandung versi (misalnya
php8.3-fpm.sock); versi yang salah adalah sumber umum soket tidak ditemukan.
Langkah 1: Periksa Status dan Log PHP-FPM
sudo systemctl status php8.3-fpm --no-pager
sudo tail -n 100 /var/log/php/8.3/fpm.logSesuaikan versi dengan server Anda. Jika status menunjukkan failed, baca baris error terakhir di log sebelum me-restart: restart tanpa mengetahui penyebabnya hanya mengulang kejadian. Jika layanan berjalan tetapi log penuh dengan peringatan max_children, lanjutkan ke Langkah 3.
Langkah 2: Samakan Soket antara Nginx dan PHP-FPM
Buka konfigurasi pool dan catat baris listen:
grep "^listen" /etc/php/8.3/fpm/pool.d/www.confKemudian periksa baris fastcgi_pass di server block Nginx. Keduanya harus menunjuk ke tempat yang sama — soket Unix yang sama atau alamat TCP yang sama. Ketidakcocokan ini sering terjadi setelah upgrade PHP: pool baru mendengarkan soket versi baru, sedangkan Nginx masih menunjuk ke soket versi lama. Setelah disamakan, uji dan muat ulang:
sudo nginx -t
sudo systemctl reload nginx
sudo systemctl restart php8.3-fpmLangkah 3: Atasi Pool yang Penuh
Ketika semua worker sibuk dan antrean penuh, PHP-FPM menolak koneksi baru dan Nginx menjawab 503. Hitung batas yang aman dengan rumus kasar: (RAM yang tersedia untuk PHP) dibagi (memori rata-rata per worker). Contoh: bila tersedia 1 GB untuk PHP dan tiap worker memakai sekitar 80 MB, batas aman berada di kisaran 12 worker — angka ini ilustrasi perhitungan, bukan rekomendasi universal; ukur worker Anda sendiri dengan ps. Di www.conf:
pm = dynamic
pm.max_children = 12
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6Untuk situs dengan trafik tidak menentu dan memori ketat, mode ondemand dengan pm.process_idle_timeout bisa lebih hemat, karena worker hanya dibuat saat ada permintaan. Apa pun modenya, naikkan max_children hanya setelah memastikan RAM cukup — jika tidak, Anda menukar 503 dengan OOM killer.
Langkah 4: Kurangi Beban yang Menahan Worker
Worker yang menumpuk biasanya bukan karena pengunjung membludak, melainkan karena worker tidak kunjung bebas: skrip lambat, kueri berat, cron yang menumpuk, atau bot yang menghantam wp-login.php dan admin-ajax.php. Periksa log akses untuk pola permintaan berulang dari satu IP, aktifkan cache halaman Nginx atau plugin cache agar permintaan tidak semuanya sampai ke PHP, dan batasi laju permintaan login yang mencurigakan di Nginx atau firewall. Mengurangi waktu tiap permintaan membebaskan worker jauh lebih efektif daripada sekadar menambah worker.
Verifikasi Hasil
Perbaikan berhasil bila situs terbuka normal, status PHP-FPM aktif dan stabil, log tidak lagi mencatat max_children atau kegagalan soket, dan beban puncak (misalnya beberapa permintaan bersamaan) tidak memicu 503 lagi. Pantau 24 jam, terutama pada jam sibuk yang sebelumnya memicu error.
Troubleshooting Lanjutan
| Situasi | Langkah berikutnya |
|---|---|
| PHP-FPM mati lagi setelah restart | Baca log penyebab crash: segfault, OOM, atau konfigurasi yang gagal dimuat |
| 503 hanya untuk wp-admin | Periksa pool terpisah atau batas per lokasi; admin memakai worker lebih lama |
| 503 hilang setelah reload lalu kembali | Beban berlebih kronis; ukur worker dan waktu respons, bukan sekadar menambah batas |
| Semua langkah gagal | Kirim log PHP-FPM, log Nginx, dan konfigurasi pool kepada penyedia hosting |
FAQ
Apakah restart PHP-FPM menyelesaikan 503?
Sementara, ya — bila penyebabnya hanya pool yang macet. Tetapi tanpa memperbaiki penyebab penuhnya pool, 503 akan kembali.
Kenapa 503, bukan 504?
Karena PHP-FPM menolak koneksi dengan segera (pool penuh atau mati), bukan lambat merespons. 504 adalah timeout, 503 adalah penolakan langsung.
Apakah menambah max_children selalu aman?
Tidak. Setiap worker memakai RAM. Batas yang melebihi RAM akan memicu OOM killer yang mematikan MySQL atau PHP-FPM sendiri.
Kesimpulan
503 di Nginx dengan PHP-FPM berarti upstream menolak permintaan: layanan mati, pool penuh, atau soket tidak cocok. Periksa status dan log, samakan soket, hitung max_children dari RAM yang benar-benar tersedia, dan kurangi beban yang menahan worker. Restart hanyalah pertolongan pertama; perhitungan dan log adalah perbaikannya.
Referensi
- WordPress — Nginx (Advanced Administration Handbook): developer.wordpress.org — Nginx