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

504 Gateway Timeout hatası, tarayıcının beklediği yanıtın gateway (ters proxy) katmanında zamanında gelmediğini söyler. Bu hata tek bir sebebe indirgenmez: yanlış zaman aşımı ayarı, arka uçta (backend) uygulama yavaşlığı, CDN/Load Balancer gecikmesi, DNS/rota sorunu ya da kaynak yetersizliği gibi birden fazla kök neden olabilir. Bu yazıda; 504’ün hangi katmandan geldiğini ayırmak için katman katman test edeceksiniz. Sonunda da “sunucu mu hosting mi?” sorusuna somut kanıtlarla cevap verecek bir karar akışı elinizde olacak.

1) 504’ün “gateway” katmanında oluştuğunu netleştirin

İlk adım, 504’ün gerçek anlamını doğru okumaktır. 504, çoğu zaman şu zincirdeki gecikmeye işaret eder: - Kullanıcı → CDN / WAF (varsa) → Load Balancer / Reverse proxy → Uygulama sunucusu (web app) → Veritabanı (DB)

Sunucu (application server) çöktüyse veya uygulama uzun sürüyorsa backend yanıtı zamanında gelmez; gateway 504 döndürür. Hosting kaynaklı sorunlarda (ör. oversell, ağ tıkanması, hatalı reverse proxy ayarı, rate-limit etkisi) benzer şekilde backend gecikebilir.

Semptom üzerinden ilk ayrım

Aşağıdaki gözlemler, “hangi taraf daha olası” tahminini güçlendirir: - Sadece belirli sayfalar (ör. arama, checkout, yoğun sorgular) 504 veriyorsa: çoğunlukla uygulama/DB tarafı. - Tüm site veya büyük bölümü 504 veriyorsa: ters proxy/gateway, CDN, load balancer veya genel kaynak/ağ problemi. - Belirli saat diliminde ve yük artınca oluyorsa: CPU/RAM/IOPS/DB kilidi, yetersiz ölçek. - Sadece belirli IP aralıklarında oluyorsa: WAF/geo/rate-limit veya rota/blackhole.

2) Log olmadan teşhis yapmayın: gerekli verileri toplayın

504’ün hangi katmanda geciktiğini anlamak için tek bir ekrana bakmak yetmez. Aşağıdaki veriler net bir tablo kurdurur:

Hemen toplayacağınız kanıt listesi

• Tarayıcıdan aldığınız URL + saat (dakika hassasiyetinde)
• 504’ün sayfa içeriği (site kendi 504 sayfasını mı basıyor, CDN/proxy kendi hatasını mı veriyor?)
• Response header’lar: Server, Via, X-Cache, CF-Ray (Cloudflare varsa), X-Request-Id gibi izler
• Gateway/Reverse proxy logları (Nginx/Apache/HAProxy/Traefik): upstream timed out, 504, request_id
• Uygulama logları: “request başlatıldı” ile “response üretildi” arası süre
• Veritabanı logları: yavaş query, lock wait, timeout
• Sunucu kaynak metrikleri: CPU %100, RAM swap, disk I/O wait, ağ retransmit

Loglar olmadan “hosting mi sunucu mu?” demek tahmini artırır; doğru karar oranı düşer. Bu yüzden testleri kanıt üreten şekilde yürütün.

3) Hız testi değil: katman testi yapın (CDN / proxy / backend ayrımı)

Bu bölümde hedef, “gateway neden 504 döndürdü?” sorusuna yaklaşmaktır.

3.1 CDN/WAF varsa ilk kontrol

CDN kullanıyorsanız (ör. Cloudflare, benzeri servisler): - Aynı URL’i farklı ağlardan deneyin (mobil + ofis ağı) - CDN devredeyken 504 var mı, CDN bypass (gerekirse curl ile) denemesi var mı bakın - CDN’de “origin timeout” veya “5xx” istatistiklerini inceleyin

CDN tarafında 504 artıyorsa iki tip senaryo görülür: - CDN origin’e bağlanırken gecikme (routing/ağ) - Origin/arka uç yanıtı gecikiyor (app/DB yavaş)

3.2 Ters proxy’den backend’e giden bağlantıyı test edin

Nginx reverse proxy kullanılıyorsa tipik hata metinleri şunlardır: - upstream timed out (110: Connection timed out) - proxy_read_timeout aşımı

Burada kritik olan: Nginx timeout değerini yükseltmek anlık rahatlatır ama kök nedeni çözmeyebilir. Önce altta yatan gecikmeyi ölçmelisiniz.

