504 Gateway Timeout Hatası Nedir? Nasıl Çözülür?

504 Gateway Timeout hatası, bir sunucunun (genellikle bir ağ geçidi, ters proxy ya da yük dengeleyici) arka uçtaki başka bir sunucudan yanıt beklerken zaman aşımına uğradığını gösteren bir HTTP durum kodudur. Kısaca: isteğiniz iletildi, ön taraftaki sunucu görevini yaptı, ancak asıl işi yapması gereken arka uç (PHP işlemcisi, uygulama sunucusu, veritabanı) belirlenen süre içinde cevap dönmedi. Ziyaretçi de boş bir sayfa yerine “504 Gateway Timeout” uyarısıyla karşılaşır.

Bu noktada altını çizmek gerekir: 504, ziyaretçinin internetiyle ya da tarayıcısıyla ilgili bir sorun değildir. Sorun neredeyse her zaman sunucu tarafındadır. Hata bazen birkaç dakikada kendiliğinden kaybolan geçici bir yoğunluktan kaynaklanır; ama düzenli olarak tekrar ediyorsa, altyapınızın mevcut trafiğe ya da iş yüküne yetişemediğinin somut bir işaretidir.

504 Hatası Tam Olarak Nerede Oluşur?

Modern bir web sunucusu tek bir program değildir; üst üste binmiş katmanlardan oluşur. Tipik bir kurulumda istek şu zinciri izler:

Ziyaretçi → Edge/Güvenlik katmanı → Web sunucusu (Nginx/Apache/LiteSpeed) → PHP işlemcisi (PHP-FPM/LSPHP) → Veritabanı (MySQL/MariaDB)

Bu zincirde her katmanın kendi “ne kadar bekleyeceğine” dair bir süre limiti vardır. Bir katman, bir alttaki katmandan beklediği süreyi aştığında bağlantıyı keser ve geriye 504 döner. Yani 504 gördüğünüzde asıl soru şudur: hangi katman, hangi alt katmanı beklerken pes etti? Bu soruyu cevaplamak, hatayı kalıcı olarak çözmenin anahtarıdır. Çoğu zaman suçlu, çok uzun süren bir PHP işlemi ya da yavaş bir veritabanı sorgusudur.

504 Hatasının Yaygın Nedenleri

En sık karşılaşılan neden, sunucunun aşırı yüklenmesi ya da yetersiz CPU/RAM kaynağıdır. Bunun dışında pratikte en çok şu nedenlerle karşılaşılır:

• Yavaş veritabanı sorguları: İndekslenmemiş tablolar, büyük WooCommerce mağazalarında ağır ürün sorguları, kötü yazılmış arama filtreleri. Sorgu 30 saniyede bitmiyorsa PHP işlemi de bitmez.
• Ağır veya çakışan eklentiler: Yedekleme, içe aktarma, sayfa oluşturucu (page builder) ya da dış servise (ödeme, sosyal medya, hava durumu) bağlanan eklentiler işlem süresini uzatır.
• Düşük PHP zaman aşımı limitleri: max_execution_time değeri varsayılan olarak çoğu sunucuda 30 saniyedir. Meşru bir işlem bu süreyi aşıyorsa kesilir.
• Yanlış yapılandırılmış proxy veya güvenlik duvarı: Öndeki katmanın zaman aşımı, arka ucun işini bitirmesi için gereken süreden kısaysa 504 üretir.
• wp-cron ve arka plan görevleri: WordPress’in zamanlanmış görevleri (wp-cron.php) takılıp kalan uzun işlemler yaratabilir.
• Ani trafik artışı: Paylaşımlı bir pakette aynı anda gelen yoğun istek, işlemci kuyruğunu doldurur ve yanıt süreleri uzar.
• Bot ve DDoS baskısı: Otomatik trafik, sunucu kaynaklarını gerçek ziyaretçilerden çalar.

Zaman Aşımı Limitleri ve Tipik Varsayılan Değerler

504’ü doğru çözebilmek için hangi ayarın hangi katmana ait olduğunu bilmek gerekir. Aşağıdaki tablo, en sık devreye giren zaman aşımı ayarlarını ve tipik varsayılanlarını özetler. Burada en kritik kural şudur: her dış katmanın süresi, içteki katmanınkine eşit veya ondan büyük olmalıdır. Aksi halde önde bekleyen katman, arka uç işini bitirmeden bağlantıyı keser.

