Mengatasi Error 504 Gateway Timeout di WordPress: Penyebab, Diagnosis, dan Cara Memperbaikinya untuk Publisher Indonesia

Error 504 Gateway Timeout di WordPress adalah pesan bahwa ada satu server di tengah jalan yang sudah menunggu terlalu lama, lalu menyerah. Pengunjung Anda mengklik sebuah halaman, permintaan itu diteruskan dari satu server ke server lain, tetapi server yang seharusnya membangun halaman tidak kunjung menjawab dalam batas waktu yang ditentukan. Akibatnya, pengunjung hanya melihat halaman error, iklan AdSense tidak tampil, dan Googlebot mencatat kegagalan server. Artikel ini menjelaskan apa itu error 504, bagaimana membedakannya dari error 502, 503, dan 524, cara mendiagnosis penyebabnya langkah demi langkah, serta perbaikan yang bisa Anda lakukan sendiri — dari yang paling sederhana sampai yang membutuhkan akses server — agar situs WordPress Anda kembali normal dan tidak kambuh.

Poin Kunci

• Error 504 berarti server perantara (gateway atau proxy) tidak menerima respons tepat waktu dari server di belakangnya; definisi ini berasal dari RFC 9110 bagian 15.6.5.
• Bedakan 504 dari 502 (respons upstream tidak valid), 503 (server tidak tersedia), dan 524 (kode khusus Cloudflare saat origin lambat lebih dari 100 detik).
• Durasi sebelum error muncul adalah petunjuk diagnosis tercepat: sekitar 30 detik mengarah ke batas CloudFront, 60 detik ke batas default Nginx, dan 100 detik ke batas Cloudflare.
• Penyebab paling umum di WordPress adalah skrip PHP yang melewati batas max_execution_time, query database yang lambat, worker PHP-FPM yang habis, plugin berat, dan pekerjaan cron atau impor yang berjalan di dalam satu request.
• Google memperlambat crawl saat menemukan error 5xx dan menghapus URL dari indeks bila error terus berlanjut, jadi 504 yang dibiarkan berhari-hari merugikan SEO dan pendapatan iklan.
• Perbaikan berurutan: diagnosis dulu (waktu, header, log), lalu perbaiki penyebabnya; menaikkan batas timeout tanpa memperbaiki penyebab hanya menunda error berikutnya.
• Menaikkan max_execution_time ke 300 detik adalah patokan praktik yang umum dipakai, bukan aturan resmi WordPress; selalu cek nilai aktif lewat Site Health setelah mengubahnya.

Daftar Isi

1. Apa Itu Error 504 Gateway Timeout?
2. 504 vs 502 vs 503 vs 524: Jangan Salah Diagnosis
3. Dampak Error 504 bagi Publisher: Iklan dan SEO
4. Penyebab Paling Umum Error 504 di WordPress
5. Diagnosis Langkah demi Langkah: Cari Lapisan yang Gagal
6. Perbaikan Cepat Tanpa Akses Server
7. Menyesuaikan Batas Waktu PHP: max_execution_time dan Memory Limit
8. Menyesuaikan Timeout Nginx dan PHP-FPM di VPS
9. Mengatasi Error 504 yang Berasal dari Cloudflare
10. Query Database Lambat dan Pekerjaan Cron yang Menumpuk
11. Kapan Harus Menghubungi Hosting atau Naik Paket
12. Checklist Pencegahan agar Error 504 Tidak Kembali
13. FAQ
14. Kesimpulan
15. Sumber resmi yang dirujuk

Apa Itu Error 504 Gateway Timeout?

Saat seseorang membuka halaman WordPress Anda, permintaannya jarang langsung dijawab oleh satu server saja. Rantai yang umum adalah: browser pengunjung, lalu CDN seperti Cloudflare, lalu reverse proxy seperti Nginx, lalu server aplikasi PHP-FPM, lalu database MySQL atau MariaDB. Setiap lapisan meneruskan permintaan ke lapisan berikutnya dan menunggu jawaban.

Error 504 Gateway Timeout muncul ketika salah satu lapisan perantara itu menunggu jawaban dari server di belakangnya, tetapi jawaban tidak kunjung datang sebelum batas waktu yang sudah dikonfigurasi habis. Perantara itu kemudian menghentikan penantian dan mengembalikan kode 504 ke browser.

Definisi resminya ada di RFC 9110 bagian 15.6.5, standar yang mengatur semantik HTTP: kode status 504 menunjukkan bahwa server, ketika bertindak sebagai gateway atau proxy, tidak menerima respons tepat waktu dari server upstream yang dibutuhkannya untuk menyelesaikan permintaan. Tiga kata kunci dalam definisi itu penting dipahami.

Pertama, “gateway atau proxy” adalah server perantara. Dalam instalasi WordPress modern, peran ini bisa dipegang oleh Nginx, Apache dengan mod_proxy, Cloudflare, load balancer, atau layanan CDN lain. Kedua, “upstream server” adalah server di belakang perantara — biasanya PHP-FPM yang menjalankan WordPress, atau database yang ditanyai WordPress. Ketiga, “tepat waktu” tidak punya angka universal. Setiap perantara menetapkan batasnya sendiri, sehingga 504 selalu merupakan pernyataan tentang dua hal sekaligus: seberapa lambat backend Anda, dan berapa batas yang dikonfigurasi di perantara.

Hal yang sering disalahpahami: error 504 bukan berarti server Anda mati. Server perantara justru bekerja dengan benar; ia menerima permintaan, meneruskannya, menunggu, lalu memberi tahu Anda bahwa ia menyerah. Yang bermasalah adalah server di belakangnya yang terlalu lambat atau tidak merespons. Karena itu, memperbaiki 504 berarti mencari tahu lapisan mana yang lambat dan mengapa ia lambat, bukan sekadar me-restart semuanya dan berharap.

