"HTTP error" Saat Upload Gambar di WordPress: Pohon Keputusan yang Benar-Benar Menemukan Penyebabnya

“HTTP error” bukan penyebab. Itu pengakuan dari media uploader bahwa file Anda sudah dikirim ke server tapi balasannya tidak bisa dibaca sebagai tanda sukses — dan setidaknya ada enam kegagalan yang tidak saling berhubungan menghasilkan dua kata yang persis sama. Menebak di antara keenamnya itulah alasan orang menghabiskan satu sore menaikkan upload_max_filesize di situs yang masalah aslinya adalah aturan firewall.

Jalan keluar tercepat adalah satu pengamatan yang membelah keenam penyebab itu jadi dua kelompok, lalu satu pemeriksaan per cabang.

Pertama: baca respons yang sebenarnya

Buka developer tools di browser Anda, masuk ke tab Network, lalu unggah filenya lagi. Perhatikan request ke async-upload.php. Apa pun yang kembali dari sana adalah diagnosis Anda.

Yang Anda lihat	Artinya	Lanjut ke
403 atau 406, isi berupa HTML	Firewall atau mod_security menolak request	Cabang A
500, respons kosong, atau isi yang terpotong	PHP crash atau kehabisan memori di tengah proses	Cabang B
413	Body request melebihi batas server	Cabang C
200, tapi isinya bukan JSON bersih	Ada plugin atau tema yang mencetak output sebelum respons	Cabang D
Request tidak pernah selesai / timeout	Batas waktu eksekusi, biasanya pada file besar	Cabang B

Satu pengamatan itu langsung mencoret sebagian besar saran yang beredar di internet. Kalau Anda tidak bisa mengakses developer tools, nyalakan dulu logging di wp-config.php:

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

Ulangi proses unggahnya, lalu baca wp-content/debug.log. Baris fatal error akan menyebut cabangnya secara langsung. Kalau barisnya terlalu padat, tempelkan ke decoder error log — alat itu memetakan pola fatal error yang umum ke penjelasan apa yang sebenarnya rusak.

Cabang A — aturan firewall atau mod_security

Kode 403 dengan halaman HTML di body-nya berarti request tidak pernah sampai ke WordPress. Ada sesuatu di depannya — mod_security, Cloudflare, Wordfence, Sucuri, atau aturan bawaan hosting Anda — yang menilai POST tersebut mencurigakan.

Cara memeriksanya: nonaktifkan sementara semua plugin keamanan lalu coba unggah lagi. Kalau tidak ada perubahan, aturan itu ada di level server, dan Anda perlu meminta pihak hosting memeriksa audit log mod_security pada jam kegagalan tadi. Mereka bisa membuat pengecualian untuk rule ID tertentu.

Jujurlah pada diri sendiri soal saran yang akan Anda temukan di sini. Potongan kode yang menyuruh Anda menempelkan ini ke .htaccess:

SecFilterEngine Off
SecFilterScanPOST Off

ditujukan untuk mod_security 1.x, yang praktis sudah punah. Di server modern, direktif itu tidak melakukan apa-apa atau justru melempar 500 yang membuat situs makin parah. mod_security modern memakai SecRuleEngine, dan sebagian besar managed hosting pun memblokir penimpaan pengaturannya per direktori. Tanya hosting Anda; jangan asal tempel.

Cabang B — batas memori atau waktu eksekusi PHP

Ini cabang paling umum sekaligus yang cirinya paling jelas: kegagalannya tidak konsisten. File yang sama berhasil di percobaan ketiga, atau foto 2MB gagal sementara PDF 6MB lolos mulus. Batas konfigurasi yang keras selalu gagal dengan pola sama persis. Kegagalan memori tidak begitu, karena jumlah yang tersedia bergantung pada apa lagi yang sedang dikerjakan server.

Kenapa gambar khususnya: WordPress bukan cuma menyimpan filenya, tapi mendekompresnya jadi piksel mentah untuk membuat setiap ukuran turunan — medium_large, semua ukuran yang didaftarkan lewat add_image_size, woocommerce_thumbnail kalau Anda punya toko, ditambah salinan -scaled kalau gambarnya melebihi big_image_size_threshold. JPEG 12 megapiksel hanya beberapa MB di disk tapi sekitar 48MB di memori, itu belum termasuk buffer proses resize. Batas 128MB cepat sekali habis.

Naikkan di wp-config.php, di atas baris “stop editing”:

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

Konsekuensi nyatanya: WP_MEMORY_LIMIT tidak bisa melampaui batas yang diizinkan PHP itu sendiri. Kalau hosting Anda mengunci memory_limit di 128M, konstanta ini cuma hiasan. Periksa nilai yang benar-benar berlaku di Perkakas → Kesehatan Situs → Info → Server, bukan di apa yang Anda tulis. Kalau batas PHP-nya sendiri yang jadi plafon, hanya pihak hosting yang bisa menaikkannya.

Cabang C — batas ukuran file dan post

Periksa angka aslinya di Perkakas → Kesehatan Situs → Info → Penanganan Media. Ada dua pengaturan yang berpengaruh dan orang selalu cuma mengubah satu:

