NGINX 502 ve 504 hatalarının gerçekte nerede ortaya çıktığının kaynak koduyla doğrulanmış haritası

NGINX istek işlemenin state machine haritası

dev.to üzerindeki bir yazı, en tanıdık iki üretim hatasına alışılmadık bir açıdan yaklaşıyor: yazar düzeltmeler listelemek yerine açık kaynak NGINX stable 1.30'u hiyerarşik bir state machine olarak modelliyor ve her geçişi resmi nginx.org dokümantasyonu, CHANGES dosyası ve kaynak kodunun kendisiyle doğruluyor. Bunun kazancı, 502 Bad Gateway ve 504 Gateway Timeout yanıtlarının gerçekte nerede üretildiğinin ve hangi yapılandırma varsayılanlarının hangisini göreceğinizi belirlediğinin net bir hesabı.

502 ile 504 ayrımı

Yazıya göre ayrım tek bir fonksiyonda, ngx_http_upstream_next() içinde gerçekleşiyor. Zaman aşımları 504'e karşılık geliyor: NGINX upstream'i bekliyordu ve bekleme yapılandırılmış limitleri aştı. Bağlantı hataları, geçersiz yanıt başlıkları ve "no live upstreams" durumu ise 502'ye karşılık geliyor: NGINX kullanılabilir bir yanıt hiç elde edemedi.

Bu ayrım hata ayıklama kısayoludur. Bir 504 sizi backend gecikmesine ve timeout ayarına yönlendirir; bir 502 ise upstream'in erişilebilir, sağlıklı ve geçerli HTTP döndürüp döndürmediğini kontrol etmeye gönderir.

On bir faz ve sınırlı bir rewrite döngüsü

Yazarın sayımına göre istek işleme on bir fazdan geçiyor. Bir rewrite URI'yi değiştirdiğinde kontrol FIND_CONFIG fazına geri döngüleniyor ve NGINX bu döngüye 500 hatası döndürmeden önce en fazla on yineleme izin veriyor. Uzun rewrite zincirlerine sahip yapılandırmalar bu yüzden sonsuza kadar döngüye girmek yerine katı bir üst sınıra çarpıyor.

Stable 1.30'daki yeni varsayılanlar

Eski materyalleri okurken gözden kaçması kolay olan bir değişiklik var. 1.29.7'den beri ve dolayısıyla stable 1.30'da, proxy keepalive ve HTTP/1.1 upstream bağlantılarında varsayılan ve Connection başlığı artık gönderilmiyor. Her proxied isteğin taze bir bağlantı aldığı eski modele dayalı hata ayıklama sezgisi, NGINX ile backend arasında gerçekte yaşananlarla artık eşleşmeyebilir.

Yeniden denemeler ve upstream sağlığı

Bir upstream hatasından sonra NGINX'in başka bir sunucuyu deneyip denemeyeceği proxy_next_upstream'a bağlı; yazıya göre varsayılanı "error timeout". İdempotent olmayan metotlar için bir istisna var: zaten iletilmiş POST, LOCK veya PATCH kullanan istekler yeniden denenmiyor, bu yüzden bu istekler için tek bir başarısız deneme hikayenin tamamı olabiliyor.

Upstream sağlığı varsayılan olarak pasif; max_fails 1'e, fail_timeout ise 10 saniyeye ayarlı. Yazının işaret ettiği aktif health_check direktifi, açık kaynak sürümün değil ticari NGINX Plus ürününe ait.

Başlatma ve reload davranışı

Resmi iki operasyonel detay tamamlıyor. Başlangıçta, başarısız bir bind() NGINX hâlâ bağlanamadığını bildirmeden önce 500 milisaniye arayla beş kez yeniden deneniyor. Bir reload sırasında master process önce yeni yapılandırmayı doğrulayıp uygular: bu başarısız olursa önceki yapılandırma yerinde kalır ve mevcut worker'lar hizmet vermeye devam eder; başarılı olursa yeni worker'lar başlarken eski worker'lar halihazırda ele aldıkları istekleri bitirir. İyi davranışlı bir reload bu yüzden devam eden işleri düşürmemek üzere tasarlanmıştır.

Neden önemli

502 ve 504 semptomlardır, nedenler değil ve farklı nedenlere işaret ederler. Zaman aşımlarının 504'e, bağlantı hataları ile bozuk yanıtların 502'ye dönüşmesini bilmek, belirsiz bir olay bildirimini yönlendirilmiş bir soruşturmaya dönüştürür. Varsayılanlar da en az bunun kadar önemli: zaten gönderilmiş POST'ları atlayan yeniden deneme kuralları, on saniye içinde tek bir hatadan sonra bir sunucuyu devre dışı bırakabilen pasif sağlık kontrolleri ve yeni varsayılan olan keepalive bağlantıları, hangi hatanın ne zaman görüneceğini değiştiriyor. NGINX'i sorunlu backend'lerin önünde çalıştıran ekipler için bu tür kaynak koduyla doğrulanmış bir harita, bir sonraki pager uyarısı sırasında değil önceden okumaya değer.