Untuk publisher Indonesia, konteksnya konkret. Situs berita dan blog monetisasi biasanya memakai shared hosting atau cloud hosting dengan Cloudflare di depannya, memakai banyak plugin, dan menjalankan tugas berat seperti impor konten, backup, atau optimasi gambar. Kombinasi itu membuat WordPress rentan terhadap timeout, terutama pada halaman yang berat: halaman arsip dengan banyak query, halaman admin saat menyimpan perubahan besar, atau proses impor dan ekspor.

Bagaimana rantai permintaan bekerja di WordPress

Agar diagnosis lebih mudah, bayangkan alur berikut pada situs WordPress yang memakai Cloudflare dan Nginx:

1. Browser pengunjung meminta halaman ke Cloudflare.
2. Cloudflare meneruskan permintaan ke server origin Anda.
3. Nginx di server menerima permintaan dan meneruskannya ke PHP-FPM.
4. PHP-FPM menjalankan WordPress: memuat tema dan plugin, lalu menjalankan query ke database.
5. Database mengembalikan data, WordPress merangkai halaman HTML, dan jawaban dikirim balik melalui rantai yang sama.

Error 504 bisa muncul di setiap titik tunggu dalam rantai itu. Cloudflare menunggu origin, Nginx menunggu PHP-FPM, PHP-FPM menunggu database, atau WordPress menunggu API eksternal. Tugas Anda adalah menemukan titik mana yang kehabisan waktu. Untungnya, durasi dan header respons biasanya memberi petunjuk yang cukup jelas, seperti dijelaskan pada bagian diagnosis di bawah.

504 vs 502 vs 503 vs 524: Jangan Salah Diagnosis

Empat kode error ini sering tertukar, padahal masing-masing menunjuk ke masalah yang berbeda dan perbaikannya pun berbeda. Tabel berikut merangkum perbedaannya.

Perbedaan kunci antara 502 dan 504 adalah apa yang diterima perantara. Pada 502, upstream sempat menjawab tetapi jawabannya tidak valid, atau koneksi terputus di tengah jalan. Pada 504, upstream tidak mengirim apa pun sebelum batas waktu habis. Keduanya sama-sama error 5xx dan sama-sama masalah sisi server, tetapi langkah perbaikannya berbeda: 502 lebih sering mengarah ke proses PHP yang crash atau mati, sedangkan 504 mengarah ke proses yang hidup tetapi terlalu lambat.

Kode 524 adalah kode khusus Cloudflare, bukan bagian dari standar HTTP. Cloudflare memakai 524 ketika koneksi ke origin berhasil, tetapi origin tidak mengembalikan respons HTTP dalam batas 100 detik. Jadi, bila situs Anda berada di belakang Cloudflare dan Anda melihat 524, artinya masalahnya ada di origin Anda yang lambat. Sebaliknya, 504 yang terlihat melalui Cloudflare biasanya berasal dari load balancer atau reverse proxy Anda sendiri di belakang Cloudflare, bukan dari Cloudflare itu sendiri. Detail ini dibahas lagi pada bagian Cloudflare.

Kode 503 juga perlu dibedakan. Server yang mengembalikan 503 secara eksplisit menyatakan dirinya tidak tersedia untuk sementara — misalnya sedang maintenance, kelebihan beban, atau membatasi laju permintaan. WordPress sendiri mengembalikan 503 saat mode maintenance aktif selama update. Sementara itu, 504 tidak memberi pernyataan apa pun dari upstream; upstream hanya diam.

Mengapa pembedaan ini penting

Salah diagnosis berarti salah perbaikan. Publisher yang mengira 504 adalah masalah DNS akan membuang waktu mengubah nameserver, padahal penyebabnya adalah satu query database yang lambat. Publisher yang mengira 504 sama dengan 502 mungkin me-restart PHP-FPM berulang kali, padahal PHP-FPM hidup dan hanya butuh query yang dioptimalkan. Catat kode persis yang muncul, berapa lama waktu yang dibutuhkan sebelum error tampil, dan apakah error terjadi di semua halaman atau hanya halaman tertentu. Tiga data itu saja sudah mempersempit penyebab secara drastis.

Dampak Error 504 bagi Publisher: Iklan dan SEO

Bagi publisher yang pendapatannya berasal dari iklan, error 504 bukan sekadar masalah teknis. Setiap kali halaman gagal dimuat, iklan di halaman itu tidak tampil, tidak terlihat, dan tidak menghasilkan apa pun. Bila error terjadi pada jam-jam traffic tinggi atau pada artikel yang sedang viral, kerugian pendapatannya langsung terasa. Lebih dari itu, pengunjung yang berulang kali menemui halaman error cenderung tidak kembali, dan mereka mungkin menganggap situs Anda tidak terawat.

Dampak terhadap SEO juga nyata dan terdokumentasi oleh Google. Google Search Central menjelaskan bahwa kode status 5xx — termasuk 504 — membuat crawler Google memperlambat laju crawl untuk sementara. Penurunan laju crawl itu sebanding dengan jumlah URL yang mengembalikan error server: satu halaman bermasalah berdampak ringan, tetapi error di seluruh situs bisa membuat crawling hampir berhenti. Konten yang disajikan dengan respons 5xx diabaikan oleh Google, URL yang sudah terindeks dipertahankan untuk sementara, tetapi akan dihapus dari indeks bila error terus berlanjut. Setelah server kembali menjawab dengan kode sukses 2xx secara konsisten, Google secara bertahap menaikkan kembali laju crawl.

