504 Gateway Timeout: Ne Anlama Gelir ve Nasıl Düzeltilir

504 Gateway Timeout Nedir?

504 Gateway Timeout, gateway veya proxy olarak çalışan bir sunucunun, upstream sunucudan zamanında yanıt alamadığını gösteren bir HTTP durum kodudur. Proxy, upstream sunucunun yanıtını bekledi ama bu çok uzun sürdü; proxy da vazgeçip tarayıcınıza 504 döndürdü.

RFC 9110 bunu şöyle tanımlar: «504 (Gateway Timeout) durum kodu, sunucunun gateway veya proxy olarak çalışırken isteği tamamlamak için erişmesi gereken bir upstream sunucudan zamanında yanıt almadığını gösterir» (RFC 9110 §15.6.5).

Anahtar sözcük gateway'dir. 504 her zaman en az iki sunucu içerir: bağlandığınız sunucu (proxy/gateway) ve arkasındaki, yanıt veremeyen sunucu (upstream/origin). Yaygın proxy'ler arasında Nginx reverse proxy, Cloudflare, AWS Application Load Balancer (ALB) ve CloudFront bulunur.

504 Hatası Nasıl Görünür

Metin, hangi katmanın vazgeçtiğine göre değişir:

• Altında «nginx» yazan 504 Gateway Time-out: nginx (tireli yazar)
• 504 Gateway Time-out · The server didn't respond in time.: HAProxy'nin varsayılan sayfası
• Gateway Timeout · The gateway did not receive a timely response from the upstream server or application.: PHP-FPM'in önündeki Apache (mod_proxy_fcgi). Bir HTTP backend'e proxy yapan Apache ise bunun yerine Proxy Error · Error reading from remote server gösterir (bu bir 502'dir).
• ERROR · The request could not be satisfied · 504 ERROR: Amazon CloudFront
• Error 524: A timeout occurred: Cloudflare'in sürümü; sunucunuza ulaştı ama yanıt zamanında gelmedi
• Bu sayfa çalışmıyor · example.com ana makinesinin yanıt vermesi çok uzun sürdü. · HTTP hatası 504: Chrome, 504'ün kendi sayfası yoksa

İfade ne olursa olsun neden aynıdır: bir proxy arkasındaki sunucuyu bekledi ve yanıt zamanında gelmedi. (Chrome, tarayıcınız hiç bağlanamadığında da aynı «yanıt vermesi çok uzun sürdü» cümlesini kullanır; ancak o zaman başlık «Bu siteye ulaşılamıyor», kod da HTTP hatası 504 değil ERR_CONNECTION_TIMED_OUT olur: bkz. ERR_CONNECTION_TIMED_OUT.)

504 Gateway Timeout Nasıl Oluşur

504 hatasını anlamak için tarayıcınızla origin sunucu arasındaki timeout zincirini anlamanız gerekir. Tipik bir web isteği birden çok katmandan geçer ve her katmanın kendi timeout ayarı vardır.

Tipik bir istek akışı şöyledir: Tarayıcı → CDN (Cloudflare) → Yük dengeleyici → Nginx → PHP-FPM → Veritabanı. Veritabanı sorgusu 90 saniye sürerse ve nginx'in fastcgi_read_timeout değeri 60 saniyeyse, nginx beklemeyi bırakır ve yük dengeleyiciye 504 döndürür; o da bunu CDN üzerinden tarayıcınıza iletir.

504'ü döndüren sunucu genellikle aradaki bir proxy'dir, uygulamanın kendisi değil. Uygulama isteği hâlâ işliyor olabilir ya da takılmış olabilir.

Kaynaklar: Cloudflare 524, CloudFront origin ayarları, Google Cloud ve her sunucunun kendi belgeleri. PHP'nin kendi max_execution_time değeri (30 saniye) 504 üretmez: bu sınıra ulaşan betik ölümcül bir hatayla durur ve bu bir 500 olarak görünür. Linux'ta ayrıca veritabanı ya da diğer G/Ç beklemelerini saymaz; yani yavaş bir sorguya takılan betik bundan çok daha uzun çalışabilir.

504 Gateway Timeout'un Yaygın Nedenleri

Bir proxy'nin beklemekten vazgeçmesinin olağan nedenleri:

• Yavaş bir istek — ağır bir veritabanı sorgusu, bir rapor ya da yavaş bir üçüncü taraf API çağrısı proxy'nin timeout süresinden uzun sürer.
• Aşırı yüklü sunucu — CPU %100'de, bellek baskısı var ya da tüm PHP-FPM worker'ları meşgul; yeni istekler proxy pes edene kadar kuyrukta bekler.
• Veritabanı darboğazları — yavaş sorgular, eksik indeksler, kilitli tablolar veya tükenmiş bir bağlantı havuzu.
• Fazla düşük timeout'lar — nginx'in 60 saniyesi, gerçekten daha uzun süreye ihtiyaç duyan bir backend (dışa aktarma, içe aktarma, büyük yükleme) için kısadır.
• Proxy ile origin arasındaki ağ sorunları — paket kaybı ya da proxy'nin paketlerini sessizce düşüren bir güvenlik duvarı (paketleri reddeden bir güvenlik duvarı 502 verir).
• CDN'in sabit sınırı — nginx ne izin verirse versin Cloudflare, Free, Pro ve Business'ta 125 saniye bekler, ardından Error 524 gösterir.
• Trafik seli — ani bir artış ya da saldırı worker'ları meşgul eder ve sıradan istekler zamanında yanıtlanamaz. (Aşırı yüklendiğini bilen bir sunucu bunun yerine 503 ile yanıt verebilir.)

Ziyaretçiler İçin Çözüm: Neler Yapabilirsiniz

Başka bir web sitesinde 504 hatası görüyorsanız sorun onların sunucusundadır, sizin cihazınızda değil. Yine de denemeye değer birkaç şey var.

• Bir dakika bekleyip yenileyin — birçok 504, sunucudaki yoğun anın sürdüğü kadar sürer.
• Sitenin herkes için kapalı olup olmadığına bakın — Website Down Checker sayfayı 11 farklı yerden açar. Onlar da 504 alıyorsa sorun sitededir.
• Başka bir ağ deneyin — Wi-Fi yerine mobil veri ya da VPN'siz bağlantı; zaman aşımına uğrayan gateway kendi proxy'niz veya VPN'iniz olabilir.
• Sitenin durum sayfasına veya sosyal medya hesaplarına bakın — yoğun siteler kesintileri çoğu zaman duyurur.

Çözüm 1: Timeout Ayarlarını Artırın (Nginx ve Apache)

504 hataları için en yaygın çözüm, reverse proxy'nizdeki timeout değerlerini artırmaktır. Backend'iniz meşru olarak 60 saniyeden (varsayılan) uzun süre gerektiriyorsa proxy'nin daha uzun beklemesi gerektiğini bilmesi gerekir.

# nginx — reverse proxy to a backend (Node.js, Python, etc.)
location / {
    proxy_pass http://backend;
    proxy_read_timeout 300;
    proxy_send_timeout 300;
}

# nginx — FastCGI (PHP-FPM)
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_read_timeout 300;
    fastcgi_send_timeout 300;
    include fastcgi_params;
}

