504 Gateway Timeout: arti, penyebab & cara mengatasinya

Apa itu 504 Gateway Timeout?

504 Gateway Timeout adalah kode status HTTP yang berarti server yang bertindak sebagai gateway atau proxy tidak menerima respons tepat waktu dari server upstream. Proxy menunggu upstream untuk merespons, tetapi terlalu lama, sehingga proxy menyerah dan mengembalikan error 504 ke browser Anda.

RFC 9110 mendefinisikannya: “Kode status 504 (Gateway Timeout) menunjukkan bahwa server, saat bertindak sebagai gateway atau proxy, tidak menerima respons tepat waktu dari server upstream yang perlu diaksesnya untuk menyelesaikan permintaan” (RFC 9110 §15.6.5).

Kata kuncinya adalah gateway. Error 504 selalu melibatkan setidaknya dua server: server yang Anda hubungi (proxy/gateway) dan server di belakangnya (upstream/origin) yang gagal merespons. Proxy yang umum termasuk Nginx reverse proxy, Cloudflare, AWS Application Load Balancer (ALB), dan CloudFront.

Tampilan error 504

Tampilannya bergantung pada lapisan mana yang menyerah:

• 504 Gateway Time-out dengan “nginx” di bawahnya — nginx (menulisnya dengan tanda hubung)
• 504 Gateway Time-out · The server didn't respond in time. — halaman bawaan HAProxy
• Gateway Timeout · The gateway did not receive a timely response from the upstream server or application. — Apache di depan PHP-FPM (mod_proxy_fcgi). Apache yang mem-proxy backend HTTP menampilkan Proxy Error · Error reading from remote server (sebuah 502).
• ERROR · The request could not be satisfied · 504 ERROR — Amazon CloudFront
• Error 524: A timeout occurred — versi Cloudflare: sudah sampai ke server Anda, tetapi respons tidak tiba tepat waktu
• Halaman ini tidak berfungsi · example.com membutuhkan terlalu banyak waktu untuk merespons. · Kesalahan HTTP 504 — Chrome, saat 504 tidak punya halaman sendiri

Apa pun tampilannya, penyebabnya sama: sebuah proxy menunggu server di belakangnya dan jawaban tidak datang tepat waktu. (Chrome memakai kalimat “membutuhkan terlalu banyak waktu untuk merespons” yang sama saat browser Anda sama sekali tidak bisa terhubung, tetapi judulnya lalu “Situs ini tidak dapat dijangkau” dan kodenya ERR_CONNECTION_TIMED_OUT, bukan Kesalahan HTTP 504: lihat ERR_CONNECTION_TIMED_OUT.)

Bagaimana 504 Gateway Timeout terjadi

Untuk memahami error 504, Anda perlu memahami rantai timeout antara browser dan server origin. Permintaan web yang umum melewati beberapa lapisan, dan setiap lapisan punya pengaturan timeout sendiri.

Alur permintaan yang umum: Browser → CDN (Cloudflare) → Load Balancer → Nginx → PHP-FPM → Database. Jika query database memakan 90 detik dan fastcgi_read_timeout nginx 60 detik, nginx berhenti menunggu dan mengembalikan 504 ke load balancer, yang meneruskannya lewat CDN ke browser Anda.

Server yang mengembalikan 504 biasanya proxy di tengah, bukan aplikasinya sendiri. Aplikasi mungkin masih mengerjakan permintaan itu, atau mungkin macet.

Sumber: Cloudflare 524, pengaturan origin CloudFront, Google Cloud, dan dokumentasi tiap server. max_execution_time milik PHP (30 detik) tidak menghasilkan 504: skrip yang mencapainya berhenti dengan fatal error, yang tampil sebagai 500. Dan di Linux ia tidak menghitung waktu menunggu database atau I/O lain, sehingga skrip yang tersangkut di query lambat bisa berjalan jauh lebih lama.

Penyebab umum 504 Gateway Timeout

Alasan yang biasa membuat proxy berhenti menunggu:

