Tiesto

Tiesto

WFN Üye
Konular
635
Mesajlar
635
Çözüm
0
Ticaret Puanı
0
Üyelik
24 Gün
Konum
Antalya
Web Sitesi
Var
Alanı
Domain Uzmanı
1/1
Konu sahibi
502 Bad Gateway, Nginx’in isteği yönlendirdiği arka uç uygulamasından geçerli bir yanıt alamadığını gösterir. Bu nedenle çözüm çoğunlukla Nginx’i yeniden başlatmak değil; proxy_pass ile gösterilen servis, adres-port bilgisi, soket izinleri ve uygulama günlüklerini sırayla kontrol etmektir. Önce Nginx hata günlüğündeki gerçek nedeni bulun, ardından arka uç servisini aynı sunucudan doğrudan test edin; sorun düzeldikten sonra yapılandırmayı test edip yeniden yükleyin.

Önce 502’nin nedenini günlükten belirleyin​


Nginx’in hata günlüğünü dağıtıma ve kurulum yöntemine göre değişen dosya yolundan okuyun. Yaygın bir Linux kurulumunda şu komut kullanılabilir:

Bash: 
sudo tail -n 50 /var/log/nginx/error.log

Aynı anda yeni bir istek göndererek yalnızca o isteğe ait satırları izlemek için:

Bash: 
sudo tail -f /var/log/nginx/error.log

Günlükte özellikle connect() failed, connection refused, no live upstreams, upstream timed out veya upstream sent invalid response ifadelerini arayın. Hata günlüğü başka bir dosyaya yönlendirilmişse nginx -T çıktısındaki error_log tanımını kontrol edin. Nginx, günlük dosyasını error_log yönergesiyle farklı bir konuma yazabilir.
Günlükte görülen ifadeGenellikle ne anlama gelir?İlk işlem
connection refusedArka uç çalışmıyor veya belirtilen portta dinlemiyor.Servis durumunu ve dinleme portunu kontrol edin.
no live upstreamsTanımlı arka uçların tamamı erişilemez durumda.Upstream adreslerini ve servis erişimini doğrulayın.
upstream timed outBağlantı veya yanıt, tanımlı zaman aşımı içinde gerçekleşmedi.Uygulamanın yükünü ve ilgili timeout ayarını inceleyin.
invalid responseArka uçtan beklenen protokole uygun yanıt alınmadı.HTTP, HTTPS, FastCGI veya başka protokol seçiminin doğru olduğunu kontrol edin.
Bu satır 502’nin Nginx’in kendi uygulama hatası olduğunu kanıtlamaz; çoğu durumda sorun Nginx ile arka uç arasındaki iletişimdedir. Kesin nedeni, hata satırındaki upstream adresi ve port ile birlikte değerlendirin.

Arka uç servisini ve portu doğrudan test edin​


Yapılandırma dosyasında ilgili server veya location bloğunu bulun. Örneğin varsayımsal olarak şu tanım, isteği yerel makinedeki 8080 portuna gönderir:

NGINX: 
location / {
    proxy_pass http://127.0.0.1:8080;
}

Önce servisin gerçekten çalışıp çalışmadığını ve hangi adreste dinlediğini kontrol edin:

Bash: 
sudo ss -ltnp | grep ':8080'
curl -i http://127.0.0.1:8080/

ss çıktısında 8080 portu görünmüyorsa Nginx’in hedefi yanlıştır veya uygulama çalışmıyordur. Uygulamanız systemd ile yönetiliyorsa kendi servis adınızla şu komutu çalıştırın:

Bash: 
sudo systemctl status uygulama-servisi
sudo systemctl restart uygulama-servisi

Yeniden başlatmadan önce uygulamanın kendi günlüğündeki başlatma hatasını, port çakışmasını, eksik ortam değişkenini veya veritabanı bağlantı hatasını inceleyin. curl doğrudan 200, 301 ya da uygulamanızın beklediği başka bir yanıt döndürürse arka uç en azından erişilebilir durumdadır; bu, uygulamanın bütün istekleri doğru işlediğini kanıtlamaz. Buna rağmen Nginx 502 döndürüyorsa proxy yapılandırmasındaki adres, protokol veya soket yolunu karşılaştırın.

