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 hatalı bir yanıt verdi (ya da bağlantıyı kapattı), 504 = upstream zamanında hiç yanıt vermedi. Komşu hataları ayrıntılı rehberlerimizde ele alıyoruz: 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şmış, yeni isteklerin gidecek yeri yok.

• 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 ile kaynak sunucu arasında güvenlik duvarı veya ağ değişikliği. Örneğin IP adresi ya da güvenlik duvarı kuralları değişen bir kaynak sunucuya CDN artık ulaşamıyor.

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 HTTP Başlık Kontrolü aracı sayfayı bizim sunucularımızdan ister ve tam durum kodunu gösterir. Biz de 502 alıyorsak sorun sizde değil, sitededir. Ping Aracı ise sunucu makinesinin yanıt verip vermediğini gösterir.

• Önbelleği atlayarak yenileyin ve önbelleği temizleyin. Ctrl + Shift + R (Mac: Cmd + Shift + R), size eski bir hata sayfasının gösterilme ihtimaline karşı önbellekteki kopyayı atlar.

• 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 neyin yanlış gittiğini neredeyse her zaman tam olarak kaydeder. Şu dört kontrolü sırayla uygulayın.

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

502 hatasını yeniden oluşturun, ardından proxy sunucusundaki hata günlüğünün son satırlarını okuyun:

# 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

Aşağıdaki nginx mesajları 502 hatalarının büyük çoğunluğunu kapsar ve her biri çözüme işaret eder:

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ı?
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?
grep -rn "proxy_pass\|fastcgi_pass" /etc/nginx/sites-enabled/

# 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). Her değişiklikten sonra sudo nginx -t ve sudo systemctl reload nginx komutlarını çalıştırın.

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ı:

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;
}

nginx -t ve yeniden yüklemenin ardından sayfa 200 döndürdü. Çı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 büyük çerezler 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ı varsayılan olarak 5 saniye sonra kapatır (server.keepAliveTimeout, Node.js 26 ve öncesinde); 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 // keepAliveTimeout değerinin biraz üzerinde tutun

Cloudflare'de 502 Bad Gateway

Cloudflare arkasındaysanız önce hata sayfasını kimin oluşturduğuna bakın:

• Cloudflare markalı sayfa (Browser ✓ / Cloudflare ✓ / Host ✗): Cloudflare çalışıyor, ancak kaynak sunucunuzdan geçerli bir yanıt alamadı. Kaynak sunucunun açık olduğunu, 443/80 portlarında dinlediğini ve güvenlik duvarında Cloudflare'in IP aralıklarını engellemediğini kontrol edin. Kaynak sunucuyu doğrudan Port Kontrolü aracıyla test edin.

• Sade, markasız 502 sayfası: sayfada cloudflare geçmiyorsa (örneğin nginx veya Apache adı yazıyorsa), 502'yi kendi kaynak sunucunuz üretmiştir. Yukarıdaki sunucu tarafı adımlarını uygulayın. Altında yalnızca "cloudflare" yazan boş bir sayfa ise Cloudflare'in kendisinden gelir; örneğin kısa süreli trafik yeniden yönlendirmesi sırasında ya da kaynak sunucu bozuk gzip içeriği gönderdiğinde.

• Kaynak IP'si mi değişti? Barındırma firması değiştirdiyseniz Cloudflare DNS'teki A kaydını güncelleyin. DNS Sorgulama aracı, dünyanın şu anda ne gördüğünü gösterir.

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.