Praktiknya, ini berarti 504 yang hanya terjadi sesekali dan cepat diperbaiki biasanya pulih tanpa kerusakan jangka panjang. Namun 504 yang berulang selama berhari-hari dapat membuat artikel-artikel Anda hilang dari hasil pencarian, dan pemulihannya berlangsung bertahap, bukan instan. Search Console menyediakan laporan Page Indexing dengan alasan “Server error (5xx)” serta laporan Crawl Stats yang menunjukkan lonjakan error server dan waktu respons. Kedua laporan ini adalah tempat pertama yang harus Anda periksa setelah memperbaiki error, lalu gunakan tombol “Validate fix” untuk meminta Google memeriksa ulang.

Dampak lain yang sering luput: proses internal situs Anda sendiri juga bisa gagal karena timeout. Impor konten yang berhenti di tengah jalan, backup yang tidak selesai, update plugin yang gagal, atau sinkronisasi dengan layanan eksternal yang terputus — semuanya bisa berakar pada batas waktu yang sama. Jadi, memperbaiki 504 bukan hanya soal pengunjung, tetapi juga soal menjaga operasional situs tetap berjalan.

Penyebab Paling Umum Error 504 di WordPress

Sebagian besar kasus 504 di WordPress berasal dari tujuh penyebab berikut. Urutannya dari yang paling sering ditemui pada instalasi WordPress biasa.

1. Skrip PHP melewati batas max_execution_time

PHP membatasi berapa lama satu skrip boleh berjalan melalui pengaturan max_execution_time. Nilai default yang umum di shared hosting adalah 30 detik. Bila sebuah proses WordPress — misalnya impor file besar, regenerasi thumbnail ribuan gambar, atau backup — membutuhkan waktu lebih lama, PHP menghentikan skrip itu. Tergantung konfigurasi server, penghentian ini bisa tampil sebagai fatal error “Maximum execution time exceeded” atau sebagai 504 dari proxy yang menunggu.

2. Query database yang lambat atau tidak terindeks

Satu query yang tidak memakai indeks, tabel wp_postmeta yang membengkak, atau query dari plugin yang buruk bisa menahan halaman selama puluhan detik. Ini adalah penyebab klasik 504 pada halaman arsip, halaman pencarian internal, dan halaman dengan banyak filter. Database yang lambat juga menjelaskan mengapa 504 sering muncul hanya pada halaman tertentu, sementara halaman lain baik-baik saja.

3. Worker PHP-FPM habis

PHP-FPM hanya menyediakan sejumlah worker (proses) untuk menangani permintaan secara bersamaan. Bila semua worker sedang sibuk menangani permintaan yang lambat, permintaan baru harus antre. Bila antrean ini melebihi batas waktu proxy, hasilnya 504 — meskipun setiap permintaan sebenarnya masih diproses. Lonjakan traffic mendadak, serangan bot, atau banyak permintaan bersamaan ke endpoint berat seperti admin-ajax.php bisa menghabiskan worker dengan cepat.

4. Plugin atau tema yang berat dan bermasalah

Plugin yang melakukan panggilan API eksternal yang lambat, menjalankan query berat di setiap halaman, atau mengalami deadlock bisa membuat seluruh situs lambat. Tema dengan builder yang berat dan banyak query juga bisa menjadi penyebab. Ciri khas penyebab ini: error muncul setelah memasang atau memperbarui plugin atau tema tertentu.

5. Tugas berat yang dijalankan dalam satu request

WordPress menjalankan banyak tugas lewat WP-Cron, tetapi WP-Cron dipicu oleh kunjungan, bukan oleh jadwal server. Impor besar, ekspor data, pengiriman email massal, atau optimasi gambar yang dijalankan sebagai satu request HTTP yang panjang sangat rentan terhadap timeout. Tugas-tugas seperti ini seharusnya berjalan di latar belakang, bukan di dalam request halaman.

6. Server kelebihan beban atau sumber daya habis

CPU atau RAM yang penuh, disk yang penuh, atau paket hosting yang sudah tidak cukup untuk traffic saat ini akan membuat semua permintaan menjadi lambat. Pada shared hosting, “tetangga” yang boros sumber daya juga bisa memengaruhi situs Anda. Ciri khasnya: 504 muncul pada jam sibuk dan hilang pada jam sepi.

7. Masalah jaringan, DNS, atau firewall

Firewall server yang memblokir IP Cloudflare, aturan keamanan yang terlalu agresif, atau masalah resolusi DNS bisa membuat perantara tidak bisa mencapai origin tepat waktu. Penyebab ini lebih jarang, tetapi layak diperiksa bila semua penyebab di atas sudah disingkirkan, terutama bila error muncul setelah perubahan pada firewall atau DNS.

Diagnosis Langkah demi Langkah: Cari Lapisan yang Gagal

Diagnosis yang baik menghemat waktu lebih banyak daripada perbaikan apa pun. Ikuti urutan berikut sebelum mengubah konfigurasi apa pun.

Langkah 1: Catat pola errornya

Jawab empat pertanyaan ini terlebih dahulu: apakah error terjadi di semua halaman atau hanya halaman tertentu? Apakah terjadi di halaman publik saja, di wp-admin saja, atau keduanya? Kapan error mulai muncul — setelah update, setelah memasang plugin, atau setelah lonjakan traffic? Dan berapa lama waktu yang dibutuhkan dari klik sampai error tampil? Bila error hanya muncul di satu halaman, penyebabnya hampir pasti ada di halaman itu: query, konten, atau shortcode di dalamnya. Bila semua halaman terkena, masalahnya ada di lapisan server.

