502 Bad Gateway Açıklandı: Ne Anlama Geldiği, Neden Oluştuğu ve Nasıl Sorun Giderileceği

Anahtar Kelimeler

Bu hızlı sözlük, daha derinlemesine açıklama aşamasında kafa karışıklığı yaratması muhtemel altyapı kelimelerini kapsar.

Neden 502 Hatası Bu Kadar Yıkıcı Hissettiriyor

Bir deployment’ı push edersiniz, siteyi yeniden yüklersiniz ve domain anında yanıt verir — sadece uygulamanızla değil. Ya da bir müşteri Checkout’a tıklar, sayfa yüklenir ve işlem keskin bir 502 Bad Gateway mesajının arkasında ölür. Bu hatayı bu kadar stresli kılan şey budur: site erişilebilir, ancak devri tamamlamak için yeterince sağlıklı değildir.

502 garip bir orta durumda oturur. Tamamen kaybolmuş gibi görünmez, ancak çalışan bir hizmet gibi de davranmaz. Geliştiriciler için, bozuk bir deploy veya API zinciri anlamına gelebilir. İşletme sahipleri için, kayıp güven veya kesintiye uğramış gelir. Takımlar için, en kötü kısım genellikle sahiplik: sorunun gerçekten hangi katmanı sahibi?

Buna yaklaşmanın yararlı yolu tahmin etmek değildir. İlk olarak, hatanın ne anlama geldiğini tanımlayın. Ardından, istek zincirinde nerede yaşadığını haritala. Ardından, hatayı mantıksal olarak, bir seferde bir devri sorun giderin. Zinciri görebildiğiniz zaman, hata rastgele görünmeyi bırakır.

502 Bad Gateway Aslında Ne Anlama Geliyor

Bir 502 Bad Gateway hatası genellikle ağ geçidi veya proxy görevi gören bir sunucunun, arkasındaki bir sonraki katmandan aldığı yanıtı kullanamadığı anlamına gelir. Basit bir deyişle: bir sunucu isteğinizi başka bir sunucuya iletmeye çalıştı ve bu iletim o kadar kötü başarısız oldu ki ön tarafta bulunan sunucu normal bir sonuç döndüremedi.

📝 Not: Upstream kendi başına geçerli bir HTTP hatası döndürürse, proxy genellikle bu hatayı iletir. Uygulama gerçek bir 503 Service Unavailable döndürürse, ön katman normalde bu 503‘ü iletmeli, 502 uydurmamalıdır. 502 yanıtın kendisinin kullanılamaz olduğu anlamına gelir. Zamanında kullanılabilir bir yanıt gelmezse, bu genellikle 504 olur.

5xx hatalarını yanlış okumayı durdurmak için en hızlı yol, onları hatanın nerede yaşandığına ve hangi soruyu ilk olarak tetiklediğine göre ayırmaktır:

⚠️ Uyarı: 500, 502, 503 ve 504‘ü tek bir genel “sunucu kapalı” kategorisine indirmeyin. Bunlar farklı hata şekillerine işaret eder ve bu, ilk olarak neyi kontrol etmeniz gerektiğini değiştirir.

Bu tanım açık olduktan sonra, bir sonraki soru çok daha yararlı hale gelir: gerçek bir yığında bu başarısız iletim aslında nerede gerçekleşir?

Hatanın Gerçek Bir İstek Zincirinde Nerede Oluştuğu

Çoğu modern istek tarayıcıdan uygulamaya doğrudan gitmez. Katmanları geçer: tarayıcıdan CDN veya edge’e, edge’den reverse proxy veya load balancer’a, proxy’den uygulama sürecine. Bir 502 bu handoff noktalarından birinde görünür hale gelir.

Basitleştirilmiş istek zinciri: Browser → CDN/Edge → Reverse Proxy / Load Balancer → App / Process

Bir reverse proxy genel isteği kabul eder ve onu dahili olarak iletir. Bir load balancer benzer bir şey yapar, ancak birden fazla sağlıklı hedef arasında seçim yapabilir. Her iki durumda da, ön katman isteği yönlendiriyor, kendisi iş mantığını yapmıyor.

