504 Gateway Timeout: Ne Anlama Gelir ve Nasil Duzeltilir

504 Gateway Timeout Nedir?

504 Gateway Timeout, gateway veya proxy olarak davranan bir sunucunun upstream sunucudan zamaninda yanit alamadigini gosteren bir HTTP durum kodudur. Proxy, upstream sunucunun yanitini bekledi, ancak cok uzun surdu ve proxy vazgecip tarayiciniza 504 hatasi dondurdu.

Resmi tanim RFC 9110 (HTTP Semantics), Bolum 15.6.5'ten gelmektedir: "504 (Gateway Timeout) durum kodu, sunucunun bir gateway veya proxy olarak hareket ederken, istegi tamamlamak icin erismesi gereken bir upstream sunucudan zamaninda yanit alamadigini gosterir."

Anahtar kelime gateway'dir. 504 hatasi her zaman en az iki sunucu icerir: baglanti kurdugunuz sunucu (proxy/gateway) ve arkasindalki (upstream/origin) zamaninda yanit veremeyen sunucu. Yaygin proxyler arasinda Nginx reverse proxy, Cloudflare, AWS Application Load Balancer (ALB) ve CloudFront bulunur.

504 Hatasi Nasil Gorunur

504 hata mesaji tarayiciya, web sunucusuna ve CDN'ye gore degisir. Karsilasacaginiz en yaygin mesajlar sunlardir.

• 504 Gateway Timeout

• 504 Gateway Time-out (Nginx varsayilani — tire kullanir)

• HTTP Error 504 — Gateway Timeout

• Bu sayfa calismiyordur — [alan adi] yanitlamak icin cok uzun surdu (Chrome / Edge)

• Gateway Timeout (Firefox)

• Error 504

• 504 Gateway Time-out — Sunucu zamaninda yanitlamadi (mod_proxy ile Apache)

