Nginx Ayarları ile 502 ve 504 Hatalarını Giderme

Nginx ayarları kaynaklı görünen 502 ve 504 hatalarında önce web sunucusunu rastgele yeniden başlatmak veya tüm zaman aşımı değerlerini yükseltmek yerine, Nginx ile arka uç uygulaması arasındaki iletişimi inceleyin. 502 genellikle geçersiz ya da alınamayan bir arka uç yanıtını, 504 ise yanıtın beklenen sürede gelmediğini gösterir. Doğru düzeltme, hata kaydındaki somut bulguya göre seçilmelidir.

Önce erişim kapsamını ve hatanın sınırını belirleyin

Bu işlem, Nginx yapılandırmasına ve hata günlüklerine erişebilen bir sunucu yöneticisi için uygundur. Paylaşımlı hosting hesabında siteye özel Nginx ayarları, proxy kuralları veya günlükler görünmüyorsa global yapılandırmayı değiştirmeye çalışmayın; paneldeki uygulama günlüklerini ve hosting sağlayıcısının sunduğu hata kayıtlarını kullanın. Yetkiniz yoksa sağlayıcıya hata zamanı, etkilenen URL ve hata koduyla başvurmak güvenli yoldur.

İlk olarak hatanın her istekte mi, yalnızca giriş yapan kullanıcıda mı veya sadece uzun süren bir işlemde mi oluştuğunu ayırın. Statik bir dosya açılırken sorun yok, ancak PHP, Node.js ya da başka bir arka uç uygulamasına yönlenen URL 502 veriyorsa Nginx ile uygulama arasındaki upstream bağlantısını incelemek gerekir. Yalnızca uzun rapor üretiminde 504 görülüyorsa bağlantı kuruluyor olabilir; bu durumda işlem süresi, uygulama logu ve proxy zaman aşımı birlikte değerlendirilir.

502 ve 504 için Nginx ayarları hangi kanıtı sağlar?

Nginx’in hata günlüğü, istemcide görünen koddan daha açıklayıcıdır. Kayıtta connection refused benzeri bir ifade varsa Nginx’in bağlanmaya çalıştığı portta uygulama dinlemiyor olabilir. upstream timed out ifadesi bağlantının veya yanıtın zamanında tamamlanmadığını düşündürür; ancak bunun nedeni yavaş veritabanı sorgusu, uygulama kilitlenmesi ya da gerçekten kısa bir proxy süresi olabilir. invalid header benzeri kayıtlar ise arka ucun HTTP açısından geçersiz yanıt ürettiğine işaret eder.

Karar, bu ayrımdan sonra verilir: bağlantı reddediliyorsa önce uygulamanın çalıştığı servis, port veya Unix soketi ile Nginx upstream tanımının aynı olup olmadığını kontrol edin; yalnızca timeout varsa uygulamanın aynı isteği ne kadar sürede tamamladığını ölçmeden süreyi artırmayın. Arka uç isteği hiç tamamlamıyorsa Nginx’e daha uzun bekleme süresi vermek asıl sorunu gizleyebilir.

Güvenli inceleme ve düzeltme adımları

1. Hata zamanını kaydedin. Etkilenen URL’yi, HTTP kodunu, mümkünse istek saatini ve aynı anda çalışan uygulama işlemini not edin. Böylece eski günlük satırlarını yeni bulgularla karıştırmazsınız. Aynı hatayı kontrollü biçimde yeniden oluşturabiliyorsanız önce mevcut durumu belgeleyin.
2. İlgili Nginx hata günlüğünü bulun. Yönetim panelinde alan adına veya sanal sunucuya ait hata günlüklerini açın; yönetilen sunucuda Nginx’in yapılandırmasında tanımlanan error_log hedefini kullanın. Kayıt belirli bir upstream adresi ve connection refused diyorsa Nginx ayarını hemen büyütmek yerine uygulamanın gerçekten o portta dinleyip dinlemediğini ve upstream’deki adresin güncel olup olmadığını kontrol edin.
3. Arka uç uygulamasını ve eşleşen ayarı karşılaştırın. Uygulamanın servis yöneticisindeki durumunu, uygulama loglarını ve Nginx’teki proxy_pass ya da benzer upstream hedefini birlikte inceleyin. Uygulama başka bir portta dinliyor, Nginx eski porta yönleniyorsa yalnızca ilgili upstream hedefini doğru değere getirin. Uygulama durmuşsa önce neden durduğunu ve uygulamanın kendi güvenli başlatma prosedürünü inceleyin; rastgele servis yeniden başlatmayı çözüm kabul etmeyin.
4. Yapılandırmayı yüklemeden test edin. Yönetici erişiminiz olan Linux sunucuda, yapılandırma değişikliğinden önce orijinal dosyanın veya panel ayarının kopyasını saklayın. Nginx’in yapılandırma test aracını, genellikle nginx -t, çalıştırarak sözdizimi ve dosya referanslarını kontrol edin. Başarılı test yapılandırmanın geçerli olduğunu gösterir; arka uç uygulamasının çalıştığını veya isteğin başarılı olacağını tek başına kanıtlamaz. Test başarısızsa değişikliği etkinleştirmeyin ve hatalı satırı düzeltin.
5. Aynı isteği tekrar edip yeni kanıtı inceleyin. Değişiklikten sonra daha önce başarısız olan aynı URL’yi, mümkünse aynı işlem koşuluyla açın. Yeni hata günlüğünde zaman damgası isteğin yeni denemesine ait olmalıdır. connection refused kaydı ortadan kalkıp uygulama yanıtı geliyorsa bağlantı hedefi düzeltilmiştir. Yeni kayıtta upstream timed out varsa ilk sorunun çözüldüğünü, fakat uygulamanın yanıt süresi veya yeni bir katmanın ayrıca incelenmesi gerektiğini kabul edin.

