504 Gateway Timeout: Sunucu mu hosting mi? Net teşhis rehberi

504 Gateway Timeout, ziyaretçinin tarayıcısına "sunucu zamanında yanıt veremedi" sinyali geçildiğini gösteren bir HTTP hatasıdır. Bu hata; uygulama (backend), web sunucusu (Nginx/Apache), ters proxy (reverse proxy), CDN (Cloudflare benzeri) veya hosting altyapısı arasındaki bir darboğazdan kaynaklanabilir. Buradaki zorluk, ekranda yazan kodun (504) tek başına kök nedeni söylememesidir. Bu rehberde, 504’ün sunucu mu hosting mi sorusuna teknik olarak nasıl yanıt verileceğini; test, log ve yapılandırma adımlarıyla netleştireceksiniz.

Önce tek bir hedef koyalım: 504’ü üreten katmanı sınırlamak (L7: uygulama/HTTP akışı). Bunu yaparken “hemen sağlayıcıyla konuşun” demek yerine, önce sizin doğrulayabileceğiniz kanıtları toplayacağız.

1) 504’ün anlamı: Hangi “kapıdan” geçerken timeout oluyor?

504 Gateway Timeout, genellikle bir bileşenin (gateway) upstream’e (asıl hedefe) zamanında bağlanamaması veya upstream’in yanıt süresinde gecikmesidir. Akış şu şekilde olur:

• Kullanıcı → (CDN / Load balancer / Reverse proxy) → (Web sunucusu) → (Uygulama / uygulama sunucusu)

Gateway katmanı, bir üst katmandan yanıt bekler ve süre dolunca 504 döndürür.

Bu yüzden aynı anda şu olasılıklar vardır: - Uygulama tarafında (PHP-FPM, Node, Java) uzun çalışan işlem veya deadlock - Web sunucusu tarafında (Nginx/Apache) upstream timeout ayarları - Reverse proxy/CDN tarafında zaman aşımı veya origin kaynaklı sorun - Hosting altyapısında kapasite, ağ dalgalanması, WAF/anti-DDoS gecikmesi

Net teşhis için, 504’ün zamanlamasını ve hangi isteklere geldiğini sınırlamak gerekir.

Hızlı ayrım: Statik mi dinamik mi etkileniyor?

Aynı domain üzerinde: - CSS/JS görseller sorunsuz yükleniyor, fakat sayfa tamamı 504 veriyorsa: büyük olasılıkla dinamik (PHP/uygulama) tarafında gecikme. - Her şey 504 ise: daha geniş bir upstream problemi veya gateway katmanının tamamı etkileniyor. - Sadece belirli sayfalar/endpoint’ler 504 ise: uygulama sorguları (DB, dış API) veya cache katmanı kilitleniyor olabilir.

2) İlk kanıt: 504 hangi dağıtımda oluşuyor? (gerçek kullanıcı örnekleriyle)

Teşhisin yüzde 60’ı, olayın kapsamını bulmaktır. Aşağıdaki testler için ekran görüntüsü değil, sonuçları not alın.

A) Aynı URL’yi 3 farklı ağdan deneyin

• Ev interneti
• Mobil veri (4G/5G)
• Mümkünse farklı bir Wi-Fi

Sonuç yorumu: - Her ağdan aynı şekilde 504: sistematik bir sunucu/uplink problemi. - Sadece belirli ağdan 504: çoğunlukla routing, DNS/CDN POP farkı veya yerel ağ kaynaklı.

B) Aynı anda farklı tarayıcılarda ve farklı protokollerle kontrol

• HTTP/1.1 mi HTTP/2 mi fark ediyor?
• Tarayıcı eklentileri (proxy/VPN) kapatılınca düzeliyor mu?

C) 504 her zaman mı, yoksa dalgalı mı?

• Sürekli: kalıcı bir yapılandırma/kapasite sorunu
• Dalgalı: yük zirvesi, kaynak tüketimi (CPU/RAM), DB kilitlenmesi veya GC (garbage collection) gibi zamanlamalı problem

3) Loglar: 504’ün zincirdeki düğümünü bulma

Burada hedef, “hosting mi” “sunucu mu” sorusuna somut cevap üreten log satırlarını yakalamak.

H3) Web sunucusu (Nginx/Apache) erişim ve hata logları

Nginx’te tipik alanlar: - access.log - error.log - Upstream timeout sinyalleri (ör. upstream timed out gibi)

Apache’de de error.log benzer şekilde timeout/proxy kaynaklı satırlar içerir.

Ne arayın? - Aynı zaman aralığında çok sayıda “timeout” satırı - Hangi upstream’e (ör. fastcgi://..., proxy_pass ...) giden isteklerde oluştuğu - 504’ün geldiği URI ile hata log satırının eşleşmesi

H3) Uygulama logları (PHP-FPM, Node, Java)

• PHP-FPM için: yavaş istekler veya worker exhaustion
• Node için: event loop tıkanması
• Java için: thread pool saturation

“504 var ama uygulama logunda normal görünüyor” ise şu ihtimalleri düşünün: - Zaman aşımı web sunucusu/gateway katmanında oluşuyor - Uygulama aslında yanıt veriyor ama gateway beklerken gecikiyor (ör. response buffering veya büyük response)

H3) Veritabanı logları (MySQL/MariaDB)