• Permintaan yang lambat — query database berat, laporan, atau panggilan ke API pihak ketiga yang lambat memakan waktu lebih lama daripada timeout proxy.
• Server kelebihan beban — CPU 100%, memori menipis, atau semua worker PHP-FPM sibuk, sehingga permintaan baru mengantre sampai proxy menyerah.
• Hambatan database — query lambat, index yang hilang, tabel terkunci, atau connection pool yang habis.
• Timeout terlalu rendah — 60 detik milik nginx terlalu singkat untuk backend yang memang butuh lebih lama (ekspor, impor, unggahan besar).
• Masalah jaringan antara proxy dan origin — packet loss atau firewall yang diam-diam membuang paket proxy (firewall yang menolaknya memberi 502).
• Batas tetap CDN — Cloudflare menunggu 125 detik di Free, Pro, dan Business, apa pun yang diizinkan nginx Anda, lalu menampilkan Error 524.
• Lonjakan lalu lintas — lonjakan atau serangan menyibukkan worker, sehingga permintaan biasa tidak terjawab tepat waktu. (Server yang tahu dirinya kelebihan beban bisa menjawab 503.)

Solusi untuk pengunjung: yang bisa Anda lakukan

Jika Anda melihat error 504 di situs orang lain, masalahnya ada di server mereka, bukan di perangkat Anda. Namun ada beberapa hal yang layak dicoba.

• Tunggu semenit lalu muat ulang — banyak 504 hanya berlangsung selama server sedang sibuk.
• Periksa apakah situs down untuk semua orang — Website Down Checker membuka halaman dari 11 lokasi. Jika mereka juga mendapat 504, masalahnya ada di situs.
• Coba jaringan lain — data seluler alih-alih Wi-Fi, atau tanpa VPN, kalau-kalau proxy atau VPN Anda sendiri yang menjadi gateway yang timeout.
• Lihat halaman status atau akun media sosial situs — situs yang ramai sering mengumumkan gangguan.

Solusi 1: tingkatkan pengaturan timeout (Nginx & Apache)

Perbaikan paling umum untuk error 504 adalah menaikkan nilai timeout pada reverse proxy Anda. Jika backend Anda memang butuh lebih dari 60 detik (default), proxy perlu diberi tahu agar menunggu lebih lama.

# nginx — reverse proxy to a backend (Node.js, Python, etc.)
location / {
    proxy_pass http://backend;
    proxy_read_timeout 300;
    proxy_send_timeout 300;
}

# nginx — FastCGI (PHP-FPM)
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_read_timeout 300;
    fastcgi_send_timeout 300;
    include fastcgi_params;
}

# Leave proxy_connect_timeout / fastcgi_connect_timeout at their defaults:
# nginx caps them at about 75 seconds, and a dead backend should fail fast.

Untuk Apache, tambahkan ProxyTimeout 300 di VirtualHost Anda atau gunakan ProxyPass / http://backend:8080/ timeout=300 untuk satu backend.

Penting: timeout baca dan kirim mengukur jeda antara dua operasi baca atau tulis berurutan, bukan total waktu transfer. Jadi proxy_read_timeout 300 berarti “jika tidak ada data selama 300 detik”, bukan “seluruh respons harus selesai dalam 300 detik”. Muat ulang konfigurasi setelah mengubahnya: sudo nginx -t && sudo systemctl reload nginx.

Di belakang CDN, batasnya sendiri tetap berlaku: Cloudflare memutus pada 125 detik (Free sampai Business) dan CloudFront pada 30 detik secara default, jadi menaikkan nginx melewati angka itu tidak mengubah apa pun bagi pengunjung yang datang lewat CDN.

Solusi 2: optimalkan skrip lambat dan query database

Jika backend Anda terus-menerus melebihi timeout, menaikkan nilai timeout hanya menutupi masalah. Perbaikan sebenarnya adalah membuat backend merespons lebih cepat.

• Temukan query lambat — Aktifkan slow query log MySQL (slow_query_log = 1, long_query_time = 1) atau gunakan EXPLAIN ANALYZE pada query yang dicurigai. Tambahkan index yang hilang, hindari SELECT *, dan gunakan paginasi untuk hasil yang besar.
• Tambahkan caching — Gunakan Redis atau Memcached untuk meng-cache hasil query yang mahal. Query yang memakan 5 detik di setiap pemuatan halaman sebaiknya di-cache.
• Pindahkan pekerjaan berat ke background job — Pembuatan laporan, pengiriman email, pemrosesan gambar, dan impor data sebaiknya berjalan di antrean job (Celery, Sidekiq, Bull), bukan dalam siklus permintaan HTTP.
• Optimalkan panggilan API — Jika backend memanggil API pihak ketiga yang lambat, tambahkan timeout pada panggilan itu dan terapkan circuit breaker agar satu API lambat tidak memblokir semua permintaan.
• Kurangi query N+1 — Query yang dihasilkan ORM sering membuat ratusan panggilan database terpisah. Gunakan eager loading atau query batch untuk mengurangi jumlah round trip.

