503 neyi vaat eder, neyi etmez
503, sunucunun "varım, seni anladım, sonra gel" demesidir. 500'ün aksine bir şeyin bozulduğunu iddia etmez; 502'nin aksine arkadaki bir makineyle başarısız olmuş bir konuşmaya dair değildir. Üstü kapalı bir "şimdilik" taşıyan bir rettir.
O "şimdilik", 503'ü planlı bakım ve aşırı yük için doğru, kalıcı hiçbir şey için doğru olmayan kod yapar. Arama motorları onu geçici sayar ve geri gelir; deploy sırasında tam da istediğiniz, yayından kaldırdığınız bir sayfada ise hiç istemediğiniz şey budur — orada kod 410 ya da 301'dir.
Sebep 1 — origin'in kapasitesi bitti
Her sunucunun eşzamanlı işte bir tavanı vardır: PHP-FPM çocuk süreçleri, uygulama worker'ları, veritabanı bağlantıları. Tavana ulaşıldığında iyi yapılandırılmış bir yığın, yeni işi kabul edip zaman aşımına uğratmak yerine hızlıca 503 ile reddeder. Bir arıza gibi görünse de sistemin baskı altında doğru davranmasıdır.
Nasıl tanınır. 503'ler trafiği takip eder: zirvelerde çıkar, zirve geçtiğinde kaybolur. Origin'iniz bu süre boyunca ayaktadır ve sakin bir anda yaptığınız isteğe anında cevap verir.
Gerçekten ne işe yarar. Worker sayısını artırmak tavanı yükseltir ve darboğazı genelde belleğe ya da veritabanına taşır. Kalıcı çözüm, tekrar eden işi origin'e hiç göndermemektir: önbelleğe alınabilecek sayfaları önbelleğe alın, onlara anlamlı bir TTL verin ve zirveyi edge soğursun. Saniyede 200 istekte bir origin'i eriten kampanyanın 195 isteği çoğu zaman aynı birkaç sayfa içindir.
Sebep 2 — bakım modu
Deploy araçları ve CMS eklentileri, çalışırken siteyi bir bakım sayfasının arkasına alıp 503 döner. Bu doğru davranıştır ve kod da doğrudur.
Burada iki şey ters gider. Birincisi hiç kaldırılmayan bir bakım modudur — başarısız bir deploy bayrak dosyasını yerinde bırakır ve site, iş bittikten çok sonra da 503 sunmaya devam eder. İkincisi 200 ile sunulan bir bakım sayfasıdır; bu da botlara bakım duyurusunun asıl içeriğiniz ve dizine girmeye değer olduğunu söyler.
Bakım modu birkaç dakikadan uzun sürecekse bir Retry-After başlığı ekleyin. Bir satıra mal olur ve nazikçe geri çekilen bir bot ile sitenizin güvenilmez olduğuna karar veren bir bot arasındaki farktır.
Sebep 3 — bir rate limit isteği reddetti
Rate limiting, ayarlanan eşikten hızlı gelen istekleri reddeder. Yazılıma ve yapılandırmasına göre bu ret 429 Too Many Requests olarak ya da 503 olarak gelir — örneğin nginx, aksi söylenmedikçe limitlenen istekleri 503 ile reddeder.
Bu, log okurken önem kazanır: her şey normal sunulurken tek bir istemciyi, tek bir yolu ya da tek bir user agent'ı etkileyen bir 503 salvosu, bir kapasite sorunu değil işini yapan bir rate limit'tir. Çözüm, limite kimin çarptığına bakmaktır. Çarpan bir kazıyıcıysa limit çalışıyordur. Bir ucu saniyede bir yoklayan kendi mobil uygulamanızsa, limit doğrudur ve yanlış olan uygulamadır.
Sebep 4 — edge'in bu alan adı için origin'i yok
Yarım gün yiyen sebep budur ve sunucunuzla hiçbir ilgisi yoktur.
Bir alan adının DNS'i bir CDN edge'ini gösterirken o alan adı edge'de tanımlanmamışsa — hesap henüz yoksa, dağıtım alan adı eklenmemişse ya da bir yazım hatası kaydı yanlış ismin üstüne koymuşsa — edge'in soracağı bir origin yoktur. 502 döndüremez, çünkü başarısız olmuş bir konuşma yoktur. Bu alan adı için tanımlı bir servis olmadığını söyleyen bir sayfayla 503 döner.
Bunu üreten sıra hep aynıdır: biri önce DNS'i değiştirir, panel yapılandırmasını sonra tamamlar; ya da alan adı çıplak hâliyle eklenmişken DNS'i www için değiştirir. DNS yayıldığı anda site "düşer", origin'de hiçbir sorun yoktur ve yanlış makineye bakmayı bıraktığınızda çözüm bir dakika sürer.
Anında nasıl tanınır. Yalnızca durum koduna değil, hata sayfasına bakın. Bir CDN'in "tanımlı servis yok" sayfası tanınmayacak gibi değildir ve sorunu adıyla söyler. Sonra panelinizdeki alan adının DNS kaydındaki isimle birebir eşleştiğini kontrol edin, www dahil.
Ne göndermeli ve ziyaretçi ne görmeli
503'ü döndüren sizseniz, iki şey onu çok daha ucuza mal eder.
Retry-After gönderin. Ya saniye cinsinden bir sayı ya da bir HTTP tarihi. Botlar buna uyar, düzgün yazılmış istemciler buna uyar ve bu, bir reddi bir takvime çevirir.
İnsana göre bir şey sunun. Proxy'nin varsayılan hata sayfası ziyaretçiye hiçbir şey anlatmaz ve bozuk görünür. Ne olup bittiğini bir cümleyle anlatan markalı bir sayfa çok az emek ister, bir olayın nasıl deneyimlendiğinde ise büyük fark yaratır.
Ve içerik önbelleğe alınabilir cinstense, origin reddederken CDN önbellekteki kopyayı sunmaya devam edebilir — "site on dakika yavaştı" ile "site on dakika kapalıydı" arasındaki fark budur.
503 Service Unavailable SSS
503, 502'den iyi mi kötü mü?
Daha bilgilendiricidir. 503 bilinçli bir rettir, yani yoldaki bir şey karar verecek kadar iyi çalışıyordur. 502 ise arkadaki makineyle yapılan konuşmanın başarısız olduğu demektir. Pratikte 503 daha sık sizin kontrolünüzdeki bir kapasite ya da yapılandırma meselesi, 502 ise daha sık bozuk bir origin olur.
503 arama sıralamama zarar verir mi?
Gerçekten geçiciyse vermez. Arama motorları 503'ü "sonra gel" diye okur; bakım sırasında doğru kod olmasının sebebi de budur. Günlerce süren bir 503 ise başka mesele: sayfalar eninde sonunda düşer. Botun ne bekleyeceğini bilmesi için Retry-After ekleyin.
DNS'i CDN'e yönlendirir yönlendirmez 503 alıyorum. Şimdi ne olacak?
Hata sayfasına bakın. Bu alan adı için tanımlı bir servis olmadığını söylüyorsa, alan adı edge'de henüz kurulmamıştır — origin işin içinde değildir. Panelde alan adını birebir ekleyin, DNS kaydına uyacak şekilde www'li ya da www'siz; yapılandırma edge'lere ulaşır ulaşmaz 503 kalkar.
503'ü önbelleğe alabilir miyim?
Almamalısınız, ya da yalnızca saniyeler için. Önbelleğe alınmış bir 503, sebep ortadan kalktıktan sonra da ziyaretçileri reddetmeye devam eder. Hata yanıtlarını çok kısa bir TTL ile sunun ve düzeltme devreye girer girmez o yolu purge'leyin.
Daha büyük bir sunucu almadan yük altındaki 503'leri nasıl durdururum?
Origin'e ulaşanı azaltın. Önbelleğe alınabileni bir trafik sıçramasından sağ çıkacak bir TTL ile önbelleğe alın, önbellek anahtarının takip parametreleriyle parçalanmadığından emin olun ve otomatik trafik çeken uçlarda rate limit bulundurun. Daha büyük sunucu tavanı yükseltir; önbellekleme ise tavana yüklenen isteklerin çoğunu ortadan kaldırır.