• upload_max_filesize — batas untuk satu file.
• post_max_size — batas untuk seluruh body request.

Kalau total POST melebihi post_max_size, PHP membuang request itu sebelum WordPress menjalankan satu baris kode pun. Tidak ada apa pun yang bisa dikembalikan, jadi uploader menerima respons yang tak bisa dibaca dan berkata “HTTP error”. post_max_size harus selalu jauh lebih besar daripada upload_max_filesize.

Ada satu catatan yang perlu diketahui: kalau file hanya melebihi upload_max_filesize, uploader biasanya menangkapnya di browser dan bilang filenya melebihi ukuran unggah maksimum — pesan yang jauh lebih jelas. Jadi “HTTP error” polos justru lebih sering menunjuk ke post_max_size atau ke Cabang B ketimbang ke pengaturan yang selalu dinaikkan orang duluan.

Di mana mengubahnya tergantung stack Anda. Di Apache dengan mod_php, .htaccess masih berfungsi:

php_value upload_max_filesize 64M
php_value post_max_size 128M

Di PHP-FPM, LiteSpeed, atau NGINX — yang dipakai sebagian besar hosting modern — baris itu tidak berpengaruh, bahkan bisa melempar 500. Pakai panel pengaturan PHP milik hosting atau file .user.ini sebagai gantinya. NGINX juga menerapkan client_max_body_size sendiri, yang hanya bisa dinaikkan oleh pihak hosting.

Cabang D — pustaka pengolah gambar (Imagick vs GD)

WordPress lebih memilih ImageMagick kalau ekstensi PHP-nya tersedia, dan jatuh ke GD kalau tidak. Di shared hosting, ImageMagick justru sering jadi masalah: file konfigurasi policy-nya membatasi memori, disk, dan luas area per operasi, dan ketika proses resize menyentuh salah satu batas itu prosesnya mati tanpa pesan yang berguna. Biasanya ini muncul pada gambar besar sementara yang kecil aman — mirip Cabang B padahal bukan.

Paksa pakai GD untuk menguji dugaan ini:

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

Taruh di functions.php atau di mu-plugin kecil, ulangi unggahannya, lalu hapus lagi kalau tidak ada perubahan.

Kompromi jujurnya: GD tidak otomatis lebih baik. GD menyimpan seluruh bitmap tanpa kompresi di memori PHP, jadi untuk file sangat besar ia bisa menabrak memory_limit di titik yang sebenarnya masih sanggup ditangani ImageMagick — yang sebagian bekerja di luar alokasi PHP. Menggantinya bisa menukar satu kegagalan dengan kegagalan lain. Perlakukan sebagai alat diagnosis dulu, solusi belakangan.

Cabang E — izin folder uploads

Jarang terjadi di managed hosting, tapi umum tepat setelah migrasi atau pemindahan server manual. Kalau wp-content/uploads tidak bisa ditulisi oleh user web server, atau subfolder tahun/bulan yang baru dibuat mewarisi pemilik yang salah, proses tulisnya gagal.

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

Folder umumnya harus 755 dan dimiliki oleh user yang menjalankan PHP. Jangan pasang 777 cuma karena disuruh sebuah forum — itu memperbaiki gejala dengan membuat foldernya bisa ditulisi oleh semua akun di server, dan di shared hosting itu risiko keamanan yang nyata.

Cabang F — nama file

Pemeriksaan paling murah di daftar ini, jadi lakukan sejak awal meski kemungkinannya paling kecil. Ganti nama file jadi huruf kecil biasa, angka, dan tanda hubung — tanpa aksen, tanda petik, ampersand, #, atau aksara non-Latin — lalu unggah lagi. Karakter khusus sesekali memicu aturan keamanan atau bermasalah di filesystem dengan encoding yang tidak cocok. Sepuluh detik untuk menutup kemungkinan ini.

Yang sebaiknya tidak dilakukan

Jangan mulai dengan menonaktifkan semua plugin. Cara itu mengganggu operasional dan cuma menguji Cabang A dan Cabang D. Respons di tab Network memberi tahu lebih banyak dalam lima detik.

Jangan menambahkan baris handler asal-asalan di .htaccess. Potongan kode yang beredar dengan direktif SetHandler atau AddHandler mengasumsikan konfigurasi PHP hosting tertentu. Di stack yang salah, kode itu menjatuhkan seluruh situs dengan error 500.

Jangan menganggap “berhasil setelah dicoba ulang” sebagai selesai. Keberhasilan yang datang-pergi adalah ciri khas Cabang B, dan masalahnya akan kembali begitu server sibuk atau ada yang mengunggah file lebih besar.

Masih buntu?

Kalau responsnya 200 bersih dengan JSON valid tapi unggahan tetap gagal, kerusakannya terjadi setelah file mendarat — biasanya ada plugin yang menempel di rantai pemrosesan lampiran lalu melempar fatal error, atau plugin optimizer yang mengirim request sendiri ke layanan eksternal lalu timeout. Aktifkan WP_DEBUG_LOG, ulangi kejadiannya, lalu jalankan fatal error yang muncul melalui decoder error log untuk melihat file mana dan hook mana yang benar-benar bertanggung jawab.