Web Uygulamalarında 504 ve 503 Hataları: Nginx, ALB ve Cloudflare’da Nasıl Tetiklenirler?

Web Uygulamalarında 504 ve 503 Hataları: Nginx, ALB ve Cloudflare’da Nasıl Tetiklenirler?

Bir web sitesi yöneticisi veya geliştiricisi olarak, kullanıcılarınızın aniden “Hizmet Kullanılamıyor” veya “Ağ Geçidi Zaman Aşımı” gibi mesajlarla karşılaşması kâbus gibidir. Peki, bu tanıdık ancak çoğu zaman kafa karıştırıcı 503 ve 504 HTTP durum kodları tam olarak ne anlama geliyor ve Nginx, AWS Application Load Balancer (ALB) ve Cloudflare gibi yaygın altyapı bileşenlerinde nasıl tetikleniyorlar? Bu makalede, bu kritik hata kodlarının derinliklerine inecek, temel farklarını açıklayacak ve modern web mimarilerindeki tetiklenme mekanizmalarını gerçek dünya senaryolarıyla adım adım inceleyeceğiz. Amacımız, bu hataları sadece anlamakla kalmayıp, aynı zamanda onları etkili bir şekilde giderebilmeniz ve hatta oluşmadan önleyebilmeniz için size kapsamlı bir yol haritası sunmaktır.

HTTP 5xx Hataları Nedir ve Neden Önemlidir?

Web dünyasında gezinirken veya bir uygulama geliştirirken, karşımıza çıkan her HTTP durum kodu bir hikaye anlatır. 200 OK başarıyı, 404 Not Found ise aradığımız kaynağın bulunamadığını ifade eder. Ancak işler ters gitmeye başladığında, genellikle 5xx serisi hatalarla karşılaşırız. Bu hatalar, sunucu tarafında bir sorun olduğunu, yani isteği işleyen sunucunun isteği yerine getiremediğini gösterir. Kullanıcı deneyimini doğrudan etkiledikleri ve potansiyel gelir kayıplarına yol açabildikleri için 5xx hatalarını anlamak ve yönetmek hayati öneme sahiptir. Özellikle 503 Service Unavailable ve 504 Gateway Timeout, en sık karşılaşılan ve birbirine karıştırılan hatalardan ikisidir.

503 Service Unavailable (Hizmet Kullanılamıyor) hatası, sunucunun isteği şu anda işleyemediğini belirtir. Bu durum genellikle sunucunun aşırı yüklenmesi, bakımda olması veya geçici olarak kullanılamaz hale gelmesi gibi nedenlerden kaynaklanır. Bu hata, sunucunun isteği alıp işleyebildiğini, ancak belirli bir nedenle şu anda hizmet veremediğini açıkça ifade eder. Örneğin, bir veritabanı bağlantısı koptuğunda, bir uygulama sunucusu çöktüğünde veya sistem kaynakları tükendiğinde (CPU, RAM vb.), uygulama bu durumu 503 olarak geri döndürebilir. Önemli olan, bu hatanın genellikle geçici bir durum olduğunu ve sunucunun daha sonra tekrar hizmet vermeye başlayacağını ima etmesidir. Bu nedenle, bazı 503 yanıtları, istemcilere ne kadar süre sonra tekrar denemeleri gerektiğini bildiren bir Retry-After başlığı içerebilir. Bu hata, genellikle isteğin bir proxy veya yük dengeleyici tarafından arka uç sunucusuna başarıyla iletildiğini, ancak arka uç sunucusunun kendisinin bir sorun yaşadığını gösterir.

Öte yandan, 504 Gateway Timeout (Ağ Geçidi Zaman Aşımı) hatası, sunucunun (genellikle bir ağ geçidi veya proxy) yukarı akış (upstream) sunucusundan zamanında yanıt alamadığını gösterir. Yani, istemcinin isteğini alan sunucu, bu isteği işlemek için başka bir sunucuya (örneğin bir uygulama sunucusu veya veritabanı sunucusu) yönlendirmiş, ancak bu ikinci sunucu belirli bir süre içinde yanıt vermemiştir. Bu durum, arka uç sunucusunun aşırı yavaş çalışması, kilitlenmesi veya hiç yanıt vermemesi gibi durumlarda ortaya çıkar. 504 hatası, genellikle ağ gecikmeleri, uzun süren veritabanı sorguları, harici API çağrılarının takılması veya arka uç uygulamasının iş yükünü kaldıramayacak kadar meşgul olması gibi nedenlerle tetiklenir. Bu hata, proxy sunucusunun beklediği sürenin dolduğunu ve artık daha fazla bekleyemeyeceğini belirtir. Temel farkı özetlemek gerekirse: 503, sunucunun “şu an meşgulüm/hizmet veremiyorum” demesi gibiyken, 504, “arkadaşıma sordum ama bir türlü yanıt alamadım” demesi gibidir. Bu iki hata arasındaki ayrımı anlamak, sorunun kaynağını doğru bir şekilde teşhis etmek ve gidermek için kritik öneme sahiptir.

