503 Service Unavailable Ne Demek? Nedenleri ve Çözümü

HTTP 503 Hatası Nedir?

503 Service Unavailable, sunucunun ya da önündeki bir katmanın isteğinizi şu an karşılayamadığı anlamına gelir: aşırı yüklenmiş, bakımda, istekleri sınırlıyor ya da isteği iletebileceği sağlıklı bir arka uç yok. RFC 9110 bunu, bir süre sonra büyük olasılıkla ortadan kalkacak geçici bir durum olarak tanımlar.

Sunucu, ne kadar beklemeniz gerektiğini bildiren bir Retry-After başlığı ekleyebilir. Bir şeyin bozulduğunu gösteren 500 hatasından farklı olarak 503 "şimdi değil" der; siteler planlı bakım için bu yüzden onu kullanır.

Yanıtı çoğu zaman web sunucunuz değil, önündeki bir katman verir: HAProxy gibi bir yük dengeleyici, Varnish gibi bir önbellek, Cloudflare gibi bir CDN ya da bir Kubernetes ingress. Mesajın tam ifadesi hangisi olduğunu gösterir (aşağıya bakın).

503 Hatası Nasıl Görünür

Mesaj, yanıtı hangi katmanın verdiğini gösterir. En yaygın olanlar ve onları üreten yazılımlar:

İfade ne olursa olsun anlam aynıdır: bu istek şu an karşılanamıyor ve bakılacak yer tabloda adı geçen katmandır.

HTTP 503 Hatasının Yaygın Nedenleri

Bir sunucunun ya da önündeki bir katmanın 503 döndürmesinin olağan nedenleri:

• Aşırı yük — trafik artışı, viral bir yazı veya agresif bir tarayıcı sırasında CPU, bellek ya da bağlantı sınırlarına ulaşılması
• Planlı bakım — site bir güncelleme veya taşıma için bilerek kapatılmıştır; doğru yapılırsa Retry-After başlığıyla
• Sağlıklı arka uç yok — yük dengeleyicinin, proxy'nin veya ingress'in isteği gönderebileceği çalışan bir sunucu yoktur (çöken uygulama, başarısız sağlık denetimleri, hazır pod olmaması)
• İstek ve bağlantı sınırları — nginx'in limit_req ve limit_conn ayarları varsayılan olarak 503 döndürür; yoğun bir istemci ya da tarayıcı bunu tetikleyebilir
• Çöken veya durdurulan uygulama — çalışan bir web sunucusunun arkasında PHP-FPM, Node.js veya Python'un kapalı olması; IIS'te durdurulmuş bir uygulama havuzu
• Barındırma kaynak sınırları — paylaşımlı barındırma, hesap başına CPU, bellek ve işlem sayısını sınırlar
• Eklenti, tema veya güncelleme — WordPress ve diğer CMS'lerde hatalı bir güncelleme uygulamayı çökertebilir ya da siteyi bakım modunda takılı bırakabilir
• Saldırı — bir DDoS veya bot seli, trafik artışıyla aynı kaynakları tüketir

Ziyaretçiler İçin Çözüm: Neler Yapabilirsiniz

Başkasının sitesini ziyaret ediyorsanız sorun onların tarafındadır. Yapabilecekleriniz:

• Bekleyip yeniden deneyin — 503 geçici olması için tasarlanmıştır; bir dakika bekleyip bir kez yenileyin. Sayfa bir Retry-After süresi ya da bakım mesajı gösteriyorsa o kadar bekleyin
• Herkes için mi kapalı, kontrol edin — DNS Robot'un Site Çöktü mü Kontrolü siteyi ağınızın dışından test eder
• Sitenin durum sayfasına veya sosyal medya hesaplarına bakın — planlı bakımlar ve kesintiler genellikle duyurulur
• Başka bir ağ deneyin — site mobil veriyle açılıyorsa, ya olağan ağınızdaki bir VPN veya proxy 503'ü veriyordur ya da site IP adresinizi sınırlıyordur

Çözüm 1: 503'ü Hangi Katmanın Gönderdiğini Bulun

