502 Bad Gateway: Gerçekte ne anlama gelir ve nasıl düzeltilir
Web sitenizi açıyorsunuz ve içerik yerine 502 Bad Gateway yazan boş bir sayfa görüyorsunuz. Korkutucu görünebilir, ama çoğu durumda çözüm oldukça basittir. Ne olduğunu ve sitenizi nasıl geri çalıştıracağınızı birlikte inceleyelim.
502 aslında ne anlama gelir?
Bir ziyaretçi sayfa istediğinde, istek iki katmandan geçer: bir frontend web sunucusu (genellikle Nginx) ve bir backend uygulama sunucusu (PHP-FPM, Apache, Node.js veya başka bir şey). Nginx isteği alır, backend'e iletir ve yanıt bekler.
502 Bad Gateway, Nginx'in backend'den yanıt almaya çalıştığı ancak geçersiz bir yanıt aldığı ya da hiç yanıt alamadığı anlamına gelir. Backend ya çökmüş, bağlantıyı reddetmiş ya da Nginx'in anlayamayacağı bir şey döndürmüştür.
Sık yapılan bir yanlış anlama: 502, sunucunuzun çöktüğü anlamına gelmez. Sunucunun kendisi tamamen çalışıyor — sorun Nginx'in arkasındaki uygulamada.
En yaygın nedenler
Backend servisi durmuş. Bu en sık karşılaşılan nedendir. PHP-FPM çökmüş, Apache kilitlenmiş ya da bir Node.js süreci sessizce sonlanmıştır. Nginx'in iletişim kurabileceği hiçbir şey kalmamıştır.
Sunucu RAM'i tükeniyor. Bellek azaldığında Linux, çok fazla kaynak tüketen süreçleri otomatik olarak sonlandırabilir. Bu mekanizmaya OOM killer denir ve PHP-FPM ya da MySQL genellikle ilk kurbanlar arasındadır. Bu durum düzenli olarak yaşanıyorsa, emniyet önlemi olarak swap dosyası eklemeyi düşünün.
PHP-FPM worker havuzu dolmuş. Siteniz PHP-FPM'in karşılayabileceğinden daha fazla eş zamanlı istek alırsa yeni istekler kuyruğa girer ve sonunda zaman aşımına uğrar. Bu durum sıklıkla, arama motoru botları sitenizi çok agresif şekilde taradığında yaşanır — bununla nasıl başa çıkılacağını bot engelleme rehberimizde anlattık.
Yanlış yapılandırılmış socket veya port. Nginx, PHP-FPM'i belirli bir Unix soketi veya TCP portunda bulmayı bekler. Nginx yapılandırmasındaki yol, PHP-FPM yapılandırmasıyla eşleşmiyorsa herhangi bir değişiklikten hemen sonra 502 hatası alırsınız.
Nasıl teşhis edilir
Aşağıdaki adımları uygulamak için sunucunuza SSH üzerinden bağlanın. Bunu nasıl yapacağınızı SSH makalemizden öğrenebilirsiniz.
Adım 1. Backend'in çalışıp çalışmadığını kontrol edin
Backend servisinizin durumunu kontrol edin:
sudo systemctl status php8.2-fpm
php8.2-fpm yerine gerçek PHP sürümünüzü veya backend servis adınızı yazın. Çıktı inactive (dead) ya da failed gösteriyorsa sorun burada. Servisi yeniden başlatın:
sudo systemctl restart php8.2-fpm
Ardından başarıyla başlatıldığından emin olmak için durumu tekrar kontrol edin.
Adım 2. Nginx hata logunu kontrol edin
Hata logu neredeyse her zaman tam olarak neyin yanlış gittiğini söyler:
Ardından başarıyla başlatıldığından emin olmak için durumu tekrar kontrol edin.
Adım 2. Nginx hata logunu kontrol edin
Hata logu neredeyse her zaman tam olarak neyin yanlış gittiğini söyler:
sudo tail -30 /var/log/nginx/error.log
FASTPANEL® kullanıyorsanız logları doğrudan web arayüzünden de görüntüleyebilirsiniz: site kartını açın, «Logs» bölümüne gidin ve «Frontend Error Log» sekmesini kontrol edin.
En sık karşılaşılan hata mesajları ve anlamları:
connect() failed - Connection refused — backend servisi çalışmıyor. Adım 1'de gösterildiği gibi yeniden başlatın.
connect() failed - No such file or directory — Nginx, var olmayan bir Unix soketine ulaşmaya çalışıyor. Nginx yapılandırmanızdaki soket yolunun, PHP-FPM'in gerçekte oluşturduğu yolla eşleştiğini kontrol edin.
upstream sent too big header — backend, varsayılan arabellek için çok büyük HTTP başlıkları döndürdü. Nginx site yapılandırmanızdaki server bloğuna şu satırları ekleyin:
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
Düzenledikten sonra yapılandırmayı test edin ve Nginx'i yeniden yükleyin:
sudo nginx -t && sudo systemctl reload nginx
Adım 3. Sunucu kaynaklarını kontrol edin
free -h
Available sütunu 100–200 MB'dan az boş bellek gösteriyorsa sunucunuz muhtemelen RAM'i tükeniyordur. Neyin tükettiğini kontrol edin:
ps aux --sort=-%mem | head -10
Bellek yetersizliği temel nedense, en hızlı geçici çözüm swap dosyası eklemektir. Ancak diskteki swap, RAM'den çok daha yavaştır ve kalıcı bir çözüm olarak görülmemelidir. Sunucunuz düzenli olarak bellek tükeniyorsa, uygulamalarınızı optimize etme veya daha fazla RAM'e sahip bir plana geçme zamanı gelmiş demektir.
Sonuç
502 Bad Gateway neredeyse her zaman bir backend sorunudur — çökmüş bir servis, tükenmiş worker'lar veya yetersiz bellek. Backend durumunu kontrol edin, Nginx hata logunu okuyun ve kaynak kullanımınıza bakın. Büyük çoğunlukla cevabı birkaç dakika içinde bulursunuz.
Bununla tek başınıza uğraşmak istemiyorsanız, kodu.cloud'da her VPS ve dedicated sunucu ile birlikte ücretsiz 7/24 teknik destek sunuyoruz. Tüm müşterilerimiz ayrıca ek ücret ödemeden FASTPANEL® Extended alır; bu da log analizi ve servis yönetimini web arayüzü üzerinden çok daha kolay hale getirir.