Nginx ile 503 ve 504 Hatalarının Dansı: Yapılandırma ve Tetiklenme Mekanizmaları

Nginx, modern web mimarilerinin vazgeçilmez bir parçasıdır. Genellikle bir ters proxy (reverse proxy) ve yük dengeleyici (load balancer) olarak görev yapar, gelen istekleri arka uç (upstream) sunucularına yönlendirir. Bu kritik rolü nedeniyle, Nginx’in 503 ve 504 hatalarını nasıl tetiklediğini anlamak, hata ayıklama ve sistem performansını optimize etme açısından büyük önem taşır. Nginx, bu hata kodlarını çeşitli yapılandırma ayarları ve arka uç sunucularının davranışlarına bağlı olarak üretir.

504 Gateway Timeout hatası, Nginx’in bir isteği arka uç sunucusuna ilettiğinde ve belirli bir süre içinde yanıt alamadığında tetiklenir. Nginx’in bu davranışı kontrol eden temel direktifler şunlardır: proxy_connect_timeout, proxy_send_timeout ve proxy_read_timeout. Örneğin, bir kullanıcının web sitenize erişmeye çalıştığını varsayalım. İstek önce Nginx’e ulaşır. Nginx bu isteği bir uygulama sunucusuna (örneğin, bir Node.js veya PHP-FPM sunucusu) iletir. Eğer uygulama sunucusu, Nginx’in proxy_read_timeout direktifinde belirtilen süre içinde bir yanıt göndermezse, Nginx istemciye 504 hatası döndürecektir. Bu durum, genellikle arka uç uygulamasının çok uzun süren bir veritabanı sorgusu çalıştırması, harici bir API’den yanıt beklerken takılması veya genel olarak yoğun iş yükü altında yavaşlaması gibi nedenlerden kaynaklanır. Bu zaman aşımı değerlerini dikkatli bir şekilde ayarlamak, uygulamanızın tipik yanıt sürelerine uygun olmalı, ancak aynı zamanda takılan isteklerin sistem kaynaklarını uzun süre meşgul etmesini de engellemelidir.

http {
    upstream backend_servers {
        server 192.168.1.100:8080;
        server 192.168.1.101:8080;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend_servers;
            proxy_connect_timeout 5s;   # Arka uca bağlanma süresi
            proxy_send_timeout 10s;     # Arka uca veri gönderme süresi
            proxy_read_timeout 60s;     # Arka uçtan yanıt bekleme süresi (504'ü tetikler)
            proxy_intercept_errors on;  # Arka uçtan gelen 4xx/5xx hatalarını Nginx'in yakalaması
            error_page 504 /custom_504.html; # Özel 504 hata sayfası
        }
    }
}
        

Yukarıdaki örnekte, Nginx arka uç sunucusundan 60 saniye içinde yanıt alamazsa 504 hatası dönecektir. Eğer proxy_intercept_errors direktifi on olarak ayarlanmışsa, Nginx arka uçtan gelen 5xx hatalarını da yakalayabilir ve kendi özel hata sayfalarını sunabilir. Bu, kullanıcı deneyimini iyileştirmek için önemlidir.

503 Service Unavailable hatası ise Nginx tarafından farklı senaryolarda tetiklenir. En yaygın durum, Nginx’in bir veya daha fazla arka uç sunucusunu “sağlıksız” (unhealthy) olarak işaretlemesidir. Bu durum, upstream bloğundaki max_fails ve fail_timeout direktifleri ile kontrol edilir. Eğer bir arka uç sunucusu, fail_timeout süresi içinde max_fails sayısından daha fazla hata (bağlantı hatası, zaman aşımı veya yapılandırılmış HTTP durum kodları) verirse, Nginx o sunucuyu belirli bir süre boyunca havuzdan çıkarır. Bu süre boyunca o sunucuya gelen tüm istekler, havuzda başka sağlıklı sunucu yoksa 503 hatasıyla karşılaşır.

