HTTP 413 İstek Varlığı Çok Büyük: Temel Nedenler, Düzeltmeler ve Sunucu Yapılandırma Kılavuzu

HTTP 413 Request Entity Too Large hatası, gelen bir istek gövdesi — çoğunlukla bir dosya yüklemesi — web sunucusu, ters proxy veya uygulama katmanında yapılandırılmış maksimum yük boyutunu aştığında ortaya çıkan sunucu taraflı bir yanıt durum kodudur. Sunucu, isteği işlemeden önce aktif olarak reddeder ve istemciye 413 durumu döndürür.

Bu hata, istemci taraflı bir hata değildir. Nginx ve Apache gibi web sunucularına, PHP çalışma zamanı yapılandırmalarına ve uygulama düzeyindeki ara yazılımlara yerleştirilmiş kasıtlı bir uygulama mekanizmasıdır. Hangi katmanın sınırı uyguladığını ve doğru yapılandırma yönergesinin nasıl hedefleneceğini anlamak, temiz bir düzeltme ile saatler süren sorun giderme arasındaki farktır.

HTTP 413 Hatalarının Neden Oluştuğu: Katman Katman Analiz

Bir dosya yükleme isteği, uygulamanıza ulaşmadan önce birden fazla işlem katmanından geçer. Bu katmanların herhangi biri, isteği bağımsız olarak 413 yanıtıyla reddedebilir. Hatayı doğru teşhis etmek, hangi katmanın sorumlu olduğunu belirlemeyi gerektirir.

Katman 1: Web Sunucusu Yönergeleri

Nginx, yükleme boyutu sınırlarını client_max_body_size yönergesi aracılığıyla uygular. Varsayılan değeri 1MB‘tır; bu, çoğu modern uygulama için oldukça düşük bir değerdir. Bu yönerge http, server veya location blok bağlamında ayarlanabilir ve en spesifik blok geçerli olur.

Apache, çoğu dağıtımda varsayılan olarak 0 (sınırsız) olan LimitRequestBody yönergesini kullanır — ancak barındırma sağlayıcıları bunu genellikle global veya sanal ana bilgisayar yapılandırmalarında kısıtlayıcı bir değere ayarlar. Apache ayrıca .htaccess dosyalarını da işler; bu, sınırın ana yapılandırmaya dokunulmadan dizin düzeyinde uygulanabileceği anlamına gelir.

Katman 2: PHP Çalışma Zamanı Yapılandırması

PHP, büyük bir yüklemenin başarılı olması için her ikisinin de karşılanması gereken iki bağımsız yönerge sunar:

• upload_max_filesize — tek bir yüklenen dosyanın maksimum boyutu
• post_max_size — upload_max_filesize‘a eşit veya daha büyük olması gereken, tüm POST istek gövdesinin maksimum boyutu

Yaygın bir yanlış yapılandırma, upload_max_filesize = 50M‘i ayarlarken post_max_size‘i varsayılan 8M değerinde bırakmaktır. POST gövde sınırı önce değerlendirilir; bu nedenle dosya boyutu sınırı kontrol edilmeden önce yükleme sessizce başarısız olur.

Sıklıkla göz ardı edilen üçüncü bir yönerge daha vardır: PHP’nin giriş verilerini almak için ne kadar bekleyeceğini tanımlayan max_input_time. Büyük dosyaları yükleyen yavaş bağlantılarda bu zaman aşımı, 413 veya boş yanıt olarak kendini gösteren bir hatayı tetikleyebilir.

Katman 3: Ters Proxy’ler ve Yük Dengeleyiciler

Altyapınız bir ters proxy kullanıyorsa — HAProxy, Varnish, Cloudflare veya başka bir sunucunun önünde proxy olarak çalışan bir Nginx örneği — bu proxy katmanının kendi gövde boyutu sınırları vardır. Örneğin Cloudflare tarafından döndürülen bir 413, ücretsiz ve Pro planlarda 100MB sabit sınırına sahiptir ve hiçbir sunucu taraflı yapılandırma bunu geçersiz kılamaz. 413’ün kaynağını belirlemek için her zaman proxy katmanınızın yanıt başlıklarını kontrol edin.