Langkah 2: Baca durasi sebagai petunjuk

Durasi sebelum error muncul adalah petunjuk tercepat untuk mengetahui lapisan mana yang menyerah. Angka-angka berikut adalah nilai default yang umum menurut dokumentasi masing-masing layanan, dan sebaiknya Anda mengonfirmasinya dengan konfigurasi Anda sendiri:

Bila halaman gagal pada angka yang nyaris persis sama setiap kali, Anda sedang melihat batas konfigurasi, bukan kerusakan acak. Bila waktunya berubah-ubah, penyebabnya lebih mungkin beban server atau query yang kadang cepat dan kadang lambat.

Langkah 3: Periksa header respons

Buka alat pengembang di browser (F12), tab Network, lalu muat ulang halaman yang error dan klik permintaan yang gagal. Periksa header responsnya. Header Server: cloudflare dan adanya CF-RAY menunjukkan respons itu berasal dari Cloudflare. Header Server: nginx menunjukkan respons dari Nginx di origin Anda. Informasi ini menentukan apakah Anda harus memeriksa konfigurasi CDN atau konfigurasi server sendiri.

Langkah 4: Uji origin secara langsung

Bila Anda memakai Cloudflare atau CDN lain, uji apakah origin Anda sendiri lambat tanpa perantara. Caranya antara lain mengakses situs lewat IP origin secara langsung atau menonaktifkan proxy Cloudflare sementara (mode “DNS only” atau Development Mode). Bila origin langsung pun lambat, masalahnya ada di server Anda. Bila origin langsung cepat tetapi lewat Cloudflare lambat, periksa koneksi antara Cloudflare dan origin, termasuk apakah firewall Anda memblokir rentang IP Cloudflare.

Langkah 5: Periksa log error

Log adalah sumber kebenaran yang paling bisa diandalkan. Periksa error log PHP dan Nginx/Apache di hosting Anda, serta log debug WordPress bila WP_DEBUG diaktifkan. Cari baris yang waktunya berdekatan dengan kejadian 504: pesan “upstream timed out”, “Maximum execution time exceeded”, “upstream sent too big header”, atau query lambat. Pesan “while reading response header from upstream” pada log Nginx berarti Nginx sudah terhubung ke backend, tetapi backend tidak mengirim respons tepat waktu — ini adalah tanda khas 504.

Langkah 6: Periksa Site Health dan sumber daya

Di dashboard WordPress, buka Tools → Site Health → Info → Server. Di sana tercantum batas waktu PHP (PHP time limit, yaitu max_execution_time), batas memori PHP, dan versi PHP. Bandingkan dengan beban situs Anda. Di panel hosting, periksa grafik CPU, RAM, dan jumlah proses PHP yang berjalan. Bila grafik menunjukkan CPU atau RAM penuh pada jam error terjadi, Anda sudah menemukan penyebabnya.

Langkah 7: Uji dengan plugin dan tema standar

Bila diagnosis mengarah ke WordPress, gunakan plugin Health Check & Troubleshooting untuk menguji situs dengan semua plugin nonaktif dan tema default, tanpa mengubah tampilan untuk pengunjung. Bila error hilang dalam mode itu, aktifkan kembali plugin satu per satu sampai error muncul lagi. Plugin terakhir yang diaktifkan adalah tersangka utamanya. Cara ini memang memakan waktu, tetapi jauh lebih cepat daripada menebak-nebak.

Perbaikan Cepat Tanpa Akses Server

Bila Anda tidak punya akses root atau konfigurasi server, mulailah dari langkah-langkah berikut. Sering kali satu di antaranya sudah cukup.

Muat ulang dan bersihkan cache

Langkah paling sederhana: muat ulang halaman, coba browser lain, dan bersihkan cache browser. Bila Anda memakai plugin caching, bersihkan cache situs dan cache CDN. Cache yang rusak atau kedaluwarsa kadang membuat permintaan diteruskan ke origin padahal seharusnya dilayani dari cache. Langkah ini tidak memperbaiki penyebab, tetapi memastikan Anda tidak sedang mengejar masalah yang sebenarnya sudah hilang.

Nonaktifkan plugin yang terakhir diubah

Bila error muncul setelah memasang atau memperbarui plugin, nonaktifkan plugin itu terlebih dahulu dan uji lagi. Bila Anda tidak bisa masuk wp-admin karena error juga terjadi di sana, nonaktifkan plugin lewat FTP atau file manager dengan mengganti nama folder plugin di wp-content/plugins. Ganti nama satu folder plugin berarti menonaktifkannya; kembalikan nama folder untuk mengaktifkannya lagi. Lakukan satu per satu agar Anda tahu plugin mana yang bermasalah.

Ganti ke tema default untuk pengujian

Sama seperti plugin, tema yang bermasalah bisa menyebabkan 504 pada halaman tertentu. Uji dengan tema default WordPress seperti Twenty Twenty-Four atau Twenty Twenty-Five. Bila error hilang, masalahnya ada di tema Anda — biasanya pada fungsi kustom, query di template, atau integrasi builder yang berat.

Periksa dan perbaiki database

Tabel database yang membengkak memperlambat query. Dari plugin optimasi database atau phpMyAdmin, Anda bisa membersihkan revisi postingan lama, transient yang kedaluwarsa, komentar spam, dan data plugin yang sudah tidak dipakai. Lakukan backup penuh sebelum membersihkan apa pun. Untuk situs publisher, tabel wp_postmeta dan wp_options (terutama baris autoload yang besar) adalah tempat pertama yang layak diperiksa.