Resepsiyon masası benzetmesi burada iyi çalışır. Proxy’yi bir ofis binasındaki resepsiyon masası olarak düşünün. Ziyaretçiyi kontrol eder, doğru ofisi arar ve ziyaretçiyi teslim etmeye çalışır. Ofis cevap vermezse, yanlış hattan cevap verirse veya resepsiyon masasının kullanamayacağı bir yanıt verirse, resepsiyon masası hatayı döndürür. Bu nedenle görünür hata genellikle proxy katmanında görünür, hatta daha derin neden başka yerde olsa bile.

📝 Not: Proxy genellikle hatanın habercisidir, orijinal nedeni değildir.

O resepsiyon masasının arkasındaki “sonraki sunucu” bir bağlantı noktasında normal bir HTTP hizmeti, 127.0.0.1:3000 gibi bir uygulama dinleyicisi veya PHP-FPM gibi yerel socket tarafından desteklenen bir süreç olabilir. Kök sorun proxy’de yaşamak zorunda değildir. Kötü bir dağıtım, çökmüş bir uygulama worker’ı veya hatta bir veritabanı hatası, backend’i 502’nin yüzeyde çıktığı kadar kötü şekilde bozabilir.

Edge hizmetleri bir ek twist ekler. Cloudflare gibi bir CDN, yığının daha derinlerinden origin tarafındaki bir 502’yi iletebilir veya edge-to-origin handoff başarısız olduğunda kendi başına bir 502 oluşturabilir. Bu nedenle “bu hatayı kim döndürdü?” ilk pratik sorudur, bir sonradan düşünülen şey değildir.

502 Hataları Neden Oluşur: Ana Hata Kategorileri

502’yi tek bir gizemli olay olarak görmeyi bıraktığınızda, hata nedenleri yönetilmesi çok daha kolay hale gelir. Çoğu olay üç yeniden kullanılabilir kategoriye ayrılır: upstream kullanılamaz durumda, aktarım yanlış yapılandırılmış veya yanıt gateway’in kullanamayacağı bir biçimde geri gelir.

İlk grup açık olandır: upstream kullanılabilir durumda değildir. Belki uygulama dağıtımdan sonra çöktü. Belki hizmet hiç yeniden başlamadı. Belki bir PHP-FPM havuzu öldü veya bir hedef sağlıksız olarak işaretlendi ve rotasyondan çıkarıldı. Bu klasik “hizmet kapalı” senaryosudur, ancak bu sadece 502 ortamının bir dilimi.

İkinci grup aktarım uyuşmazlığıdır. Burada, her iki katman da çalışıyor olabilir, ancak birbirlerine nasıl ulaşacakları konusunda anlaşmazlık vardır. Proxy yanlış porta işaret edebilir. Bir hostname yanlış çözümlenebilir. Bir firewall yolu engelleyebilir. Bir katman HTTPS beklerken sonraki katman sadece düz HTTP konuşabilir. Bir socket yolu değişmiş olabilir. Bu durumlarda, uygulama sağlıklı olabilir ve katmanlar arasındaki bağlantı yine de bozulmuştur.

Üçüncü grup daha zordur: upstream yanıt verir, ancak gateway’in kullanabileceği bir şekilde değil. Bir hedef TCP bağlantısını sıfırlayabilir, çok erken kapatabilir, hatalı biçimlendirilmiş veya aşırı boyutlu başlıklar gönderebilir veya yük altında kısmi çıktı döndürebilir. Uygulama sadece “kapalı” değildir; gateway’in aldığını reddetmesi için yeterince kötü yanıt vermektedir.

Bu aynı zamanda 502’nin sadece bir zaman aşımı hikayesi olmadığı nedenidir. Bazı zaman aşımı durumları 502 değil, 504 Gateway Timeout olur. Cloudflare, origin bağlantısı veya sıkıştırma bozulduğunda edge tarafından oluşturulan 502’leri ortaya çıkarabilir. Yük dengeleyiciler, kaydı silme zamanlaması sorunları veya TLS el sıkışması hataları sırasında 502’ler yayabilir. “Hizmet kapalı” bir neden kategorisidir, hatanın tanımı değildir.