Katman 4: Uygulama ve CMS Kısıtlamaları

İçerik yönetim sistemleri ve çerçeveler, sunucu ve PHP katmanlarının üzerine kendi yükleme kısıtlamalarını uygular. WordPress, etkin yükleme sınırını PHP’nin çalışma zamanı değerlerinden okur ancak aynı zamanda kendi medya kitaplığı kısıtlamalarını da uygular. Bazı WordPress eklentileri ek doğrulama katmanları ekler. Özel PHP uygulamaları, sunucunun izin verdiğinden daha katı sınırlar getiren $_FILES doğrulama mantığı kullanabilir.

Nginx Yapılandırması: Web Sunucusu Düzeyinde 413’ü Düzeltme

Nginx için düzeltme, doğru yapılandırma bağlamında client_max_body_size‘ı değiştirmeyi gerektirir. http bloğunu düzenlemek sınırı global olarak uygular; server veya location bloğunu düzenlemek ise yalnızca o sanal ana bilgisayar veya uç noktaya uygular.

# Global setting — applies to all virtual hosts
http {
    client_max_body_size 100M;
}

# Per-virtual-host setting — preferred for multi-tenant environments
server {
    listen 80;
    server_name example.com;
    client_max_body_size 100M;

    # Granular control — apply only to the upload endpoint
    location /wp-admin/async-upload.php {
        client_max_body_size 256M;
    }
}

Düzenledikten sonra, yeniden yüklemeden önce yapılandırma sözdizimini doğrulayın:

nginx -t && systemctl reload nginx

Kritik uç durum: Nginx, PHP-FPM veya başka bir uygulama sunucusunun önünde ters proxy olarak çalışıyorsa, proxy_read_timeout ve proxy_send_timeout yönergelerini de kontrol etmeniz gerekir. Zaman aşımından daha uzun süren büyük bir yükleme, aktarım ortasında sonlandırılır ve proxy davranışına bağlı olarak 413 veya 504 hatası üretir.

Apache Yapılandırması: Web Sunucusu Düzeyinde 413’ü Düzeltme

Apache’nin LimitRequestBody yönergesi bayt cinsinden bir değer kabul eder. Yönerge httpd.conf‘a, bir VirtualHost bloğuna, bir Directory bloğuna veya bir .htaccess dosyasına yerleştirilebilir.

# In httpd.conf or VirtualHost block
LimitRequestBody 104857600

# In .htaccess (if AllowOverride is enabled for the directory)
LimitRequestBody 104857600

104857600 değeri 100MB’a (100 × 1024 × 1024) eşittir. httpd.conf‘ı veya sanal ana bilgisayar dosyasını değiştirdikten sonra Apache’yi yeniden başlatın:

apachectl configtest && systemctl restart apache2

Önemli nüans: Paylaşımlı barındırma ortamlarında, barındırma sağlayıcısı sunucu düzeyindeki yapılandırmalarında AllowOverride None‘ı ayarlamışsa .htaccess değişiklikleri görmezden gelinebilir. Bu durumda, yalnızca barındırma sağlayıcısı sınırı değiştirebilir. Bu, sunucu yapılandırmasına tam kök erişimine sahip olduğunuz bir VPS Hosting ortamına geçmeyi düşünmenin birincil teknik nedenlerinden biridir.

PHP Yapılandırması: Çalışma Zamanı Düzeyinde 413’ü Düzeltme

php.ini dosyası, PHP yükleme sınırları için yetkili kaynaktır. Düzenlenecek doğru dosya, PHP yürütme modelinize (mod_php, PHP-FPM, CLI) bağlıdır. Hangi php.ini‘ın gerçekten yüklendiğini belirlemek için phpinfo() veya php --ini kullanın.