http {
    upstream backend_servers {
        server 192.168.1.100:8080 max_fails=3 fail_timeout=30s; # 30 saniyede 3 hata sonrası 30s boyunca devre dışı
        server 192.168.1.101:8080 max_fails=3 fail_timeout=30s;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend_servers;
            proxy_next_upstream error timeout http_500 http_502 http_503 http_504; # Hata durumunda diğer upstream'e geç
            error_page 503 /custom_503.html;
        }
    }
}
        

Yukarıdaki örnekte, eğer 192.168.1.100:8080 sunucusu 30 saniye içinde 3 kez hata verirse, Nginx onu 30 saniyeliğine havuzdan çıkarır. Bu süre içinde o sunucuya gönderilecek istekler, eğer proxy_next_upstream direktifi ile başka bir sağlıklı sunucuya yönlendirilemezse, 503 hatasıyla sonuçlanabilir. proxy_next_upstream direktifi, bir arka uç sunucusunda belirli hatalar (error, timeout, http_503 vb.) oluştuğunda Nginx’in isteği bir sonraki arka uç sunucusuna yönlendirmesini sağlar. Bu, sistemin esnekliğini artırır ancak tüm arka uç sunucuları aynı anda çökerse veya hepsi sağlıksız olarak işaretlenirse, Nginx en sonunda 503 hatası döndürecektir.

Gerçek dünya senaryosunda, bir e-ticaret sitesinin ödeme işlemi sırasında arka uç mikroservislerinden birinin veritabanı bağlantı havuzunun dolduğunu ve yeni bağlantıları reddetmeye başladığını düşünelim. Bu durumda, mikroservis doğrudan 503 yanıtı döndürebilir veya o kadar yavaşlar ki Nginx’in proxy_read_timeout süresi dolarak 504 hatası tetiklenir. Eğer mikroservis sürekli 503 dönüyorsa ve max_fails eşiğini aşarsa, Nginx o sunucuyu havuzdan çıkaracak ve bu da kullanıcılar için 503 hatalarına yol açacaktır. Dolayısıyla, Nginx’in yapılandırması, arka uç hizmetlerinin sağlığı ve performansı ile doğrudan ilişkilidir ve bu hata kodlarının ne zaman ve nasıl görüneceğini belirler.

AWS Application Load Balancer (ALB) ile Hata Yönetimi: 503 ve 504 Neden Karşımıza Çıkar?

AWS Application Load Balancer (ALB), modern bulut tabanlı uygulamalar için esneklik ve ölçeklenebilirlik sağlayan kritik bir bileşendir. Gelen trafiği birden fazla hedef (target) arasında dağıtarak uygulamanızın yüksek erişilebilirliğini ve performansını garanti eder. Ancak ALB de, arka uç hedeflerinin durumuna ve kendi yapılandırmasına bağlı olarak 503 ve 504 hataları üretebilir. Bu hataların ALB bağlamında nasıl tetiklendiğini anlamak, AWS ortamındaki uygulamalarınızın sorunlarını gidermek için temel bir adımdır.

ALB’nin 503 Service Unavailable hatası üretmesinin en yaygın nedeni, hedef grubundaki (target group) tüm hedeflerin sağlıksız (unhealthy) olarak işaretlenmesi veya hedeflerin tamamen eksik olmasıdır. ALB, hedef gruplarındaki her bir hedef için düzenli sağlık kontrolleri (health checks) yapar. Bu sağlık kontrolleri, belirli bir HTTP yolu (path) üzerinden hedeflere istek göndererek veya belirli bir TCP portunu kontrol ederek hedefin yanıt verip vermediğini ve beklenen durumu (örneğin, HTTP 200 OK) döndürüp döndürmediğini denetler. Eğer bir hedef, yapılandırılmış sağlık kontrolü eşiklerini (örneğin, unhealthy threshold) aşan bir şekilde başarısız olursa, ALB o hedefi sağlıksız olarak işaretler ve ona trafik göndermeyi durdurur. Eğer hedef grubundaki *tüm* hedefler sağlıksız hale gelirse veya hedef grubunda hiç kayıtlı hedef yoksa, ALB gelen tüm isteklere 503 Service Unavailable hatası döndürür. Bu durum, genellikle arka uç EC2 örneklerinin çökmesi, uygulama sunucularının yanıt vermemesi, veritabanı bağlantı sorunları veya kaynak tükenmesi gibi nedenlerle ortaya çıkar. Örneğin, bir web uygulamasının ani bir trafik artışı yaşaması ve tüm EC2 örneklerinin CPU veya bellek limitlerine ulaşarak donması, ALB’nin tüm hedefleri sağlıksız olarak işaretlemesine ve dolayısıyla 503 hatası vermesine neden olabilir.