Herhangi bir şeyi yeniden başlatmadan önce mesaja ve yanıt başlıklarına bakın: yanıtı hangi katmanın verdiğini gösterirler. Dışarıdan DNS Robot'un HTTP Başlık Kontrolü ile veya curl -sI ile kontrol edin; server başlığına ve yanıt gövdesine bakın (yukarıdaki tabloya bakın).

Ardından yalnızca web sunucusunu değil, sorunlu katmanı yeniden başlatın:

# Restart Nginx
sudo systemctl restart nginx

# Restart Apache
sudo systemctl restart apache2      # Debian/Ubuntu
sudo systemctl restart httpd         # CentOS/RHEL

# Restart PHP-FPM
sudo systemctl restart php8.2-fpm    # Adjust version as needed

# Restart Node.js (PM2)
pm2 restart all

# Restart entire server (last resort)
sudo reboot

503, yeniden başlatmadan dakikalar sonra geri dönüyorsa neden hâlâ yerindedir: kaynaklara ve günlüklere geçin.

Çözüm 2: Sunucu Kaynaklarını Kontrol Edin (CPU, RAM, Disk)

Sunucu aşırı yüklenmişse, yeniden başlatmak yalnızca geçici rahatlama sağlar. Kaynakları neyin tükettiğini kontrol edin.

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space
df -h

# Check memory in detail
free -m

# Check active connections
ss -s

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

CPU veya RAM %90 ve üzerindeyse uygulamanızı optimize etmeniz, kontrolsüz süreçleri sonlandırmanız veya sunucunuzu yükseltmeniz gerekir. Disk alanı doluysa günlük dosyalarını, eski yedekleri veya geçici dosyaları temizleyin.

Çözüm 3: Hata Günlüklerini Kontrol Edin

Günlükler 503'ün tam olarak neden oluştuğunu söyler. Son satırları aşağıdaki komutlarla okuyun, sonra içlerinde şunları arayın:

# Nginx error log
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log      # Debian/Ubuntu
tail -50 /var/log/httpd/error_log         # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.2-fpm.log

# WordPress debug log (if WP_DEBUG_LOG is enabled)
tail -50 /var/www/html/wp-content/debug.log

# System log
tail -50 /var/log/syslog

"limiting requests" veya "limiting connections" (nginx) — limit_req ya da limit_conn isteği reddetti; limit_req_status veya limit_conn_status ayarlamadıkça 503 döndürür.

"max_children" (PHP-FPM, ör. "server reached pm.max_children setting") — tüm PHP işçileri meşgul: Apache 503 döndürür, nginx ise 502 ya da 504.

"AH01114" / "failed to make connection to backend" (Apache mod_proxy) — Apache arka uca ulaşamadı ve 503 döndürdü.

"Too many connections" (MySQL) — veritabanı bağlantı sınırı tükendi.

nginx'in "no live upstreams" ve "upstream timed out" mesajları 503'e değil, 502 Bad Gateway ve 504 Gateway Timeout hatalarına aittir.

Çözüm 4: Eklentileri ve Temaları Devre Dışı Bırakın (WordPress / CMS)

WordPress ve diğer CMS'lerde ağır bir eklenti PHP işçilerini ya da barındırma sağlayıcınızın kaynak sınırlarını tüketebilir ve 503'e yol açar (çöken bir eklenti ise bunun yerine 500 verir). 503 bir eklenti güncellemesinden veya kurulumundan sonra başladıysa o eklentiyle başlayın.

WordPress yönetim paneline erişemiyorsanız eklentileri dosya sistemi veya veritabanı üzerinden devre dışı bırakın.

# Disable all plugins by renaming the plugins folder
cd /var/www/html/wp-content
mv plugins plugins_disabled

# If the site loads, rename it back and re-enable plugins one by one
mv plugins_disabled plugins

# To disable a single plugin
mv plugins/problem-plugin plugins/problem-plugin.disabled

Hatalı eklentiyi bulduktan sonra onu güncelleyin, bir alternatifle değiştirin ya da eklenti geliştiricisiyle iletişime geçin. PHP sürümünüzün uyumlu olup olmadığını da kontrol edin: sunucu PHP'yi yükselttiğinde bazı eklentiler bozulur.

