Di awal, dugaan masalah mengarah ke konfigurasi PHP dan upload media. Namun setelah ditelusuri lebih jauh, ternyata penyebabnya berasal dari gabungan beberapa faktor: konfigurasi PHP-FPM yang belum ideal, query theme yang terlalu berat, belum adanya page cache yang benar, dan cache Cloudflare yang belum dimanfaatkan secara optimal.
Langkah pertama adalah memastikan versi PHP yang benar-benar dipakai oleh website. Ini penting karena hasil php -v di SSH sering hanya menunjukkan versi PHP CLI, bukan versi PHP-FPM yang dipakai domain.
Awalnya php -v menunjukkan PHP 8.2, tetapi setelah dicek lebih lanjut, domain ternyata benar-benar berjalan di PHP-FPM 8.3. Ini dibuktikan dari service PHP-FPM aktif dan pool domain yang menggunakan PHP 8.3.
Jangan langsung menyimpulkan versi PHP website hanya dari php -v. Pada server multi-PHP, versi CLI dan versi FPM bisa berbeda.
Setelah dipastikan website memakai PHP-FPM 8.3, langkah berikutnya adalah mengecek konfigurasi php.ini untuk FPM.
Nilai akhir yang dipakai adalah sebagai berikut:
Website berita dengan banyak gambar cenderung memerlukan waktu lebih panjang saat upload, resize, dan proses media. Dengan limit bawaan yang terlalu kecil, PHP bisa berhenti di tengah jalan dan memicu timeout.
Setelah mengubah php.ini, service PHP-FPM perlu direstart:
Selain php.ini, tuning dilanjutkan di level pool PHP-FPM domain. Ini penting agar proses PHP tidak terlalu sedikit, tetapi juga tidak terlalu banyak sampai membebani RAM.
Konfigurasi akhir yang dipakai:
Pada VPS 2 GB, menaikkan pm.max_children terlalu tinggi justru berbahaya karena RAM cepat habis, swap meningkat, lalu server semakin lambat. Konfigurasi di atas dipilih setelah beberapa kali penyesuaian sampai menemukan titik yang paling stabil.
Setelah edit selesai, lakukan restart dan cek status:
Setelah tuning PHP, optimasi dilanjutkan dengan Redis sebagai object cache. Tujuannya adalah mengurangi beban query WordPress yang berulang.
Contoh konfigurasi di wp-config.php:
Verifikasi Redis:
Jika hasilnya PONG, berarti Redis aktif. Setelah WordPress terhubung, jumlah key cache juga bisa dicek:
Redis berhasil membantu mengurangi beban object query WordPress, tetapi perlu diingat bahwa Redis bukan page cache. Karena itu, optimasi belum berhenti di sini.
Pada proses berikutnya ditemukan bahwa website masih memiliki W3 Total Cache. Ini menimbulkan konflik karena object cache lama bentrok dengan Redis dan ada file drop-in cache yang bukan milik Redis.
Solusinya adalah menonaktifkan dan menghapus W3 Total Cache, lalu membersihkan sisa file cache lama:
Setelah konflik cache lama dibersihkan, sistem menjadi lebih stabil dan Redis bisa bekerja tanpa bentrok.
Setelah Redis aktif dan cache lama dibersihkan, website memang membaik, tetapi timeout belum hilang sepenuhnya. Di tahap ini dilakukan pengecekan lebih dalam dengan:
Saat halaman kategori dibuka, muncul query berat seperti query taxonomy/tag, query popular post berbasis post_views_count, query dengan ORDER BY RAND(), dan query related posts berdasarkan kategori serta tag.
Slow log mengungkap fungsi-fungsi theme yang berat, yaitu:
Kesimpulannya, masalah utama ternyata bukan hanya konfigurasi server, tetapi juga theme WordPress yang menjalankan terlalu banyak query berat dalam satu halaman.
Karena fungsi-fungsi theme tadi terbukti menjadi penyebab utama overload, langkah berikutnya adalah menonaktifkan sementara bagian tersebut.
Fungsi yang dinonaktifkan sementara:
Langkah ini sangat penting karena satu halaman bisa memanggil banyak query berat sekaligus. Setelah fungsi-fungsi ini dinonaktifkan, website mulai jauh lebih stabil dan frekuensi gateway timeout berkurang secara nyata.
Dalam proses optimasi, sempat dicoba plugin related article inline. Namun setelah dipasang, CPU server kembali melonjak dan proses php-fpm menjadi padat.
Pelajarannya sederhana: pada server dengan resource terbatas, plugin yang melakukan related posts dinamis, pemrosesan isi artikel, atau query tambahan di setiap request, bisa membuat server kembali berat. Plugin seperti ini sebaiknya tidak dipakai dulu sampai sistem benar-benar stabil.
Setelah theme mulai dibersihkan dan Redis aktif, langkah paling penting berikutnya adalah menambahkan page cache. Karena arsitektur server menggunakan Nginx → Apache → PHP-FPM, pendekatan paling praktis adalah memakai plugin WP Super Cache.
Aktifkan opsi berikut:
Biarkan nonaktif untuk opsi berikut:
Aktifkan fitur ini agar parameter seperti utm_source, utm_medium, gclid, dan fbclid tidak memecah cache.
Setelah diaktifkan, WP Super Cache berhasil lolos tes cache. Artinya, page cache di sisi origin sudah bekerja dengan baik.
WP Super Cache menampilkan peringatan bahwa cron WordPress dinonaktifkan. Dalam kasus ini, kondisi tersebut justru benar karena wp-cron diganti dengan cron sistem agar server lebih stabil.
Tambahkan di wp-config.php:
Lalu buat cron sistem:
Isi dengan:
Dengan cara ini, task WordPress dijalankan oleh sistem Linux, bukan oleh setiap pengunjung website.
Sebelumnya Cloudflare sempat diubah menjadi DNS Only untuk keperluan pengujian. Setelah server mulai stabil, proxy Cloudflare diaktifkan kembali:
Langkah ini penting karena tahap berikutnya adalah memanfaatkan edge cache Cloudflare.
Karena menggunakan Cloudflare Free Plan, jumlah Page Rules terbatas. Maka dipilih konfigurasi yang paling efisien.
Setting: Cache Level: Bypass
Rule ini melindungi area sensitif WordPress seperti /wp-admin/, /wp-login.php, dan /wp-cron.php.
Setting:
Setting:
Urutannya harus seperti ini:
Dengan kombinasi ini, halaman publik mulai dicache di Cloudflare, sedangkan area admin tetap aman.
Setelah seluruh konfigurasi cache selesai, cache dibersihkan dari dua sisi:
Lalu lakukan pengecekan berikut:
Jika header tersebut muncul, berarti halaman publik sudah tersimpan di edge Cloudflare dan request berikutnya tidak lagi selalu membebani origin server.
Setelah semua tahapan selesai, website akhirnya berjalan dengan susunan cache berlapis seperti ini:
Melayani halaman publik dari edge network.
Menyediakan page cache di sisi WordPress.
Menyimpan object dan query WordPress yang sering dipakai.
Melayani request yang memang benar-benar dinamis.
Setelah seluruh langkah di atas dijalankan secara berurutan, hasil yang dirasakan sangat jelas:
Masalah 504 tidak selalu berarti server terlalu kecil. Sering kali masalah sebenarnya ada pada theme, plugin, dan cache yang belum benar.
Redis sangat membantu, tetapi untuk website berita, page cache tetap wajib.
Fitur seperti trending post, related content, random post, dan popular tag sangat berpotensi membuat server berat jika tidak ditulis dengan efisien.
Begitu cf-cache-status berubah menjadi HIT, beban server turun jauh.
Masalah 504 Gateway Timeout pada WordPress di VPS bisa diselesaikan, tetapi tidak cukup dengan satu langkah saja. Dalam kasus ini, solusi yang benar-benar berhasil adalah kombinasi dari:
Jika semua dilakukan dengan urutan yang benar, hasilnya sangat terasa: website menjadi stabil, lebih cepat, dan jauh lebih tahan terhadap lonjakan traffic.
Penyebabnya bisa bermacam-macam, tetapi yang paling sering adalah query theme yang berat, cache yang belum benar, serta PHP dan database yang terbebani.
Tidak. Redis membantu object cache, tetapi halaman publik tetap membutuhkan page cache agar PHP dan MySQL tidak selalu dipanggil ulang.
Bisa. Redis dipakai untuk object cache, sedangkan WP Super Cache dipakai untuk page cache. Keduanya bekerja di lapisan yang berbeda.
Itu berarti halaman belum dicache di edge Cloudflare. Solusinya adalah memastikan proxy aktif dan Page Rules atau Cache Rules sudah benar.
Tidak. Jika theme memiliki fungsi yang memicu query berat seperti related post dinamis, trending tag, atau random post, sebaiknya dimatikan atau ditulis ulang agar lebih efisien.
