503 Hatası; Kasıtlı Kesinti ile Gerçek Arıza Arasındaki Fark

Site açılmıyor ve tarayıcı 503 rakamıyla birlikte boş bir sayfa gösteriyor. Çoğu site yöneticisinin yaptığı ilk şey web servisini yeniden başlatmaktır. Bu, vakaların yarısında sorunu daha da kötüleştirir, çünkü 503'ün birbirinden tamamen farklı iki anlamı vardır ve hangisini gördüğünüzü bilmeden atacağınız her adım karanlıkta ateş etmek gibidir.

503 hatası kasıtlı mı, istenmeyen mi?

Yanıt başlığına bir bakış bunu netleştirir. Eğer sunucu servisi geçici olarak kesmeye kendisi karar verdiyse, Retry-After başlığını gönderir:

HTTP/1.1 503 Service Unavailable
Retry-After: 3600
Cache-Control: no-store

Retry-After başlığının varlığı, birinin bu 503'ü önceden tasarladığı anlamına gelir. Bu durum bakım modunda, WordPress'in maintenance mode halinde veya Nginx bir reverse proxy olarak kapatılmış bir upstream'in arkasında olduğunda ortaya çıkar. Eğer bu başlık yoksa ve bunun yerine yanıtta varsayılan gövdeyle birlikte Server: nginx görüyorsanız, muhtemelen upstream gerçekten ölmüştür.

Bu ikisi arasındaki pratik fark logdadır. Kasıtlı 503 genellikle access.log içinde 503 koduyla ve error.log içinde hiçbir iz olmadan kaydedilir. İstenmeyen 503'ün ise error.log'da her zaman karşılık gelen bir satırı vardır:

connect() failed (111: Connection refused) while connecting to upstream

Ya da PHP-FPM versiyonu:

connect() to unix:/run/php/php8.2-fpm.sock failed (2: No such file or directory)

Bu ikinci satırı çok görüyorum. Yani PHP-FPM soketi mevcut değil; ya servis ayağa kalkmamış ya da PHP sürümü değişmiş ve Nginx yapılandırmasındaki soket yolu güncellenmemiş.

Google neden doğru 503'ü cezalandırmaz

Google'ın tarayıcısı 503 ile 500 arasında ayrım yapar ve bu ayrım site sıralaması için hayati önemdedir. 503 geçici bir koddur. Google bekler, tekrar ziyaret eder ve sayfayı indeksten çıkarmaz. Ancak 500 veya 404, birkaç hafta boyunca sayfayı arama sonuçlarından kaldırabilir.

Koşul, 503'ün gerçekten geçici olmasıdır. Eğer siteniz üst üste üç hafta 503 döndürürse, Google bunu kalıcı bir arıza gibi görür ve organik trafik düşer. Kişisel deneyimim: Sunucu taşımasından sonra bir hafta maintenance modunda kalan siteler, iki ila üç hafta sonra yüzde 30 ila 40 trafik düşüşü hissetti.

Daha az söylenen bir teknik nokta: Maintenance modunda Retry-After başlığını mutlaka ayarlayın. Mantıklı değer 3600 ile 86400 saniye arasındadır. Bu başlık yoksa, tarayıcı kısa ve ardışık aralıklarla denemeye çalışır ve ek yük tam da bakımda olan sunucuya biner.

Üç dakikada hızlı teşhis

Herhangi bir değişiklik yapmadan önce şu sırayı izleyin:

1. curl -I https://example.com ile başlıkları görün. Retry-After ile birlikte 503 kodu kasıtlı olduğu anlamına gelir.
2. Sunucuda systemctl status nginx php8.2-fpm komutunu çalıştırın. Servislerden biri failed ise sorun odur.
3. Bir istekle eşzamanlı olarak tail -f /var/log/nginx/error.log ile hata satırını okuyun.
4. ss -lntp | grep :80 ile 80 portunda birinin dinleyip dinlemediğine bakın.

Eğer servisler sağlıklıysa ve hâlâ 503 alıyorsanız, muhtemelen kaynak sınırlamasıdır. PHP-FPM pm.max_children sınırına ulaştığında, yeni istekler kuyrukta bekler ve timeout sonrası 503 ile geri döner. Bu durumu /var/log/php8.2-fpm.log içinde şu mesajla tanırsınız:

WARNING: [pool www] server reached pm.max_children setting (10), consider raising it

Bu sayıyı artırmak çözüm değildir, sadece semptomları yer değiştirir. Her PHP-FPM süreci yaklaşık 30 ila 80 megabayt RAM alır. 2 gigabaytlık bir sunucuda sayıyı 10'dan 40'a çıkarırsanız, 503 yerine OOM Killer hatası ve MySQL'in yeniden başlamasını alırsınız. Önce free -m ile gerçek bellek tüketimini ölçün, sonra karar verin.

Burada hata yapıyorlar

Gördüğüm en yaygın hata: Site yöneticisi 503'ü Nginx'i yeniden başlatarak çözer, site iki dakika açılır ve sonra tekrar düşer. Bunun nedeni, sorunun başka bir katmanda olmasıdır. Eğer veritabanı ağır bir sorgu çalıştırıyorsa veya disk IOPS sınırına ulaşmışsa, web sunucusunu yeniden başlatmak sadece istek kuyruğunu boşaltır.

İşareti şudur: Her yeniden başlatmadan sonra site tam olarak birkaç dakika çalışır ve sonra aynı 503 geri döner. Bu durumda web sunucusu yerine MySQL'de SHOW FULL PROCESSLIST; ve iostat -x 1 komutlarına yönelin. Eğer diskin %util değeri yüzde 90'ın üzerindeyse, darboğaz web sunucusu değil I/O'dur.

