413 Request Entity Too Large Hatası Nasıl Çözülür?

413 Request Entity Too Large hatası, gönderdiğiniz isteğin gövdesinin sunucunun kabul ettiği azami boyutu aştığını söyler. Pratikte bunu bir video yüklerken, WooCommerce'e toplu ürün görseli aktarırken, Duplicator arşivini geri yüklerken ya da destek formuna büyük bir ek eklerken görürsünüz. Dosya yükleme boyutu hatası olarak da bilinir ve tarayıcıda çoğu zaman nginx imzalı, süssüz bir hata sayfası şeklinde çıkar.

Bu yazının var olma sebebi şu: dolaşımdaki tavsiyelerin neredeyse tamamı "PHP'de upload_max_filesize değerini artırın" der ve orada biter. Bu tek başına çalışmaz. Çünkü 413 hatasını üreten katman genellikle PHP değil, Nginx'in client_max_body_size direktifidir ve varsayılan değeri sadece 1 MB'dır. Nginx isteği daha PHP'ye devretmeden reddettiğinde, php.ini içinde ne yazdığının hiçbir önemi kalmaz. Aşağıda bu zinciri baştan sona kuruyorum: hangi katmanın engellediğini kesin olarak tespit etme, Nginx / Apache / PHP / WordPress / Cloudflare taraflarını doğru sırayla ayarlama ve değerlerin birbiriyle tutarlı olmasını sağlama.

413 Request Entity Too Large Hatası Nedir#

413, HTTP standardında "Content Too Large" olarak tanımlanan durum kodudur ve sunucunun isteğin gövdesini çok büyük bulduğunu bildirir. Adres değil, gövde. Yani bir GET isteğinde neredeyse hiç görülmez; POST, PUT ve çok parçalı (multipart) dosya yüklemelerinde çıkar.

Hatanın önemli bir özelliği şudur: sunucu genellikle isteğin tamamını almadan reddeder. Nginx, Content-Length başlığını okuduğu anda limiti aşıldığını görürse bağlantıyı orada keser. Bu yüzden ilerleme çubuğu %2'de takılıp aniden hata verir; dosya sonuna kadar yüklenmez.

Tarayıcıda gördüğünüz yüzeyler farklı olabilir:

• 413 Request Entity Too Large yazan çıplak Nginx sayfası.
• WordPress medya yükleyicide "Yüklemeye çalıştığınız dosya bu sitenin azami yükleme boyutunu aşıyor" uyarısı.
• Yükleme ilerlemesinin donması ve ardından "HTTP hatası" mesajı.
• Ağ sekmesinde net::ERR_CONNECTION_RESET — Nginx bağlantıyı kestiği için.

Durum kodunu net görmek için kendi ölçümünüzü yapın:

# 20 MB'lık sahte bir dosya üret
dd if=/dev/zero of=/tmp/test20.bin bs=1M count=20

# Yükleme uç noktasına gönder ve sadece durum kodunu yazdır
curl -s -o /dev/null -w "%{http_code}\n" \
  -F "file=@/tmp/test20.bin" \
  https://ornek.com/wp-admin/async-upload.php

Çıktı 413 ise limit devrededir. Bu testi boyutu kademeli düşürerek (20 → 10 → 5 → 2 MB) tekrarlayın; hangi eşikte 413'ün kesildiğini bulmak, hangi katmanın konuştuğunu anlamanın en hızlı yoludur.

Zinciri Anlamak: İsteği Kim Reddediyor#

Kısa cevap: bir dosya yüklemesi sunucuya varana kadar en az beş ayrı limitten geçer ve en dar olanı kazanır.

İstek sırayla şu kapılardan geçer:

1. CDN / ters vekil (Cloudflare gibi) — kendi yükleme sınırı vardır.
2. Web sunucusu (Nginx client_max_body_size / Apache LimitRequestBody).
3. PHP-FPM'e devredilen gövde — burada post_max_size devreye girer.
4. PHP dosya yükleme katmanı — upload_max_filesize.
5. Uygulama (WordPress, e-ticaret altyapısı) — kendi filtresi olabilir.

Her katmanın varsayılanı ve aşıldığında ürettiği belirti farklıdır:

Bu tablodaki en kritik satır ikincisidir. Nginx'in 1 MB'lık varsayılanı, PHP'nin 2 MB'lık varsayılanından daha dardır. Yani PHP'yi 128 MB'a çıkarsanız bile Nginx 1 MB'da kesmeye devam eder — ve hata mesajı size PHP'yi işaret etmez, sadece "Request Entity Too Large" der. Türkçe kaynakların çözemediği düğüm tam olarak buradadır.

Adım Adım Teşhis: Hangi Limit Devrede#

Sırayı takip edin; her adım bir katmanı eleyecek.

1. Cloudflare arkasında mısınız?

curl -sI https://ornek.com/ | grep -i 'cf-ray\|server'

cf-ray başlığı varsa istek Cloudflare'den geçiyor demektir. Emin olmak için Cloudflare'i geçici olarak devre dışı bırakmadan test edebilirsiniz — isteği doğrudan sunucu IP'sine gönderin:

curl -s -o /dev/null -w "%{http_code}\n" \
  --resolve ornek.com:443:SUNUCU_IP \
  -F "file=@/tmp/test20.bin" https://ornek.com/wp-admin/async-upload.php

Doğrudan IP'ye giderken 200, Cloudflare üzerinden 413 alıyorsanız sınır CDN tarafındadır.

2. Web sunucusu logunu okuyun.

Nginx:

grep 'client intended to send too large body' /var/log/nginx/error.log | tail -5

Örnek satır:

2026/08/11 10:14:52 [error] 812#812: *4471 client intended to send too large body: 21495808 bytes, client: 88.240.x.x, server: ornek.com, request: "POST /wp-admin/async-upload.php HTTP/2.0"

Bu satır varsa suçlu kesin olarak client_max_body_size'dır ve PHP'ye hiç dokunmanıza gerek yok.

Apache:

grep -i 'request entity too large\|LimitRequestBody' /var/log/apache2/error.log | tail -5

3. Web sunucusu logunda iz yoksa PHP tarafına bakın. Nginx/Apache logu temizse istek PHP'ye ulaşmıştır ve limit oradadır. Etkin değerleri görmek için:

php -i | grep -E 'upload_max_filesize|post_max_size|memory_limit|max_execution_time|max_file_uploads'

⚠️ CLI'da gördüğünüz php.ini ile web sunucusunun kullandığı farklı olabilir. Gerçek değeri web tarafından okumak için geçici bir dosya oluşturun:

<?php
// bilgi.php — kontrolden sonra MUTLAKA silin
echo 'Yüklenen ini: ' . php_ini_loaded_file() . PHP_EOL;
echo 'upload_max_filesize: ' . ini_get( 'upload_max_filesize' ) . PHP_EOL;
echo 'post_max_size: '       . ini_get( 'post_max_size' ) . PHP_EOL;
echo 'memory_limit: '        . ini_get( 'memory_limit' ) . PHP_EOL;

php_ini_loaded_file() çıktısı, düzenlemeniz gereken dosyanın tam yolunu verir. Yanlış php.ini dosyasını düzenlemek, bu konudaki ikinci en yaygın zaman kaybıdır.

Nginx: client_max_body_size Ayarı#

Kısa cevap: client_max_body_size değerini yükleyeceğiniz en büyük dosyadan büyük bir değere çekin ve Nginx'i yeniden yükleyin.

Direktif üç yerde tanımlanabilir ve en dar kapsam kazanır: http, server, location. Tüm siteye uygulamak için http bloğuna yazmak en pratik yoldur.

# /etc/nginx/nginx.conf — http bloğu içinde
http {
    client_max_body_size 128M;
    client_body_timeout  300s;
    client_body_buffer_size 1M;
    ...
}

Yalnızca belirli bir uç noktaya izin vermek daha güvenlidir — böylece sitenin geri kalanı büyük gövde saldırılarına açık kalmaz:

server {
    server_name ornek.com;
    client_max_body_size 8M;   # site geneli dar kalsın

    location = /wp-admin/async-upload.php {
        client_max_body_size 256M;
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php-fpm.sock;
        fastcgi_read_timeout 300s;
    }

    location = /wp-admin/update.php {
        client_max_body_size 256M;
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }
}

0 değeri sınırı tamamen kaldırır (client_max_body_size 0;) ama bunu üretimde kullanmayın: sınırsız gövde, tek bir isteğin diski ve belleği doldurmasına izin verir.