"Briefly unavailable for scheduled maintenance" ekranında mı takıldınız? WordPress güncellemeler sırasında sitenin kök dizininde bir .maintenance dosyası oluşturur ve 10 dakikadan eski olduğunda yok sayar. Daha çabuk dönmek için silin; mesaj kalıyorsa wp-content/maintenance.php dosyasına ya da sayfanın önbelleğe alınmış bir kopyasına bakın.

Çözüm 5: PHP ve Sunucu Sınırlarını Artırın

Sunucunuzda PHP işçileri tükeniyorsa veya bellek sınırlarına ulaşıyorsa, yapılandırmadaki sınırları artırmanız gerekir.

; PHP-FPM pool (e.g. /etc/php/8.2/fpm/pool.d/www.conf); the default ships with pm.max_children = 5
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

; php.ini (defaults: memory_limit = 128M, max_execution_time = 30)
memory_limit = 256M
max_execution_time = 300

Yeni sınırların yüklenmesi için ardından PHP-FPM'i yeniden başlatın (sudo systemctl restart php8.2-fpm, kendi sürümünüzle).

Çözüm 6: CDN'inizi veya Yük Dengeleyicinizi Kontrol Edin

Cloudflare, başka bir CDN ya da yük dengeleyici kullanıyorsanız 503 sunucunuzdan değil, onlardan gelebilir.

Cloudflare'in kuralı (503 rehberi):

• Sayfada "cloudflare" veya "cloudflare-nginx" geçiyor — sayfayı Cloudflare üretti: CPU ya da bellek sınırlarını aşan bir Worker olup olmadığına bakın, sonra /cdn-cgi/trace çıktısıyla Cloudflare desteğiyle iletişime geçin
• Cloudflare işareti yok — 503'ü kaynak sunucunuz döndürdü ve Cloudflare iletti: kaynak sunucunun günlüklerine bakın ve barındırma sağlayıcınıza Cloudflare'in IP adreslerini sınırlayıp sınırlamadığını sorun