PHP-FPM gibi Unix soketi kullanan yapılarda proxy_pass yerine fastcgi_pass bulunabilir. Bu durumda soket dosyasının varlığını ve Nginx worker kullanıcısının dosyaya erişim iznini kontrol edin. Soket mevcut değilse PHP-FPM çalışmıyor olabilir; izin hatası varsa yalnızca dosyayı rastgele 777 yapmak yerine servis kullanıcıları ve grup izinleri düzeltilmelidir.

Nginx yapılandırmasını doğrulayın ve güvenli biçimde yeniden yükleyin​


Adres, port veya protokolü düzelttikten sonra doğrudan yeniden başlatmak yerine önce sözdizimini test edin:

Bash: 
sudo nginx -t

Çıktıda syntax is ok ve testin başarılı olduğunu belirten mesajları görmelisiniz. Test başarısızsa Nginx’i yeniden yüklemeyin; hata satırında belirtilen dosya ve satırı düzeltin. Test başarılı olduktan sonra yapılandırmayı kesintisiz biçimde yeniden yükleyin:

Bash: 
sudo systemctl reload nginx

Ardından siteye yeniden istek gönderin ve hata günlüğünü tekrar izleyin. 502 kaybolduysa bağlantı sorunu çözülmüştür. 502 devam ediyorsa yeni hata satırını esas alın; eski günlük satırına bakarak tahminde bulunmayın.

Zaman aşımı durumunda neyi değiştirmelisiniz?​


Günlükte upstream timed out görülüyorsa uygulama yanıt üretmeden önce Nginx’in bekleme süresi dolmuş olabilir. Nginx’te proxy_connect_timeout arka uca bağlantı kurma süresini, proxy_read_timeout ise arka uçtan iki yanıt parçası arasındaki bekleme süresini belirler. Bu değerleri artırmak, çöken veya kilitlenen uygulamayı düzeltmez; yalnızca uygulamanın gerçekten uzun süren işlemlerinde kullanılmalıdır.

Örneğin uzun süren fakat beklenen bir HTTP isteği için ilgili location bloğunda şu ayarlar kullanılabilir:

NGINX: 
proxy_connect_timeout 10s;
proxy_read_timeout 120s;

Değişiklikten sonra mutlaka nginx -t çalıştırın ve başarılıysa systemctl reload nginx uygulayın. Zaman aşımı devam ederse uygulamanın işlem süresini, kaynak kullanımını ve kendi günlüklerini inceleyin; yalnızca timeout değerini sürekli yükseltmek bağlantı kopmalarını gizleyebilir.

Birden fazla upstream sunucusu kullanıyorsanız her hedefi Nginx sunucusundan ayrı ayrı test edin. Bir hedef çalışıyor, diğeri çalışmıyorsa tüm uygulamayı yeniden başlatmak yerine hatalı sunucunun adresini, portunu, güvenlik duvarını ve servis durumunu düzeltin. Sorun dış bir servise bağlanırken oluşuyorsa destek talebine alan adı, istek zamanı, Nginx hata günlüğündeki ilgili satır, hedef adres-port ve doğrudan bağlantı testinin sonucu ekleyin; erişim anahtarlarını, parolaları ve kişisel verileri göndermeyin. Tanılama için geçici olarak artırılan ayrıntılı günlük seviyesini sorun çözüldükten sonra eski seviyesine indirin.
 

Sende şimdi bize katılmak ister misin?

Kayıt ol

Bize katılım kolay ve ücretsizdir!

Üye ol
Foruma git ?

Bu konuyu görüntüleyen kullanıcılar

Bu konuyu şu anda görüntüleyen üye bulunmuyor.
Robotlar:
  • Anthropic
Toplam: 1 (Üye: 0, misafir: 0, robot: 1)