Kurangi beban halaman yang error

Bila error hanya terjadi pada halaman tertentu, kurangi beban halaman itu: kurangi jumlah postingan per halaman arsip, nonaktifkan widget yang melakukan query berat, dan pastikan gambar sudah dioptimalkan. Halaman arsip yang menampilkan 50 postingan lengkap dengan thumbnail besar akan jauh lebih lambat daripada arsip yang menampilkan 10 postingan dengan excerpt.

Menyesuaikan Batas Waktu PHP: max_execution_time dan Memory Limit

Bila diagnosis menunjukkan skrip PHP kehabisan waktu, langkah logisnya adalah menaikkan batas waktu — tetapi dengan catatan penting: menaikkan batas hanya memberi napas lebih panjang bagi tugas yang memang butuh waktu lama dan sah, seperti impor atau backup. Bila penyebabnya adalah plugin yang boros atau query yang buruk, menaikkan batas hanya menunda error berikutnya.

Berapa nilai yang wajar

Nilai default max_execution_time yang umum di shared hosting adalah 30 detik. Nilai 300 detik (5 menit) adalah patokan praktik yang paling sering direkomendasikan berbagai panduan hosting untuk tugas WordPress yang berat. Angka ini bukan aturan resmi WordPress, melainkan kesepakatan praktis: cukup panjang untuk impor dan backup yang sah, tetapi tidak terlalu panjang sehingga skrip yang macet bisa menggantung tanpa batas. Bila tugas Anda masih gagal pada 300 detik, masalahnya bukan lagi di batas — melainkan pada skrip yang memang bermasalah atau server yang kekurangan sumber daya.

Perlu dipahami satu detail teknis: pada Linux, max_execution_time menghitung waktu CPU yang dipakai skrip, bukan waktu dinding (wall-clock). Waktu yang dihabiskan menunggu database atau API eksternal tidak selalu dihitung. Karena itu, skrip yang menunggu respons API lambat bisa saja tetap gagal lewat timeout proxy meskipun belum melewati max_execution_time.

Cara menaikkan max_execution_time

Ada empat jalur yang umum, dan Anda cukup memakai satu jalur yang didukung hosting Anda:

1. Panel hosting (paling mudah). Di cPanel, buka Select PHP Version → Options atau MultiPHP INI Editor, cari max_execution_time, dan ubah nilainya menjadi 300. Di panel hosting lain, cari menu PHP Settings atau PHP Configuration yang setara.
2. File php.ini atau .user.ini. Tambahkan atau ubah baris max_execution_time = 300 dan sekalian max_input_time = 300 serta memory_limit = 256M. Pada banyak shared host, file .user.ini di folder root situs sudah cukup.
3. File .htaccess (Apache atau LiteSpeed). Tambahkan baris php_value max_execution_time 300 di luar blok rewrite WordPress. Cara ini hanya bekerja bila konfigurasi server mengizinkan override PHP lewat .htaccess.
4. File wp-config.php. Tambahkan set_time_limit(300); tepat sebelum baris /* That's all, stop editing! */. Fungsi ini mereset timer eksekusi dari titik ia dipanggil. Perlu dicatat, cara ini tidak selalu berhasil bila host mengunci pengaturan di level server, dan pemanggilan tanpa pengecekan bisa menimbulkan error pada PHP 8 bila fungsi tersebut dinonaktifkan — jadi bungkus dengan pengecekan function_exists bila Anda memakai cara ini.

Setelah mengubah, verifikasi bahwa perubahan benar-benar berlaku: buka Tools → Site Health → Info → Server dan lihat nilai “PHP time limit”. Bila nilainya tidak berubah, host Anda mengunci pengaturan tersebut dan Anda perlu meminta bantuan dukungan hosting.

Memory limit yang sejalan

Batas waktu dan batas memori saling berkaitan. Skrip yang kehabisan memori akan gagal sebelum kehabisan waktu, dan sebaliknya. Nilai default WordPress untuk WP_MEMORY_LIMIT adalah 40 MB pada instalasi single-site dan 64 MB pada multisite, dengan WP_MAX_MEMORY_LIMIT 256 MB untuk area admin. Untuk situs publisher dengan banyak plugin, menaikkan memory_limit PHP ke 256M adalah patokan praktik yang umum. Tetapkan di wp-config.php dengan define('WP_MEMORY_LIMIT', '256M'); bila diperlukan, lalu verifikasi lewat Site Health.

Menyesuaikan Timeout Nginx dan PHP-FPM di VPS

Bila Anda mengelola VPS sendiri atau memakai hosting yang memberi akses konfigurasi, batas waktu di lapisan proxy dan PHP-FPM juga perlu diselaraskan. Aturan praktisnya: batas di proxy harus sedikit lebih panjang daripada batas di PHP, supaya PHP yang menghentikan skrip terlebih dahulu dan mencatat error yang jelas, bukan proxy yang memutus secara tiba-tiba.

Timeout Nginx

Nilai default proxy_read_timeout dan fastcgi_read_timeout di Nginx adalah 60 detik. Bila proses PHP Anda memang membutuhkan waktu lebih lama dan sudah dioptimalkan, Anda bisa menaikkannya, misalnya menjadi 300 detik:

location ~ \.php$ {
    fastcgi_read_timeout 300;
    proxy_read_timeout 300;
}

Setelah mengubah konfigurasi, uji dengan nginx -t lalu muat ulang Nginx. Jangan menaikkan nilai ini secara membabi buta: timeout yang terlalu panjang membuat worker Nginx tertahan lebih lama oleh permintaan yang macet, sehingga memperparah kemacetan saat traffic tinggi.