Katman / Ayar	Görevi	Tipik Varsayılan
php max_execution_time	PHP betiğinin çalışabileceği en uzun süre	30 saniye
PHP-FPM request_terminate_timeout	FPM’in takılan PHP işlemini sonlandırması	Kapalı / 0
Nginx fastcgi_read_timeout	Nginx’in PHP-FPM’den yanıt bekleme süresi	60 saniye
Nginx proxy_read_timeout	Ters proxy’nin arka uçtan yanıt bekleme süresi	60 saniye
Apache ProxyTimeout	mod_proxy’nin arka uçtan bekleme süresi	60 saniye
Edge/proxy zaman aşımı	Öndeki edge sunucunun orijinden bekleme süresi	~100 saniye

Pratikte 504 hatalarının büyük çoğunluğu, PHP uygulamaları için fastcgi_read_timeout (veya Apache’de ProxyTimeout) değerinin, betiğin gerçekte ihtiyaç duyduğu süreden kısa kalmasıyla ilgilidir. Ancak burada bir incelik vardır: süreyi körü körüne yükseltmek doğru çözüm değildir. Eğer PHP betiğiniz 30 saniyede sonlandırılırken Nginx 120 saniye bekliyorsa, çoğu zaman 504 yerine 502 Bad Gateway ya da boş bir yanıt alırsınız. Bu yüzden değerleri katmanlar arasında uyumlu ayarlamak, tek bir değeri abartmaktan çok daha önemlidir.

504 Hatası Nasıl Çözülür? (Adım Adım)

1. Önce yeniden deneyin. Sayfayı birkaç dakika sonra yeniden yükleyin. Sorun anlık bir yoğunluksa kendiliğinden geçer. Geçmiyorsa kalıcı bir neden var demektir.
2. Hatanın katmanını belirleyin. Sade, markasız bir “504 Gateway Timeout” sayfası kendi sunucu yığınınızdan; turuncu “A timeout occurred” şeklindeki sayfa ise öndeki bir edge katmanından gelir. Bu tek gözlem, nereye bakacağınızı söyler.
3. Sunucu kayıtlarını okuyun. Asıl ipucu loglardadır. Web sunucusu hata kayıtlarında (örneğin Apache için error_log, Nginx için error.log) “upstream timed out” benzeri satırları arayın; WordPress’te WP_DEBUG ile debug.log‘u açın. Hatanın zamanını bir kullanıcı işlemi ya da zamanlanmış görevle eşleştirin.
4. Yavaş sorguları ve ağır eklentileri bulun. MySQL slow query log’unu inceleyin, gereken indeksleri ekleyin. Eklentileri tek tek devre dışı bırakarak suçluyu tespit edin. Kalıcı çözüm, süreyi uzatmak değil işlemi hızlandırmaktır.
5. Önbelleklemeyi devreye alın. Sayfa ve nesne önbelleği, isteklerin önemli kısmını PHP’ye ve veritabanına hiç dokunmadan karşılar. LiteSpeed + LSCache gibi sunucu seviyesinde çalışan bir önbellek, işlemci yükünü dramatik biçimde düşürür.
6. Limitleri uyumlu şekilde yükseltin. Yalnızca gerçekten uzun süren meşru işlemler (büyük içe aktarma, rapor üretimi) varsa max_execution_time, memory_limit ve ilgili zaman aşımı değerlerini katmanlar arasında uyumlu artırın.
7. Trafik kaynaklıysa kaynağı büyütün. Sorun düzenli olarak yoğun saatlerde geliyorsa neden çözümsüzlük değil, kaynak yetersizliğidir. Daha güçlü bir hosting paketine ya da ölçeklenebilir bir bulut sunucuya geçmek doğrudan çözümdür.

502 ile 504 Arasındaki Fark