4) En yaygın kök nedenler ve nasıl ayırt edileceği

Aşağıdaki kök nedenler 504’te en sık görülür. “Sunucu mu hosting mi?” ayrımını kolaylaştıran ayırt edici belirtileri ekledim.

4.1 Uygulama request’i uzun sürüyor (backend yavaş)

Belirtiler - Sadece belirli endpointlerde 504 (ör. /checkout, /search?q=...) - Uygulama loglarında aynı request için uzun süre “processing” görünüyor - DB tarafında yavaş sorgu/lock wait var

Teşhis - Uygulama loglarında request başlangıç-bitiş süresini ölçün - DB’de slow query log açın, lock istatistiklerini kontrol edin

Örnek karar - Backend tarafında 10-20 saniye süren işlem varsa gateway timeout daha kısa olacağı için 504 görülür. - Sorun uygulama/DB kaynaklıysa hosting tarafı sadece “ölçek yetersizliği” nedeniyle tetikleniyor olabilir. Kanıt uygulama/DB logudur.

4.2 Veritabanı darboğazı (IOPS/lock/CPU)

Belirtiler - CPU normalken dahi gecikme var (özellikle DB) - Aynı anda çok fazla bağlantı (connection count) artıyor - DB query’leri sıraya giriyor (lock wait)

Teşhis - DB’de sorgu planı (execution plan) inceleyin - Bağlantı havuzu (connection pool) limitlerini kontrol edin - Index eksikliği, yanlış join, N+1 sorgu gibi yapısal sorunları tespit edin

4.3 Sunucu kaynakları tükeniyor (CPU/RAM/swap)

Belirtiler - Uygulama sunucusu CPU %100’e yakın seyreder - RAM bitip swap’a düşme başlar (performans çöküşü) - Disk I/O wait yükselir

Teşhis - top/htop ile anlık CPU/RAM durumunu görün - vmstat, iostat, sar (varsa) ile IO wait ve swap kullanımını izleyin

Önemli ayrım - Bu durum “aynı pakette herkesin yaşadığı” genel bir problem değilse çoğu kez sunucu/konfigürasyon kaynaklıdır. - Paket aşırı oversell veya I/O performansı kalitesizse bu, “hosting tarafı” olarak değerlendirilir. Kanıt yine metrikler + tekrar eden patern.

4.4 Ağ/rota/tünel problemleri (SYN retransmit, MTU, blackhole)

Belirtiler - Tüm istekler yavaşlıyor, hatta sadece belirli bölgelerden erişim etkileniyor - Reverse proxy loglarında upstream timed out var ama uygulama içinde request hiç başlamıyor

Teşhis - Aynı sunucudan backend portuna curl -v veya telnet/nc ile erişim deneyin - Gateway loglarında request backend’e hiç düşmüyor mu bakın

Bu tip sorunlarda hosting sağlayıcısının ağ katmanı (route, firewall, upstream kapasite) daha olasıdır.

4.5 Timeout değerleri yetersiz (proxy/app/gateway ayarları)

Belirtiler - Yük anında 504 artar, fakat loglarda işlem başlıyor ve uzun sürüyor - Gateway “read timeout” yüzünden sonlandırıyor

Net yaklaşım - Timeout artırmak geçici çözümdür; kök neden hâlâ varsa tekrar eder. - Timeout’un hangi katmanda olduğunu bulmadan değiştirme yapmayın: - CDN timeout - Reverse proxy proxy_read_timeout / proxy_connect_timeout - Uygulama request timeout - Load balancer idle timeout

5) “Sunucu mu hosting mi?” için 6 adımlık karar akışı

Aşağıdaki akış, konuyu tahminden çıkarır ve kanıt toplar.

Adım 1: 504 hangi URL’lerde?

• Tek endpoint → Uygulama/DB daha olası
• Tüm site → CDN/proxy/load balancer veya genel kaynak/ağ

Adım 2: 504’ten önce request uygulamaya ulaşıyor mu?

• Reverse proxy logunda request backend’e düşüyor ama uygulama logu yok → ağ/route/servis seviyesinde problem
• Uygulama logu var ve gecikme orada → uygulama veya DB

Adım 3: Timeout türünü yakalayın

• connect timeout → backend’e bağlantı kurulamadı (ağ/firewall/capacity)
• read timeout → bağlantı kuruldu ama yanıt gelmedi (app/DB yavaş)

Adım 4: Kaynak metrikleri ile zaman eşleştirin

