- Konu sahibi
- #1
Nginx upstream bağlantı hatalarını araştırırken önce Nginx hata günlüğündeki tam mesajı bulun, ardından aynı upstream adresine Nginx dışından bağlanmayı deneyin.
Nginx, istemci isteğini uygulama sunucusuna veya başka bir HTTP servisine aktarıyorsa bu hedefe upstream denir. Örneğin Nginx
En sık görülen anlamlar şunlardır:
Tablodaki mesajı hata günlüğünde zaman aralığıyla birlikte arayın. Aynı dakikadaki access log kaydı, hatanın hangi URL ve istemci isteği sırasında oluştuğunu gösterir.
Aşağıdaki örnekte upstream hedefi
En küçük test senaryosu, Nginx’in yerel bir HTTP uygulamasına proxy geçmesidir. Aşağıdaki upstream ve server blokları ana yapılandırmanın http kapsamında yer alır; mevcut dosyanıza ikinci bir http bloğu kopyalamayın:
Bu yapılandırma
Yalnızca 502 sayfasına bakmak: 502, bağlantının kurulamadığını veya geçersiz upstream yanıtı alındığını gösterebilir; kesin neden error log’dadır.
Nginx’in bulunduğu makineyi test etmemek: Kendi bilgisayarınızdan backend’e erişebilmeniz, Nginx sunucusunun erişebildiği anlamına gelmez.
Yanlış portu düzeltmeye çalışmak: Uygulamanın gerçekten hangi adreste dinlediğini
Zaman aşımını rastgele artırmak: Bu, yavaş veya kilitlenmiş uygulamayı gizleyebilir. Önce uygulamanın neden yanıt vermediğini belirleyin; süre ayarı ancak beklenen işlem süresi ve kaynak kullanımı anlaşıldıktan sonra ele alınmalıdır.
connect() failed, connection refused, timed out ve no live upstreams farklı arızalara işaret eder. Bağlantı testini Nginx ile aynı ağ ad alanından ve mümkün olduğunca aynı erişim koşullarından yapın. Aşağıdaki curl örnekleri HTTP upstream içindir; FastCGI/PHP-FPM portuna normal HTTP isteği göndermek geçerli bir FPM testi değildir. Yapılandırmayı nginx -t ile doğrulayın; başarılı testten sonra ilgili servisin çalıştığını, dinlediği adresi ve Nginx’in o adrese erişebildiğini kontrol edin.Upstream hatası ne anlama gelir?
Nginx, istemci isteğini uygulama sunucusuna veya başka bir HTTP servisine aktarıyorsa bu hedefe upstream denir. Örneğin Nginx
127.0.0.1:8080 üzerindeki uygulamaya bağlanamıyorsa istemciye genellikle 502 veya 504 döner. Hata kodu yalnızca sonucu gösterir; asıl ipucu yapılandırılmış error_log kaydındadır. /var/log/nginx/error.log yaygın bir yoldur; kurulumunuz dosyaya,stderr veya syslog’a yazıyor olabilir.En sık görülen anlamlar şunlardır:
Tablodaki mesajı hata günlüğünde zaman aralığıyla birlikte arayın. Aynı dakikadaki access log kaydı, hatanın hangi URL ve istemci isteği sırasında oluştuğunu gösterir.
Uygulanabilir teşhis sırası
Aşağıdaki örnekte upstream hedefi
127.0.0.1:8080 olarak varsayılmıştır. Kendi yapılandırmanızdaki adresi bunun yerine kullanın.- Nginx yapılandırmasını test edin:
sudo nginx -t. Başarı çıktısında yapılandırma sözdiziminin doğru olduğu belirtilir. Hata alırsanız reload yapmayın. Diskteki hatalı yeni yapılandırma ile hâlâ çalışan önceki yapılandırmayı ayırın; okuma yetkisi hatasını sözdizimi hatası sanmayın. - Hata kaydını izleyin:
sudo tail -n 50 /var/log/nginx/error.log.connect() failed,timed outveyahost not foundbölümünü tam olarak not alın. Mesajın yalnızca son kısmını değil, hedef adresi de kaydedin. - Uygulama servisinin durumunu kontrol edin:
sudo systemctl status uygulama-servisi. Servis yoksa veya durmuşsasudo systemctl restart uygulama-servisikomutunu yalnızca uygulamanın normal başlatma prosedürünü biliyorsanız çalıştırın. Başlatma başarısızsa servis günlüğünü inceleyin; Nginx ayarını değiştirmek sorunu çözmez. - Hedefin gerçekten dinlediğini kontrol edin:
sudo ss -Hltnp 'sport = :8080'. Komut başarılı fakat satır yoksa incelenen ağ ad alanında bu TCP portu dinlenmiyordur. Uygulama başka bir portta dinliyorsa upstream tanımını ona göre düzeltin. Başka bir adrese bağlıysa Nginx’in kullandığılocalhostile aynı adres ailesine erişebildiğini doğrulayın. - Nginx sunucusundan doğrudan istek gönderin:
curl -i --max-time 5 http://127.0.0.1:8080/. HTTP yanıtı alırsanız curl işleminin temel ağ bağlantısı kuruluyor demektir; bu, Nginx worker’ın aynı izin/ağgüvenlik koşullarına sahip olduğunu kanıtlamaz. sonraki inceleme uygulamanın belirli URL’si, başlıkları, yetkilendirmesi veya yanıt süresidir.Connection refusedalırsanız dinleme, servis veya port yanlıştır. Zaman aşımı alırsanız uygulama günlüğü, kaynak kullanımı ve bağımlı servisleri inceleyin. - Düzeltmeden sonra tekrar
sudo nginx -tçalıştırın ve başarılıysasudo systemctl reload nginxuygulayın. Ardından aynı isteği dışarıdan tekrarlayıp access ve error log kayıtlarını birlikte karşılaştırın.
| Günlük mesajı | Muhtemel neden | İlk kontrol | Sonraki adım |
|---|---|---|---|
| connection refused | Servis çalışmıyor veya port dinlenmiyor | Servis durumu ve dinleme portu | Uygulamayı başlatın ya da Nginx portunu düzeltin |
| upstream timed out | Servis yanıt vermiyor, aşırı yavaş veya ağ erişimi engelli | Yerel istek ve uygulama günlükleri | Yükü, bağımlılıkları ve uygun zaman aşımını inceleyin |
| host not found in upstream | Ad çözümleme başarısız veya ad yanlış | Yapılandırmadaki hostname ve DNS çözümlemesi | Doğru adı kullanın ve çözümlemeyi düzeltin |
| no live upstreams | Seçim için uygun hedef kalmamış; hedefler geçici olarak başarısız sayılmış veya down işaretli olabilir | Her backend hedefini ayrı test edin | Çalışmayan hedefi düzeltin veya havuzdan çıkarın |
Somut yapılandırma örneği
En küçük test senaryosu, Nginx’in yerel bir HTTP uygulamasına proxy geçmesidir. Aşağıdaki upstream ve server blokları ana yapılandırmanın http kapsamında yer alır; mevcut dosyanıza ikinci bir http bloğu kopyalamayın:
Kod:
upstream app_backend {
server 127.0.0.1:8080;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://app_backend;
}
}Bu yapılandırma
nginx -t ile başarıyla doğrulanır ve 127.0.0.1:8080 isteği HTTP yanıtı verirse curl kullanan sürecin hedefe eriştiği anlaşılır. Son doğrulama, isteğin Nginx üzerinden geçmesi ve worker hata kaydında yeni bağlantı sorunu bulunmamasıdır. Başarı yoksa önce Nginx’i değil, 127.0.0.1:8080 üzerinde dinleyen uygulamayı ve onun günlüklerini düzeltin. Uygulama Unix socket kullanıyorsa port testi yerine socket dosyasının varlığını, sahipliğini ve Nginx çalışan kullanıcısının erişimini kontrol edin.Sık yapılan hatalar
Yalnızca 502 sayfasına bakmak: 502, bağlantının kurulamadığını veya geçersiz upstream yanıtı alındığını gösterebilir; kesin neden error log’dadır.
Nginx’in bulunduğu makineyi test etmemek: Kendi bilgisayarınızdan backend’e erişebilmeniz, Nginx sunucusunun erişebildiği anlamına gelmez.
curl testini Nginx’in çalıştığı makinede yapın.Yanlış portu düzeltmeye çalışmak: Uygulamanın gerçekten hangi adreste dinlediğini
ss ile görmeden port değiştirmeyin. Container, proxy veya Unix socket kullanan yapılarda görünen servis portu ile Nginx hedefi farklı olabilir.Zaman aşımını rastgele artırmak: Bu, yavaş veya kilitlenmiş uygulamayı gizleyebilir. Önce uygulamanın neden yanıt vermediğini belirleyin; süre ayarı ancak beklenen işlem süresi ve kaynak kullanımı anlaşıldıktan sonra ele alınmalıdır.