# Leave proxy_connect_timeout / fastcgi_connect_timeout at their defaults:
# nginx caps them at about 75 seconds, and a dead backend should fail fast.

Apache için VirtualHost'unuza ProxyTimeout 300 ekleyin ya da tek bir backend için ProxyPass / http://backend:8080/ timeout=300 kullanın.

Önemli: okuma ve gönderme timeout'ları toplam aktarım süresini değil, ardışık iki okuma veya yazma işlemi arasındaki boşluğu ölçer. Yani proxy_read_timeout 300, «300 saniye boyunca veri gelmezse» demektir; «yanıtın tamamı 300 saniyede bitmeli» demek değildir. Değiştirdikten sonra yeniden yükleyin: sudo nginx -t && sudo systemctl reload nginx.

CDN arkasındayken CDN'in kendi sınırı da geçerlidir: Cloudflare 125 saniyede (Free'den Business'a) keser, CloudFront varsayılan olarak 30 saniyede keser; bu yüzden nginx'i bunların üzerine çıkarmak CDN üzerinden gelen ziyaretçiler için hiçbir şeyi değiştirmez.

Çözüm 2: Yavaş Scriptleri ve Veritabanı Sorgularını Optimize Edin

Backend'iniz sürekli timeout süresini aşıyorsa timeout değerini artırmak sorunu yalnızca gizler. Asıl çözüm backend'in daha hızlı yanıt vermesini sağlamaktır.

