X

Lütfen Ülke (Bölge) Seçiniz

Türkiye (Türkçe)Türkiye (Türkçe) Worldwide (English)Worldwide (English)
X

Lütfen Para Birimi Seçiniz

₺ Türk Lirası $ US Dollar
X

Lütfen Ülke (Bölge) Seçiniz

Türkiye (Türkçe)Türkiye (Türkçe) Worldwide (English)Worldwide (English)
X

Lütfen Para Birimi Seçiniz

₺ Türk Lirası $ US Dollar

Nginx Ayarları ile 413 Yükleme Hatasını Güvenle Çözme

AnasayfaYazılarTeknik RehberlerNginx Ayarları ile 413 Yükleme Hata...

Nginx ayarları içinde 413 Request Entity Too Large hatasını çözmek için önce yüklenen dosya boyutunun hangi katmanda reddedildiğini belirleyin. Yönetici erişiminiz varsa ilgili alan adı veya konum için client_max_body_size değerini kontrol edin; yalnızca gereken kapsamda değişiklik yapın, yapılandırmayı doğrulayın ve aynı yükleme isteğini yeni günlük kayıtlarıyla tekrar test edin.

413 hatası hangi ayarı gösterir?

413, istemcinin gönderdiği istek gövdesinin sunucunun kabul ettiği sınırı aştığını ifade eder. Dosya yükleme sırasında Nginx’in verdiği bir 413 yanıtı görüyorsanız en önemli ayar genellikle client_max_body_size direktifidir. Bu değer Nginx’in bir istek gövdesi için kabul edeceği üst sınırı belirler; uygulamanın kendi yükleme sınırı, bir CDN veya başka bir ters vekil sunucu bu değerden bağımsız olarak daha düşük bir sınır uygulayabilir.

Bu rehber, yapılandırma dosyalarına ve Nginx’in test ile yeniden yükleme işlemlerine erişebildiğiniz yönetilen bir Linux sunucusu içindir. Paylaşımlı hosting panelinde dosya düzenleme veya servis yenileme yetkisi bulunmayabilir. Böyle bir ortamda panelde alan adına ait PHP, uygulama ya da istek boyutu ayarı sunuluyorsa yalnızca o alanı kullanın; panelin Nginx katmanını yönetip yönetmediği belli değilse rastgele bir dosyayı değiştirmeyin.

Değişiklikten önce doğru katmanı ayırın

Yanıtın kaynağını ve isteğin türünü belirleyin

Hata yalnızca büyük dosya yüklenirken oluşuyor, küçük dosyalar başarıyla gönderiliyorsa boyut sınırı güçlü bir adaydır. Buna karşılık hata uzun süren bir yüklemenin sonunda geliyorsa zaman aşımı; uygulama yanıtı oluşturduktan sonra görünüyorsa uygulamanın kendi sınırı veya doğrulaması incelenmelidir. İstek Nginx’e gelmeden önce bir CDN, güvenlik duvarı ya da hosting katmanından geçiyorsa dış katmandaki sınır da sonucu belirleyebilir.

Önce etkilenen alan adını, URL’yi, yaklaşık dosya boyutunu ve hatanın saatini not edin. Nginx’in hata günlüğünde aynı dakikaya ait kayıtlarda isteğin reddedildiğine dair bir satır varsa Nginx sınırını ele alın. Nginx günlüğünde kayıt yoksa, isteğin başka bir proxy tarafından durdurulması veya günlük seviyesinin farklı olması mümkündür; bu durumda Nginx değerini artırmak tek başına çözüm olmayabilir.

