502 Bad Gateway: Proksinin Arkasında Ne Bozuldu

Kim 502 döndürür ve neden

RFC 9110, isteği yerine getirmeye çalışırken eriştiği bir gelen sunucudan geçersiz bir yanıt alan, ağ geçidi veya proksi olarak davranan bir sunucu için 502'yi tanımlar. Her modern yığında en az bir bu türden sıçrama vardır: bir uygulama sunucusunun önünde nginx veya Apache, bir filonun önünde bir yük dengeleyici, kaynağınızın önünde bir CDN, veya üçü birden.

Bu katmanlaşma, bir 502'yi okumanın anahtarıdır. Yanıt veren bileşen bir hata sayfası oluşturacak kadar sağlıklıdır. Arkasındaki bileşen değildir. Yani bir 502, yığınınızı her zaman çalışan bir yarı ve bozuk bir yarıya böler, ve göreviniz sınırın nerede olduğunu bulmaktır.

Komşuları daha dar bir şey söyler. Bir 504 Gateway Timeout, arka ucun erişilebilir ama çok yavaş olduğu anlamına gelir. Bir 500, arka ucun kendisinin çalıştığı ve bir hata fırlattığı anlamına gelir. Bir 502, arka ucun kötü bir yanıt verdiği veya hiç yanıt vermediği anlamına gelir. Tam karşılaştırma 5xx genel bakışındadır.

Yaygın nedenler

• Arka uç süreci çalışmıyor. Çökmüş bir uygulama sunucusu, durdurulmuş bir PHP-FPM havuzu, çıkan veya sağlık kontrolünü geçemeyen bir konteyner. Proksi, kimsenin dinlemediği bir porta bağlanır.
• Arka uç istek ortasında çöktü. Bellek yetersizliği yüzünden sonlandırma veya bir bölümleme hatası, yanıt başlıkları tamamlanmadan bağlantıyı kapatır.
• Yanlış üst akış adresi veya portu. Bir değişiklikten sonra eski porta, veya artık çözümlenmeyen bir ana bilgisayara işaret eden bir yapılandırma.
• Protokol uyuşmazlığı. Proksi, TLS bekleyen bir porta düz HTTP konuşur, veya tersi. Baytlar ayrıştırılamaz, bu yüzden proksi yanıtı geçersiz sayar.
• Yanıt başlıkları çok büyük. Aşırı büyük bir çerez veya alışılmadık derecede uzun bir başlık, proksinin tamponunu aşar, ve yanıt iletilmek yerine reddedilir.
• Keep-alive uyuşmazlığı. Proksi, arka ucun zaten kapattığı boşta bir bağlantıyı yeniden kullanır, bu da aksi halde normal yük altında ara sıra 502'ler üretir.
• Yeniden başlatmalar ve dağıtımlar. Eski sürecin durduğu ve yenisinin henüz bağlantı kabul etmediği herhangi bir pencere.
• Tüm arka uçlar sağlıksız. Geçen üyesi olmayan bir yük dengeleyicinin isteği gönderecek hiçbir yeri yoktur.

Genellikle soruşturmayı sonlandıran proksi günlüğünü okumak

Durum kodu geneldir, ama proksi günlük satırı belirlidir. nginx ile, tanınmaya değer mesajlar şunlardır:

[error] connect() failed (111: Connection refused) while connecting to upstream,
        upstream: "http://127.0.0.1:8080/"

[error] upstream prematurely closed connection while reading response header
        from upstream

[error] recv() failed (104: Connection reset by peer) while reading response
        header from upstream

[error] upstream sent too big header while reading response header from upstream

[error] no live upstreams while connecting to upstream

Her biri farklı bir yere işaret eder:

• connect() failed (111: Connection refused). O adres ve portta hiçbir şey dinlemiyor. Arka uç durdurulmuş, farklı bir arayüze bağlanmış, veya yapılandırmanın söylediğinden farklı bir porttadır.
• upstream prematurely closed connection. Arka uç isteği kabul etti ve sonra yanıtı bitirmeden çöktü veya kapandı. nginx'te değil, uygulamanın içinde çökmeleri, bellek yetersizliği sonlandırmalarını veya bir işçi zaman aşımını arayın.
• connection reset by peer. Benzer, ama bağlantı aktif olarak sıfırlandı. Genellikle arada bir güvenlik duvarı, veya proksinin hala açık saydığı havuzlanmış bir bağlantıyı kapatan bir arka uç.
• upstream sent too big header. Arka uçta değil proksideki bir tampon boyutu sorunu. Yanıt geçerlidir ama proksinin tutmak üzere yapılandırıldığından daha büyüktür.
• no live upstreams. Sağlık kontrolleri her arka ucu çökük olarak işaretlemiştir.

Nasıl düzeltilir

1. Proksiyi atlayarak arka ucu doğrudan test edin. Proksi ana bilgisayarından, üst akış adresinin kendisini isteyin:

   curl -sS -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8080/

   Genel URL'de bir 502 varken burada bir 200, arızanın proksi yapılandırmasında veya ikisi arasındaki bağlantıda olduğu anlamına gelir. Reddedilen bir bağlantı, arka ucun gerçekten çökük olduğu anlamına gelir.
2. Proksinin beklediği adreste arka ucun çalıştığını ve dinlediğini kontrol edin. Proksi bir konteyner adresini ararken 127.0.0.1'e bağlanmak sık görülen bir nedendir.
3. Herhangi bir yapılandırmayı değiştirmeden önce proksi hata günlüğünü okuyun ve mesajı yukarıdaki listeyle eşleştirin.
4. Sonra arka uç günlüğünü okuyun. Aynı saniyedeki bir çökme, bir bellek yetersizliği sonlandırması veya bir işçi zaman aşımı, "erken kapatıldı" durumunu doğrular. Sessizlik bağlantı sorununa işaret eder.
5. Özellikle bir göç veya bir konteyner yeniden derlemesinden sonra, proksi yapılandırmasındaki üst akış adresini, portu ve şemayı doğrulayın.
6. Günlük başlığın çok büyük olduğunu söylüyorsa proksi başlık tamponlarını yükseltin, ve ayrıca başlığın neden büyüdüğünü bulun.
7. Dağıtımları örtüştürün. Yeni süreci başlatın, bir sağlık kontrolünü geçmesini bekleyin, sonra eskisini boşaltıp durdurun. Sağlık kapılı aşamalı güncellemeler, dağıtım zamanı 502'lerine neden olan yeniden başlatma penceresini tamamen ortadan kaldırır.

Yirmi saniye süren bir 502'yi yakalamak

Dağıtım zamanı ve çökme döngüsü 502'leri kısadır. Bir arka uç yeniden başlar, yirmi saniye hata verir ve kurtarılır, bu yüzden biri kontrol ettiğinde site sorunsuzdur ve bakılacak hiçbir şey kalmamıştır. Sürekli çalışan zamanlanmış bir HTTP kontrolü, o pencereleri zaman damgalarıyla kaydeder, ki bu da "bu sabah kısaca tuhaftı"yı dağıtımlar ve yeniden başlatmalarla ilişkilendirebileceğiniz bir düzene dönüştürür. Bir 502, kaynağınız yerine bir CDN kenarından da gelebilir, bu yüzden birkaç bölgeden kontrol etmek, küresel bir arka uç arızasını trafiğinizin bir kısmını etkileyen bir kenar sorunundan ayırır, ki dağıtık erişilebilirlik izlemesinin var olma amacı budur.