Worker PHP-FPM

Bila diagnosis menunjukkan worker habis, periksa konfigurasi pool PHP-FPM Anda. Parameter kuncinya adalah pm.max_children (jumlah maksimum proses anak), pm.start_servers, pm.min_spare_servers, dan pm.max_spare_servers. Menaikkan pm.max_children memberi kapasitas lebih, tetapi setiap worker memakai RAM — menaikkan tanpa menambah RAM hanya memindahkan kemacetan dari antrean ke memori. Sebagai patokan praktik, hitung kebutuhan RAM per worker dari pemakaian rata-rata proses PHP Anda, lalu sesuaikan jumlah worker dengan RAM yang tersedia. Bila Anda tidak yakin, mintalah rekomendasi dari penyedia hosting Anda.

Periksa juga request_terminate_timeout pada konfigurasi pool PHP-FPM. Parameter ini menghentikan permintaan PHP yang berjalan lebih lama dari nilai tersebut. Bila nilainya lebih kecil dari max_execution_time, PHP-FPM yang akan menghentikan skrip terlebih dahulu. Selaraskan nilainya dengan batas yang Anda tetapkan di PHP.

Timeout Apache dan LiteSpeed

Bila server Anda memakai Apache, direktif yang relevan adalah Timeout dan ProxyTimeout. Bila memakai LiteSpeed, periksa pengaturan External App dan connection timeout di konfigurasi server. Prinsipnya sama: selaraskan batas di semua lapisan agar tidak ada satu lapisan yang memutus lebih dulu secara diam-diam.

Mengatasi Error 504 yang Berasal dari Cloudflare

Cloudflare adalah lapisan yang paling sering membingungkan publisher, karena Cloudflare memakai kode 524 untuk kasus yang di server lain disebut 504. Memahami perbedaan ini menghemat banyak waktu diagnosis.

Cloudflare 524: origin lambat lebih dari 100 detik

Cloudflare menunggu respons HTTP dari origin selama 100 detik secara default. Bila origin tidak menjawab dalam waktu itu, Cloudflare menampilkan halaman error 524. Batas 100 detik ini tidak bisa dinaikkan pada paket Free, Pro, atau Business; hanya pelanggan Enterprise yang bisa meminta batas lebih panjang. Artinya, bila situs Anda menampilkan 524, solusinya bukan mengubah pengaturan Cloudflare, melainkan membuat origin Anda menjawab lebih cepat dari 100 detik. Perbaiki query yang lambat, optimalkan halaman yang berat, atau pindahkan tugas panjang ke proses latar belakang.

Cloudflare 504: biasanya berasal dari balik Cloudflare

Bila Anda melihat kode 504 saat memakai Cloudflare, kode itu biasanya berasal dari load balancer atau reverse proxy Anda sendiri di belakang Cloudflare, bukan dari Cloudflare. Cloudflare hanya meneruskan kode tersebut. Dalam kasus ini, diagnosis dilakukan di origin seperti biasa: periksa log Nginx dan PHP-FPM di server Anda.

Langkah pemeriksaan khusus Cloudflare

Pertama, periksa header respons untuk memastikan siapa yang mengembalikan error. Header Server: cloudflare dan CF-RAY menunjukkan Cloudflare yang mengembalikan respons. Kedua, aktifkan Development Mode di Cloudflare untuk melewati cache sementara dan menguji origin secara langsung. Ketiga, periksa apakah firewall server Anda memblokir rentang IP Cloudflare — bila IP Cloudflare diblokir, koneksi dari Cloudflare ke origin bisa gagal atau menggantung sampai timeout. Cloudflare mempublikasikan daftar rentang IP-nya, dan daftar itu harus diizinkan di firewall Anda pada port 80 dan 443. Keempat, periksa aturan Page Rules atau konfigurasi Argo dan fitur lain yang bisa memengaruhi routing. Terakhir, bila situs Anda memakai Cloudflare APO atau fitur cache otomatis, pastikan cache tidak memaksa permintaan dinamis yang berat untuk selalu mencapai origin.

Query Database Lambat dan Pekerjaan Cron yang Menumpuk

Dua penyebab yang sering luput dari perhatian adalah query database yang lambat dan pekerjaan terjadwal yang menumpuk. Keduanya tidak terlihat dari dashboard, tetapi sangat memengaruhi kecepatan.

Menemukan query yang lambat

Pasang plugin Query Monitor untuk sementara dan buka halaman yang mengalami 504. Query Monitor menampilkan semua query yang dijalankan halaman itu, berapa lama masing-masing berjalan, dan komponen mana yang memicunya. Query yang berjalan lebih dari satu detik layak diselidiki; query yang berjalan lebih dari lima detik hampir pasti adalah penyebab masalah. Perhatikan query dari plugin yang melakukan pencarian LIKE pada tabel postmeta tanpa indeks, atau query yang memuat ribuan baris sekaligus.

Perbaikan yang umum: tambahkan indeks pada kolom yang sering dipakai dalam klausa WHERE, batasi jumlah hasil dengan paginasi, dan ganti query yang memuat semua postingan dengan query yang hanya memuat kolom yang dibutuhkan. Bila query berasal dari plugin, laporkan ke pengembang plugin atau cari alternatif yang lebih ringan. Untuk situs besar, object cache seperti Redis atau Memcached bisa mengurangi beban database secara signifikan karena hasil query yang sering dipakai disimpan di memori.

WP-Cron yang menumpuk