Değişiklik sonrası hata sürüyorsa yalnızca bir faktörü değiştirmiş olduğunuzdan emin olun. Uygulama logunda aynı zaman aralığında veritabanı, bellek veya işlem süresi sorunu görünüyorsa Nginx timeout değerini artırmak yerine uygulama katmanını ele alın. Sorun, yalnızca meşru biçimde uzun süren ve uygulama tarafından başarıyla tamamlanan bir işlemde oluşuyor; loglar da bağlantının kurulduğunu gösteriyorsa ilgili proxy_read_timeout değerinin kontrollü artırılması düşünülebilir. Orijinal değeri saklayın, küçük bir değişiklik yapın ve yine aynı isteği tekrarlayın.

Hipotetik bir bulgu nasıl yorumlanır?

Örneğin bir rapor URL’si 504 döndürsün ve Nginx günlüğünde istek saatine uyan upstream timed out while reading response kaydı bulunsun. Uygulama günlüğü rapor sorgusunun hâlâ çalıştığını gösteriyorsa önce sorgunun neden uzadığını incelemek daha uygundur; Nginx timeout’unu artırmak yalnızca bekleme süresini uzatır. Uygulama raporu normal sürede tamamlıyor, fakat Nginx’in okuma süresi sınırı belirgin biçimde daha kısaysa, orijinal değeri kaydedip yalnız ilgili proxy okuma süresini kademeli artırabilirsiniz. Yeni denemede 504 yerine tamamlanmış yanıt ve eşleşen yeni log satırı görülmelidir.

Buna karşılık aynı örnekte uygulama logu hiç yeni istek göstermiyor ve Nginx kaydı connection refused diyorsa timeout ayarıyla uğraşmak yanlış yöndür. Uygulamanın portu, soket yolu veya servis durumu ile upstream tanımını karşılaştırın. Düzeltme sonrası uygulama isteği görmeye başlıyorsa bağlantı katmanı onarılmıştır; bu kez oluşan yeni hata varsa onu ayrı bir bulgu olarak değerlendirin. Sorun devam ederse geçici değişikliği geri alıp hizmet sağlayıcının veya uygulama yöneticisinin arka uç durumunu incelemesini isteyin.

Değişiklik yapmadan önce ve sonra kontrol

Nginx ayarlarında güvenli çalışma, birden fazla limiti aynı anda yükseltmemeye dayanır. Orijinal upstream adresini, timeout değerini ve değişiklik saatini kaydedin; yapılandırma testi başarısızsa etkinleştirmeyin. Başarılı bir yanıt tek başına yeterli değildir: aynı URL’nin yeni denemesi, Nginx hata günlüğündeki yeni zaman damgası ve uygulama logundaki karşılığı birlikte incelenmelidir.

Paylaşımlı hosting kullanıyorsanız erişebildiğiniz günlükleri ve hata saatlerini hazırlayarak İyibirNet üzerinden ilgili hizmet ve yönetim seçeneklerini inceleyebilirsiniz. Yönetici erişiminiz varsa bir sonraki güvenli adım, tek bir ayarı değiştirip yapılandırma testini çalıştırmak ve başarısız isteği aynı koşullarda yeniden gözlemlemektir.