; Minimum required changes for large file uploads
upload_max_filesize = 128M
post_max_size = 128M
max_input_time = 300
max_execution_time = 300
memory_limit = 256M

php.ini‘ı düzenledikten sonra, ilgili servisi yeniden başlatın:

# For PHP-FPM
systemctl restart php8.2-fpm

# For Apache with mod_php
systemctl restart apache2

php.ini erişilemez olduğunda alternatif yöntemler:

Doğrudan php.ini erişimi olmayan paylaşımlı bir barındırma planındaysanız, PHP ayarlarını şunları kullanarak geçersiz kılabilirsiniz:

1. Web kökünde bir .user.ini dosyası (PHP-FPM ile çalışır):

upload_max_filesize = 64M
post_max_size = 64M

1. Bir .htaccess yönergesi (yalnızca mod_php ile çalışır):

php_value upload_max_filesize 64M
php_value post_max_size 64M

1. Çalışma zamanı PHP kodu (sınırlı etkinlik, üretim için önerilmez):

@ini_set('upload_max_filesize', '64M');
@ini_set('post_max_size', '64M');

ini_set()‘ın PHP 7.x ve sonrasında çalışma zamanında upload_max_filesize veya post_max_size‘ı geçersiz kılamayacağını unutmayın — bu yönergeler betik yürütme başlamadan önce değerlendirilir. .user.ini veya .htaccess yöntemleri çok daha güvenilirdir.

413 Hataları için WordPress’e Özgü Düzeltme

WordPress, etkin yükleme sınırını Medya > Yeni Ekle ekranında görüntüler. Gösterilen sınır php.ini‘da yapılandırdığınızdan düşükse, sorun genellikle WordPress’in farklı bir PHP sürecinden okuması veya bir önbellek katmanının eski yapılandırma verilerini sunmasıdır.

Yükleme boyutunu açıkça tanımlamak için wp-config.php‘a aşağıdakileri ekleyin:

@ini_set( 'upload_max_size', '128M' );
@ini_set( 'post_max_size', '128M' );
define( 'WP_MEMORY_LIMIT', '256M' );

WordPress Multisite kurulumlarında, ağ düzeyindeki yükleme boyutu Ağ Yöneticisi > Ayarlar > Ağ Ayarları > Maksimum yükleme dosyası boyutu altında ayrıca kontrol edilir. Bu ayar, PHP sınırlarından bağımsızdır ve sunucu düzeyindeki değişikliklere ek olarak yapılandırılmalıdır.

Karşılaştırma: Barındırma Ortamına Göre 413’ün Nerede Düzeltileceği

Hangi Katmanın 413 Döndürdüğünü Teşhis Etme

Herhangi bir düzeltme uygulamadan önce, 413 yanıtının kaynağını doğrulayın. Yanıt başlıklarını incelemek için ayrıntılı çıktıyla curl kullanın:

curl -v -X POST -F "file=@/path/to/largefile.zip" https://example.com/upload

Server yanıt başlığını ve X-Powered-By veya CF-RAY başlıklarını inceleyin. CF-RAY başlığı, 413’ün sunucunuzdan değil Cloudflare’den kaynaklandığını gösterir. nginx/1.x.x‘den gelen bir yanıt, Nginx katmanına işaret eder. Server başlığının olmaması, uygulamanızın yukarısındaki bir yük dengeleyici veya WAF’ı işaret edebilir.

Ayrıca 413’ü tetikledikten hemen sonra sunucu hata günlüklerinizi kontrol edin:

# Nginx
tail -f /var/log/nginx/error.log

# Apache
tail -f /var/log/apache2/error.log

# PHP-FPM
tail -f /var/log/php8.2-fpm.log

Sunucu Yapılandırması Yeterli Olmadığında: Altyapı Değerlendirmeleri