İki hata da ağ geçidi/arka uç kaynaklıdır ama farklı durumları anlatır. 502 Bad Gateway, ağ geçidinin arka uçtan geçersiz ya da bozuk bir yanıt aldığını gösterir; arka uçtaki servis çökmüş, beklenmedik biçimde kapanmış olabilir. 504 Gateway Timeout ise arka uçtan hiç yanıt alamadığını, yani süre dolduğunu gösterir. Kabaca: 502 “yanlış bir cevap geldi”, 504 “hiç cevap gelmedi” demektir. 502 çoğunlukla çökmüş bir servisle, 504 ise yavaşlık ve aşırı yükle ilişkilidir.

504 ve 524 Aynı Şey mi?

Tam olarak değil. 504 standart bir HTTP durum kodudur ve yığınınızdaki herhangi bir proxy katmanından (Nginx, Apache, yük dengeleyici) gelebilir. Cloudflare gibi bir edge servisi kullanan sitelerde sıkça karşılaşılan 524 “A Timeout Occurred” ise standart değil, edge sağlayıcısına özgü bir koddur: TCP bağlantısı orijin sunucuya kurulmuş ama orijin, edge’in beklediği süre (genelde 100 saniye) içinde HTTP yanıtı dönmemiştir. Pratik fark şudur: 524 genellikle orijindeki bir işlemin tamamen takılı kaldığı anlamına gelirken, 504 araya giren bir proxy katmanının erken pes ettiğini işaret eder. Gördüğünüz hata sayfasının markasız mı yoksa turuncu edge şablonu mu olduğu, sorunu hangi tarafta arayacağınızı söyler.

504 Hatasını Önlemenin Yolu: Yeterli Kaynak ve Önbellek

504 hataları çoğunlukla kaynak yetersizliğinin habercisidir. Yüksek trafikli projelerde LiteSpeed + LSCache gibi güçlü bir önbellekleme katmanı, isteklerin büyük bölümünü PHP’ye hiç uğramadan karşılayarak sunucu üzerindeki yükü ciddi biçimde azaltır. Buna yeterli CPU/RAM sunan bir hosting paketi eklendiğinde, hem ortalama yanıt süresi düşer hem de yoğun saatlerde zaman aşımı riski neredeyse ortadan kalkar.

WordPress kullanıyorsanız WordPress hosting tarafında LSCache’in tam entegre çalışması ek bir avantajdır; eklenti çoğu kez sıfır yapılandırmayla devreye girer. İhtiyaç büyüdüğünde ise kaynakları bağımsız ölçeklenebilen bir bulut sunucu, ani trafik dalgalanmalarında bile 504’leri pratikte önler. Türkiye’de barındırılan, ziyaretçilere düşük gecikmeyle hizmet veren bir altyapı seçmek de hem yanıt sürelerini hem de zaman aşımı marjını lehinize çevirir.

Alastyr Altyapısı Bu Noktada Ne Sunar?

Alastyr, web sitelerini İzmir’deki kendine ait veri merkezinde barındırır; bu merkez N+1 yedekli klima, jeneratör ve UPS sistemleriyle Tier III standartlarında tasarlanmıştır. Sunucu tarafında LiteSpeed + LSCache önbelleği, CloudLinux + CageFS izolasyonu ve PHP sürüm seçici varsayılan olarak gelir. CloudLinux her hesaba ayrılmış CPU/RAM sınırları tanımladığı için, komşu bir sitenin ani yükü sizin sitenizi yavaşlatıp 504’e sürükleyemez. Yüksek trafikli projeler içinse, 10’lu HA cluster mimarisi ve all-flash depolama üzerinde çalışan bulut sunucular bağımsız ölçeklenebilir kaynak sağlar. Tüm bunlar %99.9 uptime, günlük yedekleme ve 7/24 destekle birlikte gelir; bir aksaklıkta sadece dokümana değil, aynı zamanda bir uzmana da ulaşabilirsiniz.

504 Hatasının SEO’ya Etkisi

Sık ve uzun süreli 504 hataları, arama motoru botlarının sitenizi tarayamamasına ve kullanıcıların siteyi terk etmesine yol açar. Googlebot bir sayfayı tekrar tekrar zaman aşımıyla karşılarsa, tarama bütçesini kısar ve içerikleriniz daha seyrek güncellenir. Aynı anda artan terk oranı (bounce) ve düşen sayfa hızı, kullanıcı sinyalleri üzerinden sıralamanızı da olumsuz etkiler. Bu nedenle 504 kalıcı hale geldiyse, kaynak artırımı ve önbellekleme yalnızca kullanıcı deneyimi için değil, doğrudan SEO için de kritik bir yatırımdır.