Bu zihinsel model, bir yapılandırma dosyasına dokunmadan önce size gerçek bir kontrol listesi verir. Muhtemelen hangi grupta olduğunuzu sorun, ardından kanıt için test edin. Bu, sorun giderme dizisini ritüelci yerine mantıklı hissettirir.

502 Hataları için Akıllı Sorun Giderme Sırası

502’yi en hızlı şekilde gidermek için hangi katmanın hatayı döndürdüğünü belirlemek, ardından herhangi bir şey değiştirmeden önce o katmanın arkasındaki bir sonraki adımı test etmektir. Amaç, başarısız el değiştirmenin nerede olduğunu kanıtlamaktır.

💡 İpucu: Herhangi bir şeyi yeniden başlatmadan veya düzenlemeden önce, 502‘yi kimin döndürdüğünü belirleyin. Temiz bir atıf adımı genellikle baskı altında insanların denediği ilk beş “çözümden” daha fazla zaman kazandırır.

Aşama 1: Katmanı belirleyin

Genel taraftan başlayın ve internet’e açık katmanın gerçekte ne döndürdüğünü sorun:

curl -I https://example.com

Bu, genel URL’den HTTP durumunu ve başlıkları gösterir. Başlıklar açıkça bir CDN, yük dengeleyici veya ters proxy’ye aitse, ilk ipucunuza sahipsiniz. Hata sayfası Cloudflare markalıysa, Cloudflare 502’yi kendisi oluşturmuş olabilir; markalı değilse, kenar yalnızca orijin tarafındaki bir hatayı iletebilir. cf-error-type veya cf-error-origin gibi başlıklar Cloudflare tarafından oluşturulan hata sayfalarında görünebilir; bu tam olarak her 502’de görünmedikleri için yararlıdır.

📝 Not: Yalnızca bir ziyaretçi hatayı görürken diğerleri siteye ulaşabiliyorsa, yerel VPN, proxy, güvenlik duvarı veya DNS ayarları sorunun bir parçası olabilir. 502 genellikle sunucu tarafındadır, ancak izole bir istemci yolu gözlemlediğiniz şeyi karmaşık hale getirebilir.

Aşama 2: Yukarı akış yolunu doğrulayın

Hangi katmanın 502 döndürdüğünü öğrendikten sonra, arkasındaki bir sonraki adımı test edin. Ters proxy söz konusuysa, hem proxy hem de arka uç hizmetinin çalıştığını ve beklenen dinleyicinin var olduğunu doğrulayın:

systemctl status nginx
systemctl status <app-service>
ss -tlnp

<app-service> yerine arka uç hizmet adınızı yazın. systemctl status proxy veya uygulama işleminin canlı, başarısız veya yeniden başlatılıp başlatılmadığını söyler. ss -tlnp beklediğiniz portta gerçekten bir şeyin dinlenip dinlenmediğini gösterir.

Ardından arka uç ortasında proxy olmadan doğrudan yanıt verip vermediğini test edin:

curl -i http://127.0.0.1:3000

Doğrudan istek çalışırsa ancak genel URL hala 502 dönerse, arka uç sağlıklı olabilir ve el değiştirme gerçek sorun olabilir. Bu, sizi uygulama kodu yerine proxy hedef ayarları, protokol uyuşmazlıkları, yukarı akış ana bilgisayar adları, TLS beklentileri veya güvenlik duvarı kurallarına yönlendirir.

Aşama 3: Komutları tören değil, kanıt olarak kullanın

Doğrudan kontrollerin ardından, el değiştirmenin neden başarısız olduğunu açıklayan kanıtlara geçin:

journalctl -u nginx -u <app-service> --since "15 min ago"
dig +short example.com
nginx -t

