WordPress'e görsel yüklerken çıkan HTTP error ne demek?

Tarayıcıdaki yükleyicinin dosyanızı sunucuya gönderdiği, ama geri dönen yanıtı geçerli bir başarı yanıtı olarak ayrıştıramadığı anlamına gelir. Mesaj nedeni değil, belirtiyi anlatır. Çöken bir PHP süreci, bir güvenlik duvarı engeli, bir 403 ve boş bir yanıt — hepsi aynı üç kelimeyi üretir.

Aynı görsel neden bazen yükleniyor bazen hata veriyor?

Aralıklı hatalar neredeyse her zaman bir yapılandırma limitini değil, bellek ya da CPU tükenmesini işaret eder. Büyük bir fotoğrafı yeniden boyutlandırmak ani bir bellek ihtiyacı doğurur ve paylaşımlı hostingde eldeki miktar sunucu yüküne göre değişir. post_max_size gibi katı bir limit ise her seferinde birebir aynı şekilde hata verir.

WordPress'i Imagick yerine GD kullanacak şekilde değiştirmek HTTP error hatasını çözer mi?

Bazen ve yalnızca tek bir dal için. Paylaşımlı hostinglerde ImageMagick çoğu zaman bir politika dosyasıyla ya da düşük kaynak limitleriyle kısıtlanır ve GD'nin başardığı yerde hata verir. Ancak GD çok büyük dosyalarda daha fazla bellek kullanır, dolayısıyla geçiş yapmak bellek kaynaklı hataları iyileştirmek yerine kötüleştirebilir.

Hosting güvenlik duvarımın yüklemeyi engellediğini nasıl anlarım?

Tarayıcınızın ağ araçlarını açın, dosyayı yükleyin ve async-upload.php için dönen durum koduna bakın. HTML gövdeli bir 403 ya da 406, bir web uygulaması güvenlik duvarının veya mod_security kuralının isteği reddettiği anlamına gelir. 500 ya da boş yanıt ise bunun yerine PHP'nin çöktüğünü gösterir.

upload_max_filesize değerini artırmak HTTP error hatasını çözer mi?

Yalnızca dosya gerçekten limitlerinizi aşıyorsa ve genelde post_max_size daha belirleyicidir. İstek gövdesinin tamamı post_max_size değerinden büyükse PHP, WordPress çalışmadan önce isteği atar ve yükleyiciye hiçbir şey dönmez. Birini diğeri olmadan yükseltmek hatayı olduğu yerde bırakır.

Bir dosya adı WordPress'te HTTP error hatasına yol açabilir mi?

Evet, ama en nadir dal budur. Türkçe karakterler, kesme işaretleri, ampersandlar ve Latin dışı alfabeler bir güvenlik kuralını tetikleyebilir ya da kodlaması uyuşmayan bir dosya sisteminde yolu bozabilir. Dosyayı sade küçük harf, rakam ve tireyle yeniden adlandırmak hiçbir şeye mal olmaz ve bu dalı on saniyede eler.

WordPress Görsel Yüklerken "HTTP error": Nedeni Gerçekten Bulan Karar Ağacı

“HTTP error” bir neden değildir. Medya yükleyicisinin, dosyanızı sunucuya gönderdiğini ama geri gelen yanıtı başarı olarak ayrıştıramadığını itiraf etmesidir — ve birbirinden bağımsız en az altı farklı arıza tam olarak bu üç kelimeyi üretir. Aralarında tahmin yürütmek, asıl sorunu bir güvenlik duvarı kuralı olan bir sitede insanların bütün bir öğleden sonrayı upload_max_filesize yükselterek geçirmesinin sebebidir.

En hızlı çıkış yolu, altı nedeni iki gruba ayıran tek bir gözlem, ardından her dal için tek bir kontroldür.

Önce: gerçek yanıtı okuyun

Tarayıcınızın geliştirici araçlarını açın, Network sekmesine geçin ve dosyayı yeniden yükleyin. async-upload.php isteğini takip edin. Geri gelen şey, teşhisinizdir.

Gördüğünüz	Anlamı	Gidilecek yer
403 ya da 406, HTML gövde	Güvenlik duvarı ya da mod_security isteği reddetti	Dal A
500, boş yanıt ya da yarım kalmış gövde	PHP çöktü ya da işlem ortasında belleği tükendi	Dal B
413	İstek gövdesi bir sunucu limitini aştı	Dal C
200, ama gövde temiz JSON değil	Bir eklenti ya da tema, yanıttan önce çıktı yazdırdı	Dal D
İstek hiç tamamlanmıyor / zaman aşımına uğruyor	Çalışma süresi limiti, genelde büyük dosyalarda	Dal B

