Sunucu odasında yine acil durum sirenleri çalıyor… Karşımızda, Plesk kullanan webmasterların ve sistem yöneticilerinin en çok karşılaştığı, sitelerin bir anda dış dünyayla bağını koparan o meşhur ve soğuk hata var: 503 Service Temporarily Unavailable (Servis Geçici Olarak Devre Dışı).

Sitenize girersiniz veya Plesk panelin kendisine erişmeye çalışırsınız ama bu hatayla karşılaşırsınız. Bu durum genellikle sunucunun çöktüğü anlamına gelmez; sadece arkada çalışan PHP-FPM servislerinin nefesinin yetmediğini, IIS/Apache/Nginx ile PHP arasındaki köprünün çöktüğünü veya sunucu kaynaklarının (RAM/CPU) anlık olarak tükendiğini gösterir.

Gelin, Plesk paneldeki bu servis kilidini açacak ve siteleri dakikalar içinde yayına döndürecek kesin çözüm yöntemlerini adım adım inceleyelim.

Plesk Panel “Service Temporarily Unavailable” Hatası Çözümü

Bir sabah sitenizi kontrol etmek için tarayıcıyı açtınız ve gri ekranda o can sıkıcı başlığı gördünüz: HTTP Error 503. The service is temporarily unavailable. Bu hata yetmezmiş gibi, Plesk yönetim panelinize girmeye çalıştığınızda da aynı duvarla karşılaşıyorsunuz. Sunucuda bir şeyler ters gidiyor ama ne?

503 hatası, web sunucunuzun (Apache, Nginx veya IIS) isteğinizi aldığını ancak arka planda bu isteği işleyecek olan kod motoruyla (genellikle PHP-FPM) iletişim kuramadığını söyler. Yani ön büro açık ama mutfaktaki aşçılar grevde! Bu durum ya başıboş kalan bir PHP sürecinin sunucu RAM’ini bitirmesinden ya da Plesk’in kendi servislerinin kilitlenmesinden kaynaklanır.

Sakin oluyoruz, tüm verileriniz yerinde duruyor. Şimdi elinize SSH anahtarlarınızı alın; sunucunun tıkalı damarlarını açacak ve servisleri ayağa kaldıracak operasyonu sırasıyla başlatıyoruz.

1. Yöntem: Plesk Servislerini SSH Üzerinden Yeniden Başlatın

Eğer hata doğrudan Plesk panelin kendi arayüzüne girmeye çalışırken (:8443 portunda) karşınıza çıkıyorsa, Plesk’in arkasındaki yönetim motoru (sw-engine) kilitlenmiş demektir. Sitelere dokunmadan sadece paneli ayağa kaldırmak için sunucunuza SSH (root) üzerinden bağlanın ve şu komutları çalıştırın:

• Linux (Ubuntu/CentOS/AlmaLinux) Sunucular İçin:

sudo systemctl restart sw-engine
sudo systemctl restart sw-cp-server

sudo systemctl restart sw-engine
sudo systemctl restart sw-cp-server

Bu komutlar Plesk’in çekirdek işlem motorunu ve web sunucusunu güvenli bir şekilde kapatıp yeniden açar. Panele girmeyi deneyin, sorun büyük ihtimalle çözülmüştür.

2. Yöntem: PHP-FPM Havuzunu (Pool) Yeniden Başlatın ve Temizleyin

Eğer panel açık ama sadece belirli web siteleriniz 503 hatası veriyorsa, o sitelerin bağlı olduğu PHP işlem havuzu çökmüş veya kilitlenmiş demektir.

• Plesk Panel Arayüzünden Çözüm: Panelinize girin. Siteler ve Alan Adları (Websites & Domains) menüsünden hata veren siteyi bulun. Sağ taraftaki PHP Ayarları (PHP Settings) alanına tıklayın. Sayfanın üst kısmında veya servisler listesinde sitenin kullandığı PHP sürümünün (Örn: PHP 8.2) yanındaki Yeniden Başlat (Restart) butonuna basın.
• SSH Terminalinden Çözüm (Daha Kesin): Eğer panelden yanıt alamazsanız, terminale girip sitenizin kullandığı PHP sürümüne ait FPM servisine doğrudan reset atın:

# Örnek: PHP 8.2-FPM için
systemctl restart plesk-php82-fpm