• Yavaş sorguları bulun — MySQL yavaş sorgu logunu açın (slow_query_log = 1, long_query_time = 1) ya da şüpheli sorgularda EXPLAIN ANALYZE kullanın. Eksik indeksleri ekleyin, SELECT * kullanmayın ve büyük sonuç kümelerini sayfalara bölün.
• Önbellek ekleyin — Pahalı sorgu sonuçlarını önbelleğe almak için Redis veya Memcached kullanın. Her sayfa yüklemesinde 5 saniye süren bir sorgu önbelleğe alınmalıdır.
• Ağır işleri arka plan görevlerine taşıyın — Rapor üretimi, e-posta gönderimi, görüntü işleme ve veri aktarımları HTTP istek döngüsünde değil, bir iş kuyruğunda (Celery, Sidekiq, Bull) çalışmalıdır.
• API çağrılarını optimize edin — Backend'iniz yavaş üçüncü taraf API'lerini çağırıyorsa bu çağrılara timeout ekleyin ve tek bir yavaş API'nin tüm istekleri tıkamaması için circuit breaker uygulayın.
• N+1 sorgularını azaltın — ORM'in ürettiği sorgular çoğu zaman yüzlerce ayrı veritabanı çağrısı yapar. Gidiş-dönüşleri azaltmak için eager loading veya toplu sorgular kullanın.

Çözüm 3: Sunucu Kaynaklarını Kontrol Edin (CPU, RAM, Disk)

Origin sunucu aşırı yüklüyse istekleri yeterince hızlı işleyemez ve proxy beklerken zaman aşımına uğrar. Kaynakları neyin tükettiğine bakın.

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space (full disk = silent failures)
df -h

# Check memory details
free -m

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Check active network connections
ss -s

CPU veya RAM %90'ın üzerindeyse uygulamanızı optimize etmeniz, kontrolden çıkmış süreçleri sonlandırmanız ya da sunucunuzu yükseltmeniz gerekir. Disk doluysa eski log dosyalarını, yedekleri veya geçici dosyaları temizleyin; dolu bir disk veritabanlarını sessizce çökertebilir ve art arda 504 hatalarına yol açabilir.

Çözüm 4: Hata Loglarını Kontrol Edin

Hata logları, proxy'nin neden 504 döndürdüğünü tam olarak söyler. Nedeni tahmin etmeden önce her zaman logları kontrol edin.

# Nginx error log (look for "upstream timed out")
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log       # Debian/Ubuntu
tail -50 /var/log/httpd/error_log          # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.3-fpm.log

# System log (OOM kills, crashes)
tail -50 /var/log/syslog

Bir 504'ün ardındaki yaygın log mesajları:

«upstream timed out (110: Connection timed out) while reading response header from upstream» (nginx): backend, proxy_read_timeout (veya fastcgi_read_timeout) süresinden uzun sürdü. Hızlandırın; bekleme meşruysa timeout'u artırın.

«upstream timed out (110: Connection timed out) while connecting to upstream» (nginx): nginx zamanında bağlanamadı bile: paketleri düşüren bir güvenlik duvarı ya da bağlantı kabul edemeyecek kadar meşgul bir backend.

«server reached pm.max_children setting» (PHP-FPM): tüm worker'lar meşgul, bu yüzden istekler kuyrukta bekliyor. pm.max_children değerini yalnızca yeterli RAM varsa artırın; yoksa worker'ları tutan yavaş istekleri bulun.

