502 Bad Gateway Hatası: Nedir ve Nasıl Çözülür?

502 Bad Gateway Hatası Nedir?

502 Bad Gateway, size yanıt veren sunucunun bir ağ geçidi ya da proxy olarak çalıştığını ve arkasındaki sunucudan geçersiz bir yanıt aldığını belirten bir HTTP durum kodudur. HTTP standardı (RFC 9110, bölüm 15.6.3) onu tam olarak böyle tanımlar: sunucu, "bir ağ geçidi veya proxy olarak çalışırken, isteği yerine getirmeye çalışırken eriştiği gelen yönlü (inbound) bir sunucudan geçersiz bir yanıt almıştır."

Modern web sitelerinin çoğunda en az iki katman bulunur. nginx, Apache, Cloudflare veya bir bulut yük dengeleyicisi gibi bir ön sunucu bağlantınızı kabul eder, ardından isteği PHP-FPM, bir Node.js uygulaması, Python'ın Gunicorn sunucusu ya da bir konteyner gibi bir upstream (arka uç) uygulamaya iletir. Bu upstream kapalıysa, çökerse veya proxy'nin kullanamayacağı bir yanıt verirse, proxy'nin size verecek bir şeyi kalmaz ve 502 döndürür.

Önemli nokta şu: ağ geçidinin kendisi çalışıyordur. İsteğinizi almış ve yanıt vermiştir. Arıza bir adım daha geridedir.

502 Hatasının Farklı Görünümleri

Durum kodu her yerde aynıdır, ancak gördüğünüz sayfa onu hangi proxy'nin ürettiğine bağlıdır:

Hangi sürümü görürseniz görün, sayfanın altındaki proxy adı faydalı bir ipucudur: site sahibine hangi katmanı incelemesi gerektiğini söyler.

502, 500, 503 ve 504 Arasındaki Fark Nedir?

5xx kodlarının hepsi "sunucu sorunu" anlamına gelir, ancak her biri farklı bir katmana işaret eder:

Kısa bir kural: 502 = upstream bağlantıyı reddetti, kapattı ya da kötü bir yanıt gönderdi, 504 = upstream zamanında yanıt vermedi. Komşu hataları ayrıntılı anlatan rehberlerimiz: 500 Internal Server Error, 503 Service Unavailable ve 504 Gateway Timeout.

502 Bad Gateway Hatasına Ne Neden Olur?

• Upstream uygulama çalışmıyor. PHP-FPM, Node, Gunicorn ya da konteyner çökmüş, bir dağıtımdan sonra başlatılamamış veya yeniden başlıyor.
• Proxy yanlış yere işaret ediyor. proxy_pass veya fastcgi_pass yanlış portu, bir yükseltmeden sonra eskimiş bir PHP soket yolunu ya da bir Docker konteyneri içinde localhost adresini kullanıyor.
• Uygulama bazı isteklerde çöküyor. Bir sayfa bellek yetersizliği nedeniyle sonlandırmayı veya yakalanmamış bir istisnayı tetikliyor ve bağlantı yanıt verilmeden kapanıyor.
• Tüm worker'lar meşgul. PHP-FPM pm.max_children sınırına ulaştı, bu yüzden yeni istekler soketin kuyruğunda bekler. Çoğu zaman aşımıyla 504 olur; kuyruk dolunca nginx (11: Resource temporarily unavailable) kaydeder ve 502 döndürür.
• Yanıt başlıkları fazla büyük. Büyük çerezler veya uzun güvenlik başlıkları nginx'in proxy_buffer_size arabelleğini taşırıyor.
• Yük dengeleyici arkasında keep-alive uyumsuzluğu. Uygulama boştaki bağlantıları yük dengeleyicinin beklediğinden daha erken kapatıyor; bu yüzden dengeleyici, kapanmakta olan bir bağlantıya istek gönderiyor.
• Proxy, ağ değişikliğinden sonra upstream'e ulaşamıyor. Proxy'yi reddeden bir güvenlik duvarı ya da yeni bir IP'ye taşınan upstream 502 verir (Connection refused, No route to host). Paketleri sessizce düşüren bir güvenlik duvarı ise 504 verir; Cloudflare arkasında bunlar 521 veya 522 olarak görünür.

Ziyaretçi Olarak 502 Hatası Nasıl Çözülür

Başkasının sunucusunu onaramazsınız, ancak bu adımlar sorunun gerçekten onların tarafında olduğunu doğrular ve nadir görülen yerel nedenleri ortadan kaldırır:

• 30 ila 60 saniye bekleyin ve sayfayı yenileyin (Ctrl + R, Mac'te Cmd + R). Birçok 502 hatası yalnızca bir dağıtım ya da yeniden başlatma sürdüğü kadar sürer.
• Sitenin herkes için kapalı olup olmadığını kontrol edin. DNS Robot'un Site Erişim Kontrolü aracı sayfayı 11 noktadan açar, HTTP Başlık Kontrolü aracı ise sunucumuzun aldığı tam durum kodunu gösterir. Onlar da 502 görüyorsa sorun sizde değil, sitededir.
• Önbelleği atlayarak yenileyin: Ctrl + Shift + R (Mac: Cmd + Shift + R). Size önbellekteki bir hata sayfası gösteriliyor olabilir.
• Site kısa süre önce barındırma firması değiştirdiyse DNS önbelleğinizi temizleyin, böylece yeni sunucuya ulaşırsınız. Her sistemde DNS önbelleği nasıl temizlenir burada anlatılıyor.
• VPN'leri ve proxy'leri kapatın. Başarısız olan "ağ geçidi" kendi proxy'niz olabilir, özellikle iş ağlarında.
• Başka bir tarayıcı ya da mobil veriye bağlı telefonunuzu deneyin. Orada çalışıyorsa o sitenin çerezlerini temizleyin.

Sunucunuzda 502 Bad Gateway Hatası Nasıl Çözülür

Sunucu tarafında 502, çözmesi en kolay hatalardan biridir, çünkü proxy genellikle neyin yanlış gittiğini kaydeder (istisnalar: yük dengeleyicinin keep-alive yarış durumu ve Cloudflare'in kendi 502'leri). Şu üç kontrolü sırayla uygulayın; dördüncü bölüm gerçek bir örnektir.

1. Proxy'nin Hata Günlüğünü Okuyun

502 hatasını yeniden oluşturun, ardından proxy'nin hata günlüğünün son 50 satırını okuyun (komutlar tablonun altında). Bu nginx mesajlarının her biri kendi çözümüne işaret eder:

# nginx
sudo tail -n 50 /var/log/nginx/error.log

# Apache
sudo tail -n 50 /var/log/apache2/error.log    # Debian/Ubuntu
sudo tail -n 50 /var/log/httpd/error_log      # RHEL/Alma/Rocky

2. Upstream Uygulamanın Çalıştığını Kontrol Edin

# PHP-FPM (sürümü kendinize göre değiştirin)
sudo systemctl status php8.3-fpm
sudo journalctl -u php8.3-fpm -n 50

# PM2 altında Node.js
pm2 status
pm2 logs --lines 50

# Docker
docker ps -a          # sürekli yeniden başlayan konteynerlere bakın
docker logs --tail 50 <container>

# Fazla bellek kullandığı için mi sonlandırıldı?
sudo dmesg -T | grep -i "killed process"

Hizmet durmuşsa başlatın ve neden durduğunu bulun: başarısız bir dağıtım, yeni sürümde bir sözdizimi hatası ya da bellek yetersizliği (OOM) sonlandırıcısı. PHP-FPM günlüğündeki server reached pm.max_children setting mesajı, tüm worker'ların meşgul olduğu anlamına gelir. pm.max_children değerini yalnızca sunucuda yeterli RAM varsa artırın; aksi hâlde worker'ları meşgul eden yavaş istekleri bulun.

3. proxy_pass'in Doğru Porta veya Sokete İşaret Ettiğinden Emin Olun

nginx'e konuşması söylenen hedefi gerçekte dinleyen hizmetle karşılaştırın:

# nginx neye proxy yapıyor?
sudo nginx -T 2>/dev/null | grep -n "proxy_pass\|fastcgi_pass"

# Gerçekte ne dinliyor?
sudo ss -tlnp            # TCP portları ve bunları kullanan işlemler
ls -l /run/php/          # PHP-FPM soket dosyaları

İki klasik uyumsuzluk vardır: PHP yükseltildikten sonra soket php8.3-fpm.sock olur ama nginx hâlâ php8.1-fpm.sock dosyasını gösterir; Docker içinde ise proxy_pass http://localhost:3000 uygulamayı değil nginx konteynerinin kendisini gösterir, bu yüzden Compose hizmet adını kullanın (http://app:3000).

4. Gerçek Bir Örnek: dnsrobot.net Nasıl 502 Verdi

Bu bizim başımıza 30 Eylül 2026 tarihinde geldi. Bir grup yeni blog yazısı yayımladıktan sonra, bunlardan tam olarak biri nginx 1.24 üzerinden 502 Bad Gateway döndürürken diğer tüm sayfalar çalışıyordu. nginx'in arkasındaki Next.js uygulaması, aynı sayfayı doğrudan 3000 portundan istediğimizde 200 OK ile döndürüyordu. Yani uygulama sağlamdı, başarısız olan ağ geçidiydi.

nginx hata günlüğü yanıtı tek satırda veriyordu: upstream sent too big header while reading response header from upstream. O sayfanın yanıt başlıkları 4.087 bayt tutuyordu; bunun çoğu uzun bir Content-Security-Policy başlığı ile preload Link başlıklarıydı. nginx, yanıtın tüm başlıkları da içeren ilk bölümünü proxy_buffer_size ile belirlenen bir arabelleğe okur ve bu arabellek varsayılan olarak bir bellek sayfası büyüklüğündedir: bizim sunucumuzda 4 KB. Geriye yalnızca 9 baytlık yer kalmıştı ve durum satırı dahil başlık bloğunun tamamı arabelleği taşırdı.

Çözüm, uygulamaya proxy yapan location bloğuna eklenen üç satırdı; nginx -t ve yeniden yüklemenin ardından sayfa 200 döndürdü:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_buffer_size 16k;        # büyük başlıklar için yer (önceden varsayılan 4k idi)
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
}