# Örnek: PHP 8.2-FPM için
systemctl restart plesk-php82-fpm

3. Yöntem: Windows Sunucularda (IIS) Application Pool Kilidini Kırmak

Eğer Plesk panelinizi bir Windows Server üzerinde, yani IIS (Internet Information Services) altyapısıyla çalıştırıyorsanız, 503 hatasının sebebi %99 oranında Application Pool (Uygulama Havuzu) çökmesidir.

IIS, bir web sitesi aşırı kaynak tükettiğinde veya ardı ardına kod hataları (Fatal Error) ürettiğinde, sunucunun tamamı çökmesin diye o siteye ait uygulama havuzunu otomatik olarak devre dışı bırakır (Rapid-Fail Protection). Havuzun durumu “Stopped” (Durduruldu) moduna geçer.

• Çözüm: Plesk panelde alan adının ayarlarına gelin ve Dedicated IIS Application Pool menüsünü bulun. Buradan havuzun durumunu kontrol edin, eğer durdurulmuşsa Recycle (Yeniden Dönüştür) veya Start (Başlat) butonuna basarak havuzu canlandırın.

4. Yöntem: PHP-FPM max_children Limitlerini Optimize Edin

Servisleri yeniden başlattınız, siteniz açıldı ama 10 dakika sonra tekrar 503 hatasına mı düştü? O zaman geçici çözümler yetmiyor demektir; sunucunuzda yapısal bir kaynak dar boğazı var. PHP-FPM, gelen ziyaretçi isteklerini işlemek için alt süreçler (child process) açar. Varsayılan ayarlarda bu sınır çok düşük tutulur ve anlık bir trafik dalgalanmasında limit dolduğu an sonraki kullanıcılar 503 kapısına çarpıp geri döner.

1. Plesk panelinizde Araçlar ve Ayarlar (Tools & Settings) menüsüne gelin.
2. Genel Ayarlar altından PHP Ayarları (PHP Settings) bölümünü seçin.
3. Sitenizin kullandığı PHP sürümüne tıklayın ve üstteki Havuz Ayarları (Pool Settings) sekmesine geçin.
4. Burada bulunan pm.max_children değerini bulun. Varsayılan olarak 5 veya 10 gibi komik bir rakamdır. Sunucunuzun RAM boyutuna göre bu değeri 20, 40 veya 50 seviyelerine yükseltin.

# Örnek Güvenli Havuz Ayarları
pm = dynamic
pm.max_children = 40
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10

# Örnek Güvenli Havuz Ayarları
pm = dynamic
pm.max_children = 40
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10

Ayarları kaydedip PHP-FPM servisini yeniden başlattığınızda, siteniz anlık hit dalgalanmalarını hiçbir isteği reddetmeden, kuyruğa alarak başarıyla işleyecektir.

💡 Teknik İpucu (Expert Box)

Bunu biliyor muydunuz? Plesk sunucularda 503 hatasının en gizli ve sinsi sebeplerinden biri sunucudaki Disk Quota (Disk Kotası) sınırlarının dolmasıdır. Eğer bir cPanel yedek dosyası açtıysanız veya sitenizin logları abartı şiştiyse ve kullanıcının disk limiti %100 dolduysa, PHP geçici oturum (session) dosyası yazamaz. Yazamadığı an PHP-FPM havuzu anında çöker ve site 503 vermeye başlar. Sunucuda yer olmasına rağmen bu hatayı alıyorsanız, aboneliğin disk limitlerini genişletmek sorunu kökten çözecektir!

Sonuç: İletişim Hatlarını Açtınız, Sunucu Yayında!

Plesk’in “Service Temporarily Unavailable” hatası, webmasterların gözünü korkutan ama sunucu katmanları arasındaki hiyerarşiyi bildiğinizde terminal üzerinden birkaç komutla çözülebilecek yapısal bir durumdur. PHP-FPM havuzlarını periyodik olarak izlemek, max_children limitlerini sunucu donanımınıza göre optimize etmek ve IIS havuz korumalarını esnetmek bu hatayı sunucunuzdan kalıcı olarak uzak tutacaktır.

Sizin sunucunuzdaki bu servis krizini hangi adım ortadan kaldırdı? PHP-FPM resetlemesi mi yoksa IIS uygulama havuzu mu? Yorumlara yazın, sunucu loglarını ve performans metriklerini birlikte optimize edelim!