Büyük dosya aktarımlarını rutin olarak işleyen uygulamalar için — video platformları, yedekleme sistemleri, tıbbi görüntüleme, büyük ölçekli e-ticaret ürün katalogları — paylaşımlı bir sunucu yapılandırmasına yüksek yükleme sınırlarını sabit kodlamak sürdürülebilir bir mimari değildir. Şu alternatifleri değerlendirin:

• Parçalı yüklemeler: Resumable.js veya Uppy gibi kütüphaneleri kullanarak büyük dosyaları istemci tarafında daha küçük parçalara bölün. Her parça sunucunun sınırı dahilindedir ve sunucu bunları yeniden birleştirir. Bu, 413’ü tamamen atlatır.
• Doğrudan nesne depolamaya yükleme: S3 uyumlu depolama için önceden imzalanmış bir URL oluşturun ve istemcinin web sunucunuzu tamamen atlayarak doğrudan yüklemesini sağlayın. Web sunucusu yalnızca meta veri işlemini yönetir.
• Özel yükleme uç noktaları: Nginx’te yükleme rotaları için daha yüksek client_max_body_size ile ayrı bir location bloğu yapılandırın; diğer tüm uç noktalar için varsayılan sınırı kısıtlayıcı tutun.

Büyük dosya işlemeyi içeren hesaplama yoğun iş yükleri için — video dönüştürme, yüklenen veriler üzerinde makine öğrenimi çıkarımı — bir GPU Hosting ortamı, hem yüklemeyi hem de sonraki hesaplamayı darboğaz olmadan işlemek için gerekli işlem kapasitesini sağlar.

Uygulamanız tam PHP yapılandırma erişimine sahip yönetilen bir kontrol paneli ortamı gerektiriyorsa, cPanel’li VPS, WHM’de MultiPHP INI Düzenleyicisi sunarak komut satırına dokunmadan etki alanı başına PHP yönerge geçersiz kılmalarına olanak tanır.

Yükleme Sınırlarını Artırırken Güvenlik Değerlendirmeleri

Yükleme sınırlarını karşılık gelen güvenlik sertleştirmesi olmadan artırmak gerçek bir saldırı yüzeyi oluşturur. 500MB POST isteklerini kabul eden bir sunucu, disk G/Ç’sini, belleği veya bağlantı havuzlarını tüketen hizmet reddi saldırıları için uygun bir hedeftir.

Herhangi bir sınır artışıyla birlikte aşağıdaki kontrolleri uygulayın:

• Yükleme uç noktalarında hız sınırlama: Nginx’te, IP başına yükleme sıklığını kısıtlamak için limit_req_zone kullanın.
• Dosya türü doğrulaması: İstemci tarafından sağlanan MIME türüne asla güvenmeyin. Dosya imzalarını (sihirli baytlar) sunucu tarafında doğrulayın.
• Yükleme dizini izinleri: Yüklemeleri alan dizin web’den erişilebilir veya çalıştırılabilir olmamalıdır. Yüklemeleri belge kökünün dışında saklayın.
• Virüs taraması: Herkese açık yükleme uç noktaları için yükleme hattına ClamAV veya benzeri bir tarayıcı entegre edin.
• Yalnızca kimlik doğrulamalı yüklemeler: Büyük yükleri kabul etmeden önce kimlik doğrulaması isteyin. Kimlik doğrulamasız büyük yükleme uç noktaları kolayca kötüye kullanılır.

Hassas yüklenen verileri işleyen üretim ortamları için, barındırma altyapınızı düzgün yapılandırılmış SSL Certificates ile eşleştirmek, dosya aktarımlarının aktarım sırasında şifrelenmesini sağlayarak yüklenen içeriğin ele geçirilmesini önler.

Teknik Karar Matrisi: Doğru Düzeltmeyi Seçme

HTTP 413’ü Çözmek için Pratik Kontrol Listesi