• Error 524: A timeout occurred (Cloudflare'e ozel — teknik olarak 504 degil, ancak ayni temel neden)

• ERROR — The request could not be satisfied — 504 ERROR (AWS CloudFront)

Mesajin ifadesinden bagimsiz olarak, temel neden her zaman aynidir: bir proxy sunucu, upstream sunucunun yanitini bekledi ve upstream sunucu yapilandirilmis timeout penceresi icinde yanit vermedi.

504 Gateway Timeout Nasil Olusur

504 hatasini anlamak icin, tarayiciniz ile origin sunucu arasindaki timeout zincirini anlamaniz gerekir. Tipik bir web istegi birden fazla katmandan gecer ve her katmanin kendi timeout ayari vardir.

Iste tipik bir istek akisi: Tarayici → CDN (Cloudflare) → Load Balancer → Nginx → PHP-FPM → Veritabani. Veritabani sorgusu 90 saniye suruyorsa ve Nginx'in proxy_read_timeout degeri 60 saniye olarak ayarlanmissa, Nginx beklemeyi birakir ve load balancer'a 504 dondurur, o da tarayiciniza iletir.

504'u donduren sunucu her zaman aracidir (proxy veya gateway), asla origin sunucunun kendisi degil. Origin sunucu sadece zamaninda yanit veremedi — istegi hala isliyor olabilir veya tamamen cokmis olabilir.

504 Gateway Timeout'un Yaygin Nedenleri

Temel nedeni anlamak, cozume giden en hizli yoldur. Iste bir sunucunun 504 dondurmesinin en yaygin nedenleri, sikliga gore siralanmistir.

• Yavas origin sunucu — Karmasik veritabani sorgulari calistiran, rapor ureten veya yavas ucuncu parti API'leri cagiran PHP scriptleri, proxy'nin timeout'unu asabilir. Bu, 504 hatalarinin 1 numarali nedenidir.

• Sunucu asiri yuklu — CPU %100'de, bellek yetersiz (OOM kills) veya tum PHP-FPM workerlari mesgul. Origin sunucu canli ama zamaninda yanit veremeyecek kadar bunalmis durumda.

• Veritabani darboazi — Yavas SQL sorgulari, eksik indeksler, tablo kilitleri veya tukenmis baglanti havuzlari. Uygulama veritabanini beklerken asiliyor ve proxy zaman asimina ugruyor.

• Yanlis yapilandirilmis timeout degerleri — Nginx proxy_read_timeout mesgru olarak daha fazla zaman gerektiren bir backend icin cok dusuk ayarlanmis (ornegin rapor ureticisi veya dosya yukleme isleyicisi).

• Proxy ile origin arasinda ag sorunlari — Veri merkezleri arasinda paket kaybi, yuksek gecikme veya yonlendirme sorunlari. Coklu bolge veya hibrit bulut yapilandirmalarinda yaygindir.

• Firewall veya security group trafigi engelliyor — AWS security gruplari gecici portlarda trafige izin vermiyor, iptables kurallari dahili baglantilari engelliyor veya bir WAF mesgru upstream isteklerini engelliyor.

• Proxy'de DNS cozumleme hatasi — Proxy, upstream ana bilgisayar adini cozumliyemiyor. Nginx'te bu, proxy_pass icinde resolver direktifi olmadan degiskenler kullanildiginda olur.

• CDN timeout — Cloudflare'in Free/Pro/Business planlarinda sabit 100 saniyelik bir limiti vardir. Origin sunucunuz 100 saniyeden fazla suruyorsa, Nginx yapilandirmanizdan bagimsiz olarak Cloudflare Error 524 dondurur.

• DDoS saldirisi — Istek seli sunucu kaynaklarini tuketir ve origin sunucuyu mesgru trafige proxy'nin timeout'u icinde yanit veremeyecek kadar yavaslatir.

Ziyaretciler Icin Cozum: Neler Yapabilirsiniz

Baskasinin web sitesinde 504 hatasi goruyorsaniz, sorun onlarin sunucusundadir — cihazinizda degil. Ancak denemeye deger birkac sey vardir.

• Bekleyin ve yenileyin — Cogu 504 hatasi gecicidir. 30-60 saniye bekleyin, ardindan Ctrl+Shift+R (Windows/Linux) veya Cmd+Shift+R (Mac) ile zorla yenileyin.

• Sitenin herkes icin kapali olup olmadigini kontrol edin — DNS Robot'un HTTP Headers aracini kullanarak sunucunun dis bir konumdan yanit kodunu kontrol edin. Herkes icin 504 donuyorsa sorun sunucu tarafindadir.

• Gizli modu veya farkli bir tarayici deneyin — Tarayici eklentilerini, onbelleklenmis hata sayfalarini ve yerel yapilandirma sorunlarini dislar.

• Farkli bir ag deneyin — Wi-Fi'den mobil veriye gecin veya VPN'inizi devre disi birakin. ISP'niz ile sunucu arasindaki yonlendirme sorunlari bazen 504'e neden olabilir.

• DNS onbellegini temizleyin — Eski DNS kayitlari istekleri yanlis sunucuya yonlendirebilir. Windows'ta: ipconfig /flushdns. Mac'te: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder.

• Sitenin durum sayfasini veya sosyal medyasini kontrol edin — Site bilinen bir kesinti veya bakim penceresi hakkinda duyuru yapmis olabilir.

Cozum 1: Timeout Ayarlarini Artirin (Nginx ve Apache)

504 hatalari icin en yaygin cozum, reverse proxy'nizdeki timeout degerlerini artirmaktir. Backend'iniz mesru olarak 60 saniyeden (varsayilan) fazla sure gerektiriyorsa, proxy'nin daha uzun beklemesi gerektigini bilmesi gerekir.

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

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

mod_proxy ile Apache icin VirtualHost'unuza ProxyTimeout 300 ekleyin veya backend bazinda yapilandirma icin ProxyPass / http://backend:8080/ timeout=300 kullanin.

Onemli: Bu timeoutlar toplam transfer suresini degil, art arda iki okuma/yazma islemi arasindaki sureyi olcer. Yani proxy_read_timeout 300, "tum yanit 300 saniye icinde tamamlanmali" degil, "300 saniye boyunca veri gelmezse" anlamina gelir. Timeout degerlerini degistirdikten sonra yapilandirmayi yeniden yukleyin: sudo nginx -t && sudo systemctl reload nginx.

Cozum 2: Yavas Scriptleri ve Veritabani Sorgularini Optimize Edin

Backend'iniz surekli timeout'u asiyorsa, timeout degerini artirmak sorunu sadece gizler. Gercek cozum, backend'in daha hizli yanit vermesini saglamaktir.

• Yavas sorgulari bulun — MySQL yavas sorgu logunu etkinlestirin (slow_query_log = 1, long_query_time = 1) veya suphelendigniz sorgularda EXPLAIN ANALYZE kullanin. Eksik indeksleri ekleyin, SELECT * kullanmayin ve buyuk sonuc kumelerini sayfalandirin.

• Onbellekleme ekleyin — Pahali sorgu sonuclarini onbelleklemek icin Redis veya Memcached kullanin. Her sayfa yuklemesinde 5 saniye suren bir sorgu onbelleklenmeli.

• Agir islemleri arka plan gorevlerine tasiin — Rapor olusturma, e-posta gonderme, goruntu isleme ve veri aktarimlar HTTP istek dongusunde degil, bir gorev kuyruğunda (Celery, Sidekiq, Bull) calistirilmalidir.

• API cagrilarini optimize edin — Backend'iniz yavas ucuncu parti API'leri cagiriyorsa, bu cagrilara timeout ekleyin ve bir yavas API'nin tum istekleri engellemamesi icin circuit breaker'lar uygulayin.

• N+1 sorgularini azaltin — ORM tarafindan olusturulan sorgular genellikle yuzlerce bireysel veritabani cagrisi yapar. Round trip'leri azaltmak icin eager loading veya toplu sorgular kullanin.

Cozum 3: Sunucu Kaynaklarini Kontrol Edin (CPU, RAM, Disk)

Origin sunucu asiri yukluyse istekleri yeterince hizli isleyemez ve proxy timeout'a ugrayor. Kaynaklari neyin tukettigini kontrol edin.

# 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+ ise uygulamanizi optimize etmeniz, kontrolsuz surecleri sonlandirmaniz veya sunucunuzu yukseltmeniz gerekir. Disk alani doluysa eski log dosyalarini, yedekleri veya gecici dosyalari temizleyin — dolu disk veritabanlarini sessizce cokertebilir ve zincirleme 504 hatalarina neden olabilir.

Cozum 4: Hata Loglarini Kontrol Edin

Hata loglari, proxy'nin neden 504 dondurdugunu tam olarak soyler. Nedeni tahmin etmeden once her zaman loglari 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.2-fpm.log

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

504'e neden olan yaygin log mesajlari:

"upstream timed out (110: Connection timed out)" (Nginx) — Upstream sunucu proxy_read_timeout suresi icinde yanit vermedi. Ya timeout'u artirin ya da yavas upstream'i duzaltin.

"server reached pm.max_children" (PHP-FPM) — Tum PHP worker surecleri mesgul. PHP-FPM havuz yapilandirmasinda pm.max_children degerini artirin.

"connect() failed (111: Connection refused)" (Nginx) — Upstream sunucu calismiyordur veya beklenen portu dinlememektedir. Backend'i yeniden baslatin.

"Too many connections" (MySQL) — Veritabani baglanti limiti tukenmis. MySQL yapilandirmasinda max_connections degerini artirin veya baglanti havuzlamasini optimize edin.

Cozum 5: PHP-FPM Ayarlarini Duzenleyin

PHP-FPM ayarlarini degistirdikten sonra hizmeti yeniden baslatin: sudo systemctl restart php8.2-fpm. Nginx'in fastcgi_read_timeout degerinin her zaman PHP'nin max_execution_time degerinden buyuk veya esit oldugundan emin olun. Aksi takdirde Nginx, PHP bitmeden vazgecer ve 504 hatasi olusur.

Cozum 6: CDN ve Proxy Yapilandirmasini Kontrol Edin

Cloudflare kullanicilari: Free, Pro veya Business planindasaniz ve origin sunucunuz 100 saniyeden fazla suruyorsa, her zaman Error 524 alirsiniz. Tek secenekler: backend'i 100 saniye icinde yanit verecek sekilde optimize edin, uzun sureli gorevleri arka plan islerine tasiyin veya Enterprise'a yuksaltin.

AWS CloudFront kullanicilari: Dagitimizin origin ayarlarinda origin yanit timeout'unu artirin. Varsayilan 30 saniye dinamik icerik icin genellikle cok dusuktur.

Yanit basliklarini kontrol etmek ve hangi katmanin 504 dondurdugunu belirlemek icin DNS Robot'un HTTP Headers aracini kullanin. Proxy'yi saptamak icin server: cloudflare, server: awselb/2.0 veya server: nginx gibi basliklara bakin.

Cozum 7: WordPress'e Ozel Cozumler

WordPress siteleri agir eklentiler, veritabani siskinligi ve paylasimli hosting limitleri nedeniyle 504 hatalarina ozellikle yatkindrir. Iste hedefe yonelik cozumler.

• Yavas eklentileri belirleyin — Tum eklentileri devre disi birakin, ardindan birer birer yeniden etkinlestirin. wp-admin'e erisemiyorsaniz SSH uzerinden plugins klasorunu yeniden adlandirin: mv wp-content/plugins wp-content/plugins_disabled. Yavas veritabani sorgularini belirlemek icin Query Monitor eklentisini kullanin.

• PHP bellegini artirin — wp-config.php dosyasina define('WP_MEMORY_LIMIT', '512M'); ekleyin. Bircok eklenti varsayilan 128MB'den fazlasina ihtiyac duyar.

• Onbellekleme eklentisi kurun — WP Super Cache, W3 Total Cache veya WP Rocket, her istekte PHP calistirmak yerine statik HTML sunarak sunucu tarafli islemeyi azaltir.

• Object caching kullanin — Redis veya Memcached ve bir WordPress object cache eklentisi kurun. Bu, veritabani sorgu sonuclarini bellekte onbellekler ve MySQL yukunu azaltir.

• Veritabanini temizleyin — Eski yazi revizyonlarini, transientleri, spam yorumlari ve yetim meta verileri silin. WP-Optimize veya WP-Sweep kullanin. Gelecekteki revizyonlari sinirlamak icin define('WP_POST_REVISIONS', 5); ekleyin.

• wp-cron'u devre disi birakin — WordPress'in sanal cron'u her sayfa yuklemesinde calisir ve gorevleri biriktirebilir. wp-config.php dosyasina define('DISABLE_WP_CRON', true); ekleyin ve bunun yerine gercek bir sunucu cron gorevi olusturun: */5 * * * * curl -s https://yoursite.com/wp-cron.php > /dev/null 2>&1.

504 vs 502 vs 503 vs 408: Fark Nedir?

Kritik ayrım: 502, proxy'nin bozuk bir yanit aldigini gosterirken 504, proxy'nin hicbir yanit alamadigini gosterir. 503 proxy gerektirmez — herhangi bir sunucu asiri yuklendiginde dondurebilir. 408, sunucunun istemciyi beklemeyi biraktigi istemci tarafli bir timeout'tur (4xx sinifi).

Ayni anda 502 ve 504 goruyorsaniz, upstream sunucu buyuk olasilikla cokmektedir. 502, proxy olen bir surecten kismi veya bozuk bir yanit aldiginda olusur ve 504, surec tamamen yanit vermez oldugunda olusur.

504 Hatasi SEO'yu Etkiler Mi?

Kisa cevap: kisa sureli bir 504'un SEO etkisi yoktur. Uzun sureli 504 deindekslemeye neden olabilir.

Dakikalar ile saatler arasi: Etki yok. Google, gecici sunucu hatalarini anlar ve hemen cezalandirmaz. Googlebot kesinti sirasinda taramiyorsa, fark bile etmez.

Saatler ile gunler arasi: Google, zorlu bir sunucuya ek yuk bindirmemek icin 5xx hatalari donduren siteler icin tarama sikligini azaltir. Sayfalar, Google Search Console'un Sayfa Indeksleme raporunda "Sunucu hatasi (5xx)" olarak gorunebilir.

Gunler ile haftalar arasi: Kalici 504 hatalari etkilenen sayfalarin deindekslenmesine yol acabilir. Siralama onemli olcude duser. Google'dan John Mueller'e gore: sunucu bir gun boyunca kapaliysa, isler iyilesme sonrasinda bir ila uc hafta "dalgali" olabilir.

Kurtarma: Sunucu yeniden guvenilir oldugunda Google, sayfalari otomatik olarak yeniden tarar ve indeksler. Onemli sayfalarin yeniden indekslenmesini istemek icin Google Search Console'un URL Inceleme aracini kullanin. Kurtarma suresi, site boyutuna ve hatalarin ne kadar surdugune baglidir.

504 Gateway Timeout Hatalarini Nasil Onlersiniz

Onlem, yangin sondurmeye her zaman yegdir. Bu uygulamalar sunucunuzun timeout limitleri icinde yanit vermesini saglar.

• Izleme kurun — Kullanicilariniz bildirmeden once 504 hatalarini tespit etmek icin uptime izleme (UptimeRobot, Pingdom veya DNS Robot'un Ping araci) kullanin.

• Timeout zincirinizi eslestirin — CDN timeout >= proxy timeout >= uygulama timeout oldugundan emin olun. Uyumsuz degerler onceden tahmin edilemeyen 504 hatalarina neden olur.

• Health check'leri uygulayin — Load balancer ve proxyler upstream sunuculari health check ile kontrol etmeli ve yanit vermeyen orneklerden trafigi uzaklastirmalidir.

• Agresif sekilde onbellekleyin — Statik varliklari, API yanitlarini ve veritabani sorgularini onbellekleyin. Onbelleklenmis bir yanit asla 504'e neden olacak kadar yavas degildir.

• Otomatik olcekleyin — Trafik artislarinin tek bir sunucuyu bunaltmamasini icin yatay olcekleme (daha fazla ornek) kullanin.

• Agir islemleri disariya alin — Dosya islemeyi, rapor olusturmayi, e-posta gondermeyi ve toplu aktarimlari arka plan gorev kuyruklarina tasiyin. Bir HTTP istegi icinde asla pahali islemler yapmayin.

• Yavas sorgulari izleyin — MySQL/PostgreSQL'de yavas sorgu loglmasini etkinlestirin. 1 saniyeyi asan sorgular icin uyarilar olusturun.

• Bagimliliklari saglikli tutun — Backend'inizin bagimli oldugu ucuncu parti API'leri izleyin. Bir yavas API'nin tum kullanicilar icin zincirleme 504 hatalarina neden olmamasi icin timeoutlar ve circuit breakerlar ekleyin.