Bu tek bakış, internetteki tavsiyelerin çoğunu sizin yerinize eler. Tarayıcı araçlarına ulaşamıyorsanız önce wp-config.php içinde log kaydını açın:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Yüklemeyi tekrarlayın, sonra wp-content/debug.log dosyasını okuyun. Bir fatal hata satırı dalı doğrudan söyler. Satır karmaşıksa hata log’u çözümleyiciye yapıştırın — yaygın fatal imzalarını gerçekte neyin bozulduğuyla eşleştirir.

Dal A — güvenlik duvarı ya da mod_security kuralı

Gövdesinde HTML sayfa olan bir 403, isteğin WordPress’e hiç ulaşmadığı anlamına gelir. Önündeki bir şey — mod_security, Cloudflare, Wordfence, Sucuri ya da hosting firmasının kendi kural seti — POST isteğinin zararlı göründüğüne karar verdi.

Kontrol şu: varsa güvenlik eklentisini geçici olarak devre dışı bırakın ve yeniden yükleyin. Hiçbir şey değişmiyorsa kural sunucu seviyesindedir ve hosting firmanızın, başarısız yüklemenin zaman damgası için mod_security denetim log’una bakması gerekir. İlgili kural kimliğini beyaz listeye alabilirler.

Burada karşınıza çıkacak tavsiyeler konusunda kendinize karşı dürüst olun. Şunu .htaccess dosyasına eklemenizi söyleyen kod parçacıkları:

SecFilterEngine Off
SecFilterScanPOST Off

mod_security 1.x’i hedefler, ki bu sürüm neredeyse tükenmiştir. Modern bir sunucuda bu direktifler ya hiçbir şey yapmaz ya da siteyi daha kötü hale getiren bir 500 hatası fırlatır. Modern mod_security SecRuleEngine kullanır ve yönetilen hostinglerin çoğu zaten dizin bazlı geçersiz kılmalara izin vermez. Yapıştırmayın; hosting firmasına sorun.

Dal B — PHP bellek ya da çalışma süresi limitleri

En yaygın dal budur ve en net işareti vardır: aralıklı olması. Aynı dosya üçüncü denemede yüklenir ya da 2MB’lık bir fotoğraf hata verirken 6MB’lık bir PDF sorunsuz geçer. Katı yapılandırma limitleri her seferinde birebir aynı şekilde hata verir. Bellek hataları vermez, çünkü ne kadar bellek kaldığı sunucunun o an başka ne yaptığına bağlıdır.

Neden özellikle görseller: WordPress dosyayı sadece saklamaz, her ara boyutu üretmek için ham piksellere açar — medium_large, add_image_size ile kaydedilmiş her boyut, mağazanız varsa woocommerce_thumbnail, ayrıca görsel big_image_size_threshold değerinin üzerindeyse bir de -scaled kopya. 12 megapiksellik bir JPEG diskte birkaç MB’dır ama bellekte, henüz yeniden boyutlandırma arabelleği bile hesaba katılmadan yaklaşık 48MB tutar. 128MB’lık bir limit hızla erir.

wp-config.php içinde, “stop editing” satırının üstünde yükseltin:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Asıl bedeli şu: WP_MEMORY_LIMIT, PHP’nin kendi izin verdiği değerin üzerine çıkamaz. Hosting firmanız memory_limit değerini 128M ile sınırlıyorsa bu sabit tamamen dekoratiftir. Gerçek değeri yazdığınız yerden değil, Araçlar → Site Sağlığı → Bilgi → Sunucu bölümünden kontrol edin. Tavan PHP’nin kendi limitiyse onu yalnızca hosting firması değiştirebilir.

Dal C — dosya boyutu ve POST limitleri

Gerçek sayılara Araçlar → Site Sağlığı → Bilgi → Medya İşleme altından bakın. İki ayar önemlidir ve insanlar hep sadece birini değiştirir:

upload_max_filesize — tek bir dosyanın üst sınırı.
post_max_size — tüm istek gövdesinin üst sınırı.

POST isteğinin tamamı post_max_size değerini aşarsa PHP, WordPress herhangi bir kod çalıştırmadan önce isteği atar. Döndürülecek hiçbir şey kalmaz, yükleyici de ayrıştırılamaz bir yanıt alır ve “HTTP error” der. post_max_size her zaman upload_max_filesize değerinden rahatça büyük olmalıdır.

Bilinmesi gereken bir ayrıntı: bir dosya yalnızca upload_max_filesize değerini aştığında yükleyici bunu genelde tarayıcıda yakalar ve dosyanın azami yükleme boyutunu aştığını söyler — çok daha net bir mesaj. Yani kuru bir “HTTP error”, herkesin ilk yükselttiği ayardan çok post_max_size ya da Dal B’yi işaret eder.

Bunları nerede değiştireceğiniz altyapınıza bağlıdır. mod_php ile çalışan Apache’de .htaccess işe yarar:

php_value upload_max_filesize 64M
php_value post_max_size 128M

PHP-FPM, LiteSpeed ya da NGINX üzerinde — ki modern hostinglerin çoğu böyledir — bu satırlar hiçbir şey yapmaz, hatta 500 hatası verebilir. Bunun yerine hosting firmasının PHP ayarları panelini ya da bir .user.ini dosyasını kullanın. NGINX ayrıca yalnızca hosting firmasının yükseltebileceği kendi client_max_body_size sınırını uygular.

Dal D — görsel işleme kütüphanesi (Imagick vs GD)

WordPress, PHP eklentisi mevcutsa ImageMagick’i tercih eder, yoksa GD’ye düşer. Paylaşımlı hostinglerde sorun sıklıkla ImageMagick’tir: politika yapılandırma dosyası işlem başına belleği, diski ve alanı kısıtlar ve bir yeniden boyutlandırma bu limitlerden birine takıldığında süreç işe yarar bir mesaj vermeden ölür. Bunu genelde büyük görsellerde görürsünüz, küçükler sorunsuz çalışır — Dal B’ye benzer ama o değildir.

Teoriyi test etmek için GD’yi zorlayın:

add_filter( 'wp_image_editors', function ( $editors ) {
    return array( 'WP_Image_Editor_GD' );
} );

Bunu functions.php dosyasına ya da küçük bir mu-plugin içine koyun, yüklemeyi tekrar deneyin, sonra hiçbir şey değişmediyse kaldırın.

Dürüst takas şu: GD kesin olarak daha iyi değildir. Sıkıştırılmamış görüntünün tamamını PHP’nin belleğinde tutar, dolayısıyla çok büyük dosyalarda — PHP’nin ayırdığı belleğin bir kısmının dışında çalışan — ImageMagick’in başarabileceği yerde memory_limit sınırına çarpabilir. Geçiş yapmak bir hatayı başka bir hatayla değiştirebilir. Bunu önce bir teşhis, sonra bir çözüm olarak görün.

Dal E — uploads dizini izinleri

Yönetilen hostinglerde nadirdir, ama bir taşıma ya da elle sunucu değişimi sonrasında sıktır. wp-content/uploads web sunucusu kullanıcısı tarafından yazılabilir değilse ya da yeni oluşan yıl/ay alt klasörü yanlış sahibi devraldıysa yazma işlemi başarısız olur.

ls -ld wp-content/uploads
ls -ld wp-content/uploads/2026/07

Dizinler tipik olarak 755 olmalı ve PHP’nin çalıştığı kullanıcıya ait olmalıdır. Bir forumda öyle yazdığı için 777 yapmayın — bu, klasörü sunucudaki her hesabın yazabileceği hale getirerek belirtiyi çözer, ki paylaşımlı hostingde bu gerçek bir güvenlik açığıdır.

Dal F — dosya adı

Listedeki en ucuz kontrol, o yüzden en düşük olasılık olmasına rağmen erken yapın. Dosyayı sade küçük harf, rakam ve tirelerle yeniden adlandırın — Türkçe karakter, kesme işareti, ampersand, # ya da Latin dışı karakter olmasın — ve tekrar yükleyin. Özel karakterler zaman zaman bir güvenlik kuralını tetikler ya da kodlaması uyuşmayan bir dosya sisteminde bozulur. Elemek on saniye sürer.

Yapılmaması gerekenler

İşe tüm eklentileri kapatarak başlamayın. Hem yıkıcıdır hem de yalnızca Dal A ile Dal D’yi test eder. Ağ yanıtı size beş saniyede daha fazlasını söyler.

Rastgele bir .htaccess handler satırı eklemeyin. Dolaşımdaki SetHandler ya da AddHandler direktifi ekleyen kod parçacıkları belirli bir hosting firmasının PHP kurulumunu varsayar. Yanlış altyapıda tüm siteyi 500 hatasıyla yere serer.

“Tekrar denedim, oldu” ifadesini çözüm saymayın. Aralıklı başarı Dal B’nin imzasıdır ve sunucu yoğunlaştığı ya da biri daha büyük bir şey yüklediği anda geri döner.

Hâlâ takıldınız mı?

Yanıt geçerli JSON içeren temiz bir 200 ise ve yükleme yine de başarısız oluyorsa arıza dosya karşıya geçtikten sonradır — genelde ek işleme zincirine bağlanan bir eklentinin fatal hata fırlatması ya da bir optimizasyon eklentisinin dış bir servise gönderdiği isteğin zaman aşımına uğraması. WP_DEBUG_LOG değerini açın, sorunu tekrarlayın ve çıkan fatal hatayı hata log’u çözümleyiciden geçirerek hangi dosyanın ve hangi kancanın gerçekten sorumlu olduğunu görün.