# AWS CLI komutları ile örnek sağlık kontrolü yapılandırması
# Hedef Grubunu Güncelleme
aws elbv2 modify-target-group \
    --target-group-arn arn:aws:elasticloadbalancing:REGION:ACCOUNT_ID:targetgroup/my-target-group/ID \
    --health-check-protocol HTTP \
    --health-check-port 80 \
    --health-check-path /health \
    --health-check-interval-seconds 30 \
    --health-check-timeout-seconds 5 \
    --healthy-threshold-count 3 \
    --unhealthy-threshold-count 3 \
    --matcher HttpCode=200

# Eğer /health endpoint'i 30 saniye içinde 3 kez 200 dönmezse, hedef sağlıksız sayılır.
        

504 Gateway Timeout hatası ise ALB tarafından, bir isteği arka uç hedefine yönlendirdiğinde ve hedeften yapılandırılmış süre içinde yanıt alamadığında tetiklenir. ALB’nin bu davranışı kontrol eden temel ayar, yük dengeleyicinin Idle timeout (Boşta kalma zaman aşımı) süresidir. Varsayılan olarak 60 saniye olan bu süre, ALB’nin bir bağlantıyı açık tutma ve arka uçtan yanıt bekleme süresini belirler. Eğer arka uç hedefi, bu Idle timeout süresi içinde ALB’ye herhangi bir veri (bir yanıt başlığı veya gövdesi) göndermezse, ALB bağlantıyı kapatır ve istemciye 504 Gateway Timeout hatası döndürür. Bu durum, genellikle arka uç uygulamasının çok uzun süren bir işlem yapması (örneğin, karmaşık bir rapor oluşturma, büyük bir dosya işleme veya yavaş bir harici API’ye bağımlılık) nedeniyle ortaya çıkar. Örneğin, bir kullanıcının büyük bir Excel dosyasını yükleyip işlemesini bekleyen bir web uygulaması, bu işlemin 60 saniyeyi aşması durumunda ALB’den 504 hatası alabilir. Bu zaman aşımını, uygulamanızın en uzun süren işlemlerini göz önünde bulundurarak ayarlamanız önemlidir. Ancak, çok uzun bir zaman aşımı belirlemek de, takılan isteklerin sunucu kaynaklarını gereksiz yere meşgul etmesine yol açabilir.

Bir vaka analizi olarak, popüler bir sosyal medya platformunun resim yükleme hizmetini düşünelim. Kullanıcılar yüksek çözünürlüklü resimler yüklediğinde, arka uç servisi bu resimleri yeniden boyutlandırmak ve farklı formatlara dönüştürmek için zaman alıcı işlemler yapabilir. Eğer bu işlemler, ALB’nin varsayılan 60 saniyelik Idle timeout süresini aşarsa, kullanıcılar 504 hatasıyla karşılaşır. Bu sorunu çözmek için ALB’nin Idle timeout süresi, en uzun resim işleme süresine uygun olarak artırılabilir (örneğin, 300 saniyeye). Ancak daha iyi bir çözüm, resim işleme görevini bir mesaj kuyruğuna (örneğin, SQS) atıp, arka planda asenkron olarak işlemek ve kullanıcıya hemen bir “resminiz işleniyor” mesajı dönmektir. Bu yaklaşım, hem zaman aşımı sorunlarını ortadan kaldırır hem de kullanıcı deneyimini iyileştirir.

Sonuç olarak, ALB ortamında 503 ve 504 hatalarını gidermek için öncelikle hedef grubunun sağlık kontrollerini ve hedeflerin durumunu kontrol etmek gerekir. 503 hatası genellikle hedef sağlığıyla ilgiliyken, 504 hatası daha çok arka uç uygulamasının yanıt süresi ve ALB’nin Idle timeout ayarlarıyla ilişkilidir. Bu bileşenleri doğru bir şekilde izlemek ve yapılandırmak, uygulamanızın kesintisiz çalışmasını sağlamanın anahtarıdır.