Değişikliği sınayıp yükleyin:

nginx -t && systemctl reload nginx

nginx -t başarısız olursa reload çalıştırmayın — çalışan yapılandırmayı bozarsanız site 502 vermeye başlar ve bu sefer başka bir hatayla uğraşırsınız. Nginx ile PHP-FPM arasındaki soket, zaman aşımı ve tampon ayarlarının tamamı için Nginx PHP-FPM yapılandırma yazısına bakabilirsiniz.

⚠️ Nginx bir ters vekil olarak Apache'nin önünde duruyorsa (klasik cPanel + Nginx önbellek kurulumu) iki katmanı da ayarlamanız gerekir. Nginx'i 128 MB yapıp Apache'yi unutmak, hatanın devam etmesine yol açar ve "yaptım ama olmadı" hissini üretir.

Apache ve LiteSpeed: LimitRequestBody#

Apache'de karşılık gelen direktif LimitRequestBody'dir ve değeri bayt cinsindendir — M ya da G soneki kabul etmez. Varsayılanı 0, yani sınırsızdır; ancak birçok barındırma sağlayıcısı bunu sunucu genelinde bir değere sabitler.

.htaccess içinde (izin verilmişse):

# 128 MB = 134217728 bayt
LimitRequestBody 134217728

Sanal host yapılandırmasında:

<Directory "/var/www/ornek.com/public_html">
    LimitRequestBody 134217728
</Directory>

⚠️ .htaccess içinde LimitRequestBody yazdığınızda 500 Internal Server Error alıyorsanız, sağlayıcı AllowOverride ile bu direktifi kapatmıştır. Satırı hemen kaldırın ve destek üzerinden sunucu genelinde artırılmasını isteyin — direktifi zorlamak siteyi tamamen düşürür. Bu tip yapılandırma kaynaklı hataların teşhisi için 500 Internal Server Error çözümü yazısına göz atabilirsiniz. LiteSpeed'de karşılık gelen ayar yönetim panelindeki Max Request Body Size değeridir; .htaccess üzerinden LimitRequestBody da genellikle onurlandırılır.

PHP Tarafı: upload_max_filesize ve post_max_size#

Kısa cevap: post_max_size her zaman upload_max_filesize değerinden büyük olmalıdır, aksi halde PHP isteği sessizce düşürür.

Neden? Çünkü bir dosya yüklemesi çok parçalı bir POST gövdesi içinde taşınır. Gövdede yalnızca dosya değil, formun diğer alanları, sınır dizeleri ve başlıklar da vardır. upload_max_filesize tek bir dosyanın tavanıdır; post_max_size ise tüm gövdenin tavanıdır. İkincisi birinciden küçükse, dosya kendi başına limite uysa bile toplam gövde reddedilir — ve tipik belirti tuhaftır: hata mesajı çıkmaz, $_POST ile $_FILES bomboş gelir, form hiçbir şey olmamış gibi geri döner.

