504 Gateway Timeout: Hata sunucudan mı hostingten mi?

504 Gateway Timeout, istemcinin (tarayıcı/uygulama) bir gateway veya proxy üzerinden bağlandığı upstream sunucunun zamanında yanıt verememesi durumunda oluşur. Hata mesajı tek başına “suçlunun kim olduğunu” söylemez: sorun uygulama katmanında (ör. PHP/Node), reverse proxy tarafında (Nginx/HAProxy), hosting tarafında (proxy/CDN/WAF veya load balancer), hatta DNS/CDN önbellek akışında bile görülebilir.

Bu rehberde amaç, “sorun hosting mi sunucu mu?” sorusuna ölçülebilir testlerle net yanıt vermek. 15 Ağustos 2026 şartlarına uygun şekilde CDN/WAF, port/route, log korelasyonu ve performans sinyallerini kullanarak kaynağı sınıflandıracaksınız.

504 Gateway Timeout’un tipik akışını doğru okuyun

Bir 504 genelde şu zincirde gecikme olduğunda çıkar:

1. Tarayıcı bir alan adını (domain) çözer (DNS).
2. Trafik çoğu kurulumda CDN/WAF veya hosting’in edge proxy katmanına gider.
3. Edge proxy, sizin altyapınıza yönlendirir (reverse proxy / load balancer).
4. Reverse proxy, uygulamanın servis verdiği upstream’e bağlanır (ör. Nginx → PHP-FPM, Nginx → Node, Nginx → başka container).
5. Upstream yanıt vermezse proxy zaman aşımına düşer ve 504 döner.

Önemli nokta: 504’ün kaynağı çoğunlukla upstream yanıt süresi ve proxy zaman aşımı (timeout) kombinasyonudur. Yani “hosting yavaş” ya da “sunucu çöktü” demek yerine önce zinciri bölmeniz gerekir.

Hangi bileşenler 504 üretebilir?

Aşağıdaki bileşenlerden herhangi biri 504 döndürebilir:

• CDN/WAF (ör. Cloudflare benzeri edge): Upstream yanıt gelmediğinde veya kural/limitlemede gateway timeout dönebilir.
• Hosting’in reverse proxy / load balancer’ı: Hizmet katmanında timeout ayarı yüksek trafik altında tetiklenebilir.
• Kendi Nginx/Apache kurulumunuz: proxy_read_timeout, fastcgi_read_timeout, keepalive_timeout gibi ayarlar kritik olur.
• Uygulama: Uygulama yanlış sorgu, kilitlenme, dış servis beklemesi (API call) veya veri tabanı kilidi yüzünden yanıt üretemez.
• DNS yönlendirme / yanlış route: Her istek düzgün upstream’e gitmezse bazı akışlar timeout üretir.

504’ü “sunucu mu hosting mi?” diye ayıran 6 net test

Aşağıdaki testler sırayla yapıldığında hatanın hangi katmanda yoğunlaştığı ortaya çıkar. Her testin çıktısı, karar ağacını “tahmin” değil “kanıt” haline getirir.

1) 504 her kullanıcıda mı, yoksa sadece bazı IP/ülkelerde mi?

• Sadece belirli coğrafya/ISP: CDN/route farklılığı veya upstream’e giden bağlantı kalitesi (packet loss, BGP yolu) ihtimali artar.
• Tüm kullanıcılar: uygulama veya origin tarafında yaygın bir timeout olasılığı yükselir.

Net gösterge: CDN varsa “edge konumu” bazlı metriklerde hata oranı görünür. Yoksa tarayıcıdan farklı ağlar (mobil veri + farklı Wi-Fi) ile aynı anda deneme yapın.

2) 504 sayfası aynı mı? (CDN/Proxy imzası)

504 hata sayfasının görsel/HTML içeriği bile ipucu verir:

• Hosting’in standart 504 sayfası (markalı bir tema) → genellikle hosting’in gateway katmanı.
• Kendi Nginx hata sayfanız → Nginx/uygulama reverse proxy katmanı.
• CDN’nin standart hata sayfası → edge katmanı.

