Son gözden geçirme: Eylül 2026 · Ubuntu 24.04, AlmaLinux 9 ve Plesk Obsidian resmî dokümanına göre
Hızlı çözüm
502 Bad Gateway hatası ziyaretçi olarak siteye girmeye çalışırken görünür; site sahibiyseniz Plesk 502 Bad Gateway hatası çoğunlukla nginx’in arkasındaki PHP-FPM havuzunun çökmesinden ya da yanıt vermemesinden kaynaklanır ve PHP-FPM servisini yeniden başlatmak çoğu durumda yeterlidir.
systemctl status plesk-php81-fpm ile ilgili PHP-FPM servisinin durumunu kontrol edin.systemctl restart plesk-php81-fpm ile yeniden başlatın.| Panel | Plesk |
|---|---|
| Sistem | Ubuntu 22.04/24.04, AlmaLinux 8/9 (VPS, VDS) |
| Yetki | root / sudo, SSH erişimi |
| Narhost ürünü | VPS Sunucu |
Başlamadan önce
Ziyaretçi tarayıcısında 502 Bad Gateway gördüğünde bu, sunucudaki nginx’in arka planda isteği PHP-FPM’e ilettiği ama PHP-FPM’den zamanında ya da hiç yanıt alamadığı anlamına gelir; hata sitenizin koduyla değil, sunucudaki iki servis arasındaki iletişimle ilgilidir. Site sahibi olarak en sık üç nedenle karşılaşırsınız: PHP-FPM havuzu bellek limitine takılıp çökmüş olabilir, bir istek tanımlı zaman aşımı süresini aşmış olabilir ya da nginx veya PHP-FPM servisi hiç çalışmıyor olabilir.
Önce hangi servisin durduğunu bulun: systemctl status nginx ve systemctl status plesk-php81-fpm (PHP sürümünüze göre servis adı değişir, Plesk’in PHP işleyici dokümantasyonuna göreTools & Settings → PHP Ayarları altında görünür) komutlarıyla her iki servisin de “active (running)” durumda olup olmadığına bakın. Servisler çalışıyorsa hata günlüklerine geçin: /var/log/nginx/error.log dosyasında “upstream” ya da “connection refused” satırları PHP-FPM ile iletişim koptuğunu gösterir, /var/log/plesk-php81-fpm/error.log altındaki günlükler ise PHP-FPM’in kendi çökme ya da zaman aşımı kayıtlarını tutar.
systemctl status plesk-php81-fpmBeklenen sonuç: servis “failed” ya da “inactive” görünüyorsa 502’nin kaynağı budur.
systemctl restart plesk-php81-fpmsystemctl restart nginxBeklenen sonuç: her iki komut da çıktı vermeden tamamlanır, servisler “active (running)” durumuna döner.
pm.max_children değerini sunucudaki boş belleğe göre düşürün ya da yükseltin. Değer çok yüksekse bellek tükenip PHP-FPM çöker, çok düşükse eşzamanlı istekler kuyrukta bekleyip zaman aşımına uğrar.
Beklenen sonuç: ayar kaydedildikten sonra PHP-FPM otomatik olarak yeniden başlar.
max_execution_time değerini ve nginx’in proxy_read_timeout yönergesini birlikte artırın.
Beklenen sonuç: uzun süren istekler 502 yerine normal şekilde tamamlanır.
Dikkat
PHP-FPM ve nginx servislerini yeniden başlatmak sunucudaki tüm sitelerde birkaç saniyelik kısa bir kesintiye yol açar; yoğun trafikli bir siteyse işlemi düşük trafikli bir saatte yapın.
Sonuç
Etkilenen alan adını tarayıcıda yeniden açıp sayfanın normal yüklendiğini görün; systemctl status plesk-php81-fpm ve systemctl status nginx çıktılarının ikisinin de “active (running)” göstermesi ve /var/log/nginx/error.log dosyasına yeni “upstream” hatası düşmemesi işlemin kalıcı olduğunu doğrular.
Narhost desteği
Talebe şunları ekleyin: alan adı, hatanın çıktığı saat, denediğiniz servis yeniden başlatma adımları ve varsa /var/log/nginx/error.log çıktısı.
Sonraki adımlar
502’de nginx, PHP-FPM’den hiç yanıt alamaz ya da bağlantı reddedilir (servis çökmüş/durmuş); 504’te PHP-FPM çalışır ama yanıtı tanımlı süre içinde tamamlayamaz. İkisi de aynı zaman aşımı ve kaynak ayarlarıyla ilişkilidir.
systemctl list-units --type=service | grep php komutuyla sunucudaki PHP-FPM servislerini listeleyebilir ya da Plesk panelinde Tools & Settings → PHP Ayarları altında aboneliğinize atanmış PHP sürümünü görebilirsiniz.
Hayır; systemctl restart yalnızca ilgili servisi durdurup tekrar başlatır, veritabanı ya da dosyalara dokunmaz. Yeniden başlatma sırasında yalnızca birkaç saniyelik erişim kesintisi olur.
Bu makale sorununuzu çözdü mü?
Geri bildiriminiz için teşekkürler.
Çözemediniz mi?
Teknik ekibimiz sunucu tarafındaki ayarları sizin için kontrol edebilir. Destek talebinizde alan adınızı ve aldığınız hata metnini paylaşmanız süreci hızlandırır.