Önerilen tutarlı set (128 MB'lık bir hedef için):

; php.ini
upload_max_filesize = 128M
post_max_size       = 160M
memory_limit        = 256M
max_execution_time  = 300
max_input_time      = 300
max_file_uploads    = 20

Kural olarak: memory_limit > post_max_size > upload_max_filesize.

max_execution_time ve max_input_time neden burada? Çünkü büyük bir dosya yavaş bir bağlantıdan yüklenirken PHP'nin girdi okuma süresi dolabilir. Bu durumda 413 değil, boş yanıt ya da zaman aşımı alırsınız — semptom benzer olduğu için aynı ayarla birlikte düşünülmelidir.

Değeri değiştiremiyor ya da php.ini'ye erişemiyorsanız, sıralı alternatifler:

1. .user.ini (PHP-FPM'de, sitenin kök dizininde):

upload_max_filesize = 128M
post_max_size = 160M
memory_limit = 256M

⚠️ .user.ini değişiklikleri anında yansımaz; user_ini.cache_ttl süresi (varsayılan 300 saniye) kadar bekleyin ya da PHP-FPM'i yeniden başlatın.

2. .htaccess (yalnızca mod_php ile çalışan Apache'de):

php_value upload_max_filesize 128M
php_value post_max_size 160M
php_value memory_limit 256M

PHP-FPM kullanan bir sunucuda bu satırlar ya yok sayılır ya da 500 üretir; işe yaramıyorsa hemen kaldırın.

3. wp-config.php üzerinden (sadece bellek için):

@ini_set( 'memory_limit', '256M' );
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Bu değerlerin her birinin ne işe yaradığı ve nerede tanımlandığı PHP upload_max_filesize yazısında ayrıntılı anlatılıyor.

cPanel ve Paylaşımlı Hostingde Ne Yapılabilir#

Paylaşımlı bir pakette Nginx yapılandırma dosyasına erişiminiz yoktur; elinizde üç araç kalır.

MultiPHP INI Editor. cPanel'de Yazılım → MultiPHP INI Editor ekranını açın, alan adınızı seçin ve temel modda upload_max_filesize, post_max_size, memory_limit, max_execution_time alanlarını doldurun. Bu ekran arka planda sizin adınıza .user.ini yazar.

Dosya Yöneticisi ile doğrudan yükleme. 413 sorunu yalnızca HTTP yükleme yolundadır. Büyük bir yedek arşivini siteye HTTP üzerinden yüklemek yerine cPanel Dosya Yöneticisi ya da FTP ile dizine koyup, uygulamayı o dosyayı yerel diskten okumaya yönlendirmek çoğu zaman en hızlı çözümdür. Panel üzerinden dosya işlemleri için cPanel dosya yöneticisi yazısına bakabilirsiniz.

Destek talebi. Sunucu genelindeki client_max_body_size ya da LimitRequestBody değerini yalnızca sağlayıcı değiştirebilir. Talebinizde tahmin yürütmek yerine ölçtüğünüz veriyi verin: hata logundaki client intended to send too large body: NNNN bytes satırını ve yüklemek istediğiniz azami dosya boyutunu yazın. Sürekli 100 MB üzeri yükleme yapıyorsanız paylaşımlı paket zaten sınırınızı zorluyor demektir; bu iş yükü için kök erişimli bir ortam daha uygundur.

WordPress, Duplicator ve Yedek Geri Yükleme#

WordPress'in kendi bir boyut limiti yoktur; PHP'den ne mirasa alırsa onu gösterir. Medya kütüphanesinde "Azami yükleme boyutu" satırında gördüğünüz değer, upload_max_filesize ile post_max_size değerlerinin küçük olanıdır.

Ancak bazı temalar ve güvenlik eklentileri bu değeri filtreyle düşürür. Kontrol için:

<?php
// functions.php içine geçici olarak ekleyin
add_filter( 'upload_size_limit', function ( $limit ) {
    error_log( 'WP upload_size_limit: ' . $limit );
    return $limit;
}, 999 );

Loga yazılan değer PHP'nin değerinden düşükse, filtreyi uygulayan bir eklenti vardır.

Duplicator, All-in-One WP Migration gibi taşıma araçlarında 413'ün klasik senaryosu şudur: arşiv 300 MB, client_max_body_size 100 MB. Bu durumda arşivi HTTP ile yüklemeye çalışmayın. Doğru yol:

1. Arşiv dosyasını ve kurulum betiğini FTP/SFTP ile hedef dizine yükleyin.
2. Tarayıcıdan kurulum betiğini çalıştırın; araç arşivi yerel diskten okur, HTTP yüklemesi devreye girmez.
3. Kurulum sırasında PHP max_execution_time ve memory_limit değerlerinin yeterli olduğundan emin olun — bu aşamada 413 değil, bellek ya da zaman aşımı hatası alırsınız.

Taşıma sürecinin tamamı ve arşiv boyutunu küçültme yöntemleri için WordPress Duplicator ile taşıma yazısına bakabilirsiniz.

Cloudflare ve Ters Vekil Kaynaklı Yükleme Sınırı#

Cloudflare'in kendi istek gövdesi sınırı vardır ve plan seviyesine göre değişir. Ücretsiz planda bu sınır dar tutulur; aştığınızda Cloudflare 413 döner ve istek sunucunuza hiç ulaşmaz. Bu yüzden Nginx error log'unda hiçbir kayıt bulamazsınız — teşhis burada tıkanır.

İki pratik çıkış yolu var:

1. Yükleme uç noktasını CDN dışına alın. DNS'te yalnızca yükleme için kullanılan bir alt alan adı tanımlayıp (örneğin yukle.ornek.com) Cloudflare panelinde bu kaydın proxy durumunu kapatın (turuncu bulut yerine gri bulut). İstek doğrudan sunucunuza gider ve Cloudflare sınırı devreye girmez.

2. Yüklemeyi parçalayın. Modern medya yükleyicileri dosyayı parçalara bölerek gönderebilir; her parça sınırın altında kaldığı için 413 çıkmaz. WordPress medya yükleyici ve pek çok e-ticaret altyapısı bunu destekler.

Doğru Değerleri Belirleme ve Kontrol Listesi#

Değerleri "ne olur ne olmaz" diye tavana çekmek iyi bir fikir değildir: büyük gövde limiti, tek bir istekle sunucunun belleğini ve diskini doldurma imkânı verir. Şu yaklaşımı öneriyorum.

1. Gerçek ihtiyacınızı ölçün. Yüklediğiniz en büyük dosya türünü belirleyin (video, tema arşivi, yedek).
2. Hedefi %25 payla belirleyin. En büyük dosyanız 80 MB ise hedef 100 MB olsun.
3. Katmanları hiyerarşik ayarlayın:

4. Site genelini dar, yükleme uç noktasını geniş tutun. Yukarıdaki location bazlı Nginx örneği tam olarak bunun içindir.
5. Değişiklikten sonra doğrulayın. Ayar yaptım demek yetmez; kademeli dd + curl testini tekrarlayıp yeni eşiği ölçün.
6. Servisleri doğru sırayla yeniden başlatın:

nginx -t && systemctl reload nginx
systemctl restart php8.3-fpm     # sürüm adınızı kullanın

PHP-FPM yeniden başlatılmadan php.ini değişiklikleri etkili olmaz — bu, ayarların "işe yaramadığı" sanılan durumların büyük kısmının açıklamasıdır.

Sıkça Sorulan Sorular#

413 Request Entity Too Large ne demek#

413 Request Entity Too Large, gönderdiğiniz HTTP isteğinin gövdesinin sunucunun kabul ettiği azami boyutu aştığı anlamına gelir. Adresle ya da yetkiyle ilgisi yoktur; sorun tamamen veri boyutundadır. Sunucu genellikle dosyanın tamamını almadan, Content-Length başlığını okuduğu anda bağlantıyı keser. Bu yüzden yükleme ilerleme çubuğu başlangıçta takılır ve dosya sonuna kadar hiç gitmez.

upload_max_filesize değerini artırdım ama hata devam ediyor#

Bunun nedeni büyük ihtimalle Nginx'in client_max_body_size direktifidir ve varsayılan değeri yalnızca 1 MB'dır. Nginx isteği PHP'ye devretmeden reddettiği için php.ini içindeki hiçbir değer devreye girmez. Kontrol için Nginx hata logunda client intended to send too large body satırını arayın; bu satır varsa suçlu kesindir. İkinci olası neden, post_max_size değerinin upload_max_filesize değerinden küçük kalmasıdır.

post_max_size ile upload_max_filesize arasındaki fark nedir#

upload_max_filesize tek bir yüklenen dosyanın azami boyutunu, post_max_size ise POST isteğinin tüm gövdesinin azami boyutunu belirler. Gövdede dosyanın yanı sıra formun diğer alanları ve çok parçalı sınır verileri de taşındığı için post_max_size her zaman daha büyük olmalıdır. İkincisi küçük kalırsa PHP isteği sessizce düşürür: hata mesajı görünmez ama $_POST ve $_FILES bomboş gelir. Bu sessiz başarısızlık, teşhisi en zor senaryolardan biridir.

Nginx client_max_body_size ayarını nereye yazmalıyım#

Direktifi http, server veya location bloklarından herhangi birine yazabilirsiniz ve en dar kapsam geçerli olur. Tüm siteye uygulamak için nginx.conf içindeki http bloğu en pratik yerdir. Daha güvenli yaklaşım, site genelini dar tutup yalnızca yükleme uç noktalarına (/wp-admin/async-upload.php gibi) geniş bir değer vermektir. Değişiklikten sonra nginx -t ile sınayıp systemctl reload nginx ile yüklemeyi unutmayın.

Paylaşımlı hostingde 413 hatasını kendim çözebilir miyim#

Kısmen çözebilirsiniz. cPanel'de MultiPHP INI Editor üzerinden PHP tarafındaki limitleri kendiniz yükseltebilirsiniz, ancak web sunucusu seviyesindeki client_max_body_size ya da LimitRequestBody değerleri yalnızca sağlayıcı tarafından değiştirilebilir. Bu durumda destek talebine hata logundaki tam satırı ve ihtiyacınız olan azami dosya boyutunu ekleyin. Büyük yedek dosyalarında ise HTTP yüklemesini tamamen atlayıp dosyayı FTP ile dizine koymak çoğu zaman daha hızlı sonuç verir.

Cloudflare kullanırken 413 alıyorum ama sunucu logunda kayıt yok#

Bu, sınırın Cloudflare tarafında olduğunu gösterir; istek sunucunuza hiç ulaşmadığı için log da üretilmez. Cloudflare'in istek gövdesi sınırı plan seviyesine göre değişir ve ücretsiz planda dar tutulur. Doğrulamak için curl --resolve ile isteği doğrudan sunucu IP'sine gönderin; orada 200 alıp CDN üzerinden 413 alıyorsanız teşhis kesindir. Çözüm, yükleme için ayrı bir alt alan adını proxy dışında tutmak ya da parçalı yükleme kullanmaktır.

413 hatası ile 508 hatası arasındaki fark nedir#

413 isteğin gövdesinin çok büyük olduğunu, 508 ise barındırma hesabının kaynak limitine (bellek, işlemci, giriş süreci) dayandığını bildirir. 413 anında ve boyut tabanlı verilir; 508 ise genellikle site yavaşladıktan sonra ortaya çıkar ve yükleme dışındaki isteklerde de görülür. İkisi de büyük bir dosya işlerken art arda çıkabilir: dosya limitten geçer ama işlenirken kaynak tükenir. Bu durumda client_max_body_size yeterlidir ama memory_limit yetersizdir.

Limitleri çok yüksek ayarlamanın bir sakıncası var mı#

Evet, sınırsız ya da aşırı yüksek bir gövde limiti güvenlik riski oluşturur. Büyük gövde kabul eden bir uç nokta, tek bir istekle sunucunun geçici disk alanını ve belleğini tüketmeye açıktır ve bu, hizmet dışı bırakma denemelerinde kullanılan basit bir yöntemdir. Doğru yaklaşım site genelini gerçek ihtiyacınızın biraz üzerinde tutmak ve geniş limiti yalnızca yetkilendirilmiş yükleme uç noktalarına vermektir. client_max_body_size 0; ifadesini üretim ortamında hiç kullanmayın.

Kapanış#

413 Request Entity Too Large hatasının çözümü tek bir ayar değil, bir zinciri baştan sona tutarlı hale getirmektir. Sıra şudur: önce isteğin Cloudflare'de mi kesildiğini --resolve testiyle ayırın, sonra Nginx hata logunda client intended to send too large body satırını arayın — bu satır varsa client_max_body_size dışında hiçbir şeye dokunmanıza gerek yoktur. Web sunucusu logu temizse istek PHP'ye ulaşmıştır ve post_max_size ile upload_max_filesize ilişkisini kontrol etme sırası gelmiştir; unutmayın ki post_max_size her zaman daha büyük olmalıdır ve memory_limit ikisini de aşmalıdır. Her değişiklikten sonra PHP-FPM'i yeniden başlatın ve kademeli dd + curl testiyle yeni eşiği gerçekten ölçün.

Bu katmanların hepsine erişemediğiniz bir ortamdaysanız ya da düzenli olarak büyük medya ve yedek dosyalarıyla çalışıyorsanız, altyapıyı ihtiyaca göre seçmek en kalıcı çözümdür. Nginx ve PHP değerlerini kendiniz belirleyebileceğiniz kök erişimli bir ortam için VDS sunucu paketlerimize, yükleme limitleri WordPress iş yüküne göre önceden ayarlanmış bir paylaşımlı ortam için WordPress hosting paketlerimize bakabilirsiniz. Büyük bir arşivi HTTP üzerinden taşımaya çalışıp 413'e takıldıysanız, aktarımı ve limit ayarlarını bizim üstlendiğimiz site taşıma hizmetimiz bu adımı tamamen ortadan kaldırır.