Pendahuluan

Masalah 504 Gateway Timeout pada WordPress sering membuat pemilik website frustrasi, terutama saat situs sudah berisi banyak artikel, gambar, dan berjalan di VPS dengan resource terbatas. Gejala yang muncul biasanya tidak hanya satu. Website bisa terasa sangat lambat, dashboard berat, upload gambar sering gagal, halaman kategori sulit dibuka, bahkan kadang situs menampilkan error gateway timeout secara acak.

Artikel ini membahas proses perbaikan berdasarkan langkah nyata yang dilakukan dari awal sampai akhir hingga website kembali stabil. Jadi, susunannya bukan teori umum, melainkan tutorial yang mengikuti proses troubleshooting yang benar-benar dijalankan, diuji, dan dipilih berdasarkan hasil yang berhasil.

Kondisi Awal Website dan Server

Pada kasus ini, website berjalan dengan kondisi sebagai berikut:

• WordPress dengan banyak berita dan gambar
• Panel menggunakan HestiaCP
• Web server depan menggunakan Nginx
• Backend menggunakan Apache
• PHP menggunakan PHP-FPM 8.3
• Database menggunakan MariaDB/MySQL
• Website berada di belakang Cloudflare
• Gejala utama adalah 504 Gateway Timeout

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.

Tahap 1: Memastikan Versi PHP yang Dipakai Website

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.

php -v
nginx -v
free -h
df -h
php -i | egrep "memory_limit|max_execution_time|max_input_time|post_max_size|upload_max_filesize"
systemctl status php8.3-fpm --no-pager
systemctl status php8.2-fpm --no-pager

Hasil yang ditemukan

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.

Pelajaran penting

Jangan langsung menyimpulkan versi PHP website hanya dari php -v. Pada server multi-PHP, versi CLI dan versi FPM bisa berbeda.

Tahap 2: Menyesuaikan Limit PHP-FPM

Setelah dipastikan website memakai PHP-FPM 8.3, langkah berikutnya adalah mengecek konfigurasi php.ini untuk FPM.

grep -nE "memory_limit|max_execution_time|max_input_time|post_max_size|upload_max_filesize" /etc/php/8.3/fpm/php.ini

Nilai akhir yang dipakai adalah sebagai berikut:

max_execution_time = 300
max_input_time = 300
memory_limit = 512M
post_max_size = 100M
upload_max_filesize = 100M

Kenapa setting ini dipilih

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:

systemctl restart php8.3-fpm

Tahap 3: Menyetel Pool PHP-FPM Supaya Lebih Stabil

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.

nano /etc/php/8.3/fpm/pool.d/infopriangan.com.conf

Konfigurasi akhir yang dipakai:

pm = dynamic
pm.max_children = 8
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 300
pm.process_idle_timeout = 10s
request_terminate_timeout = 300
pm.status_path = /status
request_slowlog_timeout = 10s
slowlog = /var/log/php8.3-fpm-slow.log
catch_workers_output = yes
php_admin_flag[log_errors] = on

Kenapa tidak dibuat terlalu besar

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:

systemctl restart php8.3-fpm
systemctl status php8.3-fpm --no-pager

Tahap 4: Memasang Redis Object Cache

Setelah tuning PHP, optimasi dilanjutkan dengan Redis sebagai object cache. Tujuannya adalah mengurangi beban query WordPress yang berulang.

Langkah yang dilakukan

1. Install redis-server
2. Install ekstensi php8.3-redis
3. Tambahkan konfigurasi Redis di wp-config.php
4. Install plugin Redis Object Cache
5. Aktifkan dari dashboard WordPress

Contoh konfigurasi di wp-config.php:

define('WP_CACHE', true);
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
define('WP_REDIS_PREFIX', 'infopriangan:');

Verifikasi Redis:

redis-cli ping

Jika hasilnya PONG, berarti Redis aktif. Setelah WordPress terhubung, jumlah key cache juga bisa dicek:

redis-cli dbsize

Redis berhasil membantu mengurangi beban object query WordPress, tetapi perlu diingat bahwa Redis bukan page cache. Karena itu, optimasi belum berhenti di sini.