İkinci hata: 503 sayfasını doğru durum kodu olmadan statik bir dosyaya koymak. Bazıları maintenance sayfasını 200 koduyla döndürür. Bu SEO için yapılabilecek en kötü şeydir, çünkü Google "site bakımda" içeriğini sayfanın gerçek içeriği olarak indeksler.

Kasıtlı 503'ü doğru uygulayın

Nginx'te en basit yol, doğru kodla statik bir dosya kullanmaktır:

location / {
    if (-f /var/www/maintenance.flag) {
        return 503;
    }
}
error_page 503 /maintenance.html;
location = /maintenance.html {
    internal;
}

Bu ayarla, maintenance.flag dosyasını oluşturmanız veya silmeniz yeterlidir; reload gerekmez. Google'ın da bunun geçici olduğunu anlaması için error_page bloğuna Retry-After başlığını ekleyin.

Eğer site WordPress üzerindeyse, maintenance mode eklentileri aynı işi yapar, ancak bazıları 200 kodu döndürür. Etkinleştirmeden önce curl -I ile gerçekten 503 aldığınızı kontrol edin.

Ne zaman altyapı yükseltmesine gitmeliyiz

Doğru pm.max_children ayarı, sorgu optimizasyonu ve önbelleği etkinleştirdikten sonra hâlâ yoğun trafik saatlerinde 503 alıyorsanız, sorun ayarlar değil kapasitedir. Bu noktada iki yolunuz var: veritabanını başka bir sunucuya ayırmak veya kaynakları tahsis edilmiş bir özel sunucuya geçmek.

Çoğu durumda tercihim ilk yoldur, çünkü daha ucuz ve daha hızlı sonuç verir. Ancak trafiğiniz sürekli olarak bir sunucunun kapasitesini aşıyorsa ve disk I/O ana darboğazsa, veritabanını ayırmak sadece ek karmaşıklık getirir ve daha güçlü donanıma yönelmelisiniz. Sorunu PHP-FPM ayarları ve önbellek olan küçük ve orta ölçekli siteler için, yeterli kaynaklara ve hassas PHP-FPM ayarı imkânına sahip bir Linux hosting yeterlidir.

Herhangi bir taşımadan önce mevcut durumu belgeleyin. Ücretsiz webmaster araçları ile sunucu yanıt süresini ve DNS durumunu ölçebilir ve taşımadan sonra karşılaştırabilirsiniz. Sorunun DNS'ten mi yoksa sunucudan mı kaynaklandığından şüpheleniyorsanız, DNS ve ağ kontrolü bu ikisini ayırmanın en hızlı yoludur.

Önbellek hakkında bir not: Siteniz bir CDN'in arkasındaysa, kaynaktan gelen 503 kenarda önbelleğe alınabilir ve sorun çözüldükten sonra bile birkaç dakika devam edebilir. Bu durumda cache'i purge etmeniz gerekir. Tarayıcı önbelleği ve Cache-Control başlıkları rehberi, hata yanıtlarının önbelleğe alınmaması için başlıkların nasıl ayarlanacağını açıklar.

Sık sorulan sorular

503 hatası SEO için tehlikeli mi?

503 hatası kendi başına SEO için tehlikeli değildir, çünkü geçici bir durum kodudur ve Google sayfayı indeksten çıkarmaz. Tehlike, 503 uzadığında başlar. İki ila üç haftadan fazla devam ederse, Google bunu kalıcı bir arıza gibi görür ve site sıralaması düşer.

İçiniz rahat olsun diye, 503 yanıtında her zaman Retry-After başlığını gönderin ve maintenance sayfasının 200 koduyla döndürülmediğinden emin olun.

503'ün kendi sunucumdan mı yoksa CDN'den mi geldiğini nasıl anlarım?

curl -I --resolve example.com:443:ana-sunucu-IP https://example.com ile doğrudan kaynağa istek gönderin. Eğer yanıt 200 ise ancak alan adı üzerinden 503 alıyorsanız, sorun CDN katmanındadır.

Bu durumda yanıtta Server ve CF-Ray veya benzeri başlığa bakın. Eğer CDN sağlayıcısının adını gösteriyorsa, kendi sunucunuzda değil CDN panelinde hata aramalısınız.

Nginx'i yeniden başlatmak 503 hatasını çözer mi?

Sadece gerçek neden Nginx süreçlerinin takılması veya istek kuyruğunun dolmasıysa. Çoğu durumda 503 PHP-FPM, veritabanı veya disk I/O'dan gelir ve Nginx'i yeniden başlatmak sadece birkaç dakikalık mühlet verir.

Yeniden başlatmadan önce her zaman error.log dosyasını okuyun. Eğer connect() failed hatası görürseniz, sorun Nginx'in kendisinde değil upstream'dedir.

503 ile 502 arasındaki fark nedir?

502, sunucunun gateway olarak upstream'den geçersiz bir yanıt aldığı anlamına gelir; 503 ise servisin şu anda kullanılamadığı anlamına gelir. Pratikte her ikisi de genellikle aynı kökten gelir: upstream kapalı veya aşırı yüklenmiş.

Bunları logdan ayırt etmek önemlidir. 502 daha çok upstream süreci yanıt verirken öldüğünde ortaya çıkar; 503 ise hiç bağlanamadığında veya kendisi kullanılamaz olduğunu bildirdiğinde.

Bir dahaki sefere 503 gördüğünüzde, herhangi bir komut vermeden önce curl -I ile kasıtlı mı değil mi sorun. Bu tek sorunun cevabı, sorun giderme yolunu yarıya indirir.