Sıkça Sorulan Sorular

504 hatası benim sitemden mi yoksa ziyaretçiden mi kaynaklanıyor?

Neredeyse her zaman sunucu tarafındandır. 504, bir ağ geçidinin arka uçtan zamanında yanıt alamadığını gösterir; ziyaretçinin internet bağlantısıyla ya da tarayıcısıyla ilgisi yoktur. En sık nedenler yavaş sorgular, ağır işlemler ve yetersiz kaynaktır.

502 ve 504 arasındaki fark nedir?

502 Bad Gateway arka uçtan geçersiz ya da bozuk bir yanıt alındığını, 504 Gateway Timeout ise hiç yanıt alınamadığını yani sürenin dolduğunu gösterir. Kısaca 502 yanlış cevap, 504 ise hiç cevap gelmemesi durumudur. İkisi de ağ geçidi veya arka uç kaynaklıdır.

504 ile 524 hatası aynı şey mi?

Aynı değildir. 504 standart bir HTTP kodudur ve herhangi bir proxy katmanından gelebilir. 524 ise Cloudflare gibi edge sağlayıcılarına özgüdür ve orijin sunucunun, edge’in beklediği süre içinde yanıt vermediğini gösterir. Markasız sayfa kendi sunucunuzdan, turuncu A timeout occurred sayfası ise edge katmanından gelir.

504 hatasının kaynağını nasıl bulurum?

İpucu sunucu loglarındadır. Web sunucusu hata kayıtlarında upstream timed out benzeri satırları arayın, WordPress’te WP_DEBUG ile debug.log’u açın ve MySQL slow query log’unu inceleyin. Hatanın zamanını bir kullanıcı işlemi ya da zamanlanmış görevle eşleştirmek çoğu zaman doğrudan suçluyu gösterir.

Sadece zaman aşımı süresini artırmak 504’ü çözer mi?

Çoğu zaman kalıcı çözüm olmaz. Süreyi uzatmak, asıl problem olan yavaş sorgu ya da ağır işlemi gizler ve sayfaları daha da yavaşlatabilir. Üstelik katmanlar arasındaki değerler uyumsuzsa 504 yerine 502 alabilirsiniz. Doğru yaklaşım önce işlemi hızlandırmak, gerekirse limitleri uyumlu biçimde artırmaktır.

Paylaşımlı hostingde 504 alıyorum, ne yapmalıyım?

Önce sunucu seviyesinde önbellekleme (örneğin LiteSpeed + LSCache) kullanın ve ağır eklentileri azaltın. Hata yoğun saatlerde tekrar ediyorsa neden büyük olasılıkla kaynak yetersizliğidir; kalıcı çözüm için daha yüksek kaynaklı bir pakete ya da ölçeklenebilir bir bulut sunucuya geçmek gerekir.

WordPress’te 504 hatasının en yaygın nedeni nedir?

Genellikle uzun süren bir veritabanı sorgusu ya da dış servise bağlanıp takılan bir eklentidir. Büyük WooCommerce mağazaları, ağır page builder eklentileri ve takılan wp-cron görevleri en sık karşılaşılan sebeplerdir. Eklentileri tek tek devre dışı bırakmak suçluyu hızlıca ortaya çıkarır.

504 hatası SEO’ya zarar verir mi?

Evet. Sık ve uzun süreli 504 hataları Googlebot’un sayfaları taramasını engeller, tarama bütçesini düşürür ve kullanıcıların siteyi terk etmesine yol açar. Hem indekslenme hem de sıralama olumsuz etkilenir, bu yüzden kalıcı 504’leri ihmal etmemek gerekir.

504 hatası kendiliğinden geçer mi?

Geçici bir yoğunluk kaynaklıysa birkaç dakika içinde kendiliğinden geçebilir. Ancak düzenli olarak tekrar ediyorsa altyapısal bir sorun vardır ve önbellekleme, sorgu optimizasyonu veya kaynak artırımı gibi kalıcı bir önlem alınması gerekir.