Cloudflare ve Hata Kodları: 503 ve 504’ün Ötesinde Bir Dünya

Cloudflare, dünya genelinde milyonlarca web sitesi için bir CDN (İçerik Dağıtım Ağı), güvenlik katmanı ve ters proxy hizmeti sunar. Bir web isteği Cloudflare üzerinden geçtiğinde, Cloudflare hem isteği önbelleğe alabilir hem de güvenlik kontrolleri uygulayabilir, ardından isteği gerçek origin (kaynak) sunucusuna yönlendirir. Bu aracı rolü nedeniyle, Cloudflare’ın 503 ve 504 gibi hata kodlarını nasıl işlediği ve kendi özel 5xx hata kodlarını ne zaman döndürdüğü, sorun giderme süreçlerinde kritik bir öneme sahiptir.

Cloudflare, bir isteği origin sunucusuna ilettiğinde ve origin sunucusundan belirli bir süre içinde yanıt alamazsa 504 Gateway Timeout hatası döndürebilir. Ancak Cloudflare’ın kendi özel hata kodları da vardır ve bunlar genellikle temel 503/504 senaryolarına karşılık gelir. Örneğin, Cloudflare’ın en yaygın zaman aşımı hatası 524 A Timeout Occurred’dur. Bu hata, Cloudflare’ın origin sunucusuna bir istek gönderdiğinde ve origin sunucusunun 100 saniye içinde (Cloudflare’ın varsayılan zaman aşımı) bir yanıt döndürmemesi durumunda tetiklenir. Bu durum, arka uç uygulamasının çok uzun süren bir işlem yapması, veritabanı sorgularının takılması veya harici API çağrılarının gecikmesi gibi nedenlerle ortaya çıkar. Temel olarak, Cloudflare’ın 524 hatası, Nginx veya ALB’nin döndüreceği 504 hatasının Cloudflare tarafındaki karşılığıdır. Bu hatayı gördüğünüzde, sorunun Cloudflare ile origin sunucunuz arasındaki iletişimde veya origin sunucunuzun kendisinde bir performans sorunu olduğunu anlamalısınız.

# Cloudflare, bu tür hataları genellikle kendi özel hata sayfalarıyla sunar.
# Cloudflare paneli üzerinden özel hata sayfaları yapılandırılabilir,
# ancak hata tetiklenme mantığı arka uç yanıt sürelerine bağlıdır.
# Örneğin, bir Cloudflare Worker'da uzun süren bir Fetch işlemi 524'e neden olabilir:

async function handleRequest(request) {
    // Çok uzun süren bir işlem veya harici API çağrısı
    const response = await fetch('https://slow-api.example.com/data', {
        signal: AbortSignal.timeout(90 * 1000) // 90 saniye zaman aşımı
    }); 
    // Eğer slow-api 90 saniyeden uzun sürerse, Worker bu hatayı yakalar.
    // Ancak Cloudflare'ın kendi 100 saniyelik zaman aşımı (524) devreye girebilir.

    return response;
}

addEventListener('fetch', event => {
    event.respondWith(handleRequest(event.request));
});
        

503 Service Unavailable hatası için Cloudflare’ın da kendi özel eşdeğerleri mevcuttur. Cloudflare’ın 521 Web Server Is Down hatası, Cloudflare’ın origin sunucunuza TCP bağlantısı kuramadığında tetiklenir. Bu, origin sunucunuzun tamamen kapalı olduğu, güvenlik duvarının Cloudflare IP’lerini engellediği veya web sunucusu uygulamasının çalışmadığı durumlarda görülür. Benzer şekilde, 522 Connection Timed Out hatası, Cloudflare’ın origin sunucusuyla TCP bağlantısı kurabildiği ancak origin sunucusunun bir HTTP yanıtı döndürmeden bağlantıyı kapattığı durumlarda ortaya çıkar. Bu, origin sunucusunun aşırı yüklenmesi, kaynaklarının tükenmesi veya hatalı bir ağ yapılandırması nedeniyle gerçekleşebilir. Bu 521 ve 522 hataları, temelde origin sunucunuzun hizmet veremediğini gösteren 503’ün farklı varyasyonlarıdır.