Tahap 5: Menghapus Konflik Cache Lama

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:

rm -f /home/admin/web/infopriangan.com/public_html/wp-content/advanced-cache.php
rm -rf /home/admin/web/infopriangan.com/public_html/wp-content/cache/*
systemctl restart php8.3-fpm
systemctl restart nginx

Setelah konflik cache lama dibersihkan, sistem menjadi lebih stabil dan Redis bisa bekerja tanpa bentrok.

Tahap 6: Menemukan Bottleneck Sebenarnya di Theme

Setelah Redis aktif dan cache lama dibersihkan, website memang membaik, tetapi timeout belum hilang sepenuhnya. Di tahap ini dilakukan pengecekan lebih dalam dengan:

• htop
• SHOW FULL PROCESSLIST
• slow log PHP-FPM

Temuan dari database

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.

Temuan dari slow log PHP-FPM

Slow log mengungkap fungsi-fungsi theme yang berat, yaitu:

• trending_blog()
• related_content()
• related_blog()
• featured_cat2()

Kesimpulannya, masalah utama ternyata bukan hanya konfigurasi server, tetapi juga theme WordPress yang menjalankan terlalu banyak query berat dalam satu halaman.

Tahap 7: Menonaktifkan Fungsi Theme yang Berat

Karena fungsi-fungsi theme tadi terbukti menjadi penyebab utama overload, langkah berikutnya adalah menonaktifkan sementara bagian tersebut.

Fungsi yang dinonaktifkan sementara:

• trending_blog() pada sidebar
• related_content() pada single post
• related_blog() pada single post
• random_blog() pada single post
• featured_cat2() pada homepage

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.

Tahap 8: Menghindari Plugin yang Menambah Beban PHP

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.

Tahap 9: Memasang WP Super Cache sebagai Page Cache

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.

Setting utama yang dipakai

Tab Easy

• Caching On

Tab Advanced

Aktifkan opsi berikut:

• Enable Caching
• Simple caching
• Compress pages
• 304 Browser caching
• Disable caching for logged in visitors
• Cache rebuild
• Clear all cache files when a post or page is published or updated

Biarkan nonaktif untuk opsi berikut:

• Preload mode
• Mobile device support
• Extra homepage checks
• Dynamic caching
• Late init
• Lock down

Cache Timeout

Cache Timeout = 1800
Timer = 900

Rejected URL Strings

/wp-admin/
/wp-login.php
/xmlrpc.php
/wp-cron.php

Tracking Parameters

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.

Tahap 10: Mengganti WP-Cron dengan System Cron

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:

define('DISABLE_WP_CRON', true);

Lalu buat cron sistem:

crontab -e

Isi dengan:

*/5 * * * * curl -s https://infopriangan.com/wp-cron.php > /dev/null 2>&1

Dengan cara ini, task WordPress dijalankan oleh sistem Linux, bukan oleh setiap pengunjung website.

Tahap 11: Mengaktifkan Kembali Proxy Cloudflare

Sebelumnya Cloudflare sempat diubah menjadi DNS Only untuk keperluan pengujian. Setelah server mulai stabil, proxy Cloudflare diaktifkan kembali:

• infopriangan.com → Proxied
• www → Proxied

Langkah ini penting karena tahap berikutnya adalah memanfaatkan edge cache Cloudflare.

Tahap 12: Menambahkan Cloudflare Page Rules

Karena menggunakan Cloudflare Free Plan, jumlah Page Rules terbatas. Maka dipilih konfigurasi yang paling efisien.

Rule 1

*infopriangan.com/wp-*

Setting: Cache Level: Bypass

Rule ini melindungi area sensitif WordPress seperti /wp-admin/, /wp-login.php, dan /wp-cron.php.

Rule 2