Çıkarılacak ders: sitenin geri kalanı çalışırken yalnızca bazı sayfalar 502 döndürüyorsa, uygulamadan şüphelenmeden önce o sayfalardaki büyük başlıklar veya Set-Cookie değerleri gibi bir boyut sınırına bakın.

Yük Dengeleyici Arkasında Node.js: Rastgele 502 Hataları

Node.js'i AWS Application Load Balancer veya benzeri bir dengeleyicinin arkasında çalıştırıyorsanız ve uygulama günlüklerinizde hiçbir hata olmadan ara sıra 502 görüyorsanız, keep-alive zaman aşımlarını kontrol edin. Node'un HTTP sunucusu boştaki keep-alive bağlantılarını Node 26 ve öncesinde varsayılan olarak 5 saniye sonra kapatır (server.keepAliveTimeout; Node 24.6 ve 22.19, bunun üzerine 1 saniyelik bir keepAliveTimeoutBuffer ekledi, bir sonraki ana sürüm ise varsayılanı 65 saniyeye çıkarıyor); AWS ALB ise boştaki bağlantıları 60 saniye açık tutar. Bazen dengeleyici bir bağlantıyı tam Node onu kapatırken yeniden kullanır ve o istek 502 olarak geri döner.

Çözüm, uygulamanın zaman aşımını dengeleyicininkinden uzun tutmaktır:

const server = app.listen(3000)
// Yük dengeleyicinin boşta kalma zaman aşımından uzun olmalı (ALB varsayılanı: 60 sn)
server.keepAliveTimeout = 65_000
server.headersTimeout = 66_000 // yalnızca Node 18'den öncesinde gerekli; sonrasında zararsız

Cloudflare'de 502 Bad Gateway

Cloudflare arkasındaysanız önce hata sayfasını kimin oluşturduğuna bakın (Cloudflare'in 502/504 rehberi):

• Cloudflare markalı sayfa (Browser ✓ / Cloudflare ✓ / Host ✗): kaynak sunucunuzun kendisi Cloudflare'e 502 veya 504 döndürdü. Yukarıdaki sunucu tarafı adımlarıyla kaynak sunucuda düzeltin. Cloudflare kaynak sunucuya hiç bağlanamıyorsa 502 değil, 521 veya 522 alırsınız.
• "502 Bad Gateway" yazan ve altında "cloudflare" geçen sade bir sayfa: bu, Cloudflare'in kendisinden gelir. Cloudflare'in belgeleri iki neden sayar: kaynak sunucunun bozuk gzip içeriği ya da güncel Content-Length olmadan gzip içeriği göndermesi (denemek için kaynak sunucuda sıkıştırmayı kapatın) ve bir Cloudflare veri merkezinde ani trafik artışı; ikincisi kendiliğinden geçer.
• nginx veya Apache adı geçen bir sayfa: genellikle istek sunucunuza Cloudflare'den geçmeden ulaştı; yani DNS kaydı proxy'siz (gri bulut, "DNS only") ya da doğrudan kaynak sunucuya bakıyorsunuz (bir Cache Rule "Origin error page pass-through" seçeneğini açmadıysa).
• Barındırma firması mı değiştirdiniz? Cloudflare DNS'teki kaynak A kaydını güncelleyin (yanlış kaynak IP'si genellikle 521, 522 veya 523 olarak görünür). DNS Sorgulama aracı kaynak sunucuyu yalnızca gri bulutlu (DNS only) kayıtlar için gösterir; proxy'li kayıtlar Cloudflare'in kendi IP'leriyle yanıt verir.

502 Hatası SEO'ya Zarar Verir mi?

Kısa bir kesinti zarar vermez. Google'ın belgelerine göre 5xx sunucu hataları, tarayıcılarının taramayı geçici olarak yavaşlatmasına yol açar. Zaten dizine eklenmiş sayfalar ilk başta dizinde kalır, ancak hatalar sürerse Google sonunda bu URL'leri dizinden çıkarır.

Yani bir dağıtım sırasında birkaç dakika süren bir 502 zararsızdır. Önemli sayfalarda günlerce süren ya da haftalarca aralıklı olarak görünen bir 502 ise taramayı azaltıp sıralama kaybına yol açabilir. Önemli URL'lerinizi izleyin ve her kesintiden sonra Search Console'daki Tarama istatistikleri raporunu kontrol edin.