«Too many connections» (MySQL): bağlantı sınırı doldu. Yeni bağlantılar hemen başarısız olur (WordPress'in «Error establishing a database connection» hatası gibi bir 500), bunları tutan sorgular ise çoğu zaman 504'lerinizin ardındaki yavaş sorgulardır.

Çözüm 5: PHP-FPM Ayarlarını Düzenleyin

PHP uygulamalarında (WordPress, Laravel, Magento) timeout'ları bir zincir olarak tutun; her katman arkasındakinden biraz uzun olsun: nginx'in fastcgi_read_timeout ≥ PHP-FPM'in request_terminate_timeout ≥ PHP'nin max_execution_time değeri.

PHP-FPM ayarlarını değiştirdikten sonra yeniden başlatın (sudo systemctl restart php8.3-fpm, sürümü kendinize göre uyarlayın). nginx'in fastcgi_read_timeout değeri PHP'nin sınırlarından kısaysa nginx önce pes eder ve PHP hâlâ çalışırken ziyaretçiler 504 görür.

Çözüm 6: CDN ve Proxy Yapılandırmasını Kontrol Edin

Siteniz Cloudflare veya AWS CloudFront gibi bir CDN'in arkasındaysa CDN'in kendi timeout ayarları vardır ve bunlar sunucu yapılandırmanızın önüne geçebilir.

Cloudflare: Free, Pro ve Business'ta origin'iniz 125 saniye içinde yanıt vermeye başlamazsa Cloudflare pes eder ve Error 524 gösterir (Cloudflare). Cloudflare'in kendi önerisi: isteği hızlandırın, uzun işleri arka plana taşıyın ya da bunları yalnızca DNS'li (gri bulut) bir alt alan adından sunun; Enterprise planlar sınırı artırabilir.

CloudFront: dağıtımın origin ayarlarında origin'in response timeout değerini artırın (AWS). AWS önce yavaş origin'i düzeltmenizi önerir. GET ve HEAD isteklerinde CloudFront origin'i yeniden dener (varsayılan 3 bağlantı denemesi); yani ziyaretçi 504'ü almadan önce origin aynı isteği birkaç kez görebilir.

504'ü hangi katmanın gönderdiğini görmek için yanıt başlıklarına HTTP Header Checker ile bakın: server: awselb/2.0 bir AWS yük dengeleyicidir, x-cache: Error from cloudfront CloudFront'tur, server: nginx ise nginx'tir. Cloudflare arkasında her yanıt server: cloudflare der; orada ipucu kodun kendisidir (524 veya 504).

Çözüm 7: WordPress'e Özel Çözümler

WordPress siteleri; ağır eklentiler, şişmiş veritabanları ve paylaşımlı hosting sınırları yüzünden 504 hatalarına özellikle yatkındır. İşte hedefe yönelik çözümler.

• Yavaş eklentileri belirleyin — Tüm eklentileri devre dışı bırakın, sonra birer birer yeniden etkinleştirin. wp-admin'e erişemiyorsanız SSH üzerinden plugins klasörünü yeniden adlandırın: mv wp-content/plugins wp-content/plugins_disabled. Yavaş veritabanı sorgularını bulmak için Query Monitor eklentisini kullanın.
• Önbellek eklentisi kurun — WP Super Cache, W3 Total Cache veya WP Rocket, her istekte PHP çalıştırmak yerine statik HTML sunarak sunucu tarafındaki işi azaltır.
• Nesne önbelleği kullanın — Redis veya Memcached ile bir WordPress nesne önbelleği eklentisi kurun. Bu, veritabanı sorgu sonuçlarını bellekte tutar ve MySQL yükünü azaltır.
• Veritabanını temizleyin — Eski yazı revizyonlarını, transient'leri, spam yorumları ve sahipsiz meta verileri silin. WP-Optimize veya WP-Sweep kullanın. Gelecekteki revizyonları sınırlamak için define('WP_POST_REVISIONS', 5); ekleyin.
• wp-cron'u gerçek bir cron görevine taşıyın — sayfa ziyaretleri WP-Cron'u tetikler; o da zamanı gelen görevleri kendine ait bir PHP worker'ı tutan bir loopback isteğinde çalıştırır. wp-config.php dosyasına define('DISABLE_WP_CRON', true); ekleyin, ardından sunucunun wp cron event run --due-now komutunu 5 dakikada bir çalıştırmasını sağlayın.

504 vs 502 vs 503 vs 408: Fark Nedir?

Bu HTTP hata kodları sık karıştırılır. Her birinin gerçekte ne anlama geldiği şöyle.

Kritik fark şudur: 502, proxy'nin bozuk bir yanıt aldığı ya da bağlantının reddedildiği veya kapatıldığı anlamına gelir; 504 ise upstream sessiz kalırken proxy'nin zamanlayıcısının dolduğu anlamına gelir. 503 için proxy gerekmez: aşırı yüklenen herhangi bir sunucu onu gönderebilir. 408 ise istemci tarafı bir timeout'tur (4xx sınıfı); burada sunucu istemciyi beklemekten vazgeçmiştir.

502 ve 504'ü birlikte görüyorsanız backend büyük olasılıkla zorlanıyordur: zaman aşımına uğrayan istekler 504, çöken veya sonlandırılan worker'lar 502 verir.

504 yerine 502 görüyorsanız 502 Bad Gateway rehberimiz, bu siteden gerçek bir vaka dahil, onu açıklayan nginx hata logu mesajlarını anlatır.

504 Hatası SEO'yu Etkiler Mi?

Google'ın belgeleri 5xx hatalarının ne yaptığını açıklar (Google tarama belgeleri):

• Tarama yavaşlar — tüm site için, sunucu hatası döndüren URL sayısıyla orantılı olarak.
• Dizindeki sayfalar başta korunur ama sürekli sunucu hatası döndüren URL'ler sonunda kaldırılır.
• Tarama kademeli olarak toparlanır — sunucu yeniden 2xx ile yanıt vermeye başladığında.

504 Gateway Timeout Hatalarını Nasıl Önlersiniz

Önlem almak, yangın söndürmekten her zaman iyidir. Bu uygulamalar sunucunuzun timeout sınırları içinde yanıt vermesini sağlar.

• İzleme kurun — Önemli sayfaları birkaç dakikada bir yükleyen bir uptime izleyici, 504'leri kullanıcılarınız bildirmeden yakalar.
• Timeout zincirinizi eşleştirin — CDN timeout ≥ proxy timeout ≥ uygulama timeout olduğundan emin olun. Uyumsuz değerler öngörülemeyen 504 hatalarına yol açar.
• Health check uygulayın — Yük dengeleyiciler ve proxy'ler upstream sunucuları health check ile denetlemeli ve yanıt vermeyen örneklerden trafiği başka yere yönlendirmelidir.
• Önbelleği yoğun kullanın — Statik dosyaları, API yanıtlarını ve veritabanı sorgularını önbelleğe alın. Önbellekten gelen bir yanıt hiçbir zaman 504'e yol açacak kadar yavaş değildir.
• Otomatik ölçekleyin — Trafik artışları tek bir sunucuyu bunaltmasın diye yatay ölçekleme (daha fazla örnek) kullanın.
• Ağır işleri dışarı alın — Dosya işleme, rapor üretimi, e-posta gönderimi ve toplu aktarımları arka plan iş kuyruklarına taşıyın. HTTP isteği içinde asla pahalı işler yapmayın.
• Yavaş sorguları izleyin — MySQL/PostgreSQL'de yavaş sorgu loglamasını etkinleştirin. 1 saniyeyi aşan sorgular için uyarı kurun.
• Bağımlılıkları sağlıklı tutun — Backend'inizin bağlı olduğu üçüncü taraf API'leri izleyin. Tek bir yavaş API'nin tüm kullanıcılar için art arda 504 hatalarına yol açmaması için timeout'lar ve circuit breaker'lar ekleyin.