503 Service Unavailable Hatası: Nedenleri ve Çözümü

503 ne anlama gelir?

MDN iki temel durumu öne çıkarır. Birincisi bakım: yöneticiler bakım sırasında tüm trafiği geçici olarak bir 503 sayfasına yönlendirebilir ya da bu, yazılım güncellemeleri sırasında otomatik olarak olabilir. İkincisi aşırı yük: bazı sunucu uygulamaları bellek, işlemci veya bağlantı havuzu gibi sınırlara ulaşıldığında yeni istekleri 503 ile reddeder; bu, kaynakların tamamen tükenip daha ciddi bir çöküş yaşanmasını önler.

MDN önemli bir ayrımı da yapar: belirli istemcilerden gelen istekler hız sınırı (rate limiting) nedeniyle kısıtlanıyorsa doğru kod 503 değil 429 Too Many Requests'tir. RFC 9110 ise sunucunun aşırı yüklendiğinde 503 kullanmak zorunda olmadığını not eder; bu yüzden aynı aşırı yük bazı kurulumlarda 502, 504 ya da 500 olarak da görünebilir. Bu kodlar için 502 ve 504 gateway hataları ve 500 Internal Server Error yazılarına bakabilirsiniz.

Retry-After başlığı

RFC 9110'a göre sunucu 503 yanıtıyla birlikte istemcinin ne kadar beklemesi gerektiğini önermek için Retry-After başlığı gönderebilir. 503 ile gönderildiğinde bu başlık hizmetin ne kadar süre kullanılamayacağının beklendiğini belirtir. Değer iki biçimde yazılabilir: bir HTTP tarihi ya da saniye cinsinden bekleme süresi.

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

İkinci örnekte bekleme süresi 2 dakikadır. MDN, 503 geçici bir durumu anlattığı için bu yanıtların genellikle önbelleğe alınmaması gerektiğini de vurgular; aksi halde sorun giderildikten sonra bile bazı ziyaretçiler eski hata sayfasını görebilir. Önbellek mantığı için önbellek nedir yazımıza bakabilirsiniz.

503 ve Google: bakım sırasında doğru kod

Google Search Central'ın siteyi geçici olarak durdurma rehberine göre siteyi tamamen 503 ile kapatmak yalnızca çok kısa bir süre, en fazla birkaç gün için yapılmalıdır. Acil ve 1-2 gün süren bir kesinti için bilgilendirici bir hata sayfasıyla 503 döndürmek önerilir; daha uzun kapanışlarda ise 200 döndüren bir bilgi sayfası tercih edilir. Google ayrıca 503 süresince başlık, açıklama ve yapılandırılmış verileri güncelleyemeyeceğini belirtir.

Google'ın HTTP durum kodları belgesine göre 500, 502 ve 503 hataları tarama hızını düşürür ve sürekli sunucu hatası döndüren URL'ler zamanla dizinden çıkarılır. Yani kısa ve doğru işaretlenmiş bir 503 bakım için doğru tercihtir; haftalarca süren bir 503 ise zararlıdır.

Ziyaretçiyseniz: kısa kontroller

• Birkaç dakika bekleyip sayfayı yenileyin. 503 tanımı gereği geçicidir; bakım veya anlık yoğunluk çoğu zaman kısa sürer.
• Sayfada bir bakım mesajı veya tahmini süre yazıyorsa o süre dolana kadar bekleyin.
• Başka bir cihazdan veya bağlantıdan deneyin. Hata herkeste sürüyorsa sorun sitededir.
• Hata saatlerce sürüyorsa site sahibine veya sitenin sosyal medya hesaplarına haber verin.

Site sahibiyseniz: yaygın nedenler

1. WordPress'te takılı kalan bakım modu (.maintenance)

WordPress belgelerine göre WordPress güncelleme yaparken kök klasöre otomatik olarak bir .maintenance dosyası koyar ve ziyaretçiler "Briefly unavailable for scheduled maintenance. Check back in a minute." mesajını görür. WordPress kaynak kodundaki wp_maintenance() fonksiyonu bu sırada 503 durum kodu ve Retry-After: 600 başlığı gönderir. Yani WordPress doğru davranır: bakım sırasında 503 verir.

Sorun, güncelleme yarıda kesildiğinde dosyanın silinmemesidir. WordPress belgelerindeki çözüm basittir: FTP veya cPanel Dosya Yöneticisi ile site kök klasörüne girin, gizli dosyaları gösterin ve .maintenance dosyasını silin. wp_is_maintenance_mode() fonksiyonunun kaynak koduna göre dosyanın içindeki $upgrading zaman damgası 10 dakikadan eskiyse WordPress bakım modunu kendiliğinden bitmiş sayar; ancak siz yine de dosyayı silip yarım kalan güncellemeyi panelden tamamlamalısınız.

2. PHP-FPM havuzunun dolması