Solusi 3: periksa sumber daya server (CPU, RAM, disk)

Jika server origin kelebihan beban, ia tidak bisa memproses permintaan cukup cepat dan proxy akan timeout saat menunggu. Periksa apa yang menghabiskan sumber daya.

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space (full disk = silent failures)
df -h

# Check memory details
free -m

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Check active network connections
ss -s

Jika CPU atau RAM berada di atas 90%, Anda perlu mengoptimalkan aplikasi, mematikan proses liar, atau meng-upgrade server. Jika disk penuh, bersihkan file log lama, backup, atau file sementara; disk penuh bisa diam-diam membuat database crash dan memicu rentetan error 504.

Solusi 4: periksa error log

Log error memberi tahu persis mengapa proxy mengembalikan 504. Selalu periksa log sebelum menebak penyebabnya.

# Nginx error log (look for "upstream timed out")
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log       # Debian/Ubuntu
tail -50 /var/log/httpd/error_log          # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.3-fpm.log

# System log (OOM kills, crashes)
tail -50 /var/log/syslog

Pesan log yang umum di balik 504:

“upstream timed out (110: Connection timed out) while reading response header from upstream” (nginx) — backend memakan waktu lebih lama daripada proxy_read_timeout (atau fastcgi_read_timeout). Percepat backend, atau naikkan timeout jika penantiannya wajar.

“upstream timed out (110: Connection timed out) while connecting to upstream” (nginx) — nginx bahkan tidak bisa terhubung tepat waktu: firewall yang membuang paket, atau backend yang terlalu sibuk untuk menerima koneksi.

“server reached pm.max_children setting” (PHP-FPM) — semua worker sibuk, sehingga permintaan menunggu di antrean. Naikkan pm.max_children hanya jika RAM-nya cukup; jika tidak, cari permintaan lambat yang menahan worker.

“Too many connections” (MySQL) — batas koneksi habis. Koneksi baru langsung gagal (sebuah 500, seperti “Error establishing a database connection” di WordPress), sementara query yang menahannya sering kali query lambat di balik 504 Anda.

Solusi 5: sesuaikan pengaturan PHP-FPM

Untuk aplikasi PHP (WordPress, Laravel, Magento), jaga timeout dalam satu rantai, tiap lapisan sedikit lebih panjang daripada lapisan di belakangnya: fastcgi_read_timeout nginx ≥ request_terminate_timeout PHP-FPM ≥ max_execution_time PHP.

Setelah mengubah pengaturan PHP-FPM, restart (sudo systemctl restart php8.3-fpm, sesuaikan versinya). Jika fastcgi_read_timeout nginx lebih pendek daripada batas PHP, nginx menyerah lebih dulu dan pengunjung melihat 504 padahal PHP masih bekerja.

Solusi 6: periksa konfigurasi CDN dan proxy

Jika situs Anda berada di belakang CDN seperti Cloudflare atau AWS CloudFront, CDN punya pengaturan timeout sendiri yang bisa menimpa konfigurasi server Anda.

Cloudflare: di Free, Pro, dan Business, jika origin Anda belum mulai menjawab dalam 125 detik, Cloudflare menyerah dan menampilkan Error 524 (Cloudflare). Saran Cloudflare sendiri: percepat permintaan, pindahkan pekerjaan panjang ke latar belakang, atau layani lewat subdomain DNS-only (awan abu-abu); paket Enterprise bisa menaikkan batasnya.

CloudFront: naikkan response timeout origin di pengaturan origin distribusi (AWS). AWS menyarankan memperbaiki origin yang lambat terlebih dahulu. Untuk permintaan GET dan HEAD, CloudFront mencoba ulang origin (default 3 percobaan koneksi), sehingga origin bisa melihat permintaan yang sama beberapa kali sebelum pengunjung menerima 504.

Untuk melihat lapisan mana yang mengirim 504, periksa header respons di HTTP Header Checker: server: awselb/2.0 adalah load balancer AWS, x-cache: Error from cloudfront adalah CloudFront, dan server: nginx adalah nginx. Di belakang Cloudflare setiap respons berisi server: cloudflare, jadi di sana petunjuknya adalah kodenya sendiri (524 atau 504).

Solusi 7: solusi khusus WordPress