• 504 anında CPU/RAM/IO wait artıyor → kaynak yetersizliği (sunucu tarafı)
• Kaynaklar normal kalıyor ama yine de gecikme var → ağ veya harici servis bağımlılığı

Adım 5: Aynı sağlayıcıda diğer kullanıcılar etkileniyor mu?

• Paylaşımlı (shared) ortamda birden fazla kullanıcı aynı anda etkileniyorsa hosting tarafı daha güçlü aday
• Sadece sizin trafiğinizde ve sizin endpointlerinizdeyse sunucu/uygulama tarafı daha güçlü aday

Adım 6: Ölçekleme gereksinimi netleşiyor mu?

• Backend gecikmesi sürekli 5-10 saniyeyi aşıyorsa, mevcut paket/konfigürasyon yetersizdir.
• Örn. VDS/VPS’te CPU limitleri, storage IOPS kalitesi veya DB planı performansı belirler.

6) Paylaşımlı hosting / VDS / VPS farkı: 504’ün sorumluluğu nasıl değişir?

504’ün “kimin problemi olduğu” ortam tipine göre değişir. Bu bölüm, doğru çerçeveyi kurar.

Ortam tipine göre olasılık tablosu

7) Hata giderme: “timeout artırma” yerine önce ölçün

504 devam ederken yapılan en yaygın hata, sadece gateway timeout’unu yükseltmektir. Bu; sorunu saklar ama maliyeti artırır (daha uzun request’ler, daha çok eşzamanlı iş parçacığı, DB daha çok yüklenir).

Doğru sıra

1. Hangi endpoint gecikiyor?
2. Gecikme backend’de mi yoksa backend’e bağlantı mı kuruluyor?
3. Backend gecikiyorsa neden uzun sürüyor: DB sorgusu mu, harici servis çağrısı mı, dosya I/O mu?
4. Kaynak yetersizse ölçek veya optimizasyon: - Uygulama tarafı: query optimizasyonu, caching, background job - Sunucu tarafı: daha iyi IOPS, RAM/CPU artırımı - Mimari taraf: CDN cache TTL ayarı, sayfa optimizasyonu

Hızlı aksiyon örnekleri (hepsi ölçümle birlikte)

• En yavaş 10 DB sorgusunu bulup index/plan düzeltmesi yapmak
• Backend request’lerini queue/async hale getirmek (ör. ödeme sonrası işlemleri background job)
• CDN cache’i olmayan sayfalarda gereksiz dinamik yükü azaltmak
• Reverse proxy timeout’u artırmadan önce uygulama timeout’u ile eşleştirmek

8) Sağlayıcıya destek talebi nasıl yazılmalı? (kanıt odaklı)

“Hosting mi sunucu mu?” tartışmasını teknik kanıta bağlamak gerekir. Sağlayıcıya şu formatta veri gönderin: - Tarih/saat aralığı (ör. 12.06.2026 14:20-14:35) - Etkilenen URL’ler - Response header örnekleri (varsa X-Request-Id, Via) - Reverse proxy logundan örnek satırlar (connect/read timeout) - Sunucu metrikleri (CPU/RAM/IO wait) - Uygulama/DB loglarında ilgili request ID

Bu şekilde destek ekibi “sorun sizde mi”yi varsaymadan, upstream logları ve ağ metrikleriyle karşılaştırma yapabilir.

Sonuç: 504’ü tek cümleyle suçlamayın, katman katman kanıtlayın

504 Gateway Timeout hatasında sorumluluk çoğu zaman “ya hosting ya sunucu” değil; gateway zincirinin hangi halkasında gecikme olduğu belirler. Uygulama loglarında request başlıyor mu, reverse proxy upstream’e bağlanabiliyor mu, DB sorguları yavaş mı, sunucu metrikleri 504 anında boğuluyor mu gibi sorulara net yanıt verin. Eğer gecikme backend’de ise çözüm uygulama/DB ve ölçek tarafında; gecikme backend’e hiç düşmüyorsa ağ/gateway tarafı daha güçlü aday olur. Bu akışı uygulayın; ilk destek talebinizi de kanıtla besleyin.

Aksiyon önerisi: 504 yaşadığınız her olayda URL + saat + proxy log örneği + sunucu metriklerini tek dosyada toplayın. Sonraki adımda ya timeout/konfigürasyonu değil kök nedeni hedefleyen bir optimizasyon yapın ya da mevcut kaynak planını (VDS/VPS) ölçüm sonuçlarınıza göre büyütün.