www.infopriangan.com/*

Setting:

• Cache Level: Cache Everything
• Edge Cache TTL: 2 hours

Rule 3

infopriangan.com/*

Setting:

• Cache Level: Cache Everything
• Edge Cache TTL: 2 hours

Urutan rule

Urutannya harus seperti ini:

1. Bypass WordPress
2. www cache everything
3. root domain cache everything

Dengan kombinasi ini, halaman publik mulai dicache di Cloudflare, sedangkan area admin tetap aman.

Tahap 13: Purge Cache dan Verifikasi Akhir

Setelah seluruh konfigurasi cache selesai, cache dibersihkan dari dua sisi:

• Delete Cache di WP Super Cache
• Purge Everything di Cloudflare

Lalu lakukan pengecekan berikut:

curl -I https://infopriangan.com/

Hasil akhir yang dicari

cf-cache-status: HIT

Jika header tersebut muncul, berarti halaman publik sudah tersimpan di edge Cloudflare dan request berikutnya tidak lagi selalu membebani origin server.

Arsitektur Akhir yang Berhasil

Setelah semua tahapan selesai, website akhirnya berjalan dengan susunan cache berlapis seperti ini:

Layer 1: Cloudflare Edge Cache

Melayani halaman publik dari edge network.

Layer 2: WP Super Cache

Menyediakan page cache di sisi WordPress.

Layer 3: Redis Object Cache

Menyimpan object dan query WordPress yang sering dipakai.

Layer 4: PHP-FPM dan MySQL yang Sudah Dituning

Melayani request yang memang benar-benar dinamis.

Hasil Nyata Setelah Semua Optimasi

Setelah seluruh langkah di atas dijalankan secara berurutan, hasil yang dirasakan sangat jelas:

• Gateway timeout turun drastis
• Homepage, kategori, dan artikel jauh lebih cepat
• CPU server lebih stabil
• PHP-FPM tidak lagi melonjak seperti sebelumnya
• MySQL lebih tenang
• Website lebih siap menghadapi traffic tinggi

Pelajaran Penting dari Kasus Ini

1. Jangan langsung menyalahkan VPS

Masalah 504 tidak selalu berarti server terlalu kecil. Sering kali masalah sebenarnya ada pada theme, plugin, dan cache yang belum benar.

2. Redis saja tidak cukup

Redis sangat membantu, tetapi untuk website berita, page cache tetap wajib.

3. Theme bisa menjadi sumber bottleneck terbesar

Fitur seperti trending post, related content, random post, dan popular tag sangat berpotensi membuat server berat jika tidak ditulis dengan efisien.

4. Cloudflare akan sangat membantu jika dikonfigurasi dengan benar

Begitu cf-cache-status berubah menjadi HIT, beban server turun jauh.

Kesimpulan

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:

• memastikan PHP-FPM yang benar
• menyesuaikan limit PHP
• men-tuning pool PHP-FPM
• mengaktifkan Redis
• membersihkan konflik plugin cache lama
• menonaktifkan fungsi theme yang berat
• memasang WP Super Cache
• mengganti WP-Cron dengan system cron
• mengaktifkan kembali proxy Cloudflare
• menambahkan Page Rules yang tepat
• memverifikasi hasil dengan cf-cache-status: HIT

Jika semua dilakukan dengan urutan yang benar, hasilnya sangat terasa: website menjadi stabil, lebih cepat, dan jauh lebih tahan terhadap lonjakan traffic.

FAQ

Apa penyebab utama gateway timeout pada WordPress di VPS?

Penyebabnya bisa bermacam-macam, tetapi yang paling sering adalah query theme yang berat, cache yang belum benar, serta PHP dan database yang terbebani.

Apakah Redis saja cukup untuk mempercepat WordPress?

Tidak. Redis membantu object cache, tetapi halaman publik tetap membutuhkan page cache agar PHP dan MySQL tidak selalu dipanggil ulang.

Apakah WP Super Cache bisa dipakai bersamaan dengan Redis?

Bisa. Redis dipakai untuk object cache, sedangkan WP Super Cache dipakai untuk page cache. Keduanya bekerja di lapisan yang berbeda.

Kenapa Cloudflare masih menunjukkan DYNAMIC?

Itu berarti halaman belum dicache di edge Cloudflare. Solusinya adalah memastikan proxy aktif dan Page Rules atau Cache Rules sudah benar.

Apakah semua fitur theme perlu tetap aktif?

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.