Situs WordPress sangat rentan terhadap error 504 karena plugin yang berat, database yang membengkak, dan batasan shared hosting. Berikut solusi yang ditargetkan.

• Identifikasi plugin lambat — Nonaktifkan semua plugin, lalu aktifkan kembali satu per satu. Jika Anda tidak bisa mengakses wp-admin, ganti nama folder plugins melalui SSH: mv wp-content/plugins wp-content/plugins_disabled. Gunakan plugin Query Monitor untuk mengidentifikasi query database yang lambat.
• Pasang plugin caching — WP Super Cache, W3 Total Cache, atau WP Rocket mengurangi pemrosesan server-side dengan menyajikan HTML statis alih-alih menjalankan PHP di setiap request.
• Gunakan object caching — Pasang Redis atau Memcached dan plugin WordPress object cache. Ini meng-cache hasil query database di memori, mengurangi beban MySQL.
• Bersihkan database — Hapus revisi post lama, transient, komentar spam, dan metadata orphan. Gunakan WP-Optimize atau WP-Sweep. Tambahkan define('WP_POST_REVISIONS', 5); untuk membatasi revisi di masa depan.
• Pindahkan wp-cron ke cron sungguhan — kunjungan halaman memicu WP-Cron, yang menjalankan tugas jatuh tempo dalam permintaan loopback yang memakai satu worker PHP tersendiri. Tambahkan define('DISABLE_WP_CRON', true); ke wp-config.php, lalu minta server menjalankan wp cron event run --due-now setiap 5 menit.

504 vs 502 vs 503 vs 408: apa bedanya?

Kode error HTTP ini sering tertukar. Berikut arti sebenarnya dari masing-masing.

Pembedanya: 502 berarti proxy menerima jawaban rusak, atau koneksi ditolak atau ditutup; 504 berarti timer proxy habis sementara upstream tetap diam. 503 tidak butuh proxy: server mana pun bisa mengirimnya saat kelebihan beban. 408 adalah timeout di sisi klien (kelas 4xx), saat server berhenti menunggu klien.

Jika Anda melihat 502 dan 504 bersamaan, backend kemungkinan sedang kesulitan: permintaan yang timeout memberi 504, dan worker yang crash atau dimatikan memberi 502.

Jika yang Anda lihat 502, bukan 504, panduan 502 Bad Gateway kami membahas pesan log error nginx yang menjelaskannya, termasuk kasus nyata dari situs ini.

Apakah error 504 memengaruhi SEO?

Dokumentasi Google menjelaskan dampak error 5xx (dokumentasi crawler Google):

• Crawling melambat untuk seluruh situs, sebanding dengan jumlah URL yang mengembalikan error server.
• Halaman yang sudah terindeks awalnya dipertahankan, tetapi URL yang terus mengembalikan error server akhirnya dihapus.
• Crawling pulih bertahap setelah server kembali menjawab dengan 2xx.

Cara mencegah error 504 Gateway Timeout

Pencegahan lebih baik daripada pemadaman kebakaran. Praktik-praktik ini akan menjaga server Anda merespons dalam batas timeout.

• Siapkan monitoring — monitor uptime yang memuat halaman penting setiap beberapa menit menangkap 504 sebelum pengguna Anda melaporkannya.
• Sesuaikan rantai timeout — Pastikan timeout CDN ≥ timeout proxy ≥ timeout aplikasi. Nilai yang tidak cocok menyebabkan error 504 yang tidak terduga.
• Implementasikan health check — Load balancer dan proxy harus melakukan health-check ke server upstream dan mengarahkan traffic menjauhi instance yang tidak merespons.
• Gunakan caching secara agresif — Cache aset statis, respons API, dan query database. Respons yang di-cache tidak pernah cukup lambat untuk menyebabkan 504.
• Auto-scale — Gunakan horizontal scaling (lebih banyak instance) agar lonjakan traffic tidak membanjiri satu server.
• Pindahkan pekerjaan berat — Pindahkan pemrosesan file, pembuatan laporan, pengiriman email, dan impor massal ke background job queue. Jangan pernah melakukan pekerjaan mahal di dalam HTTP request.
• Monitor query lambat — Aktifkan slow query logging di MySQL/PostgreSQL. Atur alert untuk query yang melebihi 1 detik.
• Jaga kesehatan dependensi — Monitor API pihak ketiga yang menjadi dependensi backend Anda. Tambahkan timeout dan circuit breaker agar satu API yang lambat tidak menyebar menjadi error 504 untuk semua pengguna.