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.

Definisi resminya berasal dari RFC 9110 (HTTP Semantics), Bagian 15.6.5, yang menyatakan: "Kode status 504 (Gateway Timeout) menunjukkan bahwa server, saat bertindak sebagai gateway atau proxy, tidak menerima respons tepat waktu dari server upstream yang perlu diakses untuk menyelesaikan permintaan."

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

Terlepas dari perbedaan kata-kata, penyebab dasarnya selalu sama: server proxy menunggu server upstream untuk merespons dan server upstream tidak merespons dalam batas waktu timeout yang dikonfigurasi.

• 504 Gateway Timeout

• 504 Gateway Time-out (default Nginx — menggunakan tanda hubung)

• HTTP Error 504 — Gateway Timeout

• This page isn't working — [domain] took too long to respond (Chrome / Edge)

• Gateway Timeout (Firefox)

• Error 504

• 504 Gateway Time-out — The server didn't respond in time (Apache dengan mod_proxy)

• Error 524: A timeout occurred (khusus Cloudflare — secara teknis bukan 504, tetapi penyebab yang sama)

• ERROR — The request could not be satisfied — 504 ERROR (AWS CloudFront)

Bagaimana 504 Gateway Timeout Terjadi

Untuk memahami error 504, Anda perlu memahami rantai timeout antara browser dan server origin. Sebuah request web biasa melewati beberapa lapisan, dan setiap lapisan memiliki pengaturan timeout sendiri.

Berikut alur request yang umum: Browser → CDN (Cloudflare) → Load Balancer → Nginx → PHP-FPM → Database. Jika query database memakan waktu 90 detik dan proxy_read_timeout Nginx diatur ke 60 detik, Nginx berhenti menunggu dan mengembalikan 504 ke load balancer, yang meneruskannya kembali ke browser Anda.

Server yang mengembalikan 504 selalu merupakan perantara (proxy atau gateway), bukan server origin itu sendiri. Server origin hanya tidak merespons tepat waktu — mungkin masih memproses request, atau mungkin telah crash sepenuhnya.

Penyebab Umum 504 Gateway Timeout

Memahami akar masalah adalah jalan tercepat menuju solusi. Berikut penyebab paling umum server mengembalikan 504, diurutkan berdasarkan frekuensi.

• Server origin lambat — Skrip PHP yang menjalankan query database kompleks, membuat laporan, atau memanggil API pihak ketiga yang lambat bisa melebihi timeout proxy. Ini adalah penyebab #1 error 504.

• Server kelebihan beban — CPU di 100%, kehabisan memori (OOM kills), atau semua worker PHP-FPM sibuk. Server origin hidup tetapi terlalu kewalahan untuk merespons tepat waktu.

• Bottleneck database — Query SQL lambat, index yang hilang, table lock, atau connection pool yang habis. Aplikasi hang menunggu database, dan proxy timeout.

• Nilai timeout yang salah konfigurasi — proxy_read_timeout Nginx diatur terlalu rendah untuk backend yang memang membutuhkan waktu lebih lama (misalnya, generator laporan atau handler upload file).

• Masalah jaringan antara proxy dan origin — Packet loss, latensi tinggi, atau masalah routing antar data center. Umum terjadi pada setup multi-region atau hybrid cloud.

• Firewall atau security group memblokir traffic — AWS security group tidak mengizinkan traffic pada port ephemeral, aturan iptables memblokir koneksi internal, atau WAF memblokir request upstream yang sah.

• Kegagalan resolusi DNS di proxy — Proxy tidak bisa me-resolve hostname upstream. Di Nginx, ini terjadi saat menggunakan variabel di proxy_pass tanpa directive resolver.

• Timeout CDN — Cloudflare memiliki batas keras 100 detik pada paket Free/Pro/Business. Jika origin Anda membutuhkan lebih dari 100 detik, Cloudflare mengembalikan Error 524 terlepas dari konfigurasi Nginx Anda.

• Serangan DDoS — Banjir request menghabiskan sumber daya server, membuat origin terlalu lambat untuk merespons traffic yang sah dalam batas timeout proxy.

Solusi untuk Pengunjung: Yang Bisa Anda Lakukan

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

• Tunggu dan refresh — Sebagian besar error 504 bersifat sementara. Tunggu 30-60 detik, lalu hard-refresh halaman dengan Ctrl+Shift+R (Windows/Linux) atau Cmd+Shift+R (Mac).

