504 Gateway Timeout berarti server di depan — biasanya Nginx atau sebuah load balancer — meneruskan permintaan Anda ke backend, menunggu, lalu menyerah. Backend tidak menolak, tidak crash; ia hanya belum sempat menjawab.
Membedakan ini dari 502 menghemat banyak waktu. 502 berarti backend mengembalikan sesuatu yang tidak masuk akal atau sudah mati; 504 berarti ia masih berjalan, masih bekerja, hanya lebih lambat daripada batas kesabaran yang dikonfigurasi. Hampir semua perbaikan 504 bermuara pada dua hal: mempercepat pekerjaannya, atau menaikkan batas tunggu — dan urutan itu sebaiknya tidak dibalik.
Beda 504 dengan 502, 503, dan 408
Keempatnya muncul saat ada yang salah antara proxy dan aplikasi, tetapi masing-masing menunjuk ke tempat yang berbeda.
| Kode | Apa yang terjadi | Periksa dulu |
|---|---|---|
| 504 Gateway Timeout | Backend hidup tapi menjawab terlalu lambat | Query lambat, API eksternal, proses panjang |
| 502 Bad Gateway | Backend mati atau balasannya rusak | Log crash PHP-FPM, Node, Gunicorn |
| 503 Service Unavailable | Server menolak menerima pekerjaan baru | Antrean penuh, maintenance, rate limit |
| 408 Request Timeout | Klien mengirim permintaan terlalu lambat | Jaringan pengguna, upload besar |
Timeout mana yang sebenarnya habis
Inilah yang membuat 504 lebih menyebalkan dari seharusnya: satu permintaan melewati beberapa lapisan, masing-masing punya hitungan mundur sendiri, dan lapisan yang habis lebih dulu menentukan pesan yang Anda lihat. Menaikkan angka yang salah tidak mengubah apa pun.
| Lapisan | Parameter umum | Nilai bawaan tipikal |
|---|---|---|
| Nginx → backend | proxy_read_timeout | 60 detik |
| Nginx → PHP-FPM | fastcgi_read_timeout | 60 detik |
| PHP | max_execution_time | 30 detik |
| PHP-FPM | request_terminate_timeout | biasanya nonaktif |
| Cloudflare (paket gratis) | timeout tetap | 100 detik — tidak bisa diubah |
Penyebab umum, dari yang paling sering
- Query database lambat. Penyebab nomor satu, hampir selalu satu query tanpa index yang memindai seluruh tabel setelah datanya membesar.
- Panggilan API eksternal tanpa timeout. Aplikasi Anda menunggu layanan pihak ketiga yang sedang lambat, dan karena tidak ada batas waktu, ia menunggu selamanya.
- Pekerjaan berat dijalankan di dalam permintaan HTTP. Ekspor laporan, kirim email massal, pemrosesan gambar — semua itu milik antrean latar belakang, bukan siklus permintaan.
- Worker habis. Semua proses PHP-FPM atau Node sibuk dengan permintaan lambat, sehingga permintaan baru mengantre sampai waktunya habis sebelum sempat diproses.
- Cron yang tumpang tindih. wp-cron di situs ramai terpicu setiap kunjungan, menumpuk, dan menghabiskan worker.
- Server kehabisan RAM lalu mulai swap. Semua tetap berjalan, hanya puluhan kali lebih lambat, dan timeout muncul di seluruh situs.
- Plugin atau pustaka yang mengakses jaringan saat halaman dimuat. Cek pembaruan, validasi lisensi, memuat font jarak jauh — masing-masing menambah beberapa detik.
Periksa dengan urutan ini
- Tentukan apakah error terjadi di semua halaman atau hanya beberapa. Seluruh situs lambat biasanya soal sumber daya server; satu halaman lambat hampir selalu satu query atau satu panggilan eksternal di halaman itu.
- Ukur waktu respons sebenarnya dengan "curl -o /dev/null -s -w '%{time_total}\n' https://situsanda.com/". Angkanya memberi tahu apakah Anda mepet di ambang batas atau jauh melewatinya.
- Aktifkan slow query log MySQL dengan ambang 1 detik lalu biarkan beberapa menit. Ini langkah dengan hasil tercepat di seluruh daftar ini.
- Baca error log Nginx. Baris "upstream timed out" menyebutkan backend dan endpoint mana yang kehabisan waktu.
- Periksa RAM dan swap dengan "free -m". Kalau swap dipakai banyak, tangani memori dulu — sisanya cuma mengobati gejala.
- Hitung worker yang sibuk dibanding totalnya. PHP-FPM punya halaman status; kalau selalu menyentuh pm.max_children, masalahnya antrean, bukan timeout itu sendiri.
- Nonaktifkan sementara komponen yang memanggil layanan eksternal. Kalau 504 hilang, pelakunya ketemu dan Anda bisa memberi timeout pendek untuk panggilan itu.
- Naikkan timeout hanya setelah tahu persis apa yang lambat, dan lakukan sebagai langkah sementara yang disengaja, bukan sebagai perbaikan.
Memperbaiki akar masalahnya
Setelah tahu apa yang lambat, penanganannya hampir selalu jatuh ke salah satu dari tiga kelompok berikut.
Tambahkan index untuk query lambat. Kolom yang sering difilter tanpa index memaksa database membaca seluruh tabel di setiap permintaan. Jalankan EXPLAIN pada query terlambat di log; kalau terlihat pemindaian penuh, Anda sudah menemukan pekerjaannya dan biasanya selesai kurang dari semenit.
Keluarkan pekerjaan panjang dari siklus permintaan. Ekspor file, kirim email, buat thumbnail, dan sinkronisasi data sebaiknya berjalan di antrean latar belakang, sementara permintaan HTTP langsung menjawab bahwa pekerjaan sudah diterima. Ini perubahan paling memakan tenaga, tapi juga yang menghapus seluruh kelas error 504 secara permanen.
Beri timeout pada setiap panggilan keluar. Setiap permintaan ke layanan pihak ketiga harus punya batas beberapa detik dan penanganan kegagalan. Tanpa itu, API lambat di belahan dunia lain langsung menjadi halaman error Anda.
Kalau semuanya sudah wajar tapi server tetap tidak sanggup, barulah masalahnya benar-benar sumber daya. CPU selalu tinggi, RAM selalu habis, dan swap aktif terus adalah tanda nyata untuk upgrade — berbeda dengan upgrade hanya karena melihat 504.
Butuh sumber daya yang cukup agar tak berlomba dengan timeout?
Cloud VPS NVMe dengan akses root penuh — atur sendiri timeout, slow query log, dan jumlah worker. Mulai ฿150/bulan.
Pertanyaan yang Sering Diajukan
Saya sudah menaikkan timeout tapi 504 tetap muncul. Kenapa?
Karena Anda menaikkan lapisan yang salah. Permintaan melewati Nginx, lalu PHP-FPM atau application server, lalu database, dan setiap lapisan punya timeout sendiri — yang terpendek yang menang. Kalau situs berada di belakang Cloudflare paket gratis, ada pula batas keras 100 detik yang tidak bisa dilewati konfigurasi server mana pun.
Apakah 504 memengaruhi SEO?
Ya, kalau berlangsung lama. Googlebot yang menemui 504 akan mencoba lagi nanti, dan beberapa kejadian sesekali hampir tidak berdampak. Tapi timeout terus-menerus selama berhari-hari menurunkan laju crawl dan akhirnya membuat halaman keluar dari indeks. Laporan Crawl stats di Search Console menunjukkan berapa banyak error yang benar-benar ditemui Googlebot.
Kenapa 504 hanya muncul saat jam ramai?
Karena yang habis adalah worker, bukan waktu. Saat semua proses sibuk, permintaan baru mengantre dan hitungan timeout sudah berjalan sebelum ada yang memprosesnya. Cari query lambat yang menahan worker terlalu lama, alih-alih menambah worker lalu kehabisan RAM.
Admin WordPress saya 504 tapi halaman publiknya normal. Kenapa?
Karena halaman admin tidak di-cache dan menjalankan jauh lebih banyak query. Penyebab tersering adalah tabel wp_options yang membengkak oleh transient kedaluwarsa, atau plugin yang mengecek pembaruan saat halaman dimuat. Bersihkan transient lama dan matikan plugin satu per satu untuk menemukan pelakunya.
GUIDES
Artikel terkait
Lanjut membaca topik serupa
502 Bad Gateway — Arti dan Cara Mengatasinya
502 berarti satu server meminta halaman ke server lain dan menerima jawaban yang tidak bisa dipakai. Panduan ini menjelaskan dua mesin mana yang terlibat, beda 502 dengan 500 dan 504, serta urutan pemeriksaan supaya Anda menemukan penyebab aslinya lebih dulu.
Baca selengkapnya
503 Service Unavailable — Penyebab dan Cara Mengatasinya
503 berbeda dari semua error 5xx lainnya dalam satu hal: sering kali ia jawaban yang disengaja. Server tetap berjalan, tetap memahami permintaan, dan secara aktif mengatakan bahwa saat ini ia tidak menerima pekerjaan.
Baca selengkapnya
500 Internal Server Error — Penyebab dan Cara Mengatasinya
500 adalah error paling tidak informatif di web: artinya "ada yang salah dan saya tidak akan bilang apa". Kabar baiknya, server hampir selalu menuliskan alasan sebenarnya ke sebuah file log. Panduan ini menunjukkan di mana log itu dan urutan pemeriksaan yang paling cepat menemukan biangnya.
Baca selengkapnya