• Herhangi bir değişiklik yapmadan önce curl -v ve sunucu hata günlüklerini kullanarak 413’ü döndüren katmanı belirleyin
• Nginx’te, en spesifik geçerli blokta client_max_body_size‘ı ayarlayın (location, server ve http‘dan tercih edilir)
• php.ini‘da post_max_size‘ın her zaman upload_max_filesize‘a eşit veya daha büyük olduğundan emin olun
• Yavaş bağlantılarda büyük dosyalar için max_input_time ve max_execution_time‘ı artırın
• Bunlara güvenmeden önce .htaccess geçersiz kılmalarına izin verildiğini doğrulayın (AllowOverride All veya AllowOverride Options)
• Tüm proxy katmanlarını bağımsız olarak kontrol edin — CDN, yük dengeleyici ve uygulama sunucusu her biri sınırları ayrı ayrı uygular
• Herhangi bir yapılandırma değişikliğinden sonra, ilgili servisi yeniden başlatın (yalnızca restart değil, reload) ve herhangi bir opcode veya sayfa önbelleğini temizleyin
• WordPress Multisite için, PHP yönergelerine ek olarak ağ düzeyindeki yükleme sınırını yapılandırın
• Herkese açık yükleme uç noktalarında sınırları artırmadan önce hız sınırlama ve dosya türü doğrulaması uygulayın
• Paylaşımlı barındırma yapılandırma erişimini engelliyorsa, tam kontrol için bir VPS Hosting veya Dedicated Servers ortamına geçin

Sıkça Sorulan Sorular

Nginx’te 413 hatasına neden olan varsayılan yükleme sınırı nedir?

Nginx, client_max_body_size‘ı varsayılan olarak 1MB’a ayarlar. 1MB’ı aşan herhangi bir istek gövdesi, bu yönerge Nginx yapılandırmasında açıkça artırılmadıkça 413 döndürür.

Sunucu kök erişimi olmadan 413 hatasını düzeltebilir miyim?

Paylaşımlı barındırmada, .htaccess (yalnızca Apache, AllowOverride izin veriyorsa) veya bir .user.ini dosyası (yalnızca PHP-FPM) aracılığıyla düzeltme deneyebilirsiniz. Ancak barındırma sağlayıcısı kısıtlayıcı global sınırlar belirlemişse, bu yöntemler etkisiz olacak ve destek ile iletişime geçmeniz ya da VPS planına yükseltmeniz gerekecektir.

php.ini’de upload_max_filesize‘ı artırdıktan sonra neden yükleme başarısız oluyor?

En yaygın neden, post_max_size‘ın daha düşük varsayılan değerinde kalmasıdır. PHP, POST gövde boyutu sınırını bireysel dosya boyutu sınırından önce değerlendirir; bu nedenle upload_max_filesize kontrol edilmeden önce yükleme reddedilir. Her zaman her iki yönergeyi aynı anda artırın.

Cloudflare 413 hatalarına neden olur mu?

Evet. Cloudflare kendi istek gövdesi boyutu sınırlarını uygular: Ücretsiz ve Pro planlarda 100MB, Business’ta 200MB ve Enterprise’ta 500MB. İsteğiniz bu sınırları aşarsa, Cloudflare istek kaynak sunucunuza ulaşmadan önce 413 döndürür. Hiçbir sunucu taraflı yapılandırma değişikliği bunu çözmez — Cloudflare planınızı yükseltmeniz, doğrudan yükleme atlaması (önceden imzalanmış URL’ler) kullanmanız veya parçalı yüklemeler uygulamanız gerekir.

cPanel sunucusunda WordPress’te 413’ü kalıcı olarak nasıl düzeltirim?

Belirli PHP sürümü ve etki alanı için upload_max_filesize ve post_max_size‘ı artırmak üzere WHM’nin MultiPHP INI Düzenleyicisini kullanın. Ardından değişikliğin WordPress’te Medya > Yeni Ekle altında yansıtıldığını doğrulayın. WordPress Multisite için, Ağ Yöneticisi > Ayarlar altında maksimum yükleme boyutunu da güncelleyin. WHM’nin INI düzenleyicisini doğrudan kullanırken .htaccess veya wp-config.php değişikliği gerekmez.