• Periksa apakah situs down untuk semua orang — Gunakan tool HTTP Headers DNS Robot untuk memeriksa kode respons server dari lokasi eksternal. Jika mengembalikan 504 untuk semua orang, masalahnya ada di sisi server.

• Coba incognito atau browser berbeda — Untuk menghilangkan kemungkinan ekstensi browser, halaman error yang di-cache, dan masalah konfigurasi lokal.

• Coba jaringan berbeda — Beralih dari Wi-Fi ke data seluler, atau matikan VPN Anda. Masalah routing antara ISP dan server terkadang bisa menyebabkan 504.

• Flush cache DNS Anda — Record DNS yang sudah kadaluarsa bisa mengarahkan request ke server yang salah. Di Windows: ipconfig /flushdns. Di Mac: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder.

• Periksa halaman status atau media sosial situs — Situs mungkin telah memposting tentang gangguan atau jadwal pemeliharaan yang diketahui.

Solusi 1: Tingkatkan Pengaturan Timeout (Nginx & Apache)

Solusi paling umum untuk error 504 adalah meningkatkan nilai timeout pada reverse proxy Anda. Jika backend Anda memang membutuhkan lebih dari 60 detik (nilai default), proxy perlu tahu untuk menunggu lebih lama.

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

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

Untuk Apache dengan mod_proxy, tambahkan ProxyTimeout 300 di VirtualHost Anda atau gunakan ProxyPass / http://backend:8080/ timeout=300 untuk konfigurasi per-backend.

Penting: Timeout ini mengukur waktu antara dua operasi read/write berturut-turut, bukan total waktu transfer. Jadi proxy_read_timeout 300 berarti "jika tidak ada data yang masuk selama 300 detik," bukan "seluruh respons harus selesai dalam 300 detik." Setelah mengubah nilai timeout, reload konfigurasi: sudo nginx -t && sudo systemctl reload nginx.

Solusi 2: Optimalkan Skrip Lambat dan Query Database

Jika backend Anda secara konsisten melebihi timeout, meningkatkan nilai timeout hanya menyembunyikan masalah. Solusi sebenarnya adalah membuat backend merespons lebih cepat.

• Temukan query lambat — Aktifkan MySQL slow query log (slow_query_log = 1, long_query_time = 1) atau gunakan EXPLAIN ANALYZE pada query yang dicurigai. Tambahkan index yang hilang, hindari SELECT *, dan paginasi result set yang besar.

• Tambahkan caching — Gunakan Redis atau Memcached untuk meng-cache hasil query yang mahal. Query yang memakan 5 detik pada setiap page load seharusnya di-cache.

• Pindahkan pekerjaan berat ke background job — Pembuatan laporan, pengiriman email, pemrosesan gambar, dan impor data seharusnya berjalan di job queue (Celery, Sidekiq, Bull), bukan dalam siklus HTTP request.

• Optimalkan panggilan API — Jika backend Anda memanggil API pihak ketiga yang lambat, tambahkan timeout pada panggilan tersebut dan implementasikan circuit breaker agar satu API yang lambat tidak memblokir semua request.

• Kurangi query N+1 — Query yang dihasilkan ORM sering membuat ratusan panggilan database individual. Gunakan eager loading atau batch query untuk mengurangi round trip.

Solusi 3: Periksa Sumber Daya Server (CPU, RAM, Disk)

Jika server origin kelebihan beban, ia tidak bisa memproses request cukup cepat, dan proxy timeout menunggu. Periksa apa yang mengonsumsi 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 di atas 90%, Anda perlu mengoptimalkan aplikasi, menghentikan proses yang tidak terkendali, atau meng-upgrade server. Jika disk penuh, bersihkan file log lama, backup, atau file temporary — disk yang penuh bisa menyebabkan database crash secara diam-diam dan memicu error 504 secara berantai.

Solusi 4: Periksa Error Log

Error log memberi tahu Anda 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.2-fpm.log

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

Pesan log umum yang menyebabkan 504:

"upstream timed out (110: Connection timed out)" (Nginx) — Server upstream tidak merespons dalam proxy_read_timeout. Tingkatkan timeout atau perbaiki upstream yang lambat.

"server reached pm.max_children" (PHP-FPM) — Semua proses worker PHP sedang sibuk. Tingkatkan pm.max_children di konfigurasi pool PHP-FPM.