WP-Cron bukan cron sungguhan. Ia hanya berjalan ketika ada kunjungan, dan semua tugas terjadwal — publikasi terjadwal, pengecekan update, pengiriman email, pembersihan transient — dijalankan di dalam request pengunjung. Bila banyak tugas menumpuk, satu kunjungan bisa memicu pekerjaan yang berjalan puluhan detik, dan pengunjung itu menerima 504.

Solusinya adalah menonaktifkan WP-Cron semu dan menggantinya dengan cron server sungguhan. Tambahkan define('DISABLE_WP_CRON', true); di wp-config.php, lalu buat cron job di server yang memanggil wp-cron.php setiap beberapa menit, misalnya setiap 5 menit. Dengan cara ini, tugas terjadwal berjalan di latar belakang pada jadwal yang teratur, bukan menumpang pada request pengunjung. Untuk tugas yang benar-benar berat seperti impor besar atau regenerasi gambar, gunakan alat yang dirancang untuk pekerjaan latar belakang — misalnya WP-CLI atau plugin yang memakai Action Scheduler — bukan menjalankan semuanya dalam satu request HTTP.

Impor dan ekspor besar

Impor file CSV besar, migrasi konten, atau ekspor data adalah pemicu 504 yang klasik. Pecah pekerjaan menjadi batch kecil, misalnya 500 baris per batch, dan jalankan lewat WP-CLI bila tersedia. Bila Anda harus memakai antarmuka web, pastikan max_execution_time sudah dinaikkan dan proses berjalan tanpa gangguan. Jangan menjalankan impor besar pada jam traffic tinggi.

Kapan Harus Menghubungi Hosting atau Naik Paket

Tidak semua 504 bisa diperbaiki dari sisi WordPress. Ada titik di mana masalahnya adalah kapasitas server, dan satu-satunya perbaikan adalah dukungan hosting atau paket yang lebih besar.

Hubungi dukungan hosting bila: error muncul di semua situs pada akun yang sama, grafik sumber daya menunjukkan CPU atau RAM penuh secara konsisten, log server menampilkan error yang hanya bisa diakses penyedia hosting, atau Anda sudah mencoba semua langkah diagnosis tetapi tidak menemukan penyebab di WordPress. Saat menghubungi dukungan, sertakan informasi yang sudah Anda kumpulkan: waktu kejadian, URL yang terkena, durasi sebelum error, dan pesan dari log. Informasi ini mempercepat penanganan secara signifikan dibandingkan laporan “situs saya error”.

Pertimbangkan naik paket atau pindah hosting bila: traffic Anda sudah tumbuh melampaui kapasitas paket saat ini, 504 muncul setiap hari pada jam sibuk meskipun situs sudah dioptimalkan, atau penyedia hosting tidak mengizinkan Anda menaikkan batas PHP dan timeout yang dibutuhkan. Sebelum memutuskan, bandingkan dengan patokan yang terukur: waktu respons rata-rata halaman, jumlah worker PHP yang tersedia, dan RAM yang dialokasikan. Naik paket tanpa optimasi terlebih dahulu sering kali hanya memindahkan masalah ke angka yang lebih besar — jadi optimalkan dulu, lalu naikkan kapasitas bila memang masih kurang.

Untuk publisher yang trafficnya naik-turun tajam karena artikel viral, pertimbangkan juga caching yang agresif dan CDN yang baik. Halaman yang disajikan dari cache tidak membebani PHP dan database sama sekali, sehingga lonjakan traffic tidak langsung berubah menjadi 504.

Checklist Pencegahan agar Error 504 Tidak Kembali

Pencegahan lebih murah daripada pemadaman. Gunakan checklist berikut secara berkala, misalnya sebulan sekali atau setiap kali traffic naik signifikan.

1. Periksa Site Health secara rutin dan pastikan tidak ada peringatan kritis tentang batas PHP, versi PHP yang usang, atau plugin yang bermasalah.
2. Pastikan max_execution_time dan memory_limit sudah sesuai dengan kebutuhan situs, dan verifikasi nilainya setelah setiap perubahan hosting.
3. Jadwalkan pembersihan database berkala: revisi lama, transient kedaluwarsa, komentar spam, dan data plugin yang tidak terpakai.
4. Ganti WP-Cron semu dengan cron server sungguhan agar tugas terjadwal tidak menumpang pada request pengunjung.
5. Audit plugin setiap beberapa bulan: hapus plugin yang tidak dipakai, ganti plugin berat dengan alternatif yang lebih ringan, dan perbarui semuanya.
6. Pasang pemantauan uptime dan waktu respons, supaya Anda mendapat peringatan saat 504 mulai muncul, bukan setelah pengunjung mengeluh.
7. Pastikan backup berjalan dan selesai dengan sukses; backup yang gagal diam-diam sering menjadi pertanda awal masalah timeout.
8. Uji halaman-halaman penting setelah setiap update besar tema, plugin, atau versi PHP.
9. Pastikan firewall mengizinkan IP Cloudflare bila Anda memakai Cloudflare, dan periksa kembali setelah perubahan firewall.
10. Simpan catatan setiap kali 504 terjadi: waktu, URL, durasi, dan penyebab yang ditemukan. Pola dari catatan ini adalah alat diagnosis terbaik untuk kejadian berikutnya.

FAQ

Apakah error 504 berbahaya bagi SEO situs saya?

Ya, bila dibiarkan. Google memperlambat crawl saat menemukan error 5xx dan menghapus URL dari indeks bila error terus berlanjut. Namun, error sesekali yang cepat diperbaiki biasanya pulih tanpa kerusakan jangka panjang. Periksa laporan Page Indexing di Search Console dan gunakan “Validate fix” setelah perbaikan.

Apa bedanya error 504 dengan 502?