Nginx ayarları güvenli biçimde nasıl değiştirilir?

  1. Etkin yapılandırmayı bulun. Yönetici kabuğunda yalnızca okuma amacıyla nginx -T komutunu çalıştırın. Bu çıktı, ana yapılandırmayla birlikte dahil edilen sanal sunucu dosyalarını gösterir. Etkilenen alan adının server bloğunu ve varsa yükleme yapılan location bloğunu bulun. Değiştirmeden önce mevcut client_max_body_size değerini ve dosyanın yedek kopyasını kaydedin.
  2. Miras alınan değeri yorumlayın. Direktif bir http, server veya location bloğunda tanımlanabilir. Daha dar olan location kapsamı, aynı sunucudaki diğer URL’leri etkilemeden uygulanabilir; ancak doğru konum eşleşmiyorsa beklediğiniz sonucu vermez. Değer hiç tanımlanmamışsa Nginx’in varsayılan davranışı devreye girebilir. Hangi bloğun isteği karşıladığını kesinleştirmeden genel yapılandırmaya yüksek bir sınır eklemeyin.
  3. Yalnızca gerekli kapsamı değiştirin. Örneğin belirli bir uygulamanın yönetim yüklemeleri için gereken sınır 20 MB ise, ilgili server veya doğru location bloğuna client_max_body_size 20M; ekleyin ya da mevcut değeri buna göre güncelleyin. Gerçek ihtiyacı aşan çok büyük bir değer, istemeden büyük istekleri kabul ettirerek kaynak kullanımını artırabilir. Uygulamanın kendi dosya sınırı 8 MB ise Nginx’i 20 MB yapmak uygulamayı 20 MB’a çıkarmaz; iki sınırdan düşük olanı geçerli olur.
  4. Sözdizimini doğrulayın. Kaydedilen dosyanın ardından nginx -t çalıştırın. Başarılı sonuç, yapılandırmanın okunabildiğini ve sözdizimi hatası bulunmadığını gösterir; yüklemenin kesinlikle çalışacağını kanıtlamaz. Test başarısızsa yeniden yükleme yapmayın, hata mesajının işaret ettiği dosyadaki son değişikliği geri alın ve önceki geçerli değeri koruyun.
  5. Yapılandırmayı yeniden yükleyin ve aynı isteği tekrarlayın. Test başarılıysa dağıtımınızın standart, zarif Nginx yeniden yükleme yöntemini kullanın; panel yönetiyorsa paneldeki yapılandırmayı uygulama işlevini tercih edin. Servisi durdurup başlatmak yerine yeniden yükleme, mevcut bağlantıların davranışını gereksiz yere değiştirmemek açısından daha uygundur. Ardından öncekiyle aynı dosya boyutunu aynı URL’ye gönderin ve yeni saat bilgisiyle Nginx hata günlüğünü ve uygulama günlüğünü inceleyin.

Sonucu nasıl yorumlamalısınız?

Aynı istek artık uygulamaya ulaşıyor ve uygulama kendi yükleme sınırını belirten bir hata veriyorsa Nginx düzeltmesi işe yaramıştır; sonraki değişiklik uygulamanın ilgili ayarında, örneğin yönetim panelindeki medya sınırında yapılmalıdır. İstek yine 413 ile dönüyorsa ve Nginx günlüğünde yeni kayıt oluşuyorsa yanlış location bloğu, daha düşük bir iç değer veya önünde bulunan başka bir proxy araştırılmalıdır. Nginx günlüğünde yeni 413 kaydı yoksa dış proxy ya da uygulama katmanına bakın.

Diyelim ki bir içerik yönetim uygulamasında yalnızca 12 MB üzerindeki görseller reddediliyor ve Nginx günlüğü 413 kaydını gösteriyor. İlgili yükleme konumunda değer 8M ise bunu 20M yapmak mantıklı bir hedef olabilir; ancak uygulamanın da en az 20 MB kabul ettiğini doğrulamak gerekir. Değişiklikten sonra aynı 15 MB dosya başarıyla yükleniyor, fakat 25 MB dosya yine uygulama hatası veriyorsa Nginx’i daha fazla büyütmek yerine uygulama sınırı ve gereksinim değerlendirilmelidir.

Değişiklik başka URL’lerde beklenmeyen yüklemelere izin veriyorsa veya güvenlik politikanızla uyuşmuyorsa önce kaydettiğiniz değere dönün. Sorun sürerken birden fazla ayarı birlikte yükseltmeyin: boyut sınırı, zaman aşımı ve uygulama limitini ayrı ayrı ele almak, yeni hatanın hangi katmanda oluştuğunu anlaşılır bırakır. Kalıcı düzenleme yapmadan önce yapılandırma yedeğini ve değişiklik saatini saklayın.

Bir sonraki güvenli adım

Önce küçük ve büyük olmak üzere iki kontrollü dosyayla, aynı URL ve aynı kullanıcı akışı üzerinden test yapın. İyibirNet hakkında genel bilgi için İyibirNet adresini inceleyebilirsiniz; ancak sunucunuzdaki gerçek Nginx kapsamını ve üst katman limitlerini kendi yapılandırma çıktınızla doğrulayın.


Top