Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
İstek akışıİstemci, NGINX ve backend arasındaki kopma noktası
Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
413 Request Entity Too Large, istemcinin gönderdiği istek gövdesinin NGINX tarafından kabul edilen sınırı aştığını gösterir. Yalnız client_max_body_size artırmak yeterli olmayabilir; PHP, uygulama, proxy, CDN ve geçici disk limitleri birlikte eşleşmelidir.
2026/07/17 03:40:44 [error] 2284#2284: *821 client intended to send too large body: 52429187 bytes, client: 203.0.113.10, request: "POST /wp-admin/async-upload.php HTTP/2.0"NGINX, POST/PUT isteğinin gövdesi client_max_body_size değerini aştığında isteği backend’e göndermeden 413 döndürür. Bu yüzden PHP logunda hiçbir kayıt oluşmayabilir.
client_max_body_size http, server veya location seviyesinde tanımlanabilir. Daha dar bloktaki değer üst seviyeyi geçersiz kılar; bu nedenle yalnız nginx.conf’a ekleme yapmak etkin vhost ayarını değiştirmeyebilir.
NGINX limiti yükseltildikten sonra PHP upload_max_filesize ve post_max_size, uygulama limiti, Nginx Proxy Manager veya CDN sınırı ayrıca kontrol edilmelidir.
Büyük istekler geçici dosyaya yazılabilir. /tmp veya client_body_temp_path doluysa limit yeterli olsa bile upload başarısız olur.
Sınırsız değer kullanmak kaynak tüketimi ve kötüye kullanım riskini artırır. Limit yalnız gereken domain/location için makul boyutta tanımlanmalıdır.
Etkin değeri tahmin etmeyin; nginx -T çıktısında aynı domain ve location için uygulanan client_max_body_size satırını bulun.
E-postada, tarayıcıda veya SSH günlüğünde gördüğünüz ifadeyi aratın. Her kartta anlam, muhtemel neden ve güvenli ilk işlem bulunur.
Anlamı: İstek gövdesi NGINX limitini aştı.
Muhtemel neden: client_max_body_size yüklenen dosyadan küçük.
Anlamı: NGINX backend’e iletmeden isteği reddetti.
Muhtemel neden: Server/location seviyesinde gövde sınırı.
Anlamı: Aynı HTTP durumunun farklı gösterimidir.
Muhtemel neden: NGINX, proxy veya API gateway limiti.
Anlamı: NGINX’i geçen dosya PHP limitine takıldı.
Muhtemel neden: PHP upload_max_filesize düşük.
Anlamı: Toplam POST gövdesi PHP post_max_size değerini aştı.
Muhtemel neden: post_max_size dosya ve form toplamından küçük.
Anlamı: Geçici upload dosyası yazılamadı.
Muhtemel neden: Disk veya inode dolu.
Anlamı: Backend framework kendi body limitini uyguladı.
Muhtemel neden: Django/Laravel/Node benzeri uygulama ayarı.
Anlamı: İstek origin’e ulaşmadan CDN limiti aşılmış olabilir.
Muhtemel neden: Plan veya proxy upload sınırı.
Bu ifadeyle eşleşen kayıt bulunamadı.
Komutlar root erişimi içindir. Önce yalnızca durum ve log toplayın; nedeni görmeden kalıcı ayar değiştirmeyin.
nginx -T | grep -n 'client_max_body_size'Include dosyaları dâhil tüm tanımları gösterir.
grep -R 'too large body' /var/log/nginx 2>/dev/null | tail -n 100İstek boyutu, URL ve domaini gösterir.
php -i | grep -E 'upload_max_filesize|post_max_size|memory_limit|max_execution_time'CLI PHP değerlerini gösterir; web PHP’si ayrıca doğrulanmalıdır.
df -h
df -i
nginx -T | grep -n 'client_body_temp_path'Upload sırasında kullanılan disk ve inode alanını kontrol eder.
curl -sk -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://example.com/yukleGerçek endpoint’e kontrollü upload testi yapar.
nginx -t && systemctl reload nginxYeni limitin güvenli uygulanmasını sağlar.
NGINX hatasının temel nedeni aynı olsa da paket yolları, servis adları, güvenlik katmanları ve sanal host yönetimi kullanılan Linux dağıtımına veya Plesk altyapısına göre değişir.
NGINX 413 Request Entity Too Large için systemd, paket yolu ve journald kontrolleri.
nginx -T | grep -n client_max_body_size
php -i | grep -E 'upload_max_filesize|post_max_size'
tail -n 100 /var/log/nginx/error.logNGINX 413 Request Entity Too Large için SELinux, PHP-FPM pool ve RHEL tabanlı servis kontrolleri.
nginx -T | grep -n client_max_body_size
php -i | grep -E 'upload_max_filesize|post_max_size'
df -h; df -iPlesk tarafından üretilen NGINX sanal host dosyalarında nginx 413 request entity too large kontrolü.
grep -R 'client_max_body_size' /var/www/vhosts/system/example.com/conf /etc/nginx 2>/dev/null
plesk repair web example.com -nHangi katmanın hangi boyutta isteği reddettiğini ölçün ve limitleri yalnız gereken kapsamda uyumlu hale getirin.
Yalnız dosya değil multipart form ek yükünü de hesaba katın.
stat -c '%n %s bytes' test.binOrigin ve CDN üzerinden ayrı test yapın.
curl -skI https://example.com/; curl -skI --resolve example.com:443:ORIGIN_IP https://example.com/Aynı server/location için en dar client_max_body_size değerini kontrol edin.
nginx -T | grep -nC 4 client_max_body_sizePHP post_max_size ve uygulama ayarı NGINX limitinden küçük olmamalıdır.
php -i | grep -E 'upload_max_filesize|post_max_size'Büyük body geçici diske yazılıyorsa boş alan ve inode gerekir.
df -h; df -iYalnız config testi değil, uygulama endpoint’ine upload yapın.
nginx -t && systemctl reload nginx
curl -sk -F '[email protected]' https://example.com/yukleNGINX, PHP ve WordPress multisite limitleri birlikte kontrol edilir.
nginx -T | grep client_max_body_size; php -i | grep -E 'upload_max|post_max'Body limiti yanında PHP süre ve upload temp alanı önemlidir.
df -h /tmp; php -i | grep upload_tmp_dirNGINX sonrası framework veya API gateway de limit uygulayabilir.
curl -sv -H 'Content-Type: application/json' --data-binary @veri.json https://example.com/apiDeğişiklik container içi etkin config veya custom location alanına yazılmalıdır.
docker exec nginx nginx -T | grep client_max_body_sizeOrigin’e doğrudan test ile CDN plan limitini ayırın.
curl --resolve example.com:443:ORIGIN_IP -skI https://example.com/Additional nginx directives alanında domain bazlı limit tanımlanabilir.
plesk repair web example.com -nİstek gövdesi etkin client_max_body_size değerini aştığında NGINX backend’e göndermeden 413 döndürür.
NGINX Open Source belgelerinde varsayılan değer 1 MB olarak belirtilir.
İhtiyaca göre http, server veya en dar location bloğuna yazılabilir. Güvenlik için mümkün olan en dar kapsam tercih edilmelidir.
PHP upload_max_filesize, post_max_size, framework, CDN, proxy veya disk alanı daha düşük bir sınır uyguluyor olabilir.
0 sınırı kapatır; kötüye kullanım ve kaynak tüketimi riskini artırdığı için yalnız kontrollü senaryolarda düşünülmelidir.
NGINX limiti, aktif web PHP upload/post limitleri ve WordPress multisite upload sınırı birlikte ayarlanmalıdır.
Yapılandırma değişikliği için nginx -t sonrası reload genellikle yeterlidir; restart gerekli değildir.
cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim ve güvenlik katmanlarını birlikte analiz ederek yalnızca servisi kaldırmak yerine arızanın temel nedenini gideriyoruz.