Net karar için örnek: 504 çıktısında “Cloudflare” benzeri başlık/ikon veya Nginx imzası (ör. nginx) gibi izler kontrol edilmelidir.

3) Aynı endpoint’i doğrudan origin’e bağlanabiliyor musunuz?

CDN/WAF kullanıyorsanız origin’i doğrudan görmek için iki yaklaşım kullanın:

• Origin alan adı veya IP üzerinden istek atın.
• CDN bypass (mümkünse) veya Host başlığını doğru ayarlayarak test edin.

Amaç: Edge/proxy olmadan upstream’e ulaşınca istek tamamlanıyor mu, yoksa yine timeout mu oluyor?

Aşağıdaki komut bir “proxy zinciri” olmadan deneme için yönlendirici olur:

• curl -I https://origin.example.com/urun
• curl -v https://origin.example.com/urun

Çıktıda timeout benzeri satırlar görürsen sorun origin tarafında (sunucu/app). Edge’de çalışıyor ama origin’de de timeout oluyorsa doğrudan uygulama ya da servis kaynaklıdır.

4) 504 zamanı ile sunucu/uygulama loglarını eşleştirin (log korelasyonu)

Hatanın “ne zaman” başladığını dakika bazında tespit edin ve şu log kaynaklarını aynı zaman dilimi ile eşleyin:

• Reverse proxy logları (Nginx access/error): upstream response time, 504 üreten request’ler.
• Uygulama logları: istek başlatıldıktan sonra hangi adımda beklediği.
• Veritabanı logları / APM: uzun sorgu, lock, timeout.
• Sistem logları: OOM (Out of Memory), restart, CPU steal, disk I/O gecikmesi.

Net hedef: Aynı request için “gateway timeout” satırı ile “uygulama hanginde takıldı?” satırı arasında korelasyon kurmak.

5) Uygulama thread/process tıkanması var mı? (metrik kontrolü)

504’ün en sık nedeni upstream’in yanıtı geciktirmesidir. Şu sinyaller doğrudan “sunucu” lehine delildir:

• CPU kullanımı uzun süre %80-100 bandında
• RAM tüketimi ve swap kullanımı
• Nginx upstream timed out tarzı hatalar
• PHP-FPM havuzu (pool) dolu / queue büyümesi
• Node/Java uygulamada çalışan thread sayısı limitte
• Veritabanı bağlantı havuzu (pool) dolu

Hız göstergesi için basit test: Aynı endpoint’e art arda 10 istek atıp yanıt sürelerini karşılaştırın. Tam yükte timeout büyüyorsa tıkanma vardır.

6) Hosting kontrol panelinde “edge/WAF/DDoS throttling” sinyali var mı?

Hosting katmanı kaynaklı 504’ler genellikle “kural/limitleme veya upstream erişim sorunu” ile ilişkilidir.

Kontrol edin:

• WAF kural ihlali mi yapıyor? (belirli URL’lerde artan rate)
• DDoS koruma throttling uygulandı mı?
• Trafik yoğunluğunda 502/504 artışı var mı?
• Load balancer health check başarısız mı?

Net karar: Gateway katmanı timeout üretiyor ama origin loglarında ilgili request hiç görünmüyorsa (veya çok az görünüyorsa) suçlu çoğunlukla edge/gateway tarafıdır.

Nginx/Reverse proxy tarafında 504’ü doğrudan azaltan ayar kümeleri

Eğer kendi sunucunuzda Nginx (veya benzeri reverse proxy) kullanıyorsanız 504’ün bir kısmını timeout uyumsuzluğu belirler. Buradaki amaç “zaman aşımını körlemesine yükseltmek” değil, upstream’in gerçekten zamanında yanıt üretip üretmediğini doğrulamaktır.

En sık kullanılan timeout alanları

• proxy_read_timeout: Upstream’in yanıtı ne kadar beklenir.
• proxy_connect_timeout: Upstream’e bağlanma süresi.
• fastcgi_read_timeout: PHP-FPM gibi FastCGI cevap bekleme.
• send_timeout / keepalive_timeout: Bağlantı durumu.

Örnek (sadece mantık göstermek için):

• proxy_read_timeout 60s;
• proxy_connect_timeout 5s;

