503 Service Unavailable Hatası Nedir, Nasıl Giderilir?

Siteniz sabah çalışıyordu, öğleden sonra beyaz bir sayfada "503 Service Unavailable" yazısı beliriverdi. Belki de sadece "Service Temporarily Unavailable" gördünüz, belki WordPress'in "Kısa süreliğine planlı bakım için kapalıyız" mesajını. Panik yapmadan önce bilmeniz gereken şu: 503 Service Unavailable hatası, sunucunun isteğinizi reddettiğini değil, o an karşılayamadığını söyler. Kapı kilitli değil, kapının arkasındaki adam meşgul. Bu ayrım kritik, çünkü 403 veya 404 gibi kalıcı bir yasak değil, geçici bir durum bildiriliyor — ve o "geçici" durumun üç tamamen farklı sebebi olabilir.

Türkçe kaynakların büyük kısmı bu noktada "sunucu meşgul, biraz sonra tekrar deneyin" deyip konuyu kapatıyor. Bir ziyaretçi için bu yeterli olabilir ama site sahibiyseniz hiçbir işinize yaramaz, çünkü "biraz sonra" hiç gelmeyebilir. Bu yazıda 503'ü üç ayrı sınıfa ayırıyoruz: WordPress'in silinmeyi unutmuş .maintenance dosyası, paylaşımlı hostingde CloudLinux LVE kaynak limitinin dolması ve web sunucusunun arkasındaki servisin (PHP-FPM, LiteSpeed, uygulama süreci) ölmesi. Üçünün çözümü birbirinden tamamen farklı; birini diğerinin reçetesiyle çözmeye çalışmak zaman kaybından ibaret. Hangi durumda olduğunuzu 2-3 dakikada kesinleştirecek bir teşhis akışıyla başlayacağız.

503 Service Unavailable Hatası Ne Anlama Geliyor#

503, HTTP protokolünde sunucu tarafı hata sınıfının (5xx) bir üyesidir ve tanımı gereği geçicidir. Sunucu şunu söyler: "İsteğini aldım, anladım, ama şu anda işleyemiyorum; sonra dene."

Bu tanımın iki pratik sonucu var:

1. Arama motorları 503'ü cezalandırmaz — kısa sürerse. Googlebot 503 aldığında sayfayı dizinden çıkarmaz, daha sonra tekrar gelir. Planlı bakım sırasında doğru davranış zaten 503 döndürmektir. Ama 503 günlerce sürerse Google sayfayı dizinden düşürmeye başlar.
2. Hata sizin kodunuzda olmayabilir. 500 Internal Server Error genelde uygulamanızın kendi hatasıdır; 503 çoğu zaman uygulamanın önündeki veya arkasındaki katmandan gelir.

Yanıtla birlikte gelen başlıklar da bilgi taşır. Bir Retry-After başlığı görüyorsanız, sunucu bilinçli olarak "şu kadar saniye sonra gel" diyordur — bu neredeyse her zaman planlı bakım veya hız sınırı demektir:

curl -sSI https://ornek-siteniz.com

HTTP/2 503
server: nginx
retry-after: 600
content-type: text/html; charset=UTF-8

Retry-After yoksa ve server başlığında Apache/LiteSpeed görüyorsanız, olay büyük ihtimalle kaynak limiti veya çöken bir alt servistir.

503'ün Üç Farklı Kaynağı ve Nasıl Ayırt Edilir#

Sahada gördüğüm 503'lerin neredeyse tamamı şu üç kutudan birine düşer. Doğru kutuyu seçmek, çözümün yarısıdır.

Ayrım için en hızlı test şudur: sitenizde bir statik dosyayı doğrudan çağırın.

curl -sSI https://ornek-siteniz.com/wp-includes/js/jquery/jquery.min.js

• Statik dosya 200 dönüyor ama PHP sayfaları 503 veriyorsa → sorun PHP katmanında (PHP-FPM, LVE PHP işlem limiti, .maintenance).
• Statik dosya da 503 dönüyorsa → web sunucusunun kendisi ya da onun önündeki proxy/yük dengeleyici devrede değil.

