Web Hosting & cPanel

    PHP Dosya Yükleme Boyutunu Artırma (upload_max_filesize)

    Büyük dosya yükleme sorununu upload_max_filesize ve post_max_size ayarlarıyla çözmeyi anlatan rehber.

    11 dk okuma Güncellendi: 10 Temmuz 2026

    WordPress'te 12 MB'lık bir tema paketini yüklemeye çalışıyorsunuz ve karşınıza "Yüklenen dosya php.ini içindeki upload_max_filesize değerini aşıyor" uyarısı çıkıyor. Ya da bir müşteri e-ticaret sitesine yüksek çözünürlüklü ürün görselleri eklerken medya kütüphanesi sessizce başarısız oluyor, dosya bir türlü sunucuya gitmiyor. Bu, paylaşımlı hosting'den yönetilen sunuculara kadar her ortamda en sık karşılaşılan yapılandırma sorunlarından biridir ve neredeyse her zaman üç PHP ayarının birbirini nasıl kısıtladığını bilmemekten kaynaklanır.

    İyi haber şu: sorunun tamamı sunucu tarafındaki birkaç PHP direktifiyle çözülür ve bunları değiştirmek için çoğu zaman kök (root) erişimine bile ihtiyacınız yoktur. Bu rehberde yükleme boyutunu belirleyen değerleri tek tek açıklayacak, cPanel'in MultiPHP INI Editörü ve doğrudan php.ini dosyası üzerinden nasıl artıracağınızı göstereceğim. Ardından WordPress'in kendine özgü davranışlarına, gerçek yüklemede hangi limitin belirleyici olduğuna ve web sunucusu (Nginx/Apache) katmanındaki gizli sınırlara değineceğim. Amaç, bir daha aynı hatayla karşılaştığınızda hangi değeri neden değiştireceğinizi tereddütsüz bilmeniz.

    Yükleme Boyutunu Belirleyen Üç Değer#

    Bir dosyanın sunucuya kabul edilmesi tek bir ayara değil, birbiriyle konuşan üç PHP direktifine bağlıdır. Bunları anlamadan rastgele değer değiştirmek çoğu zaman işe yaramaz; çünkü limitlerden en düşüğü her zaman kazanır.

    DirektifNe yaparTipik varsayılanÖnerilen
    upload_max_filesizeTek bir yüklenen dosyanın maksimum boyutu2M64M
    post_max_sizeTüm POST isteğinin (dosya + form verisi) toplam boyutu8M128M
    max_execution_timeBir script'in çalışabileceği maksimum süre (saniye)30300

    upload_max_filesize, sunucunun tek bir dosya için kabul edeceği üst sınırdır. 2 MB varsayılanı bugünün ihtiyaçları için çok düşüktür; tek bir DSLR fotoğrafı bile bunu aşabilir.

    post_max_size, bir HTTP POST isteğinin tamamının boyutunu sınırlar. Bir formda birden fazla dosya veya ek alanlar olabileceği için bu değerin upload_max_filesize'dan her zaman büyük olması gerekir. Kural olarak post_max_size'ı yükleme limitinizin en az iki katı yapın.

    max_execution_time ise doğrudan boyutu değil, süreyi kısıtlar. Yavaş bir bağlantıdan büyük bir dosya yüklerken transfer 30 saniyeyi aşarsa PHP script'i zaman aşımına uğrar ve yükleme yarıda kesilir. Bu yüzden büyük dosyalarla çalışırken üç değeri de birlikte yükseltmek gerekir.

    upload_max_filesize ve post_max_size Arasındaki İlişki#

    Bu iki değer arasındaki bağı yanlış kurmak, kullanıcıların en çok kafasını karıştıran durumdur. Diyelim ki upload_max_filesize = 64M yaptınız ama post_max_size'ı 8M'de bıraktınız. Bu durumda 10 MB'lık bir dosya yüklemeye çalışan kullanıcı, "dosya limitin altında" olmasına rağmen hata alır, çünkü POST isteğinin toplam boyutu (dosya + form alanları + WordPress'in eklediği nonce ve meta veriler) post_max_size'ı aşar.

    Doğru yaklaşım her zaman şudur:

    post_max_size >= upload_max_filesize
    

    Pratikte güvenli bir marj bırakmak için post_max_size'ı yükleme limitinin biraz üzerinde tutun:

    upload_max_filesize = 64M
    post_max_size = 128M
    max_execution_time = 300
    max_input_time = 300
    memory_limit = 256M
    

    Buraya iki değer daha ekledim. max_input_time, PHP'nin gelen veriyi ayrıştırmak (dosyayı okumak) için harcayabileceği süredir ve büyük yüklemelerde max_execution_time kadar önemlidir. memory_limit ise özellikle görsel işleyen uygulamalarda (WordPress'in küçük resim üretmesi gibi) devreye girer; yüklediğiniz dosyanın işlenebilmesi için yeterli belleğin olması gerekir. Genel kural olarak memory_limit, post_max_size'dan büyük olmalıdır.

    Bir dosya boyutuna göre değerlerin nasıl ölçeklendiğini görmek isterseniz:

    İhtiyaçupload_max_filesizepost_max_sizememory_limit
    Küçük görseller8M16M128M
    Tema/eklenti paketleri64M128M256M
    Video/yedek dosyaları256M512M512M

    cPanel MultiPHP INI Editor ile Limit Artırma#

    Paylaşımlı hosting kullanıcılarının büyük çoğunluğu bu değerlere doğrudan php.ini düzenleyerek değil, cPanel'in grafik arayüzü üzerinden ulaşır. Bu en güvenli ve en hızlı yöntemdir, çünkü yanlış bir yazımla tüm siteyi çökertme riski yoktur.

    Adımlar şu şekildedir:

    1. cPanel'e giriş yapın ve Software (Yazılım) bölümünde MultiPHP INI Editor aracını açın.
    2. Üstteki Configure sekmesinde açılır menüden ayarını değiştirmek istediğiniz alan adını seçin.
    3. Karşınıza çıkan listede upload_max_filesize, post_max_size, max_execution_time ve memory_limit alanlarını bulun.
    4. Değerleri ihtiyacınıza göre girin (örneğin 64M, 128M, 300, 256M).
    5. Apply düğmesine basın.

    Bu araç arka planda alan adınıza özel bir .user.ini veya php.ini dosyası oluşturur, dolayısıyla değişiklik yalnızca sizin sitenizi etkiler. Eğer MultiPHP INI Editor'de aradığınız direktifi göremiyorsanız, aynı ekrandaki Editor sekmesini kullanarak ham metin olarak da ekleyebilirsiniz:

    upload_max_filesize = 64M
    post_max_size = 128M
    max_execution_time = 300
    memory_limit = 256M
    

    Değişikliğin hangi PHP sürümüne uygulandığına dikkat edin. cPanel her alan adı için farklı bir PHP sürümü çalıştırabildiğinden, INI Editör'de değeri değiştirdiğiniz sürüm ile sitenizin gerçekten çalıştığı sürümün aynı olması gerekir. Sürüm seçimini ve nasıl doğrulayacağınızı PHP sürüm yönetimi rehberimizde ayrıntılı anlattım.

    php.ini Dosyası Üzerinden Manuel Ayar#

    Kendi sunucunuzda (VDS, VPS veya dedicated) kök erişiminiz varsa ya da cPanel kullanmıyorsanız, değerleri doğrudan php.ini dosyasında düzenlersiniz. Önce hangi php.ini dosyasının aktif olduğunu bulmanız gerekir, çünkü bir sunucuda birden fazla olabilir:

    php --ini
    

    Bu komut "Loaded Configuration File" satırında aktif dosyanın tam yolunu verir. Tipik yollar şöyledir:

    # PHP-FPM (Debian/Ubuntu)
    /etc/php/8.2/fpm/php.ini
    
    # PHP-FPM (CentOS/AlmaLinux)
    /etc/php-fpm.d/www.conf ile /etc/php.ini
    
    # CLI
    /etc/php/8.2/cli/php.ini
    

    Web üzerinden çalışan uygulamalar için CLI değil, FPM veya Apache modülünün php.ini'sini düzenlemeniz gerektiğini unutmayın. Yanlışlıkla CLI dosyasını değiştirmek, komut satırından yaptığınız testlerin doğru görünmesine ama sitenin hiç etkilenmemesine yol açar; bu klasik bir tuzaktır.

    Dosyayı düzenleyip değerleri güncelleyin:

    sudo nano /etc/php/8.2/fpm/php.ini
    
    upload_max_filesize = 64M
    post_max_size = 128M
    max_execution_time = 300
    max_input_time = 300
    memory_limit = 256M
    

    Kaydettikten sonra değişikliğin devreye girmesi için PHP-FPM'i (ve gerekirse web sunucusunu) yeniden başlatın:

    sudo systemctl restart php8.2-fpm
    sudo systemctl restart nginx
    

    Bir uygulamaya dokunmadan tek bir dizin için ayar geçersiz kılmak isterseniz, o dizine bir .user.ini dosyası koyabilirsiniz (PHP-FPM'de çalışır):

    ; /var/www/site/public_html/.user.ini
    upload_max_filesize = 128M
    post_max_size = 256M
    

    Apache + mod_php kullanıyorsanız aynı işi bir .htaccess dosyasıyla da yapabilirsiniz:

    php_value upload_max_filesize 64M
    php_value post_max_size 128M
    php_value max_execution_time 300
    php_value memory_limit 256M
    

    Ancak .htaccess yöntemi yalnızca PHP Apache modülü olarak çalışıyorsa geçerlidir; PHP-FPM (LiteSpeed veya Nginx ile) altında bu satırlar 500 hatası bile üretebilir. Emin değilseniz .user.ini daha güvenli bir seçimdir. Kök erişimi gerektiren bu tür ince ayarlar sizi zorluyorsa, sunucu yönetimi hizmetimiz ile bu yapılandırmaları sizin adınıza yapmamız mümkün.

    WordPress Medya Yükleme Hatasını Çözme#

    WordPress, bu üç PHP değerini kendi arayüzünde okur ve Medya > Yeni Ekle ekranının altında "Maksimum yükleme boyutu" olarak gösterir. Bu satır, PHP tarafında ne yaptığınızı doğrulamanın en hızlı yoludur; değer hâlâ 2 MB görünüyorsa, değişikliğiniz gerçekte devreye girmemiş demektir.

    WordPress'te en sık karşılaşılan iki hata mesajı şudur:

    • "Yüklenen dosya php.ini içindeki upload_max_filesize değerini aşıyor" → Dosyanız upload_max_filesize'dan büyük. Bu değeri artırın.
    • "Yüklenen dosya yalnızca kısmen yüklendi" → Genellikle max_execution_time veya max_input_time yetersiz; transfer yarıda kesiliyor.

    Değeri değiştirdikten sonra WordPress hâlâ eski limiti gösteriyorsa birkaç noktayı sırayla kontrol edin. Öncelikle doğru PHP sürümünü düzenlediğinizden emin olun. Ardından cache eklentileri veya sunucu düzeyinde OPcache, eski yapılandırmayı önbelleğe almış olabilir; PHP-FPM'i yeniden başlatmak bunu temizler.

    Gerçekte hangi değerlerin yüklü olduğunu görmek için geçici bir tanı dosyası oluşturmak en kesin yöntemdir:

    <?php
    // info.php — kontrol bittikten sonra MUTLAKA silin
    echo 'upload_max_filesize: ' . ini_get('upload_max_filesize') . "\n";
    echo 'post_max_size: ' . ini_get('post_max_size') . "\n";
    echo 'max_execution_time: ' . ini_get('max_execution_time') . "\n";
    echo 'memory_limit: ' . ini_get('memory_limit') . "\n";
    

    Bu dosyayı sitenizin köküne koyup https://siteniz.com/info.php adresinden açın. Değerler beklediğiniz gibiyse ama WordPress hâlâ hata veriyorsa, sorun büyük ihtimalle bir web sunucusu limitidir (sonraki bölüm). Tanı bittiğinde info.php dosyasını mutlaka silin; sunucu bilgilerini dışarıya sızdırmak istemezsiniz.

    WordPress'e özgü diğer yükleme ve içe aktarma hatalarının (bellek, zaman aşımı, ölümcül hata) çözümlerini WordPress hata çözüm rehberimizde topladım. Sürekli yükleme sorunları yaşayan siteler için WordPress bakım hizmetimiz bu ayarları optimize edilmiş olarak sunar.

    Gerçek Yüklemede Etkili Sınır Nasıl Hesaplanır#

    Değerleri ayarladıktan sonra sıklıkla sorulan soru şudur: "Hepsini 64M yaptım ama neden 60 MB'lık dosya yüklenmiyor?" Cevap, gerçek etkili sınırın tek bir direktifle değil, birkaç katmanın en düşüğüyle belirlenmesidir.

    Bir yükleme başarılı olabilmek için şu zincirin tamamını geçmelidir:

    Kullanıcı dosyası
       ↓
    Web sunucusu limiti (client_max_body_size / LimitRequestBody)
       ↓
    post_max_size (tüm istek)
       ↓
    upload_max_filesize (tek dosya)
       ↓
    max_execution_time / max_input_time (süre)
       ↓
    memory_limit (işleme belleği)
    

    Bu zincirde herhangi bir halka diğerlerinden düşükse, gerçek limit o olur. Örneğin PHP tarafını 64M yaptınız ama Nginx'in client_max_body_size değeri varsayılan 1 MB'de kaldıysa, kullanıcı PHP hatası bile görmeden Nginx'in "413 Request Entity Too Large" yanıtını alır.

    Nginx kullanıyorsanız ilgili server veya location bloğuna şunu ekleyin:

    server {
        client_max_body_size 128M;
        # PHP-FPM'e giden istekler için zaman aşımı
        location ~ \.php$ {
            fastcgi_read_timeout 300;
            include fastcgi_params;
        }
    }
    

    Değişiklikten sonra yapılandırmayı test edip yeniden yükleyin:

    sudo nginx -t && sudo systemctl reload nginx
    

    Apache tarafında karşılığı LimitRequestBody direktifidir (bayt cinsinden):

    # 128 MB = 134217728 bayt
    LimitRequestBody 134217728
    

    LiteSpeed veya CloudLinux kullanan paylaşımlı ortamlarda ise ek olarak sunucu düzeyinde bir yükleme limiti olabilir; bu durumda hosting sağlayıcınızla iletişime geçmeniz gerekebilir. Etkili sınırı hesaplarken bir de reverse proxy veya CDN (örneğin Cloudflare) katmanı olduğunu unutmayın; ücretsiz Cloudflare planı istek gövdesini 100 MB ile sınırlar. Çok büyük dosyalar yüklüyorsanız bu katmanları da gözden geçirin.

    Güvenlik ve Performans Açısından Dikkat Edilmesi Gerekenler#

    Yükleme limitlerini artırmak kullanışlıdır ama sınırsız yapmak akıllıca değildir. Yüksek upload_max_filesize ve post_max_size değerleri, kötü niyetli kullanıcıların sunucunuza devasa dosyalar göndererek disk ve bant genişliği tüketmesine (bir tür DoS) zemin hazırlayabilir. Limiti gerçek ihtiyacınızın biraz üzerinde tutun; herkese açık formlarınız varsa özellikle temkinli olun.

    memory_limit'i gereksiz yere yükseltmek de risklidir. Paylaşımlı bir sunucuda her PHP işleminin ayrılan belleği toplam kapasiteyi zorlayabilir; aynı anda çok sayıda büyük yükleme, sunucunun swap'e düşmesine ve tüm sitelerin yavaşlamasına neden olabilir. Değerleri kademeli artırın ve gerçek yükü izleyin.

    Büyük dosya yüklemelerinde bir başka pratik ipucu, mümkünse parçalı (chunked) yükleme yapan araçlar kullanmaktır. WordPress'in yeni sürümleri ve birçok yedekleme eklentisi, tek dev bir POST isteği yerine dosyayı parçalara bölerek gönderir; bu, düşük post_max_size değerlerinde bile büyük yedeklerin aktarılabilmesini sağlar. Site taşıma sırasında bu tür sınırlarla boğuşmak istemezseniz, site taşıma hizmetimiz tüm veri aktarımını sizin adınıza yapar.

    Sıkça Sorulan Sorular#

    upload_max_filesize değerini artırdım ama WordPress hâlâ eski limiti gösteriyor, neden?#

    Bunun en yaygın nedeni yanlış PHP sürümünü düzenlemenizdir. cPanel her alan adı için farklı bir PHP sürümü çalıştırabildiğinden, MultiPHP INI Editör'de sitenizin gerçekte kullandığı sürümü seçtiğinizden emin olun. İkinci olası neden PHP-FPM veya OPcache önbelleğidir; değişiklikten sonra PHP-FPM servisini yeniden başlatmak sorunu çözer. info.php ile ini_get değerlerini okuyarak gerçekte hangi ayarın yüklü olduğunu kesin olarak görebilirsiniz.

    post_max_size ile upload_max_filesize aynı olmalı mı?#

    Aynı olabilir ama post_max_size'ın daha büyük olması her zaman daha güvenlidir. Bir POST isteği yalnızca dosyayı değil, form alanlarını, güvenlik anahtarlarını ve diğer meta verileri de taşır; bu yüzden toplam istek boyutu her zaman dosyadan biraz büyüktür. Genel kural olarak post_max_sizeupload_max_filesize'ın en az iki katı yapın, örneğin 64M dosya limiti için 128M istek limiti.

    php.ini değişikliğinden sonra sunucuyu yeniden başlatmam gerekir mi?#

    PHP-FPM veya Apache modülü kullanıyorsanız evet, ilgili servisi yeniden başlatmanız gerekir; aksi halde eski yapılandırma bellekte kalır. Nginx + PHP-FPM için sudo systemctl restart php8.2-fpm yeterlidir. cPanel'in MultiPHP INI Editör'ü ile yaptığınız değişiklikler ise genellikle anında etkili olur, ayrı bir yeniden başlatma gerektirmez.

    413 Request Entity Too Large hatası alıyorum, PHP ayarları doğru olmasına rağmen neden?#

    Bu hata PHP'den değil, web sunucusundan gelir. Nginx'in client_max_body_size veya Apache'nin LimitRequestBody değeri, PHP limitlerinizden düşük kaldığında istek daha PHP'ye ulaşmadan reddedilir. Web sunucusu yapılandırmasına yükleme limitiyle uyumlu bir değer ekleyin ve servisi yeniden yükleyin. Ayrıca önünüzde bir CDN veya Cloudflare varsa onun istek gövde limitini de kontrol edin.

    Paylaşımlı hosting kullanıyorum ve MultiPHP INI Editör'de aradığım direktif yok, ne yapmalıyım?#

    Bu durumda aynı cPanel ekranındaki Editor sekmesini kullanarak eksik direktifleri ham metin olarak elle ekleyebilirsiniz. Alternatif olarak sitenizin kök dizinine bir .user.ini dosyası koyup ayarları oraya yazabilirsiniz; PHP-FPM tabanlı paylaşımlı ortamlarda bu yöntem çalışır. Yine de bir sonuç alamıyorsanız, sunucu düzeyinde bir sınır olabilir ve hosting sağlayıcınızın desteğine başvurmanız gerekir.

    Yükleme limitini çok yüksek yapmanın bir sakıncası var mı?#

    Evet, gereğinden yüksek limitler güvenlik ve performans riski taşır. Aşırı büyük dosya kabulü, sunucunuzu kaynak tüketimine dayalı kötüye kullanıma açık hale getirir ve yüksek memory_limit değerleri paylaşımlı sunucularda diğer siteleri yavaşlatabilir. Değerleri gerçek ihtiyacınızın biraz üzerinde tutun; nadiren büyük dosya yüklüyorsanız işlem sırasında geçici olarak artırıp sonra düşürmek daha güvenlidir.

    Kapanış#

    PHP yükleme sorunlarının neredeyse tamamı, upload_max_filesize, post_max_size ve max_execution_time değerlerinin birbiriyle uyumlu ayarlanmamasından kaynaklanır. Bu üçlüyü doğru orantıda yükselttiğinizde, web sunucusu tarafındaki client_max_body_size gibi katmanları da kontrol ettiğinizde, büyük dosya yükleme hataları büyük ölçüde ortadan kalkar. En önemli alışkanlık, değişiklikten sonra gerçek etkili sınırı bir tanı dosyasıyla doğrulamak ve doğru PHP sürümü üzerinde çalıştığınızdan emin olmaktır.

    Bu ayarları her seferinde kendiniz yapmakla uğraşmak istemiyorsanız, Clou.TR olarak size yardımcı olabiliriz. Web hosting paketlerimiz ve WordPress hosting çözümlerimiz esnek PHP limitleriyle gelir; daha fazla kontrol isteyenler için VDS sunucularımızda tüm yapılandırma sizin elinizdedir. Sunucu tarafındaki ince ayarları uzmanlarımıza bırakmak isterseniz sunucu yönetimi hizmetimiz de bir tık uzağınızda. İhtiyacınıza en uygun çözümü bulmak için ekibimizle iletişime geçmeniz yeterli.

    PHPYapılandırma

    Uygulamaya geçmeye hazır mısınız?

    NVMe SSD, ücretsiz SSL ve %99.9 uptime garantisiyle Clou.TR hosting ve sunucu çözümleriyle projenizi hayata geçirin.