502 Bad Gateway: Restart Atmadan Önce Bakılacak 3 Yer

502'de "nginx" yazması yanıltıcıdır: hatayı bildiren Nginx'tir, yapan değil. Kopan halka arka servistedir. Restart atmadan önce sorulacak üç soru, log satırını okuma ve saklanacak bir kontrol listesi.

Site gitti. Müşteri çevrimiçi. Sen çevrimdışısın.

Tarayıcıda tek satır yazıyor: 502 Bad Gateway — nginx. Ve bu satırı ilk gördüğünde yapmak isteyeceğin şey, yapılabilecek en kötü şey: sunucuya girip bir şeyleri yeniden başlatmak.

Bu yazı, panik anında değil panikten önce okunmak için. Sonunda kaydedip saklayacağın bir kontrol listesi var.

502 aslında ne diyor?

502'yi doğru okumak, sorunun yarısını çözer. Cümle şu:

Nginx isteği aldı. Arka taraftaki servise iletti. Ama oradan geçerli bir cevap alamadı.

Zincir şöyle:

Ziyaretçi → Nginx → PHP-FPM (ya da Node, Python, neyse arka tarafın)

502 gördüğünde ilk halka çalışıyor. Nginx isteği aldı, ayakta, seninle konuşuyor — sana bu hata sayfasını gösterebiliyor olması bunun kanıtı. Kopan yer ikinci ok.

Bu yüzden "nginx" kelimesini ekranda görmek yanıltıcıdır. Hatayı bildiren Nginx'tir, hatayı yapan değil.

Kardeş hataları da ayırt et

Aynı aileden üç hata var ve ikisi bambaşka şeyler söylüyor. Karıştırmak, yanlış yerde saatler harcamak demek:

• 502 Bad Gateway — arka servise ulaşılamadı ya da bozuk cevap geldi. Servis muhtemelen ölü, yanlış adreste veya izin vermiyor.
• 504 Gateway Timeout — arka servise ulaşıldı, ama zamanında cevap vermedi. Servis ayakta ve yavaş. Burada bakılacak yer sunucu değil, o isteğin kendisidir: uzun sorgu, dış API beklemesi, sonsuz döngü.
• 503 Service Unavailable — genellikle kasıtlıdır. Bakım modu, rate limit ya da kapasite dolu.

502 ile 504 arasındaki fark bir kelime gibi görünüyor: ulaşılamadı ve cevap vermedi. Ama biri "servis çalışmıyor", diğeri "kodun yavaş" demek. Tamamen farklı iki gün geçirirsin.

Restart atmadan önce: üç soru

Sunucuya girdin. Elin restart yazmak istiyor. Önce şu üçünü cevapla.

1. Nginx gerçekten ayakta mı?

systemctl status nginx

Beklediğin cevap active (running). Bu cevabı aldıysan Nginx'i listeden çıkardın — bir daha oraya bakma. Almadıysan zaten 502 değil, hiçbir şey görmüyor olman gerekirdi; bu durumda nginx -t ile yapılandırmayı sına.

2. Arka servis ayakta mı?

systemctl status php8.3-fpm

Sürüm numarasını kendi kurulumuna göre yaz. Node kullanıyorsan kendi servisin, Python'daysa gunicorn/uwsgi. Asıl şüpheli budur.

Burada inactive (dead) ya da failed görürsen cevabı buldun. Ama hemen başlatma — bir sonraki adımı atla, çünkü neden öldüğünü öğrenmeden başlatırsan aynı şey tekrar olur.

3. Log ne diyor?

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

Log tahmin yürütmez. Kopan yeri doğrudan söyler.

Bu üçü cevap vermeden restart yok. Sebebini birazdan anlatacağım.

Log satırını okumayı öğren

En sık göreceğin satır bu:

connect() to unix:/run/php/php8.3-fpm.sock failed
(2: No such file or directory)

Bu satır tek başına üç ihtimali birden söylüyor:

1. Servis durmuş. Socket dosyası PHP-FPM çalışırken var olur; servis ölünce dosya kaybolur. "No such file" çoğu zaman "process yok" demektir.
2. Yol yanlış. Servis çalışıyor ama başka bir socket dosyası açmış. Nginx var olmayan bir adrese gidiyor.
3. İzin yok. Dosya var, Nginx'in kullanıcısı onu açamıyor. Bu durumda mesaj genelde (13: Permission denied) olur — parantez içindeki numara önemli, oku.