Bu üç kontrol farklı soruları yanıtlar. journalctl son çökmeler, sıfırlamalar, zaman aşımı ipuçları ve dağıtımla ilgili hataları ortaya çıkarır. dig +short bağlı olduğunuz ana bilgisayar adının sunucunun beklediği şekilde çözülüp çözülmediğini söyler. nginx -t herhangi bir şeyi yeniden yüklemeden önce ters proxy sözdizimini doğrular; bu önemlidir çünkü kötü bir yukarı akış tanımı arka uç iyi olsa bile 502 üretebilir.

Pratik sinyaller genellikle şöyle görünür:

Hatırlanacak temel desen budur: katmanı belirleyin, bir sonraki adımı doğrulayın, ardından uyuşmazlığı açıklamak için günlükleri ve doğrudan testleri kullanın. Önce kanıt. Ayarlar ikinci.

Barındırma Modeline Göre Sorun Giderme Yolu Nasıl Değişir

502’den sonraki adım, yığının ne kadarını kontrol ettiğinize bağlıdır. Sorun giderme mantığı aynı kalır, ancak paylaşımlı barındırma, VPS, özel sunucular ve edge-proxy kurulumları arasında kendiniz inceleyebileceğiniz miktar çok farklı olur.

📝 Not: Paylaşımlı barındırmada, escalation bir çıkış yolu değildir. Genellikle doğru teknik harekettir çünkü 502 için önemli olan katmanlar görüş alanınızın dışında olabilir.

Paylaşımlı barındırmada yapabileceğiniz en yararlı şey kanıt toplamaktır: zaman, etkilenen URL, hatanın sabit mi yoksa aralıklı mı olduğu ve bir deploy veya konfigürasyon değişikliğinden sonra mı başladığı. Bu, desteğe harekete geçirilebilir bir şey verir. Reverse proxy, uygulama servisi veya sunucu loglarını kontrol etmiyorsanız, anlamlı katman-katman tanı hızlı biter.

VPS’de, servisler, dinleyiciler, loglar ve proxy konfigürasyonunu doğrudan inceleyebileceğiniz için tam iş akışı gerçekçi hale gelir. Reverse-proxy sorun giderme buraya aittir. AlexHost VPS altyapısında, systemctl, journalctl, ss, upstream hedefleri ve Nginx konfigürasyonunu kontrol etmek normal sahipliğin bir parçasıdır, her zaman destek arkasında gizli bir şey değildir.

Özel sunucu aynı görünürlüğü verir, ancak daha fazla sorumluluk ile. Tam yığının daha fazlasına ve muhtemelen çevresindeki ağ varsayımlarının daha fazlasına sahipsiniz. Ön tarafta bir CDN veya başka bir edge servisi eklerseniz, ilk sahiplik sorusu aynı kalır: edge 502’yi oluşturdu mu, yoksa origin-tarafı hatası iletdi mi? Daha fazla kontrol sorun gidermeyi varsayılan olarak daha basit hale getirmez. Size inceleyebileceğiniz daha fazla yer verir.

Katmanlı Düşün, Panik Yapma

Bir 502 Bad Gateway hatası, onu gerçekte ne olduğu için ele aldığınızda — rastgele bir tarayıcı olayı değil, başarısız bir sunucu-sunucu el değiştirmesi — gizemli hissetmeyi bırakır. Tarayıcı sadece bunu fark ettiğiniz yerdir. Gerçek hikaye, isteği bir sonrakine ileten ve geri kullanılabilir bir şey alamayan katmanda yaşar.

Yani sırayı basit tutun: katmanı belirleyin, sonraki adımı kontrol edin, doğrudan testler ve loglarla doğrulayın ve kanıtlar belirli bir yere işaret ettiğinde ayarları değiştirin. Tekrarlayan olaylar sizi daha derin log, proxy ve hizmet görünürlüğüne doğru itmeye devam ederse, bu noktada daha yüksek kontrol ortamları — AlexHost VPS veya özel sunucular dahil — pazarlama nedenleriyle değil, operasyonel nedenlerle kullanışlı hale gelir. Burada yöntem ezberlemekten daha iyidir.