Bu tek komut, teşhis süresini genelde yarıya indirir.

Birinci İhtimal: WordPress'in .maintenance Dosyası#

WordPress bir eklenti, tema veya çekirdek güncellemesi başlattığında site kök dizinine .maintenance adında küçük bir PHP dosyası yazar. İçeriği tek satırdır:

<?php $upgrading = 1754899200; ?>

Güncelleme normal bittiğinde WordPress bu dosyayı siler. Ama güncelleme yarıda kalırsa — tarayıcı sekmesi kapandı, PHP zaman aşımına uğradı, bağlantı koptu — dosya orada kalır ve WordPress her istekte "ben bakımdayım" deyip 503 döndürür. Sitede gördüğünüz mesaj şudur:

Kısa süreliğine planlı bakım için kapalıyız. Bir dakika sonra tekrar kontrol edin.

Bu, tüm 503 senaryoları içinde en zararsız ve en hızlı çözüleni. Çözümü tek adım: dosyayı silin.

cPanel Dosya Yöneticisi ile:

1. cPanel → Dosya Yöneticisi'ni açın.
2. Sağ üstteki Ayarlar düğmesine basın, Gizli Dosyaları Göster (dotfiles) kutusunu işaretleyin. .maintenance nokta ile başladığı için varsayılan görünümde görünmez — insanların en çok takıldığı yer burasıdır.
3. public_html (veya alan adının kök dizini) içine girin.
4. .maintenance dosyasını seçip silin.
5. Siteyi yenileyin.

SSH ile:

cd ~/public_html
ls -la | grep maintenance
rm -f .maintenance

Dosyayı sildikten sonra site açılıyorsa iş bitmiştir — ama yarıda kalan güncellemeyi mutlaka tamamlayın. Yarım güncelleme, veritabanı şeması ile dosya sürümünün uyuşmadığı bir ara durum bırakabilir. WordPress yönetim paneline girip Kontrol Paneli → Güncellemeler ekranından işlemi tekrar başlatın. Bu senaryonun ayrıntısı ve tekrar yaşanmaması için alınacak önlemler wordpress maintenance dosyası hatası yazısında ayrıca ele alınıyor.

Dosyayı silmenize rağmen 503 devam ediyorsa, teşhis yanlıştı; ikinci ihtimale geçin.

İkinci İhtimal: Kaynak Limiti (CloudLinux LVE ve Entry Process)#

Paylaşımlı hostingde 503'ün açık ara en yaygın sebebi budur ve Türkçe içerikte neredeyse hiç anlatılmaz. Modern paylaşımlı sunucular CloudLinux üzerinde çalışır; CloudLinux her hesabı LVE (Lightweight Virtual Environment) adı verilen bir kafese kilitler. Bu kafesin dört ayrı sınırı vardır ve hangisinin dolduğu, alacağınız hata kodunu belirler:

Anahtar satır EP'dir. Entry Process limiti, "bu hesap aynı anda kaç PHP isteği işleyebilir" demektir. Tipik bir paylaşımlı pakette bu sayı tek haneli veya düşük çift hanelidir. Sitenize aynı anda gelen istek sayısı bu sınırı aştığında, fazla gelen istekler sıraya girmez — doğrudan 503 alır.

Bu, hatanın neden "aralıklı" göründüğünü de açıklar: siz test ettiğinizde site açılır, ziyaretçi yoğunluğu artınca 503 döner. Çoğu site sahibi bu yüzden sorunu "bazen oluyor, geçiyor" diye geçiştirir ve aylarca ziyaretçi kaybeder.

Nasıl doğrularsınız:

1. cPanel'e girin, arama kutusuna Kaynak Kullanımı (Resource Usage) yazın.
2. Geçmiş sekmesine geçin ve son 24 saate bakın.
3. Grafiklerde EP satırına odaklanın. Tepe noktalarının limit çizgisine değdiği zaman aralıklarını not edin.
4. Bu zamanlar, 503 aldığınız zamanlarla örtüşüyorsa teşhis kesindir.

CloudLinux ayrıca hesabın snapshot'ını tutar; "Bu hesap sınırına ulaştı" uyarısının altındaki detay bağlantısı, limitin dolduğu anda hangi PHP dosyasının çalıştığını gösterir. Bu, suçluyu bulmanın en hızlı yoludur. Kafes mantığının bütünü ve diğer limitlerin davranışı için cloudlinux nedir yazısına bakabilirsiniz. Limitin dolduğu anda 503 yerine açıkça "Resource Limit Is Reached" ekranı görüyorsanız o senaryo 508 resource limit is reached hatası yazısında ele alınıyor.

EP limiti dolduğunda yapılacaklar — sırayla:

1. Bot trafiğini kesin. Erişim loglarında en çok isteği kimin yaptığına bakın:

awk '{print $1}' ~/access-logs/ornek-siteniz.com | sort | uniq -c | sort -rn | head -20

Tek bir IP'den saniyede onlarca istek geliyorsa bu bir tarayıcı/kazıyıcı botudur, ziyaretçi değil. cPanel → IP Engelleyici ile engelleyin.

2. Sayfa önbelleği kurun. EP limitini dolduran şey PHP isteğidir. Önbellek eklentisi, aynı sayfayı her seferinde PHP çalıştırarak üretmek yerine hazır HTML olarak sunar ve eşzamanlı PHP isteği sayısını dramatik biçimde düşürür. Tek başına bu adım, çoğu 503 vakasını kapatır.
3. XML-RPC ve wp-cron'u kontrol edin. WordPress'te xmlrpc.php brute force botlarının favorisidir ve her isteği bir entry process yakar. Aynı şekilde varsayılan wp-cron, her ziyaretçi isteğinde tetiklenir. wp-config.php içine şu satırı ekleyip gerçek bir cron görevi tanımlamak yükü belirgin şekilde azaltır:

define('DISABLE_WP_CRON', true);

4. Yavaş sorguları düzeltin. Bir istek ne kadar uzun sürerse, entry process o kadar uzun süre işgal edilir. 40 istek/saniye kapasiteniz varsa ve her istek 2 saniye sürüyorsa, gerçekte 20 eşzamanlı ziyaretçiye bakabiliyorsunuz demektir.
5. Paketi büyütün ya da mimariyi değiştirin. Yukarıdakileri yaptıktan sonra hâlâ limite dayanıyorsanız, siteniz paylaşımlı paketin kapasitesini aşmış demektir. Bu bir başarısızlık değil, büyüme işaretidir.

Üçüncü İhtimal: Arkadaki Servisin Ölmesi#

Statik dosyalar da 503 dönüyorsa veya sunucunuz kendi VDS'inizse, olay muhtemelen bir upstream sorunudur: Nginx ayakta ama arkasındaki PHP-FPM, uygulama sunucusu veya reverse proxy hedefi cevap vermiyor.

Nginx bu durumda error log'a çok net bir satır yazar:

2026/08/11 14:22:09 [error] 1187#1187: *4412 connect() to unix:/run/php/php8.3-fpm.sock
failed (2: No such file or directory) while connecting to upstream,
client: 203.0.113.44, server: ornek-siteniz.com, request: "GET / HTTP/1.1"

No such file or directory mesajı, soket dosyasının olmadığını yani PHP-FPM'in çalışmadığını söyler. Doğrulayın ve başlatın:

systemctl status php8.3-fpm
systemctl start php8.3-fpm
journalctl -u php8.3-fpm -n 50 --no-pager

journalctl çıktısı neden öldüğünü söyler. En sık gördüğüm üç sebep:

• Yapılandırma hatası: configuration file ... syntax error — son düzenlemeniz hatalıdır, php-fpm -t ile doğrulayın.
• Bellek yetersizliği: Out of memory: Killed process ... (php-fpm) — çekirdeğin OOM killer'ı süreci öldürmüştür. free -h ile belleğe bakın, gerekiyorsa takas alanı tanımlayın.
• Havuz doygunluğu: server reached pm.max_children setting, consider raising it — süreç havuzu doldu. Bu, VDS'teki EP limiti karşılığıdır ve düzeltmesi php-fpm pool ayarları yazısında anlatılıyor.

Farklı bir upstream hata satırı da yaygındır:

upstream sent too big header while reading response header from upstream

Bu, PHP'nin gönderdiği yanıt başlıklarının Nginx tamponuna sığmadığı anlamına gelir; çözüm site bloğuna tampon boyutu eklemektir:

location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_buffer_size 32k;
    fastcgi_buffers 8 32k;
    fastcgi_busy_buffers_size 64k;
}

Node.js veya Python uygulaması çalıştırıyorsanız aynı mantık geçerlidir: Nginx ayakta, proxy_pass hedefindeki süreç ölü. pm2 list veya systemctl status uygulamaniz ile durumu görün.

Log Dosyalarından Doğru Satırı Okumak#

503'te en çok zaman kaybettiren şey, yanlış log dosyasına bakmaktır. Aşağıdaki eşleme, hangi katmanın hangi dosyaya yazdığını gösterir:

Canlı izleme, hatayı tekrarlatırken en verimli yöntemdir. İki terminal açın; birinde log'u takip edin, diğerinde siteyi çağırın:

tail -f /var/log/nginx/error.log

Paylaşımlı hostingde SSH yoksa cPanel'in Hata Günlükleri ekranı son satırları gösterir; bu ekranın nasıl okunacağı cpanel hata kayıtları yazısında ayrıntılı anlatılıyor.

503 Aldığınızda Sırayla Uygulanacak Teşhis Akışı#

Aşağıdaki sırayı bozmadan uygularsanız, çoğu 503 vakasını 10 dakikanın altında kapatırsınız.

1. Statik dosya testi yapın. curl -I ile bir CSS veya JS dosyası çağırın. 200 dönüyorsa PHP katmanına, 503 dönüyorsa web sunucusu/upstream katmanına odaklanın.
2. Kök dizinde .maintenance arayın. Gizli dosyaları göstermeyi unutmayın. Varsa silin, siteyi test edin.
3. Yanıt başlıklarına bakın. Retry-After varsa bilinçli bir bakım/hız sınırıdır; sağlayıcınızın bakım duyurusunu kontrol edin.
4. Kaynak kullanımı grafiğini açın. EP tepe noktaları hata saatleriyle örtüşüyorsa kaynak limiti tanısı kesindir.
5. Error log'un son 50 satırını okuyun. connect() to ... failed görüyorsanız upstream ölüdür; max_children uyarısı görüyorsanız havuz doludur.
6. Son değişikliği geri alın. Hata belirli bir eklenti kurulumu, tema güncellemesi veya deploy'dan sonra başladıysa, önce o değişikliği geri alın; sonra sebebi arayın. Üretim ortamında teşhis, geri almadan sonra gelir.
7. Sunucu genelini kontrol edin. Aynı sunucudaki diğer siteleriniz de 503 veriyorsa sorun sizin sitenizde değildir; sağlayıcıya bildirin.

503'ü Kalıcı Olarak Önlemek#

503 tekrar eden bir hatadır; bir kez sildiğiniz dosya veya yeniden başlattığınız servis, altta yatan sebep durduğu sürece geri gelir.

Önbellekleme en yüksek getirili tek önlemdir. Sayfa önbelleği, dinamik istek sayısını genelde büyük oranda düşürür ve hem EP hem max_children baskısını doğrudan azaltır. WordPress kullanıyorsanız bir sayfa önbelleği eklentisinin yanına nesne önbelleği eklemek veritabanı yükünü de indirir.