HAProxy, bulut yük dengeleyici veya Kubernetes ingress için arka uçları kontrol edin: orada 503 genellikle hiçbir arka ucun isteği alamadığı anlamına gelir (AWS Application Load Balancer'da hedef grubunda kayıtlı hedef olmaması). DNS Robot'un DNS Sorgulama aracı alan adınızın hâlâ beklediğiniz yeri gösterdiğini doğrular.

Çözüm 7: DDoS veya Bot Saldırılarını Kontrol Edin

Botlardan gelen ani bir trafik artışı veya bir DDoS saldırısı sunucunuzu alt edebilir. Erişim günlüklerinizi şüpheli kalıplar açısından kontrol edin.

# Count requests per IP in the last 1000 lines
tail -1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Requests per minute (use -f1-4 for per second)
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-3 | uniq -c | sort -rn | head -10

# Block an abusive IP (-I puts the rule first, before any ACCEPT rules)
sudo iptables -I INPUT -s 1.2.3.4 -j DROP

# Or in nginx's server block:
# deny 1.2.3.4;

Tek bir adres ya da küçük bir aralık binlerce istek gönderiyorsa onu güvenlik duvarında engelleyin. Cloudflare veya başka bir CDN'in arkasındaysanız önce günlüklerinizin gerçek ziyaretçi IP'sini göstermesini sağlayın (nginx'te set_real_ip_from ile real_ip_header CF-Connecting-IP), yoksa saldırgan yerine CDN'i engellersiniz. Büyük bir saldırıda Cloudflare'in "I'm Under Attack" modu veya barındırma sağlayıcınızın DDoS koruması trafiği size ulaşmadan filtreler.

Çözüm 8: Veritabanı Bağlantı Sorunlarını Düzeltin

Veritabanının bağlantıları tükendiğinde ya da durduğunda önündeki uygulama çökebilir. Bazı uygulamalar 503 verir; WordPress ise bunun yerine "Error establishing a database connection" gösterir. Veritabanını doğrudan kontrol edin:

# Check if MySQL/MariaDB is running (the unit is mysqld on RHEL, mariadb for MariaDB)
sudo systemctl status mysql

# Restart MySQL
sudo systemctl restart mysql

# Check current connections vs limit
mysql -e "SHOW STATUS LIKE 'Threads_connected';"
mysql -e "SHOW VARIABLES LIKE 'max_connections';"

# Increase max connections (temporary)
mysql -e "SET GLOBAL max_connections = 200;"

# Check for long-running queries
mysql -e "SHOW PROCESSLIST;" | head -20

Çok sayıda uyuyan bağlantı görüyorsanız, uygulamanız veritabanı bağlantılarını düzgün kapatmıyor demektir. Uzun süren sorgular diğerlerini engelliyorsa, bu sorguları optimize edin veya veritabanının engelini kaldırmak için sonlandırın.

Çözüm 9: Barındırma Sağlayıcınızla İletişime Geçin

Paylaşımlı barındırma, yönetilen WordPress barındırma veya Squarespace, Wix ya da Shopify gibi bir platform kullanıyorsanız, sunucu günlüklerine erişiminiz veya hizmetleri yeniden başlatma yetkiniz olmayabilir. Bu durumlarda 503 hatası, barındırma sağlayıcısının altyapısından kaynaklanıyor olabilir.

Barındırma sağlayıcınızın desteğiyle iletişime geçin ve şunları belirtin:

• 503 döndüren tam URL
• Hatanın ne zaman başladığı — tarih ve saati not edin
• Neyin değiştiği — bir eklenti yüklediniz mi, tema güncellediniz mi veya DNS ayarlarını değiştirdiniz mi?
• Hatanın aralıklı mı yoksa sürekli mi olduğu — aralıklı 503 hataları kaynak sınırlarına işaret eder; sürekli 503 hataları çökme veya yapılandırma hatasına işaret eder

503 ile Diğer HTTP Hatalarının Karşılaştırması

503 hatası sıklıkla diğer sunucu hatalarıyla karıştırılır. İşte aralarındaki farklar.

Temel fark: 503 geçici olması için tasarlanmıştır ve bir Retry-After başlığı ne kadar süreceğini söyleyebilir. Tarama açısından Google, 5xx ve 429 hatalarını benzer ele alır: tarayıcıları yavaşlar, dizindeki URL'ler bir süre korunur ancak hatalar sürerse sonunda düşer (Google Search Central).

Proxy tarafı hataları için 502 Bad Gateway ve 504 Gateway Timeout yazılarına, istek sınırları için 429 Too Many Requests yazısına bakın.

503 Hatalarını Nasıl Önlersiniz

Önlem almak, yangınla mücadeleden iyidir. İşte 503 hatalarından kaçınmak için en iyi uygulamalar.

• Sunucu kaynaklarını izleyin — CPU > %80, RAM > %85 ve disk > %90 için uyarılar kurun. UptimeRobot, Pingdom veya Grafana gibi araçlar anında bildirim sağlar.
• CDN kullanın — Cloudflare, Fastly veya AWS CloudFront statik kaynakları önbelleğe alır ve trafik artışlarını karşılar, böylece kaynak sunucunuzdaki yükü azaltır.
• Önbelleğe almayı etkinleştirin — Veritabanı sorgularını ve işlenmiş sayfaları önbelleğe almak için Redis, Memcached veya Varnish kullanın. WordPress kullanıcıları: WP Super Cache veya W3 Total Cache gibi bir önbellek eklentisi yükleyin.
• Otomatik ölçeklendirme — Bulut barındırma (AWS, GCP, Azure, DigitalOcean) kullanıyorsanız, trafik artışlarında otomatik olarak daha fazla sunucu eklemek için otomatik ölçeklendirme yapılandırın.
• Botları sınırlayın — Agresif tarayıcıları ve kazıyıcıları sunucunuzu aşırı yüklemeden önce hız sınırlamak için Nginx veya Cloudflare'i yapılandırın.
• Veritabanı sorgularını optimize edin — yavaş sorgular bağlantıları ve işçileri meşgul eder. Dizinler ekleyin, birleştirmeleri optimize edin ve sonuçları Redis veya Memcached'de önbelleğe alın.
• Uygun bir bakım sayfası kullanın — Dağıtımlar sırasında sunucunun çökmesine izin vermek yerine Retry-After başlığıyla 503 döndürün. Bu, SEO'yu korur ve kullanıcıları bilgilendirir.
• Yazılımı güncel tutun — Bilinen hataları ve güvenlik açıklarını önlemek için CMS, eklentiler, PHP ve veritabanını en son kararlı sürümlere güncelleyin.