504 Gateway Timeout Nedir?
Kısa tanım
504 Gateway Timeout, ağ geçidi ya da proxy olarak çalışan bir sunucunun, isteği tamamlamak için ihtiyaç duyduğu arkadaki (upstream) sunucudan zamanında yanıt alamadığını bildiren HTTP durum kodudur. Bağlantı kurulmuş olabilir; sorun, yanıtın proxy'nin bekleme süresi dolmadan gelmemesidir. Yavaş veritabanı sorguları, uzun süren işlemler ve dış servis beklemeleri en yaygın nedenlerdir.
Diğer adları: HTTP 504, 504 hatası, ağ geçidi zaman aşımı, gateway timeout
Bekleme süresi doldu
Bir reverse proxy, arkasındaki uygulamaya isteği ilettikten sonra sonsuza kadar beklemez. Her katmanın bir zaman aşımı vardır ve bu süre içinde yanıt gelmezse proxy bağlantıyı bırakıp istemciye 504 döndürür. Uygulama belki hâlâ çalışıyor, belki birkaç saniye sonra işi bitirecektir; ama kullanıcı o sonucu hiçbir zaman görmez.
Nginx'te bu davranışı belirleyen başlıca ayarlar proxy_connect_timeout, proxy_send_timeout ve proxy_read_timeout'tur; üçünün de varsayılan değeri 60 saniyedir. proxy_read_timeout, yanıtın tamamı için değil, arka arkaya gelen iki okuma arasındaki süre için geçerlidir. Süre dolduğunda hata kaydında şu satır görünür:
upstream timed out (110: Connection timed out) while reading response header from upstreamZincirde en kısa süre kazanır
İstek birden fazla aracıdan geçiyorsa her birinin kendi zaman aşımı vardır ve ilk dolan süre hatayı belirler. Cloudflare'in origin'den yanıt bekleme süresi varsayılan olarak 125 saniyedir ve bu süre aşılırsa standart 504 yerine kendine özgü 524 kodunu gösterir. Arkada 60 saniyelik Nginx ayarı varsa, 70 saniye süren bir istek Cloudflare'e ulaşmadan Nginx tarafından 504 ile kesilir. Teşhiste ilk soru bu yüzden "hangi katmanın saati doldu?" olmalıdır.
Neden oluşur?
- İndekssiz bir tabloda tam tarama yapan yavaş sorgular; bu durumda doğru veritabanı indeksi çoğu zaman sorunu kökten çözer.
- Uygulamanın yanıt vermeden önce yavaş bir dış API'yi beklemesi.
- Bağlantı havuzunun tükenmesi: istekler sorgu çalıştırmak için boş bağlantı bekleyerek kuyrukta zaman kaybeder.
- Büyük rapor, dışa aktarma veya toplu e-posta gibi işlerin HTTP isteği içinde çalıştırılması.
Zaman aşımını uzatmak neden çözüm değil?
İlk refleks, süreyi 60 saniyeden 300 saniyeye çıkarmaktır. Bu, belirtiyi gizler ama yavaşlığı ortadan kaldırmaz; üstelik her bekleyen istek bir işçi sürecini ve bağlantıyı meşgul eder. Uzun yanıt veren uç noktalar, kaynak tüketen bir saldırı için de elverişli hedeftir; makul zaman aşımları bu açıdan bir güvenlik önlemidir. Kalıcı çözüm, uzun işi istek-yanıt döngüsünden çıkarmaktır: istek işi bir iş kuyruğuna bırakır, hemen 202 Accepted döner, istemci de sonucu ayrı bir uç noktadan sorgular.
location /api/ {
proxy_pass http://127.0.0.1:3000;
proxy_connect_timeout 5s;
proxy_read_timeout 30s;
}Bağlantı kurma süresini kısa tutmak, arkadaki sunucu tamamen erişilemez olduğunda kullanıcının bir dakika boyunca boş ekrana bakmasını önler.
SEO ve kullanıcı deneyimi
Google, 504'ü de bir 5xx yanıtı olarak işler ve taramayı yavaşlatır. Daha sinsi olan, zaman aşımına henüz ulaşmayan ama ona yaklaşan yanıtlardır: yüksek TTFB hem kullanıcının sabrını hem de tarayıcının sayfayı işleme hızını düşürür. Ara sıra görülen 504'ler genellikle aynı yavaş uç noktaların aşırı yüklenmiş anlarıdır; yanıt süresi dağılımını izlemek, sorunu 504'e dönüşmeden yakalamayı sağlar.