Cloudflare ayrıca, origin sunucunuzun doğrudan 503 veya 504 hatası döndürmesi durumunda bu hataları istemciye iletebilir. Örneğin, eğer origin sunucunuz bakım modundaysa ve 503 yanıtı veriyorsa, Cloudflare bu 503 yanıtını olduğu gibi istemciye aktarır. Ancak, Cloudflare’ın kendi güvenlik duvarı (WAF) kuralları veya DDoS koruma mekanizmaları da belirli senaryolarda 503 hatası döndürebilir. Örneğin, bir saldırı tespit edildiğinde veya bir IP adresi engellendiğinde, Cloudflare bazen 503 yanıtıyla isteği reddedebilir.

Bir vaka analizi olarak, bir haber portalının yoğun bir haber yayınlandığında ani bir trafik artışı yaşadığını düşünelim. Origin sunucuları bu yükü kaldıramayarak aşırı yüklenir ve yavaşlamaya başlar. Cloudflare, bu yavaşlayan origin sunucularına istek gönderdiğinde, origin’den 100 saniye içinde yanıt gelmezse 524 hataları tetiklenecektir. Eğer origin sunucuları tamamen çöker ve Cloudflare onlara hiç bağlanamazsa, 521 hataları ortaya çıkar. Bu durumda, Cloudflare’ın “Always Online” özelliği, önbelleğe alınmış içeriği sunarak bir nebze olsun kullanıcı deneyimini koruyabilir, ancak dinamik içerik için hata kodları kaçınılmaz olacaktır. Sorun giderme aşamasında, Cloudflare paneli üzerindeki trafik analizi ve hata loglarını kontrol etmek, origin sunucunuzun durumunu izlemek ve Cloudflare ile origin arasındaki bağlantı ayarlarını gözden geçirmek hayati öneme sahiptir. Özellikle güvenlik duvarı (firewall) ayarlarının Cloudflare IP aralıklarına izin verdiğinden emin olmak, 521 gibi bağlantı hatalarını önlemek için ilk adımlardan biridir.

Gerçek Dünya Senaryoları ve Hata Giderme Stratejileri

Web uygulamalarındaki 503 ve 504 hataları, genellikle karmaşık altyapıların birbiriyle etkileşiminden kaynaklanır. Bu hataları gidermek, sistemin farklı katmanlarını anlamayı ve doğru araçları kullanmayı gerektirir. İşte bu hataların gerçek dünya senaryoları ve etkili hata giderme stratejileri:

Senaryo 1: Yoğun Trafik Altında Bir E-ticaret Sitesi

Bir Black Friday indirimi sırasında e-ticaret sitenizin trafiği aniden fırladı. Kullanıcılar sepete ürün eklemekte veya ödeme yaparken sürekli 504 hataları alıyor. Bu durumda ne yapmalısınız?

• Adım 1: Cloudflare Kontrolü: İlk olarak Cloudflare paneline bakın. Eğer 524 hataları görüyorsanız, bu Cloudflare’ın origin sunucunuzdan yanıt alamadığını gösterir. Cloudflare’ın DDoS koruması ve önbellekleme mekanizmaları çalışıyor mu? Traffic Analytics bölümünden origin sunucunuza giden istekleri ve yanıt sürelerini kontrol edin.
• Adım 2: ALB Sağlık Kontrolleri: AWS konsoluna geçerek Application Load Balancer’ınızın (ALB) metriklerini ve hedef gruplarınızın sağlık durumunu kontrol edin. Eğer hedeflerinizden bazıları veya hepsi sağlıksız olarak işaretlenmişse, ALB 503 hatası döndürüyor olabilir. ALB’nin Idle timeout süresi, en yoğun işlem sürenizden daha kısa mı? Eğer öyleyse, 504 hataları buradan kaynaklanıyor olabilir.
• Adım 3: Nginx Logları ve Yapılandırması: Arka uç sunucularınızdaki Nginx erişim ve hata loglarını inceleyin. /var/log/nginx/access.log ve /var/log/nginx/error.log dosyaları size hangi isteğin ne zaman ve hangi hatayla karşılaştığını gösterecektir. Nginx’in proxy_read_timeout değeri yeterince yüksek mi? upstream bloğunuzdaki max_fails ve fail_timeout ayarları çok agresif mi? Eğer Nginx 504 veya 503 döndürüyorsa, bu genellikle arka uç uygulamasının yavaş çalıştığı veya çöktüğü anlamına gelir.
• Adım 4: Arka Uç Uygulaması ve Veritabanı: Son olarak, arka uç uygulama sunucularınızın (EC2, konteynerler vb.) CPU, bellek ve disk kullanımı gibi sistem kaynaklarını izleyin. Uygulama loglarını (örneğin, Node.js, Java, Python logları) kontrol edin. Uzun süren veritabanı sorguları veya harici API çağrıları var mı? Veritabanı sunucunuzun performansını (bağlantı havuzu, sorgu süreleri, kilitlenmeler) analiz edin. Genellikle bu tür yoğun trafik senaryolarında, 504 hataları yavaş veritabanı sorgularından veya yetersiz uygulama kaynaklarından kaynaklanır. 503 hataları ise uygulama sunucularının tamamen çökmesi veya kaynaklarının tükenmesiyle ilişkilidir.