Bu değerleri artırmak bazen geçici çözüm sağlar; ancak upstream’in gerçekte veri tabanı kilidi veya bekleme yüzünden gecikmesi devam ediyorsa, 504’ten farklı bir hataya (ör. 502 veya uygulama timeout) kayabilirsiniz.

Uygulama ve veritabanı kaynaklı 504’ü ayırt etme

“Sunucu mu hosting mi?” sorusunda en güçlü kanıt, uygulama tarafında gecikmeye işaret eden olaylardır.

Uygulamada 504’e giden tipik senaryolar

• Dış API çağrısı uzun sürüyor (yetersiz timeout / retry kontrolsüz)
• Veri tabanı sorgusu uzun (tablo taraması, yanlış indeks)
• Transaction lock (kilit) nedeniyle bekleme
• Bağlantı havuzu tükenmesi
• CPU spike + garbage collection (Java/Node)

Veritabanı tarafında net kontrol

• En uzun sorgular (örn. Top N by duration)
• Lock beklemeleri
• Bağlantı sayısı limitleri

Eğer 504’ler belirli bir sayfada (ör. /siparisler, /admin) yoğunlaşıyorsa uygulama/DB ekseni daha nettir.

Hosting katmanı kaynaklı 504’ü ayırt etme

Hosting kaynaklı 504’lerde şu desenler sık görülür:

• Origin’e ulaşamama: Edge → origin requestleri loglarda az/hiç yok
• Sadece peak saatlerde ve belirli planlarda artış
• Aynı origin’e rağmen sadece CDN/WAF arkasında görünürken origin doğrudan çalışır
• DDoS koruma ve throttling dönemlerinde hata oranı yükselir

Bu durumda hosting sağlayıcısının şu kayıtları istemek gerekir:

• Edge/Proxy error detayları
• Load balancer sağlık check raporu
• WAF kural ihlali istatistikleri
• Upstream routing grafiği

Karar ağacı: Sonuç nasıl netleşir?

Aşağıdaki tablo, elde ettiğiniz kanıtlara göre pratik yönlendirme sağlar.

İyileştirme planı: 30-60 dakikada aksiyon

504’ü kalıcı çözmek için “doğru yerde doğru değişiklik” gerekir. Aşağıdaki plan, hızlı ilerler.

0-10 dakika: Teşhis verisi topla

• 504’ün başladığı dakikayı kaydet.
• Aynı URL’i 2 farklı ağdan dene (mobil + Wi-Fi).
• 504 sayfasının imzasını not et (CDN mi Nginx mi?).

10-30 dakika: Log korelasyonu yap

• Reverse proxy access/error loglarında 504 üreten requestleri filtrele.
• Uygulama loglarında aynı zaman aralığında benzer endpointleri ara.
• DB’de en uzun sorgu/lock beklemelerini kontrol et.

30-60 dakika: Düzeltmeyi hedefle

• Eğer proxy timeout hatası belirginse: timeout ile upstream süre uyumunu düzelt.
• Eğer DB gecikmesi belirginse: index/query optimizasyonu ve gerekiyorsa caching.
• Eğer hosting edge kaynaklı şüpheliyse: hosting destek ekibinden edge error ve routing raporu iste.

Sonuç: “Sunucu mu hosting mi?” cevabını kanıtla verin

504 Gateway Timeout, tek başına “hosting kötü” ya da “sunucu arızalı” demek değildir; zincirde geciken upstream’e bağlıdır. En hızlı netleşme yöntemi: aynı URL’i origin’e bypass ile denemek, ardından 504 zaman aralığını reverse proxy + uygulama + DB loglarıyla korele etmektir. Eğer origin loglarında request yoksa hosting/gateway tarafını, varsa uygulama/DB tarafını öne alın.

Bir sonraki adım olarak, etkilenen URL(ler)i seçip 2 senaryoyu test edin: CDN/WAF arkasından ve origin’e doğrudan. Çıktıya göre; sunucu katmanında (timeout/pool/query) mı yoksa hosting katmanında (edge routing/health check/WAF throttling) mı aksiyon alacağınızı netleştirin.