"connect() failed (111: Connection refused)" (Nginx) — Server upstream tidak berjalan atau tidak mendengarkan di port yang diharapkan. Restart backend.

"Too many connections" (MySQL) — Batas koneksi database telah habis. Tingkatkan max_connections di konfigurasi MySQL atau optimalkan connection pooling.

Solusi 5: Sesuaikan Pengaturan PHP-FPM

Setelah mengubah pengaturan PHP-FPM, restart service: sudo systemctl restart php8.2-fpm. Pastikan fastcgi_read_timeout Nginx selalu lebih besar atau sama dengan max_execution_time PHP. Jika tidak, Nginx menyerah sebelum PHP selesai, sehingga menghasilkan 504.

Solusi 6: Periksa Konfigurasi CDN dan Proxy

Pengguna Cloudflare: Jika Anda menggunakan paket Free, Pro, atau Business dan origin Anda membutuhkan lebih dari 100 detik, Anda akan selalu mendapatkan Error 524. Satu-satunya opsi adalah: optimalkan backend agar merespons dalam 100 detik, pindahkan tugas yang berjalan lama ke background job, atau upgrade ke Enterprise.

Pengguna AWS CloudFront: Tingkatkan origin response timeout di pengaturan origin distribusi Anda. Default 30 detik sering terlalu rendah untuk konten dinamis.

Gunakan tool HTTP Headers DNS Robot untuk memeriksa response header dan mengidentifikasi lapisan mana yang mengembalikan 504. Cari header seperti server: cloudflare, server: awselb/2.0, atau server: nginx untuk menentukan proxy-nya.

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.

• Tingkatkan memori PHP — Tambahkan define('WP_MEMORY_LIMIT', '512M'); ke wp-config.php. Banyak plugin membutuhkan lebih dari default 128MB.

• 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.

• Nonaktifkan wp-cron — Virtual cron WordPress berjalan di setiap page load dan bisa menumpuk tugas. Tambahkan define('DISABLE_WP_CRON', true); ke wp-config.php dan atur cron job server yang sebenarnya: */5 * * * * curl -s https://yoursite.com/wp-cron.php > /dev/null 2>&1.

504 vs 502 vs 503 vs 408: Apa Bedanya?

Perbedaan kritis: 502 berarti proxy mendapat respons yang buruk, sementara 504 berarti proxy tidak mendapat respons sama sekali. Error 503 tidak memerlukan proxy — server mana pun bisa mengembalikannya saat kelebihan beban. Error 408 adalah timeout sisi client (kelas 4xx), di mana server menyerah menunggu client.

Jika Anda melihat 502 dan 504 secara bersamaan, server upstream kemungkinan besar sedang crash. Error 502 terjadi ketika proxy mendapat respons parsial atau rusak dari proses yang sedang mati, dan 504 terjadi ketika proses sepenuhnya tidak merespons.

Apakah Error 504 Memengaruhi SEO?

Jawaban singkat: error 504 yang singkat tidak berdampak pada SEO. Error 504 yang berkepanjangan bisa menyebabkan deindexing.

Menit hingga jam: Tidak berdampak. Google memahami error server sementara dan tidak langsung memberikan penalti. Jika Googlebot kebetulan tidak meng-crawl selama gangguan, ia bahkan tidak akan menyadarinya.

Jam hingga hari: Google mengurangi frekuensi crawl untuk situs yang mengembalikan error 5xx untuk menghindari menambah beban pada server yang sedang bermasalah. Halaman mungkin muncul sebagai "Server error (5xx)" di laporan Page Indexing Google Search Console.

Hari hingga minggu: Error 504 yang persisten bisa menyebabkan deindexing halaman yang terdampak. Peringkat turun secara signifikan. Menurut John Mueller dari Google: jika server down selama sehari, hal-hal mungkin "tidak stabil" selama satu hingga tiga minggu setelah pemulihan.

Pemulihan: Setelah server stabil kembali, Google meng-crawl ulang dan mengindeks ulang halaman secara otomatis. Gunakan tool URL Inspection di Google Search Console untuk meminta pengindeksan ulang halaman penting. Waktu pemulihan tergantung pada ukuran situs dan berapa lama error berlangsung.

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 — Gunakan uptime monitoring (UptimeRobot, Pingdom, atau tool Ping DNS Robot) untuk mendeteksi error 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.