Senaryo 2: Bakım Çalışması Sonrası Uygulama Başlatma Sorunları

Bir sunucuya yama uyguladıktan veya bir uygulama dağıtımı yaptıktan sonra, web sitenize erişmeye çalışan kullanıcılar sürekli 503 hatası alıyor.

• Adım 1: Uygulama Durumu: Uygulama sunucunuzun çalışıp çalışmadığını kontrol edin. Örneğin, bir Node.js uygulaması için pm2 status veya bir Java uygulaması için ilgili servis durumunu kontrol edin. Uygulama başlatma sırasında bir hata mı verdi? Portu doğru dinliyor mu?
• Adım 2: Nginx/ALB Sağlık Kontrolleri: Nginx’in veya ALB’nin sağlık kontrollerinin başarılı olup olmadığını kontrol edin. Eğer uygulama sunucunuz çalışıyor ancak sağlık kontrolü endpoint’iniz doğru yanıt vermiyorsa (örneğin, 200 OK yerine 500 hatası dönüyorsa), Nginx veya ALB sunucuyu sağlıksız olarak işaretleyip 503 döndürecektir.
• Adım 3: Logları İncele: Uygulamanızın başlangıç loglarını, Nginx hata loglarını ve ALB erişim loglarını inceleyerek hatanın nedenini tespit edin. Belki bir yapılandırma dosyası eksik, bir bağımlılık yüklenemedi veya bir veritabanı bağlantısı kurulamadı.

Proaktif Önlemler ve İleri Düzey İpuçları

• İzleme ve Uyarı Sistemleri: Prometheus, Grafana, Datadog gibi araçlarla Nginx, ALB ve arka uç uygulamalarınızın metriklerini sürekli izleyin. Hata oranları, yanıt süreleri, CPU/bellek kullanımı belirli eşikleri aştığında otomatik uyarılar alın.
• Otomatik Ölçeklendirme: AWS Auto Scaling grupları gibi özelliklerle trafik artışlarına otomatik olarak yanıt verin. Uygulama sunucularınızın yük altında otomatik olarak ölçeklenmesini sağlayın.
• Sağlık Kontrollerini Optimize Etme: Yük dengeleyicilerinizdeki sağlık kontrollerinin uygulamanızın gerçek sağlığını yansıttığından emin olun. Sadece bir portun açık olup olmadığını değil, uygulamanın temel işlevlerinin çalışıp çalışmadığını kontrol eden daha derin sağlık kontrolleri kullanın.
• Zaman Aşımı Ayarlarını İnceleme: Nginx’teki proxy_read_timeout, ALB’deki Idle timeout ve Cloudflare’ın 100 saniyelik zaman aşımı gibi değerleri uygulamanızın tipik ve maksimum yanıt sürelerine göre ayarlayın. Uzun süren işlemler için asenkron yaklaşımları (mesaj kuyrukları, arka plan görevleri) tercih edin.
• Hata Sayfalarını Özelleştirme: Nginx, ALB ve Cloudflare’da özel hata sayfaları (error_page direktifi) kullanarak kullanıcılarınıza daha bilgilendirici ve markanıza uygun mesajlar sunun.
• Yük Testi: Uygulamanızı periyodik olarak yük testlerine tabi tutarak darboğazları önceden tespit edin ve sisteminizin kapasitesini anlayın.

Bu hata giderme stratejileri, 503 ve 504 hatalarının karmaşık doğasına ışık tutar. Her katmanın kendi sorumlulukları ve yapılandırmaları olduğunu anlamak, sorunun kaynağını hızlıca bulmanıza ve çözmenize yardımcı olacaktır.

Sonuç ve Sıkça Sorulan Sorular