504 dinamik sayfalarda sık görülüyorsa, DB sorguları en sık suçludur. Ne arayın? - Uzayan sorgular (slow query) - Kilit (lock) beklemeleri - Bağlantı sayısı limitleri

4) Konfigürasyon tuzakları: timeout ayarları yanlışsa hosting “suçsuz” kalır

Birçok 504, “hosting kötü” değil, “timeout zinciri kısa” olduğu için çıkar.

Aşağıdaki zinciri düşünün: - CDN/reverse proxy timeout - Nginx proxy_read_timeout, fastcgi_read_timeout - PHP-FPM request_terminate_timeout veya benzeri limitler - Uygulama tarafında kendi timeout/retry mantığı

Örnek kontrol: PHP-FPM ve Nginx upstream zamanları

• Uygulama bir isteği 35 saniyede döndürüyorsa ama Nginx 30 saniyede upstream’i vazgeçiyorsa 504 döner.
• Hosting tarafında CPU/IO darboğazı varsa uygulama 35 saniyeyi 60 saniyeye çıkarır ve bu sefer timeout zinciri tetiklenir.

NetKıyas bakış açısıyla kritik soru şudur: - Sadece belirli endpoint’ler 504 alıyor mu? - Bu endpoint’ler ağır sorgu içeriyor mu? - Trafik artınca 504 sayısı artıyor mu?

Bu desen, konfigürasyonun değil uygulamanın yavaşladığını düşündürür.

5) “Sunucu mu hosting mi?” kararı için kanıt tablosu

Aşağıdaki tablo, toplanan kanıtlara göre yön gösterecektir.

H3) İpucu: “Upstream health” testi

Eğer reverse proxy kullanıyorsanız, upstream’in sağlık durumunu kontrol edin. - Upstream portu açılıyor mu? - TCP kuruluyor mu, yoksa handshake mı takılıyor? - İç ağdan (sunucunun kendisinden) curl ile yanıt var mı?

Bu ayrım önemlidir: - Sunucunun kendisi upstream’e ulaşabiliyor, fakat proxy’de timeout oluyorsa: proxy/timeout. - Sunucunun kendisi upstream’e de ulaşamıyorsa: servis down veya ağ/altyapı.

6) Hosting tarafını dışlamak: izole test ve basit sentetik kontroller

“Hosting mi” sorusunu kesinleştirmek için en net yöntem, aynı sunucuda veya aynı paket yapısında izole testler yapmaktır.

A) Aynı server’da statik dosya kontrolü

• /health benzeri statik endpoint veya küçük bir PHP testi ekleyin.
• 504 yalnızca ağır dinamik sayfalarda geliyorsa: sistematik hosting değil, uygulama/DB ağırlığı.
• Statik de etkileniyorsa: web sunucusu katmanı veya kaynak/IO.

B) Gerçek zamanlı kaynak izleme

504 çıktığı anda kontrol edin: - CPU kullanımının anormal yükselmesi - RAM baskısı (swap kullanımı) - Disk IO (IOwait) - Ağ gecikmesi

Eğer CPU/IOwait tavan yapıyorsa “hosting mi” kararı pratikte hosting paketinin yetersizliği veya altyapı tıkanmasıdır. Ancak bu yine de “yanlış konfigürasyon” ile birlikte olabilir.

C) Farklı kontrol paneli/uygulama katmanı karşılaştırması

Kontrol paneli (cPanel/Plesk gibi) arayüzde doğru görünür ama 504, gerçekten gateway katmanında olur. Yine de: - WAF/anti-DDoS modülü - cache (varsa) - PHP handler (PHP-FPM mi mod_php mi)

gibi katmanlar davranışı etkiler.

7) Son adım: Sağlayıcıya ticket atarken hangi verileri göndermelisiniz?

Eğer loglarınız, upstream’in timeout’a girdiğini veya altyapı dalgalanmasının varlığını gösteriyorsa sağlayıcıyı devreye almanız gerekir. Ticket’ta “504 hatası var” demek yetmez.

Şunları gönderin: - 504’ün başladığı tarih-saat aralığı (TZ ile) - Etkilenen URL listesi (en az 3 örnek) - İstek yöntemleri (GET/POST) ve yaklaşık response süresi - Web sunucusu hata logundan ilgili satırlar - (Varsa) CDN/WAF kullanımı ve sağlayıcı POP bilgisi - Kaynak izleme sonucu: CPU/RAM/IOwait trendi

Bu verilerle sağlayıcı “hata sunucu tarafında mı, network mi, reverse proxy mi” ayrımını hızla yapar.

Sonuç: 504’ü tek koddan değil, log + test zincirinden okuyun

504 Gateway Timeout; gateway beklerken timeout olduğunda ortaya çıkar ve bu, çoğu zaman uygulama/DB gecikmesi veya timeout zinciri uyumsuzluğu kaynaklıdır. Ancak dalgalı 5xx, CDN/WAF etkisi veya birden fazla hostta eşzamanlı problem gibi kanıtlar varsa hosting altyapısı devreye girer. Aksiyon olarak: Önce statik-dinamik ayrımı yapın, ardından web sunucusu + uygulama + DB loglarından timeout ile eşleşen satırları çekin. Kanıtınız hazır olduğunda ya konfigürasyonu düzeltecek ya da sağlayıcıdan net bir altyapı doğrulaması isteyeceksiniz.