Parantez içindeki sayı işletim sisteminin hata kodudur ve teşhisi ikiye böler: 2 → yok, 13 → var ama giremiyorum. İkisi çok farklı düzeltmeler ister.

En sık rastlanan sebep: iki taraf farklı kapıda

Bu hatayı gerçek hayatta en çok üreten şey karmaşık değil. İki dosya birbirinden habersiz.

Nginx tarafı:

fastcgi_pass unix:/run/php/php8.3-fpm.sock;

PHP-FPM havuzu:

listen = /run/php/php8.2-fpm.sock

8.3 ≠ 8.2. Nginx bir kapıyı çalıyor, PHP-FPM başka kapıda bekliyor. Kimse yanlış yapmadı; PHP sürümü yükseltildi, bir taraf güncellendi, diğeri unutuldu.

Bunu tahmin etmek yerine sorabilirsin — PHP-FPM'in gerçekte hangi adresi dinlediğini kendisine sor:

grep -r "^listen" /etc/php/*/fpm/pool.d/

Sonra Nginx'in nereye gittiğine bak:

grep -r fastcgi_pass /etc/nginx/

İki çıktıyı yan yana koy. Uyuşmuyorlarsa sorunu buldun ve kanıtın var.

Servis ölüyse neden öldüğünü öğren

PHP-FPM failed durumundaysa, başlatmadan önce kendi loguna bak:

journalctl -u php8.3-fpm -n 50 --no-pager

Sık çıkan iki sebep var:

• Bellek. Küçük bir VPS'te işletim sistemi bellek daralınca en çok yiyen süreci öldürür. dmesg | grep -i "killed process" bunu doğrudan gösterir. Böyle bir satır varsa sorun yapılandırma değil, kaynak.
• Havuz doldu. pm.max_children sınırına dayanmışsan log açıkça söyler. Bu 502'nin sebebi olabileceği gibi habercisi de olabilir: trafik arttı, kapasite artmadı.

Neden "önce restart" kötü bir alışkanlık

Restart çoğu zaman siteyi geri getirir. Sorun tam da bu.

Servisi yeniden başlattığında iki şey aynı anda olur: site açılır ve kanıt silinir. Bellek durumu, açık socket, ölmüş sürecin izi — hepsi gider. Site çalıştığı için de araştırmayı bırakırsın.

Sonra aynı şey bir hafta sonra, gece üçte tekrar olur. Elinde yine hiçbir şey yoktur ve yine restart atarsın. Bu döngü, "sunucumuz ara sıra kendiliğinden düşüyor" cümlesinin nasıl doğduğudur.

Üç komut otuz saniye sürer. O otuz saniye, ikinci kesintinin olup olmayacağını belirler.

Gerçekten acele ediyorsan bile önce şunu çalıştır, sonra ne istersen yap:

systemctl status php8.3-fpm > /tmp/olay.txt
tail -n 100 /var/log/nginx/error.log >> /tmp/olay.txt
journalctl -u php8.3-fpm -n 100 --no-pager >> /tmp/olay.txt

Kanıtı cebine koydun. Şimdi restart at.

502 kontrol listesi

Kaydet. Panik anında düşünmek zordur, okumak kolaydır.

1. Nginx servis durumunu kontrol et — systemctl status nginx
2. Arka servisi kontrol et — systemctl status php8.3-fpm (asıl şüpheli)
3. Nginx error logunu oku — tail -n 50 /var/log/nginx/error.log, parantez içindeki hata numarasına dikkat
4. Socket veya port adresini karşılaştır — iki tarafın yapılandırmasını yan yana koy
5. İzinleri ve kaynakları kontrol et — socket sahibi kim, bellek doldu mu, havuz sınırına dayandın mı

Rastgele restart atma. Kopan halkayı bul.

Son bir not

502'nin can sıkıcı tarafı teknik zorluğu değil — seni izleyen biri varken olması. O baskı altında sistem düşünmek zorlaşır ve elin refleksle hareket eder.

Bu yüzden asıl hazırlık, hata anında ne yapacağını bilmek değil: hata anında düşünmek zorunda kalmayacak kadar önceden karar vermiş olmak. Yukarıdaki liste bunun için var.

Bu yazı Sunucu Notları serisinin ilk bölümü. Seride sunucu tarafında sık karşılaşılan durumları, tahmin yürütmeden ve komut komut anlatıyorum.