Web uygulamalarındaki 503 Service Unavailable ve 504 Gateway Timeout hataları, kullanıcı deneyimini doğrudan etkileyen ve iş sürekliliği açısından kritik öneme sahip durumlardır. Bu makalede, bu iki hata kodunun temel farklarını, Nginx, AWS Application Load Balancer (ALB) ve Cloudflare gibi modern web altyapılarında nasıl tetiklendiklerini ve bu hataları gidermek için kullanılabilecek stratejileri detaylı bir şekilde inceledik. Gördüğümüz gibi, 503 genellikle sunucunun geçici olarak hizmet veremediğini (aşırı yük, bakım, çökme) gösterirken, 504 bir proxy veya ağ geçidinin yukarı akış sunucusundan zamanında yanıt alamadığını (yavaşlama, takılma, zaman aşımı) belirtir. Her iki hata da farklı kök nedenlere işaret etse de, her ikisi de uygulamanızın genel sağlığı ve performansı hakkında önemli ipuçları sunar.

Nginx, yapılandırma dosyalarındaki proxy_read_timeout ve upstream bloğundaki max_fails/fail_timeout direktifleri aracılığıyla bu hataları tetikler. ALB ise hedef grubu sağlık kontrolleri ve Idle timeout ayarlarıyla 503 ve 504 hatalarını üretir. Cloudflare ise kendi özel 5xx hatalarını (521, 522, 524) kullanarak origin sunucusuyla ilgili sorunları belirtir ve bu hatalar temel 503/504 senaryolarına karşılık gelir. Bu bileşenlerin her birinin hata yönetimindeki rolünü anlamak, sorunun kaynağını doğru bir şekilde teşhis etmek ve etkili çözümler üretmek için elzemdir. İzleme araçları, proaktif ölçeklendirme, optimize edilmiş sağlık kontrolleri ve doğru zaman aşımı ayarları, bu hataların oluşmasını önlemede veya oluştuğunda hızlıca gidermede kritik rol oynar. Unutmayın, iyi bir hata yönetimi stratejisi, sadece sorunları çözmekle kalmaz, aynı zamanda kullanıcı güvenini ve uygulama sürekliliğini de sağlar.

Sıkça Sorulan Sorular

1. 503 ve 504 hataları arasındaki temel fark nedir?

503 Service Unavailable, sunucunun isteği alıp işleyebildiğini ancak geçici olarak hizmet veremediğini (bakım, aşırı yük) belirtir. 504 Gateway Timeout ise, bir proxy veya ağ geçidi sunucusunun, isteği ilettiği yukarı akış sunucusundan belirli bir süre içinde yanıt alamadığını gösterir.

2. Nginx’te 504 hatasını önlemek için hangi ayarları kontrol etmeliyim?

Nginx’te proxy_read_timeout, proxy_connect_timeout ve proxy_send_timeout direktiflerini kontrol etmelisiniz. Bu değerlerin, arka uç uygulamanızın en uzun süren işlemlerine yetecek kadar yüksek olduğundan emin olun.

3. AWS ALB’de 503 hatası alıyorsam ilk nereye bakmalıyım?

ALB’de 503 hatası alıyorsanız, öncelikle hedef grubunuzdaki (target group) hedeflerin sağlık durumunu (health status) kontrol etmelisiniz. Genellikle bu, tüm hedeflerin sağlıksız olarak işaretlendiği veya hedef grubunda hiç hedef bulunmadığı anlamına gelir.

4. Cloudflare’ın 524 hatası ile 504 hatası arasındaki ilişki nedir?

Cloudflare’ın 524 A Timeout Occurred hatası, Cloudflare’ın origin sunucusundan belirli bir süre (varsayılan 100 saniye) içinde yanıt alamadığında tetiklenir. Bu, Cloudflare’ın kendi ağ geçidi zaman aşımıdır ve işlevsel olarak genel 504 Gateway Timeout hatasının Cloudflare’a özgü bir versiyonudur.

5. Uygulama sunucum yavaşladığında hem 503 hem de 504 hatası alabilir miyim?

Evet, alabilirsiniz. Eğer uygulama sunucunuz o kadar yavaşlarsa ki Nginx veya ALB’nin zaman aşımı süresi dolarsa 504 hatası alırsınız. Eğer uygulama sunucunuz yavaşlamanın ötesine geçip tamamen yanıt vermeyi durdurur veya çökerse, Nginx/ALB onu sağlıksız olarak işaretleyebilir ve diğer isteklere 503 hatası döndürebilir.

#Teknoloji #WebGeliştirme #HTTPHataları #Nginx #ALB #Cloudflare #503 #504