PHP-FPM kullanan sunucularda aynı anda işlenebilecek PHP isteği sayısı sınırlıdır. PHP kılavuzuna göre pm.max_children, static modda oluşturulan alt süreç sayısını, dynamic ve ondemand modlarında ise en fazla süreç sayısını belirler ve aynı anda sunulacak istek sayısının sınırıdır. Tüm süreçler meşgulken gelen yeni istekler bekler; bekleme uzarsa web sunucusu kuruluma göre 503, 502 veya 504 döndürebilir.

Çözüm sınırı körü körüne yükseltmek değildir; her süreç bellek tüketir. Önce süreçleri meşgul eden yavaş betikleri bulun. PHP kılavuzundaki request_slowlog_timeout ve slowlog ayarları, belirli bir süreyi aşan isteklerin PHP yığın izini (backtrace) bir günlük dosyasına yazar:

; PHP-FPM havuz dosyası (yol dağıtıma göre değişir) - önce yedek alın
pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 8

; 5 saniyeden uzun süren isteklerin yığın izini kaydet
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/$pool.slow

Buradaki sayılar yalnızca örnektir; doğru değer sunucunuzun belleğine ve sitenizin süreç başına tükettiği belleğe bağlıdır. Ayrıntılı hesaplama için PHP-FPM yapılandırma yazımıza, servis yönetimi için systemd servis yönetimi yazısına bakın.

3. Paylaşımlı hostingde kaynak sınırları

CloudLinux kullanan paylaşımlı sunucularda her hesabın eş zamanlı giriş süreci (entry processes), toplam süreç ve bellek sınırları vardır. LiteSpeed belgelerine göre eş zamanlı bağlantı sınırına ulaşıldığında CloudLinux'un ürettiği 508 Resource Limit Reached hatası görülür; süreç sayısı (NPROC) sınırına ulaşıldığında ise LiteSpeed 500 veya 503 döndürebilir. Bu durumda en etkili çözüm, sayfa önbelleği ile PHP'ye giden istek sayısını azaltmaktır. LiteSpeed sunucularda bunun için LiteSpeed Cache rehberine bakabilirsiniz. Site genel olarak yavaşsa web sitesi yavaş açılıyor yazısı da yardımcı olur.

4. LiteSpeed'de PHP çökmeleri

LiteSpeed belgeleri, LiteSpeed üzerindeki 503 hatalarının çoğunlukla web sunucusundan değil PHP'deki bir arızadan kaynaklandığını ve PHP çökmesinin yaygın bir neden olduğunu belirtir. Belgede sayılan olası nedenler arasında OPcache gibi önbellek eklentileri, eski veya sorunlu PHP uzantıları, özellikle /tmp bölümünün dolması, bellek sınırları, çok düşük çalışma süresi sınırı ve güvenlik yazılımlarının lsphp süreçlerini sonlandırması vardır.

Önerilen günlük sırası şöyledir: önce betiğin bulunduğu klasördeki PHP hata günlüğü, sonra /usr/local/lsws/logs/ dizinindeki web sunucusu hata günlüğü, ardından aynı dizindeki ve PHP kaynaklı 503'ler için en yararlı günlük olarak anılan stderr.log, en son da /var/log/messages veya /var/log/syslog. Disk durumunu df -h ile kontrol edebilirsiniz; dolu disk için disk doldu hatası yazımıza bakın.

5. DDoS ve kötü niyetli bot trafiği

Ani ve olağandışı trafik, sunucu kaynaklarını tüketerek meşru ziyaretçilerin de 503 almasına neden olabilir. Erişim günlüğünde aynı IP'lerden veya aynı adrese yoğun istek görüyorsanız bu bir saldırı ya da agresif bir tarayıcı olabilir. Korunma yöntemleri için DDoS koruma rehberi yazımızı okuyun. Belirli istemcileri hız sınırıyla kısıtlıyorsanız, MDN'nin önerdiği gibi bu istemcilere 429 döndürmek daha doğrudur.

Doğru bir 503 bakım sayfası nasıl sunulur?

Bakıma alacağınız sitede ziyaretçiye 200 koduyla "bakımdayız" yazmak, arama motoruna bu metnin sitenin gerçek içeriği olduğunu söyler. Kısa bakımlarda doğru yöntem, ziyaretçiye anlaşılır bir sayfa gösterirken HTTP durum kodunu 503 yapmak ve Retry-After eklemektir. MDN de 503 ile birlikte sorunu açıklayan kullanıcı dostu bir sayfa gönderilmesini önerir.

Apache ve LiteSpeed (.htaccess)

Apache'nin RewriteRule belgesine göre R bayrağına 300-399 aralığı dışında bir kod verildiğinde yerine konacak adres tamamen yok sayılır, yeniden yazma L kullanılmış gibi durur ve sunucu belirtilen kodu normal hata yanıtı yolundan, tanımlı bir ErrorDocument varsa onunla birlikte döndürür. mod_headers belgesine göre hata yanıtlarına başlık eklemek için always koşulu gerekir. Bu bilgilerle şöyle bir bakım kuralı yazılabilir:

# .htaccess - önce yedek alın, en üste ekleyin
ErrorDocument 503 /bakim.html

RewriteEngine On
# Kendi IP adresiniz siteyi normal görsün
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
# Bakım sayfası ve robots.txt istisna
RewriteCond %{REQUEST_URI} !^/bakim\.html$
RewriteCond %{REQUEST_URI} !^/robots\.txt$
RewriteRule ^ - [R=503,L]

# Yalnızca 503 yanıtlarına Retry-After (saniye) ekle
Header always set Retry-After "3600" "expr=%{REQUEST_STATUS} == 503"

203.0.113.10 yerine kendi IP adresinizi yazın. Header satırı mod_headers modülünün yüklü olmasını gerektirir; .htaccess içinde ErrorDocument kullanımı da sunucunun izin verdiği AllowOverride ayarına bağlıdır. LiteSpeed bu kuralların çoğunu okur, ancak davranışı kendi sunucunuzda test edin. Bakım bitince bu bloğu kaldırmayı unutmayın. Yazım ayrıntıları için Apache .htaccess yönlendirme rehberi yazımıza bakabilirsiniz.

Nginx

Nginx'te error_page yönergesi belirli hata kodları için gösterilecek sayfayı tanımlar; internal yönergesi ise bir location'ın yalnızca iç isteklerle kullanılmasını sağlar. Nginx belgelerine göre add_header varsayılan olarak yalnızca 200, 201, 204, 206, 301, 302, 303, 304, 307 ve 308 yanıtlarına eklenir; 503 yanıtına başlık eklemek için always parametresi gerekir.

server {
    # ... mevcut ayarlarınız ...

    error_page 503 /bakim.html;

    location = /bakim.html {
        root /var/www/bakim;
        internal;
        add_header Retry-After 3600 always;
    }

    location = /robots.txt {
        # robots.txt için 503 dönmeyin
    }

    location / {
        # Bu dosya varsa site bakım modundadır
        if (-f /var/www/bakim/aktif) {
            return 503;
        }
        # ... mevcut ayarlarınız ...
    }
}

Bakımı başlatmak için /var/www/bakim/aktif dosyasını oluşturmanız, bitirmek için silmeniz yeterlidir; yapılandırmayı yeniden yüklemeniz gerekmez. Yapılandırmanın kendisini değiştirdikten sonra ise nginx -s reload ile yeniden yükleyin. Genel yapı için Nginx yapılandırma rehberi yazımıza bakın.

WordPress

WordPress'in wp_maintenance() fonksiyonuna göre wp-content klasöründe maintenance.php adlı bir dosya varsa, bakım sırasında varsayılan mesaj yerine bu dosya yüklenir. Bu dosya varsayılan 503 ve Retry-After çıktısının yerine geçtiği için, kendi dosyanızda bu başlıkları PHP ile kendiniz göndermelisiniz:

<?php
// wp-content/maintenance.php
http_response_code( 503 );
header( 'Retry-After: 600' );
?>
<!doctype html>
<html lang="tr">
<head><meta charset="utf-8"><title>Bakımdayız</title></head>
<body><h1>Kısa bir bakım yapıyoruz</h1><p>Lütfen birkaç dakika sonra tekrar deneyin.</p></body>
</html>

Sık Sorulan Sorular

503 hatası ne kadar sürer?

Bu tamamen nedene bağlıdır. WordPress güncellemesi gibi planlı işler genellikle birkaç dakika sürer. Kaynak sınırı veya PHP-FPM havuzu nedeniyle oluşan 503'ler trafik düşünce kaybolabilir ama tekrar eder; kalıcı çözüm nedeni gidermektir.

Bakım sırasında 503 kullanmak SEO'ya zarar verir mi?

Kısa süreli kullanımda hayır; Google bunu geçici kesintiler için önerir. Ancak Google'ın rehberine göre tam site 503'ü en fazla birkaç gün sürmelidir ve robots.txt için 503 döndürülmemelidir.

"Briefly unavailable for scheduled maintenance" mesajı gitmiyor, ne yapmalıyım?

Site kök klasöründeki .maintenance dosyasını silin. Dosya Yöneticisi'nde nokta ile başlayan gizli dosyaları göstermeniz gerekebilir. Ardından yarım kalan güncellemeleri panelden tamamlayın.

503 ile 429 arasındaki fark nedir?

503 sunucunun genel olarak hizmet veremediğini anlatır. 429 ise belirli bir istemcinin çok fazla istek gönderdiği için sınırlandığını belirtir. MDN'ye göre hız sınırlamasında doğru kod 429'dur.

Yazılım, tarayıcı ve hizmet adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen şirketlerle ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: 500 Internal Server Error · 502 ve 504 hataları · 403 Forbidden · PHP-FPM yapılandırma · DDoS koruma rehberi · WordPress kritik hata