Nginx 502'yi 10 Dakikada Teşhis Et: Bir DevOps Vakası
2026-07-10 · 11 dk okuma
Saat 14:03. İzleme aracı sitenin %100 "502 Bad Gateway" döndürdüğünü söylüyor. Bu yazıda temel Linux komutlarını ezber bir liste olarak değil — gerçek bir olayı çözerken kullanacağın sırayla göreceksin. Hedef: kök nedeni 10 dakikada bulmak.
Belirti: 502 aslında ne diyor?
502 Bad Gateway, Nginx'in ayakta olduğunu ama arkasındaki upstream'e (uygulama sunucun) ulaşamadığını söyler. Yani sorun çoğu zaman Nginx'te değil, upstream'dedir. Bu zihinsel model teşhis sırasını belirler.
Not
502 = upstream ulaşılamıyor. 504 = upstream yavaş (timeout). 503 = servis geçici kapalı. Hangi kodu gördüğün, nereye bakacağını söyler.
10 dakikalık teşhis akışı
- 1Nginx hata logunu oku — upstream hatası ne diyor? (journalctl)
- 2Upstream dinliyor mu? (ss ile portu kontrol et)
- 3Upstream süreci ayakta mı, çöktü mü? (systemctl / ps)
- 4Upstream'i doğrudan çağır — sağlıklı mı? (curl)
- 5Kaynak tükenmiş mi? (free, top, df)
- 6İzin / soket sorunu var mı? (ls -l, SELinux)
Adım adım terminal
1) Nginx logu: hata tam olarak ne?
$ sudo journalctl -u nginx --since "10 min ago" --no-pager | tail -n 3connect() failed (111: Connection refused) while connecting to upstream,upstream: "http://127.0.0.1:3000/", request: "GET / HTTP/1.1"# → 'Connection refused' = upstream portu kimse dinlemiyor. İpucu net.
2) Upstream dinliyor mu?
$ sudo ss -ltnp | grep :3000# (çıktı yok) → 3000 portunda dinleyen SÜREÇ YOK. Uygulama down.$ sudo ss -ltnp | grep :80LISTEN 0 511 0.0.0.0:80 users:(("nginx",pid=712)) # nginx ise ayakta
3) Uygulama süreci çökmüş mü?
$ systemctl status myapp --no-pager● myapp.service - Node APIActive: failed (Result: exit-code) since 14:02Process: 991 ExecStart=/usr/bin/node server.js (code=exited, status=1)$ sudo journalctl -u myapp --since "15 min ago" | tail -n 2Error: listen EADDRINUSE / Cannot find module 'pg' # kök neden burada
4) Upstream'i doğrudan çağır
$ curl -sS -o /dev/null -w "%{http_code}\n" http://127.0.0.1:3000/healthcurl: (7) Failed to connect to 127.0.0.1 port 3000: Connection refused# → Nginx'i aradan çıkardık; upstream gerçekten cevap vermiyor.
5) Kaynak tükenmiş mi? (çökme sebebi olabilir)
$ free -htotal used freeMem: 3.8Gi 3.7Gi 84Mi # bellek bitmiş → OOM killer süreci öldürmüş olabilir$ df -h /Filesystem Size Used Avail Use%/dev/root 20G 20G 0 100% # disk %100 → uygulama log/temp yazamaz, çöker$ dmesg -T | grep -i "killed process" | tail -n 1[Wed] Out of memory: Killed process 991 (node) # ✓ kanıt: OOM
Dikkat
Yaygın hata: doğrudan "nginx -s reload" veya "systemctl restart nginx" yapmak. Nginx zaten sağlıklı; onu yeniden başlatmak 502'yi çözmez, sadece semptomu erteler. Önce upstream'i düzelt.
6) Çözüm ve doğrulama
$ sudo systemctl restart myapp$ sudo ss -ltnp | grep :3000LISTEN 0 511 127.0.0.1:3000 users:(("node",pid=1042)) # ✓ upstream ayakta$ curl -s -o /dev/null -w "%{http_code}\n" https://site.com200 # ✓ 502 gitti
Troubleshooting kontrol listesi
- journalctl -u nginx → 'connect() failed' hatasının tam metni
- ss -ltnp → upstream portu dinleniyor mu
- systemctl status <app> → süreç failed/active mı
- curl 127.0.0.1:<port> → upstream'i Nginx olmadan test et
- free -h / df -h / dmesg → OOM veya disk-full çökmesi mi
- İzin/SELinux: getenforce, ls -l <soket>, setsebool httpd_can_network_connect
Mini görev
Bir VM veya container'da basit bir HTTP servisini 3000 portunda çalıştır, önüne Nginx reverse proxy koy. Sonra servisi durdur ve 502'yi gör. Yukarıdaki 6 adımı sırayla uygulayıp kök nedeni 'connection refused' olarak doğrula. Bonus: servisi OOM'a sokup dmesg'de kanıtı bul.
Uygulamalı görev — tarayıcıda dene
Komutları ezberlemek değil, bir olay üzerinde doğru sırayla kullanmak önemli. Cloudpuz lab'ları tam da bu teşhis refleksini kazandırmak için gerçek terminalde bozuk senaryolar veriyor.
Resmi kaynaklar
Son doğrulama: 2026-07-17
Sıkça Sorulan Sorular
502 Bad Gateway hatası ne anlama gelir?
502 Bad Gateway, Nginx'in ayakta olduğunu ama arkasındaki upstream'e (uygulama sunucusuna) ulaşamadığını gösterir. Yani sorun çoğu zaman Nginx'te değil, upstream'dedir. Bu zihinsel model teşhis sırasını belirler: önce upstream'e bakılır.
502, 503 ve 504 hataları arasındaki fark nedir?
502 upstream'e ulaşılamadığını, 504 upstream'in yavaş olduğunu (timeout), 503 ise servisin geçici olarak kapalı olduğunu gösterir. Hangi kodu gördüğün, nereye bakman gerektiğini söyler.
Nginx 502 hatası nasıl teşhis edilir?
Sırasıyla: `journalctl -u nginx` ile Nginx hata logundaki upstream hatası okunur; `ss -ltnp` ile upstream portunun dinlenip dinlenmediği kontrol edilir; `systemctl status <app>` ile sürecin ayakta mı yoksa çökmüş mü olduğuna bakılır; `curl 127.0.0.1:<port>` ile upstream Nginx olmadan doğrudan test edilir; `free -h`, `df -h` ve `dmesg` ile OOM veya disk dolması gibi kaynak tükenmesi araştırılır; son olarak izin/SELinux sorunları kontrol edilir.
Bir portu hangi sürecin dinlediği nasıl kontrol edilir?
`sudo ss -ltnp | grep :<port>` komutu kullanılır. Çıktı yoksa o portta dinleyen süreç yoktur; bu, upstream uygulamanın down olduğunu gösterir. Çıktıda süreç adı ve PID görünürse (örneğin nginx, node) süreç ayaktadır.
Nginx'i yeniden başlatmak 502 hatasını çözer mi?
Hayır. 502 durumunda Nginx zaten sağlıklıdır; `nginx -s reload` veya `systemctl restart nginx` yapmak sorunu çözmez, sadece semptomu erteler. Önce upstream düzeltilmelidir.
Okumak yetmez — dene.
Bu konuları tarayıcıda gerçek terminalde uygula.