Pada 502, upstream sempat menjawab tetapi jawabannya tidak valid atau koneksinya putus. Pada 504, upstream tidak mengirim jawaban apa pun sebelum batas waktu habis. Perbaikannya berbeda: 502 lebih sering mengarah ke proses PHP yang crash, 504 mengarah ke proses yang hidup tetapi terlalu lambat.

Mengapa saya melihat 524, bukan 504, saat memakai Cloudflare?

Karena Cloudflare memakai kode 524 khusus untuk kasus origin yang terhubung tetapi tidak menjawab dalam 100 detik. Kode 504 yang terlihat melalui Cloudflare biasanya berasal dari load balancer atau reverse proxy Anda sendiri di belakang Cloudflare.

Berapa nilai max_execution_time yang aman untuk WordPress?

Nilai 300 detik adalah patokan praktik yang umum dipakai untuk tugas berat seperti impor dan backup. Nilai ini bukan aturan resmi. Bila tugas masih gagal pada 300 detik, penyebabnya bukan lagi batas waktu, melainkan skrip atau server yang bermasalah.

Apakah menaikkan timeout bisa menyelesaikan error 504 secara permanen?

Tidak selalu. Menaikkan timeout hanya memberi waktu lebih panjang. Bila penyebabnya adalah query lambat atau plugin boros, error akan kembali begitu beban naik. Perbaiki penyebabnya, lalu sesuaikan timeout sebagai pelengkap.

Apakah pengunjung bisa memperbaiki error 504 sendiri?

Umumnya tidak. Error 504 adalah masalah sisi server, bukan sisi browser. Pengunjung hanya bisa memuat ulang halaman dan mencoba lagi nanti. Bila error terus muncul, perbaikan harus dilakukan pemilik situs.

Kesimpulan

Error 504 Gateway Timeout adalah pesan bahwa sebuah server perantara menunggu jawaban terlalu lama lalu menyerah. Definisi resminya ada di RFC 9110: server yang bertindak sebagai gateway atau proxy tidak menerima respons tepat waktu dari upstream. Kunci penanganannya adalah diagnosis sebelum perbaikan: catat pola errornya, baca durasi sebelum error muncul, periksa header respons, uji origin secara langsung, dan baca log server. Dari sana, penyebabnya biasanya mengerucut ke salah satu dari tujuh hal: batas max_execution_time, query database yang lambat, worker PHP-FPM yang habis, plugin atau tema yang berat, tugas besar dalam satu request, server yang kelebihan beban, atau masalah jaringan dan firewall.

Perbaiki penyebabnya terlebih dahulu, lalu selaraskan batas waktu di setiap lapisan — PHP, PHP-FPM, Nginx, dan CDN — agar tidak ada lapisan yang memutus secara diam-diam. Untuk pengguna Cloudflare, ingat bahwa batas 100 detik tampil sebagai 524 dan tidak bisa dinaikkan pada paket non-Enterprise, sehingga origin harus menjawab lebih cepat. Terakhir, jadikan pencegahan sebagai kebiasaan: audit plugin, bersihkan database, ganti WP-Cron dengan cron server, dan pantau uptime. Situs publisher yang cepat bukan hanya lebih disukai pembaca dan pengiklan, tetapi juga lebih tahan terhadap lonjakan traffic yang justru datang saat artikel Anda sedang naik.

Sumber resmi yang dirujuk

1. IETF RFC 9110 bagian 15.6.5 — definisi kode status 504 Gateway Timeout (httpwg.org/specs/rfc9110.html).
2. MDN Web Docs — “504 Gateway Timeout”, definisi dan konteks HTTP.
3. Google Search Central — “How HTTP status codes, network errors, and DNS errors affect Google Search” (developers.google.com/search/docs/crawling-indexing/http-status-codes) — perlakuan 5xx: crawl diperlambat sebanding jumlah URL error, konten diabaikan, URL persisten dihapus, pemulihan bertahap, Validate fix.
4. Cloudflare Docs — “Error 524: a timeout occurred” dan “Cloudflare 5xx errors” (developers.cloudflare.com/support/troubleshooting/cloudflare-errors/troubleshooting-cloudflare-5xx-errors/) — batas 100 detik, 524 sebagai kode khusus origin lambat.
5. WordPress.org — “Common WordPress Errors” dan “Tools → Site Health” (wordpress.org/documentation/article/common-wordpress-errors/) — pengecekan PHP time limit lewat Site Health.
6. WordPress Developer Resources — “Changing File Permissions” dan “Editing wp-config.php” (developer.wordpress.org/advanced-administration/wordpress/wp-config/) — nilai default WP_MEMORY_LIMIT 40 MB single-site/64 MB multisite dan WP_MAX_MEMORY_LIMIT 256 MB.
7. Nginx Documentation — ngx_http_proxy_module dan ngx_http_fastcgi_module (nginx.org/en/docs/http/ngx_http_proxy_module.html) — nilai default proxy_read_timeout dan fastcgi_read_timeout 60 detik.
8. PHP Manual — “max_execution_time” dan “set_time_limit” (php.net/manual/en/info.configuration.php) — definisi batas eksekusi skrip dan perilaku set_time_limit.
9. Google Search Console Help — laporan Page Indexing “Server error (5xx)” dan Crawl Stats (support.google.com/webmasters) — tempat memantau dan memvalidasi perbaikan error server.
10. Cloudways Blog — “How to Fix the 504 Gateway Timeout Error” (cloudways.com/blog/wordpress-504-gateway-timeout/) — sumber sekunder untuk praktik menaikkan max_execution_time ke 300 detik dan membedakan tampilan error Cloudflare bermerek dengan halaman polos dari origin.