Trafik profilinizi tanıyın. Kaynak limitine dayanan sitelerin önemli bir kısmında suçlu ziyaretçi değil, kontrolsüz bot trafiğidir. robots.txt ile tarama hızını sınırlamak, kötü niyetli kazıyıcıları engellemek ve arama motoru dışındaki tarayıcılara sınır koymak sürdürülebilir bir kazançtır.

İzleme kurun. 503'ü ziyaretçiden öğrenmek, en pahalı öğrenme biçimidir. Basit bir kesinti izleyicisi hata başladığı anda size haber verir; kendi sunucunuzda çalıştırabileceğiniz açık kaynaklı seçenekler dakikalar içinde kurulur.

Planlı bakımda doğru davranın. Site güncellerken kasıtlı olarak 503 döndürmek doğru yaklaşımdır — ama Retry-After başlığı ile birlikte. Böylece Googlebot sayfayı dizinden düşürmez, tekrar gelir.

Büyümeyi kabul edin. Yukarıdaki optimizasyonların hepsini yaptıysanız ve hâlâ limitlere dayanıyorsanız, sorun yapılandırma değil kapasitedir. Paylaşımlı hostingden VDS'e geçiş, entry process kafesinden çıkıp süreç sayısını kendiniz belirlediğiniz bir ortama taşınmak demektir.

Sıkça Sorulan Sorular#

503 hatası benim sitemin sorunu mu yoksa hostingin sorunu mu#

İkisi de olabilir ve ayırmanın basit bir yolu vardır: aynı hosting hesabındaki başka bir siteyi veya alt alan adını açmayı deneyin. Onlar da 503 veriyorsa sorun sunucu genelindedir ve sağlayıcınıza bildirmeniz gerekir. Sadece bir siteniz 503 veriyorsa sebep o siteye özgüdür; kaynak limiti, .maintenance dosyası veya o siteye ait bir yapılandırma hatası ihtimallerini sırayla eleyin. Hosting sağlayıcınızın durum sayfası veya bakım duyurusu varsa ilk oraya bakmak birkaç dakika kazandırır.

503 hatası SEO'ma zarar verir mi#

Kısa süreli 503 SEO'ya zarar vermez, uzun süreli 503 verir. Google 503'ü "geçici" olarak yorumlar ve sayfayı dizinden hemen çıkarmaz; tarama sıklığını azaltıp daha sonra tekrar dener. Ancak hata günlerce sürerse Google sayfayı erişilemez kabul edip dizinden düşürmeye başlar. Bu yüzden planlı bakımlarda 503 döndürmek doğru davranıştır ama bakımın saatler değil dakikalar sürmesi gerekir; mümkünse Retry-After başlığı da ekleyin.

503 hatası ile 502 Bad Gateway arasındaki fark nedir#

503 sunucunun isteği kabul edemediğini, 502 ise araya giren sunucunun arkadaki sunucudan geçersiz bir yanıt aldığını söyler. Pratikte 503 çoğunlukla "arkadaki servise hiç ulaşılamadı veya kapasite doldu", 502 ise "ulaşıldı ama gelen cevap bozuktu" anlamına gelir. Nginx bir PHP-FPM soketine hiç bağlanamadığında genellikle 502 döndürür; kapasite sınırı veya bilinçli reddediş durumunda 503 üretilir. İkisi de aynı kök sebepten doğabildiği için teşhis akışları büyük ölçüde örtüşür.

WordPress bakım modundan nasıl çıkarım#

Site kök dizinindeki .maintenance dosyasını silmeniz yeterlidir. Bu dosya nokta ile başladığı için cPanel Dosya Yöneticisi'nde varsayılan olarak görünmez; Ayarlar menüsünden gizli dosyaları göstermeyi açmanız gerekir. Dosyayı sildikten sonra site hemen normale döner, ancak yarıda kalan güncellemeyi WordPress panelinden tekrar başlatmayı unutmayın. Aksi halde dosya sürümü ile veritabanı şeması uyumsuz kalabilir ve ilerleyen günlerde başka hatalar üretebilir.

