Anda membuka halaman WordPress, menunggu lama, lalu muncul 504 Gateway Timeout. Berbeda dengan 502 (PHP-FPM tidak menjawab sama sekali), 504 berarti PHP-FPM sedang bekerja, tetapi tidak selesai sebelum Nginx kehabisan kesabaran.
Daftar Isi
Jawaban Singkat
Untuk WordPress di Nginx + PHP-FPM, timeout yang paling sering menjadi biang masalah adalah fastcgi_read_timeout (default 60 detik). Jangan menaikkan semua timeout sekaligus: baca error log Nginx dulu, kenali timeout mana yang terpicu, selaraskan dengan max_execution_time PHP dan request_terminate_timeout PHP-FPM, lalu perbaiki skrip lambatnya — karena menaikkan timeout tanpa memperbaiki penyebab hanya menunda 504 berikutnya.
Memahami Rantai Timeout
| Pengaturan | Default | Mengatur apa |
|---|---|---|
| fastcgi_read_timeout | 60 detik | Berapa lama Nginx menunggu PHP-FPM |
| proxy_read_timeout | 60 detik | Berapa lama Nginx menunggu backend HTTP (bila Nginx mem-proxy ke Apache/backend lain) |
| max_execution_time (PHP) | 30 detik (umumnya) | Berapa lama skrip PHP boleh berjalan |
| request_terminate_timeout (PHP-FPM) | 0 (nonaktif) atau sesuai pool | Batas paksa penghentian permintaan di pool PHP-FPM |
Bila max_execution_time lebih kecil dari fastcgi_read_timeout, PHP akan membunuh skrip lebih dulu dan hasilnya bisa berupa 504 atau respons kosong. Ketiganya harus selaras.
Persiapan
- Akses SSH ke VPS dan hak sudo.
- Ketahui versi PHP situs Anda (contoh di bawah memakai 8.3; sesuaikan).
- Backup konfigurasi Nginx dan pool PHP-FPM sebelum mengubahnya.
Langkah 1: Baca Error Log
sudo grep -i timeout /var/log/nginx/error.log | tail -n 50
sudo grep " 504 " /var/log/nginx/access.log | tail -n 20Baris khasnya: upstream timed out (110: Connection timed out) while reading response header from upstream. Dari access log, catat URL mana yang 504: bila hanya satu jenis halaman (ekspor, laporan, impor), penyebabnya skrip halaman itu, bukan server secara keseluruhan.
Langkah 2: Temukan Skrip Lambatnya
Aktifkan slow log di pool PHP-FPM (misalnya /etc/php/8.3/fpm/pool.d/www.conf):
slowlog = /var/log/php/8.3/slow.log
request_slowlog_timeout = 10sMuat ulang PHP-FPM, ulangi halaman yang 504, lalu baca slow log. Di WordPress, penyebab klasik adalah kueri tanpa indeks, plugin statistik/pencarian yang berat, impor/ekspor besar, dan permintaan eksternal (API/lisensi) yang lambat.
Langkah 3: Selaraskan Timeout Secara Bertahap
Di blok location PHP pada konfigurasi Nginx:
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
fastcgi_read_timeout 120s;
}Di php.ini (FPM): max_execution_time = 120. Di pool PHP-FPM: request_terminate_timeout = 120. Ketiganya selaras di 120 detik sebagai titik awal. Uji konfigurasi dan muat ulang:
sudo nginx -t
sudo systemctl reload nginx
sudo systemctl reload php8.3-fpmNaikkan bertahap, bukan langsung ke 600 detik: timeout yang terlalu besar membuat worker PHP tertahan lebih lama oleh permintaan macet dan memperparah overload.
Langkah 4: Pindahkan Pekerjaan Berat dari Jalur HTTP
Ekspor besar, impor XML, dan pembuatan laporan sebaiknya tidak dijalani lewat halaman web biasa. Jalankan lewat WP-CLI atau cron server, atau pecah menjadi batch kecil. Ini solusi permanen yang lebih baik daripada timeout raksasa — dan alasan yang sama mengapa proses panjang juga bermasalah di balik Cloudflare.
Verifikasi Hasil
Perbaikan berhasil bila halaman yang 504 kini selesai memuat, access log tidak lagi mencatat 504 pada URL itu, slow log tidak lagi mencatat skrip yang sama, dan halaman lain tetap cepat. Uji di jam trafik normal dan jam sibuk.
Troubleshooting Lanjutan
| Situasi | Langkah berikutnya |
|---|---|
| 504 di semua halaman | Periksa beban server dan worker PHP-FPM; kemungkinan overload, bukan satu skrip |
| 504 hanya di wp-admin | Curigai plugin admin/keamanan; nonaktifkan satu per satu |
| 504 hilang lalu kembali saat trafik naik | Tinjau kapasitas VPS, cache, dan jumlah worker |
| 504 hanya di balik Cloudflare | Ingat batas Cloudflare sendiri; proses >125 detik perlu pekerjaan latar |
FAQ
Apakah menaikkan fastcgi_read_timeout saja cukup?
Sering cukup untuk gejala, tetapi bila max_execution_time PHP lebih kecil, PHP tetap membunuh skrip lebih dulu. Selaraskan ketiganya.
Apa bedanya 504 dengan 502?
502 berarti Nginx tidak mendapat respons valid dari upstream (misalnya PHP-FPM mati). 504 berarti upstream bekerja tetapi terlalu lama.
Kapan 504 menandakan perlu upgrade VPS?
Bila slow log bersih, timeout sudah selaras, tetapi server tetap jenuh CPU/RAM saat trafik normal — kapasitaslah batasnya, bukan konfigurasi.
Kesimpulan
Diagnosis 504 yang baik dimulai dari log, bukan dari menaikkan angka. Kenali timeout yang terpicu, selaraskan Nginx-PHP-PHP-FPM, temukan skrip lambat lewat slow log, dan pindahkan pekerjaan berat dari jalur HTTP. Dengan urutan itu, 504 berhenti menjadi tebak-tebakan.
Referensi
- GetPageSpeed — 504 Gateway Timeout in NGINX: getpagespeed.com — 504 Gateway Timeout
- Console9 — Nginx 504 Gateway Timeout: console9.com — Nginx 504