Entry process limiti nedir ve neden 503 üretir#

Entry process limiti, hosting hesabınızın aynı anda çalıştırabileceği istek sayısının üst sınırıdır. Bu sınır dolduğunda gelen yeni istekler kuyruğa alınmaz, doğrudan 503 ile reddedilir. Sınırın dolmasının en yaygın sebepleri kontrolsüz bot trafiği, önbelleklenmemiş dinamik sayfalar ve uzun süren yavaş isteklerdir. Çözümde önce sayfa önbelleği kurup bot trafiğini kısmak, ardından hâlâ yetmiyorsa paket kapasitesini artırmak gerekir; limiti aşmadan çalışan bir site limitten hiç etkilenmez.

503 hatasını sunucuya erişimim olmadan çözebilir miyim#

Kısmen çözebilirsiniz. cPanel erişiminiz varsa .maintenance dosyasını silmek, kaynak kullanımı grafiğini okumak, IP engellemek ve önbellek eklentisi kurmak sunucu kabuğuna hiç girmeden yapılabilir. Ancak PHP-FPM'i yeniden başlatmak, havuz ayarlarını değiştirmek veya sunucu genelindeki bir servisi ayağa kaldırmak kök yetkisi ister; bu durumda hosting sağlayıcınıza log satırını da ekleyerek destek kaydı açmak en hızlı yoldur. Destek kaydında hatanın başladığı saati ve error log satırını paylaşmak çözüm süresini belirgin biçimde kısaltır.

503 hatası kendi kendine geçerse yine de bir şey yapmalı mıyım#

Evet, çünkü kendi kendine geçen 503 neredeyse her zaman kaynak limiti kaynaklıdır ve tekrar edecektir. Trafik yoğunluğu limiti aştığında hata çıkar, yoğunluk düşünce kaybolur; siz test ettiğinizde site açıldığı için sorun yokmuş gibi görünür. Bu arada 503 alan ziyaretçiler sitenizi terk etmiş olur. Kaynak kullanımı geçmişini açıp tepe noktalarına bakın; hata saatleriyle örtüşüyorsa önbellekleme ve bot filtresiyle kalıcı çözüm uygulayın.

Kapanış#

503 Service Unavailable, tek bir sebebi olan tek bir hata değil; "şu an olmaz" diyen üç farklı katmanın ortak sesidir. Sitenizin kök dizinindeki unutulmuş bir .maintenance dosyası 30 saniyede çözülür; entry process limiti önbellekleme ve bot filtresiyle günler değil saatler içinde kalıcı olarak kapanır; ölü bir PHP-FPM süreci ise log satırındaki tek bir mesajla teşhis edilir. Yanlış yapılan tek şey, üçünü ayırt etmeden rastgele çözüm denemektir. Statik dosya testi, .maintenance kontrolü, kaynak kullanımı grafiği ve error log'un son 50 satırı — bu dört adım, vakaların büyük çoğunluğunu doğru kutuya yerleştirir.

Kaynak limitine sürekli dayanıyorsanız sorun artık yapılandırmada değil kapasitededir. Trafiği büyümüş bir WordPress sitesi için önbellekleme ve kaynak ayarları hazır gelen WordPress hosting paketleri bu baskıyı belirgin biçimde azaltır; entry process kafesinden tamamen çıkıp PHP-FPM havuzunu, bellek limitlerini ve süreç sayısını kendiniz belirlemek istiyorsanız VDS sunucu tarafına geçmek doğru adımdır. Sunucuyu kendiniz yönetmek istemiyor ama paylaşımlı hostingin sınırlarına da sığmıyorsanız sunucu yönetimi hizmeti servis izleme, güncelleme ve müdahale işini üstlenir; hangi kapasitenin size uyduğuna karar verirken kendi kaynak kullanımı grafiğinizdeki tepe değerlerini ölçüt alın.