Mengatasi Error 413 Request Entity Too Large di WordPress: Penyebab, Diagnosis, dan Cara Memperbaikinya untuk Publisher Indonesia

Error 413 Request Entity Too Large adalah pesan penolakan dari server yang muncul ketika ukuran data yang Anda kirim — paling sering sebuah file yang diunggah — melebihi batas yang diizinkan di salah satu lapisan antara browser dan server. Bagi publisher WordPress, error ini biasanya muncul di saat yang paling tidak tepat: ketika Anda sedang mengunggah foto sampul beresolusi tinggi, video pendek untuk artikel, file PDF, atau tema dan plugin berukuran besar. Halaman upload berhenti, muncul pesan 413, dan tidak ada penjelasan tambahan tentang lapisan mana yang menolaknya.

Kabar baiknya, error 413 hampir selalu bisa diperbaiki tanpa memindahkan hosting dan tanpa mengutak-atik kode tema. Kuncinya adalah memahami bahwa batas ukuran upload tidak hanya ada di satu tempat. Ada lima lapisan yang masing-masing punya batasnya sendiri: PHP, WordPress itu sendiri, web server (Nginx atau Apache), dan CDN atau proxy seperti Cloudflare. Batas yang berlaku adalah batas yang paling kecil di antara semuanya. Artikel ini menjelaskan cara mendiagnosis lapisan mana yang menolak upload Anda, lalu memperbaiki lapisan itu satu per satu — mulai dari pengaturan PHP di hPanel Hostinger, konfigurasi Nginx dan Apache, sampai batas paket Cloudflare — lengkap dengan angka resmi dari dokumentasi PHP, Nginx, Apache, dan Cloudflare yang sudah diverifikasi.

Poin Kunci

• Error 413 berarti request body yang Anda kirim lebih besar dari batas yang diizinkan di salah satu lapisan server; dalam standar terbaru (RFC 9110) namanya adalah “413 Content Too Large”, tetapi sebagian besar server dan browser masih menampilkan nama lama “Request Entity Too Large”.
• Batas yang berlaku adalah batas terkecil di seluruh jalur: PHP, WordPress, Nginx/Apache, dan CDN. Menaikkan satu lapisan saja tidak cukup bila lapisan lain masih lebih kecil.
• Nilai default resmi PHP adalah upload_max_filesize 2M dan post_max_size 8M, dan dokumentasi PHP menyatakan post_max_size harus lebih besar dari upload_max_filesize.
• Nginx membatasi request body secara default hanya 1 MB lewat client_max_body_size; file apa pun di atas 1 MB akan ditolak dengan 413 bila nilai ini belum diubah.
• Cloudflare membatasi upload 100 MB pada paket Free dan Pro, 200 MB pada Business, dan hingga 5 GB pada Enterprise; batas ini tidak bisa diubah dari server Anda.
• WordPress Multisite punya batas sendiri: “Max upload file size” default 1.500 KB (sekitar 1,5 MB) di Network Settings.
• Diagnosis yang benar dimulai dari layar Media › Add New di WordPress, lalu memeriksa log error server; menebak-nebak dan menaikkan semua nilai sekaligus justru menyulitkan Anda mengetahui perbaikan mana yang berhasil.

Daftar Isi

1. Apa Itu Error 413 dan Kenapa Ia Muncul di WordPress
2. Lima Lapisan Batas Ukuran yang Harus Dipahami Publisher
3. Diagnosis Cepat: Lapisan Mana yang Menolak Upload Anda
4. Langkah 1: Cek Batas yang Ditampilkan WordPress
5. Langkah 2: Naikkan Limit PHP — upload_max_filesize dan post_max_size
6. Cara Menaikkan Limit di Hostinger Lewat hPanel
7. Cara Menaikkan Limit Lewat .htaccess, .user.ini, dan wp-config.php
8. Langkah 3: Perbaiki Batas Nginx — client_max_body_size
9. Langkah 4: Periksa Batas Apache — LimitRequestBody
10. Langkah 5: Periksa Batas Cloudflare dan CDN
11. Kasus Khusus: WordPress Multisite dan Upload Tema atau Plugin
12. Solusi Tanpa Menaikkan Limit: Kompres, Potong, dan Upload Bertahap
13. Checklist Setelah Perbaikan dan Kapan Harus Menghubungi Hosting
14. FAQ
15. Kesimpulan
16. Sumber resmi yang dirujuk

1. Apa Itu Error 413 dan Kenapa Ia Muncul di WordPress

Kode status HTTP 413 didefinisikan dalam standar web sebagai penolakan terhadap request yang badan datanya (request body) terlalu besar untuk diproses server. Dalam RFC 9110, nama resminya adalah “413 Content Too Large”, menggantikan nama lama “Request Entity Too Large” dari RFC 7231. Dalam praktik, hampir semua hosting, panel, dan browser masih menampilkan nama lama, jadi jangan bingung bila Anda melihat “413 Request Entity Too Large” — itu error yang sama.

Untuk situs WordPress, skenario yang paling umum adalah upload media. Anda membuka Media › Add New, memilih sebuah file, lalu proses upload gagal dan muncul halaman 413 atau pesan “413 Request Entity Too Large”. Skenario lain yang juga umum: mengunggah tema atau plugin lewat Appearance › Themes › Add New atau Plugins › Add New, mengunggah file lewat formulir kontak atau formulir kirim artikel, serta mengimpor konten lewat Tools › Import dengan file XML berukuran besar.

Yang membuat error ini membingungkan adalah sifatnya yang “diam” di beberapa lapisan. Bila penolakan datang dari web server atau CDN, Anda langsung melihat halaman 413. Namun bila penolakan datang dari PHP, Anda sering tidak melihat kode 413 sama sekali. Dokumentasi PHP menjelaskan bahwa bila ukuran data POST melebihi post_max_size, superglobal $_POST dan $_FILES menjadi kosong — WordPress tidak menerima apa pun, sehingga upload gagal tanpa pesan yang jelas atau hanya menampilkan pesan generik seperti “HTTP error”. Karena itu, memahami lapisan demi lapisan jauh lebih penting daripada sekadar menaikkan satu angka.

Perlu juga dibedakan dari error lain yang mirip. Error 413 bukan error kehabisan memori (itu biasanya 500 atau halaman putih), bukan error timeout (itu 504), dan bukan error koneksi ke server asal (itu 521, 522, atau 524 bila Anda memakai Cloudflare). Bila Anda sudah menulis artikel tentang error-error tersebut, pola diagnosisnya sama: cari tahu lapisan mana yang berbicara, baru perbaiki lapisan itu. Artikel seri error WordPress di situs ini — termasuk Mengatasi Error 508 Resource Limit Is Reached di WordPress, Mengatasi Error 521, 522, dan 524 Cloudflare di WordPress, dan Mengatasi Error 504 Gateway Timeout di WordPress — memakai pendekatan yang sama dan bisa dibaca sebagai pelengkap.

2. Lima Lapisan Batas Ukuran yang Harus Dipahami Publisher

Setiap kali Anda mengunggah file ke WordPress, file itu melewati lima lapisan. Masing-masing lapisan memeriksa ukuran request, dan lapisan mana pun boleh menolaknya. Tabel berikut merangkum kelima lapisan itu beserta batas default resminya.

Tiga catatan penting dari tabel di atas. Pertama, nilai default PHP sangat kecil: 2 MB untuk satu file dan 8 MB untuk keseluruhan request. Sebagian besar hosting menaikkan nilai ini — Hostinger, misalnya, dalam contoh di dokumentasi resminya menunjukkan nilai default 512 MB untuk uploadMaxFilesize pada paket tertentu — tetapi nilai pastinya tergantung paket hosting Anda. Jangan berasumsi; selalu periksa nilai yang berlaku di situs Anda sendiri.

Kedua, post_max_size harus selalu lebih besar dari upload_max_filesize. Dokumentasi PHP menyatakan hal ini secara eksplisit. Alasannya, post_max_size membatasi keseluruhan isi request, termasuk file ditambah semua field formulir dan overhead multipart. Contoh hitungan yang dibuat untuk artikel ini: file 64 MB dengan overhead multipart sekitar 2% menghasilkan request sekitar 65,28 MB. Bila post_max_size Anda 72 MB, upload lolos; bila post_max_size Anda persis 64 MB, upload gagal meskipun file-nya sendiri “hanya” 64 MB. Karena itu patokan praktik yang aman adalah membuat post_max_size sekitar 8–25% lebih besar dari upload_max_filesize, misalnya 64M dan 72M, atau 128M dan 160M seperti contoh di dokumentasi Hostinger.

Ketiga, ada dua pengaturan PHP pendukung yang sering ikut bermasalah saat upload file besar, meskipun keduanya tidak menghasilkan 413. memory_limit (default 128 MB menurut dokumentasi PHP) adalah batas memori satu proses PHP; memproses gambar beresolusi tinggi untuk membuat thumbnail bisa menghabiskan memori besar, dan bila habis Anda mendapat fatal error, bukan 413. max_file_uploads (default 20) membatasi jumlah file dalam satu request; mengunggah 25 gambar sekaligus berarti lima gambar terakhir diabaikan begitu saja. Keduanya patut diperiksa bila upload Anda gagal dengan cara yang aneh setelah batas ukuran dinaikkan.

3. Diagnosis Cepat: Lapisan Mana yang Menolak Upload Anda

Sebelum mengubah pengaturan apa pun, luangkan lima menit untuk diagnosis. Menebak lapisan yang salah adalah penyebab paling umum seseorang menaikkan limit PHP berulang kali tetapi error 413 tetap muncul — karena penolaknya ternyata Nginx atau Cloudflare.

Dua alat diagnosis yang sudah tersedia di WordPress Anda sendiri adalah layar Media › Add New dan Site Health. Di Media › Add New, WordPress menampilkan “Maximum upload file size: X MB” — angka itu adalah nilai terkecil dari upload_max_filesize dan post_max_size yang dibaca dari PHP, sesuai fungsi wp_max_upload_size() di inti WordPress. Angka ini tidak mencakup batas Nginx, Apache, atau CDN, jadi angka besar di layar ini tidak menjamin upload besar akan berhasil. Di Tools › Site Health › Info › Server, Anda bisa melihat nilai PHP yang sedang aktif, termasuk versi PHP, memory_limit, dan max_execution_time.

Langkah diagnosis yang paling menentukan adalah memeriksa log error server. Di hosting Hostinger, jalurnya adalah hPanel › Advanced › Error Log atau melalui File Manager di folder logs. Bila log Nginx mencatat baris “client intended to send too large body”, penolaknya adalah Nginx. Bila log Apache mencatat 413, penolaknya adalah Apache. Bila tidak ada jejak sama sekali di log server padahal browser menampilkan 413, hampir pasti penolaknya ada di depan server — Cloudflare atau proxy lain — karena request tidak pernah sampai ke server Anda. Prinsip ini juga berlaku untuk error server lain; pada artikel Mengatasi Error 502 Bad Gateway di WordPress dan Mengatasi Error 429 Too Many Requests di WordPress dijelaskan pola baca log yang sama.

Satu pengujian sederhana yang sangat membantu: unggah file dengan ukuran bertahap. Mulai dari 1 MB, lalu 2 MB, 5 MB, 10 MB, dan 50 MB. Titik di mana upload mulai gagal memberi tahu Anda besar batas yang aktif. Bila gagal mulai di atas 1 MB, curigai Nginx dengan default 1 MB. Bila gagal mulai di atas 2 MB, curigai upload_max_filesize PHP yang masih default. Bila gagal hanya di atas 100 MB, curigai Cloudflare. Metode ini tidak membutuhkan akses SSH dan bisa dilakukan siapa saja.

4. Langkah 1: Cek Batas yang Ditampilkan WordPress

Sebelum mengubah apa pun, catat dulu batas yang sedang berlaku. Buka dashboard WordPress, lalu Media › Add New. Di bagian bawah layar tertulis “Maximum upload file size: X MB”. Angka itu adalah hasil perhitungan fungsi wp_max_upload_size() di inti WordPress, yaitu nilai terkecil antara upload_max_filesize dan post_max_size dari PHP yang sedang aktif. Bila angkanya misalnya 2 MB, Anda sudah tahu bahwa PHP masih memakai nilai default dan harus dinaikkan.

Selanjutnya, buka Tools › Site Health › Info, lalu buka bagian Server. Di sana tercantum versi PHP, memory_limit, max_execution_time, dan max_input_time yang sedang aktif. Catat semuanya — Anda akan membutuhkannya sebagai pembanding setelah mengubah pengaturan. Bila Site Health menampilkan peringatan bahwa versi PHP sudah lama, pertimbangkan juga untuk memperbarui PHP, karena versi PHP yang didukung penuh saat ini adalah 8.3 ke atas dan versi lama bisa menimbulkan masalah keamanan; panduan memperbarui WordPress dan PHP tanpa merusak iklan dan tampilan dibahas pada artikel Update WordPress Aman untuk Publisher.

Terakhir, ketahui ukuran file yang sebenarnya ingin Anda unggah. Klik kanan file di komputer Anda dan lihat propertinya. Banyak kasus 413 ternyata berawal dari ketidaksadaran: file video yang dikira 30 MB ternyata 180 MB, atau file PDF berisi puluhan gambar beresolusi tinggi yang ukurannya membengkak. Mengetahui angka pastinya membantu Anda memilih nilai batas baru yang masuk akal, bukan sekadar menaikkan semuanya ke angka maksimum.

5. Langkah 2: Naikkan Limit PHP — upload_max_filesize dan post_max_size

Bila diagnosis menunjukkan PHP sebagai penyebabnya, perbaikannya adalah menaikkan dua direktif di konfigurasi PHP: upload_max_filesize dan post_max_size. Keduanya bersifat INI_PERDIR menurut dokumentasi PHP — artinya keduanya hanya bisa diubah lewat php.ini, .user.ini, .htaccess (pada kondisi tertentu), atau konfigurasi pool PHP-FPM, dan tidak bisa diubah dengan ini_set() di dalam kode PHP yang sedang berjalan. Inilah sebabnya trik menambahkan ini_set('upload_max_filesize', ...) di wp-config.php sering tidak bekerja: nilainya dibaca sebelum skrip dieksekusi.

Paket nilai yang aman dan umum dipakai publisher adalah sebagai berikut. Untuk situs yang sesekali mengunggah gambar dan dokumen, 64M dan 72M sudah lebih dari cukup. Untuk situs yang rutin mengunggah video pendek atau file PDF besar, 128M dan 160M adalah pilihan yang wajar. Jangan langsung memasang nilai raksasa seperti 1G tanpa alasan: batas yang terlalu besar memperlebar peluang penyalahgunaan bila ada celah upload di plugin atau formulir, dan sebagian besar file media untuk artikel tidak pernah mendekati angka itu.

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

Perhatikan tiga aturan dari contoh di atas. Pertama, post_max_size (72M) lebih besar dari upload_max_filesize (64M), sesuai keharusan di dokumentasi PHP. Kedua, memory_limit (256M) lebih besar dari post_max_size, sesuai anjuran dokumentasi PHP, karena memproses file — terutama membuat thumbnail dari gambar besar — membutuhkan memori. Ketiga, max_execution_time dan max_input_time dinaikkan ke 300 detik, karena upload file besar lewat koneksi yang lambat bisa memakan waktu lama. Sebagai gambaran yang dihitung untuk artikel ini, mengunggah file 50 MB pada koneksi 10 Mbps membutuhkan sekitar 40 detik, dan file 100 MB pada koneksi yang sama membutuhkan sekitar 80 detik — keduanya masih di bawah 300 detik, tetapi sudah jauh di atas batas eksekusi default PHP yang hanya 30 detik.

Setelah mengubah nilai, Anda harus memastikan perubahan itu benar-benar aktif. Di hosting shared, perubahan lewat panel biasanya langsung berlaku, tetapi ada jeda propagasi beberapa menit. Cara memastikannya: kembali ke Media › Add New dan lihat apakah angka “Maximum upload file size” sudah berubah; bila belum, tunggu beberapa menit, bersihkan cache, dan periksa lagi. Bila Anda memakai PHP-FPM, perubahan pada file pool memerlukan restart layanan PHP-FPM — sesuatu yang hanya bisa dilakukan pemilik VPS atau tim hosting. Di shared hosting, jangan mencoba me-restart layanan sendiri; hubungi dukungan hosting bila nilai tidak berubah setelah 10–15 menit.

Satu jebakan yang sering terjadi: ada lebih dari satu file php.ini. File php.ini untuk baris perintah (CLI) berbeda dengan file php.ini untuk web server, dan WordPress membaca yang web server. Bila Anda mengubah php.ini lewat File Manager tetapi angka di Media › Add New tidak berubah, kemungkinan Anda mengubah file yang salah. Inilah salah satu alasan cara lewat panel hosting (bagian 6) lebih bisa diandalkan daripada mengedit file manual: panel mengubah file yang benar.

6. Cara Menaikkan Limit di Hostinger Lewat hPanel

Sebagian besar pembaca situs ini memakai Hostinger — situs ini sendiri berjalan di Hostinger — jadi langkah-langkah berikut memakai hPanel sebagai contoh. Prinsipnya sama di panel lain: cari menu konfigurasi PHP, ubah dua nilai, simpan.

1. Masuk ke akun Hostinger Anda, lalu buka Websites › Dashboard untuk domain yang bersangkutan.
2. Di sidebar, buka PHP Configuration. Bila Anda tidak menemukannya, gunakan kolom pencarian di hPanel dan ketik “PHP Configuration”.
3. Pilih tab PHP Options. Di sana tersedia berbagai parameter PHP, termasuk uploadMaxFilesize dan postMaxSize.
4. Ubah uploadMaxFilesize ke nilai yang Anda inginkan, misalnya 128M. Dokumentasi Hostinger menunjukkan contoh nilai default 512 MB pada paket tertentu — nilai yang tersedia tergantung paket hosting Anda.
5. Ubah postMaxSize ke nilai yang lebih besar dari uploadMaxFilesize, misalnya 160M. Dokumentasi Hostinger menegaskan bahwa postMaxSize harus selalu lebih besar dari uploadMaxFilesize.
6. Simpan perubahan. Nilai yang Anda pilih tidak bisa melebihi batas maksimum paket hosting Anda; bila nilai yang diinginkan tidak tersedia di dropdown, itu tandanya paket Anda membatasinya dan solusinya adalah upgrade paket, bukan mengedit file konfigurasi secara manual.

Setelah menyimpan, tunggu beberapa menit, lalu periksa Media › Add New di WordPress. Bila angka “Maximum upload file size” sudah sesuai nilai baru, lanjutkan ke pengujian upload. Bila belum berubah, bersihkan cache situs (bila memakai plugin cache) dan periksa lagi. Sebagai pengaman, buat cadangan sebelum mengubah pengaturan server apa pun; panduan jadwal backup dan cara restore dibahas pada artikel Backup WordPress Otomatis untuk Publisher.

Catatan penting dari dokumentasi Hostinger: nilai yang Anda atur lewat functions.php atau .htaccess tidak bisa melampaui batas maksimum paket hosting — bila Anda memasang nilai lebih besar, yang berlaku tetap batas maksimum paket. Karena itu, bila dropdown hPanel tidak menyediakan nilai yang Anda butuhkan, jangan membuang waktu mengedit file; hubungi dukungan Hostinger atau pertimbangkan upgrade paket.

7. Cara Menaikkan Limit Lewat .htaccess, .user.ini, dan wp-config.php

Bila hosting Anda tidak menyediakan panel konfigurasi PHP, atau Anda memakai VPS, ada tiga jalur file yang bisa dipakai. Pilih satu jalur yang sesuai dengan lingkungan Anda; jangan memakai ketiganya sekaligus karena akan membingungkan saat terjadi masalah.

Lewat .htaccess (Apache dengan PHP sebagai modul)

Tambahkan baris berikut di akhir file .htaccess di folder root WordPress (biasanya public_html). Cara ini hanya bekerja bila server memakai Apache dengan PHP sebagai modul dan mengizinkan override lewat .htaccess. Pada hosting yang memakai PHP-FPM atau LiteSpeed dengan konfigurasi tertentu, baris php_value di .htaccess bisa menyebabkan error 500 — bila itu terjadi, hapus baris tersebut dan gunakan cara .user.ini di bawah.

php_value upload_max_filesize 64M
php_value post_max_size 72M
php_value memory_limit 256M
php_value max_execution_time 300
php_value max_input_time 300

Lewat .user.ini (PHP-FPM dan sebagian besar shared hosting modern)

Buat atau edit file .user.ini di folder root WordPress (sejajar dengan wp-config.php), lalu isi dengan:

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

File .user.ini dibaca ulang oleh PHP setiap lima menit secara default (sesuai pengaturan user_ini.cache_ttl), jadi tunggu beberapa menit sebelum memeriksa Media › Add New. File ini tersembunyi (berawalan titik), jadi pastikan File Manager Anda menampilkan file tersembunyi.

Lewat wp-config.php (terbatas)

Menambahkan baris berikut di wp-config.php kadang bekerja pada hosting tertentu, tetapi seperti dijelaskan di bagian 5, upload_max_filesize dan post_max_size bersifat INI_PERDIR sehingga ini_set() tidak bisa mengubahnya saat skrip berjalan. Baris ini hanya berguna sebagai pelengkap, bukan solusi utama:

@ini_set( 'upload_max_size' , '64M' );
@ini_set( 'post_max_size', '72M' );
@ini_set( 'memory_limit', '256M' );

Perlu dicatat bahwa konstanta WP_MEMORY_LIMIT di wp-config.php (define( 'WP_MEMORY_LIMIT', '256M' );) mengatur batas memori WordPress, bukan batas upload. Menaikkan konstanta ini membantu pemrosesan gambar besar, tetapi tidak menyelesaikan 413 yang disebabkan upload_max_filesize atau post_max_size.

Yang tidak boleh dilakukan

Jangan menaikkan batas upload lewat plugin yang menjanjikan “increase upload limit” tanpa memeriksa apa yang sebenarnya diubah plugin itu — sebagian hanya menambahkan ini_set() yang tidak efektif, sebagian lagi mengubah functions.php tema Anda sehingga perubahannya hilang saat tema diperbarui. Dan jangan pernah menonaktifkan batas upload sepenuhnya (nilai 0 atau -1) di situs produksi: batas itu ada untuk melindungi server dari upload raksasa yang bisa menghabiskan disk dan memori. Panduan memilih dan menguji plugin dengan aman dibahas pada artikel Mengelola Plugin WordPress untuk Publisher.

8. Langkah 3: Perbaiki Batas Nginx — client_max_body_size

Inilah lapisan yang paling sering menjadi penyebab 413 yang “bandel”. Anda sudah menaikkan limit PHP, angka di Media › Add New sudah 128 MB, tetapi upload 5 MB tetap ditolak dengan 413. Penyebabnya hampir pasti Nginx: dokumentasi resmi Nginx menyatakan client_max_body_size memiliki nilai default hanya 1 MB, dan bila ukuran request melebihi nilai itu, Nginx mengembalikan error 413. File 2 MB saja sudah dua kali lipat batas default ini.

Perbaikannya adalah menambahkan atau mengubah direktif client_max_body_size di blok server konfigurasi Nginx:

server {
    listen 80;
    server_name contoh.com;

    client_max_body_size 64m;

    location / {
        ...
    }
}

Setelah mengubah konfigurasi, uji dulu sintaksnya dengan nginx -t, lalu muat ulang Nginx dengan systemctl reload nginx. Tanpa reload, perubahan tidak berlaku. Perhatikan bahwa nilai ini juga harus selaras dengan PHP: patokan praktiknya, client_max_body_size sebaiknya sama dengan atau sedikit lebih besar dari post_max_size Anda. Bila PHP mengizinkan 72 MB tetapi Nginx hanya 64 MB, Nginx tetap menolak file di antara 64 MB dan 72 MB.

Penting untuk dipahami: pengaturan Nginx tidak bisa diubah dari dashboard WordPress dan tidak bisa diubah lewat .htaccess. Di shared hosting, Anda tidak memiliki akses ke konfigurasi Nginx — dan memang tidak perlu, karena penyedia hosting yang baik sudah mengatur nilai ini cukup besar. Bila situs Anda di shared hosting dan diagnosis mengarah ke Nginx, solusinya adalah menghubungi dukungan hosting dan meminta mereka menaikkan client_max_body_size, atau memeriksa apakah ada pengaturan terkait di panel hosting Anda. Di VPS, Anda mengubahnya sendiri seperti contoh di atas.

Satu hal lagi: bila Nginx berfungsi sebagai reverse proxy di depan Apache atau PHP-FPM, pastikan direktif ini ada di blok server yang benar — yaitu blok yang melayani domain Anda, bukan blok default. Kesalahan menaruh direktif di blok yang salah adalah penyebab umum “sudah diubah tetapi tetap 413”.

9. Langkah 4: Periksa Batas Apache — LimitRequestBody

Bila server Anda memakai Apache, direktif yang relevan adalah LimitRequestBody. Direktif ini membatasi ukuran request body dalam satuan byte dan bisa dipasang di konfigurasi server, virtual host, direktori, atau .htaccess. Bila request melebihi nilai ini, Apache mengembalikan 413.

Nilai default direktif ini berubah seiring waktu. Pada Apache sebelum versi 2.4.54, nilai default adalah 0 yang berarti tanpa batas. Sejak Apache 2.4.54, nilai default yang didokumentasikan adalah 1 GB, dan beberapa distribusi seperti Red Hat Enterprise Linux mengubah default menjadi 1 GiB lebih awal sebagai perbaikan keamanan CVE-2022-29404. Praktisnya, Apache jarang menjadi penyebab 413 di instalasi standar — tetapi bisa menjadi penyebab bila seseorang (atau panel hosting) pernah memasang nilai kecil, misalnya untuk keamanan, dan lupa menaikkannya kembali.

Untuk memeriksa dan memperbaikinya, cari LimitRequestBody di file konfigurasi Apache atau .htaccess Anda. Bila menemukannya dengan nilai kecil, naikkan ke nilai yang sesuai, misalnya 64 MiB:

LimitRequestBody 67108864

Angka 67.108.864 byte sama dengan 64 MiB — hitungan ini dibuat untuk artikel ini (64 × 1.024 × 1.024). Berbeda dengan PHP dan Nginx yang menerima notasi seperti “64M”, LimitRequestBody memakai satuan byte mentah, jadi Anda harus menghitungnya sendiri. Contoh lain: 5.242.880 byte sama dengan 5 MiB. Bila Anda tidak menemukan LimitRequestBody di mana pun, berarti Apache memakai nilai default dan bukan penyebab masalah Anda — lanjutkan ke lapisan berikutnya.

10. Langkah 5: Periksa Batas Cloudflare dan CDN

Lapisan terakhir dan paling “tidak terlihat” adalah CDN atau proxy di depan server Anda, yang paling umum adalah Cloudflare. Dokumentasi resmi Cloudflare tentang error 413 menyatakan bahwa batas upload tergantung paket domain Anda: 100 MB untuk paket Free dan Pro, 200 MB untuk Business, dan hingga 5 GB untuk Enterprise. Bila request melebihi batas itu, Cloudflare mengembalikan 413 — dan karena penolakan terjadi di edge Cloudflare, request tidak pernah sampai ke server Anda, sehingga tidak ada jejaknya di log server.

Ciri khas masalah Cloudflare: semua file di bawah 100 MB berhasil diunggah, tetapi file di atas 100 MB selalu gagal dengan 413 meskipun semua pengaturan server sudah dinaikkan. Pengujian paling cepat adalah mengubah sementara record DNS domain Anda dari mode proxied (awan oranye) menjadi DNS-only (awan abu-abu) di dashboard Cloudflare, lalu mencoba upload yang sama. Bila berhasil, Anda sudah menemukan penyebabnya.

Solusinya ada tiga, tergantung kebutuhan Anda. Pertama, perkecil file sebelum diunggah — untuk video, kompres atau potong menjadi beberapa bagian; untuk arsip besar, pecah menjadi beberapa file. Kedua, unggah lewat hostname yang tidak melewati proxy Cloudflare (DNS-only), misalnya subdomain khusus seperti direct.contoh.com yang mengarah langsung ke server asal. Ketiga, naikkan paket Cloudflare ke Business (200 MB) atau Enterprise (hingga 5 GB) bila Anda memang rutin mengunggah file sangat besar — tetapi untuk sebagian besar publisher, dua solusi pertama sudah cukup. Yang tidak bisa dilakukan adalah menaikkan batas 100 MB paket Free atau Pro dari sisi server: batas itu ditetapkan oleh Cloudflare dan tidak ada pengaturan di hosting Anda yang bisa mengubahnya.

Perlu dicatat juga bahwa beberapa plugin keamanan dan firewall aplikasi web (WAF) — termasuk aturan ModSecurity di server — punya batas body sendiri. Bila Anda memakai ModSecurity, nilai default yang umum dari konfigurasi yang direkomendasikan adalah batas body sekitar 128 MB (SecRequestBodyLimit), tetapi penyedia hosting bisa mengubahnya. Bila semua lapisan di atas sudah diperiksa dan 413 tetap muncul, mintalah tim hosting memeriksa aturan WAF dan ModSecurity.

11. Kasus Khusus: WordPress Multisite dan Upload Tema atau Plugin

WordPress Multisite memiliki satu batas tambahan yang tidak ada di instalasi situs tunggal. Di Network Admin › Settings › Network Settings, bagian Upload Settings, terdapat field “Max upload file size” yang menurut dokumentasi resmi WordPress memiliki nilai default 1.500 KB (sekitar 1,5 MB). Batas ini berlaku di atas batas PHP: bila PHP mengizinkan 128 MB tetapi pengaturan jaringan hanya 1.500 KB, file 2 MB tetap ditolak dengan pesan “This file is too big. Files must be less than 1500 KB in size.”

Perbaikannya sederhana: ubah nilai itu ke angka yang Anda inginkan, dalam satuan KB. Misalnya, untuk 50 MB, isi 50000 (karena setiap 1.000 KB dihitung sebagai 1 MB dalam field ini). Simpan perubahan. Namun perlu diingat, pengaturan ini tidak bisa melampaui batas PHP — menaikkan field ini ke 100.000 KB tidak ada gunanya bila upload_max_filesize PHP hanya 2 MB. Naikkan keduanya secara berurutan: PHP dulu, baru pengaturan jaringan.

Kasus khusus kedua adalah upload tema dan plugin. File tema atau plugin premium sering berukuran 10–50 MB, dan batas upload WordPress berlaku juga untuk instalasi lewat Appearance › Themes › Add New dan Plugins › Add New. Bila file tema 30 MB ditolak padahal Media › Add New menunjukkan batas 64 MB, periksa apakah penolakan datang dari Nginx atau Cloudflare — batas upload berlaku untuk semua jenis upload, bukan hanya media. Alternatif yang selalu tersedia adalah mengunggah lewat FTP atau File Manager langsung ke folder wp-content/themes atau wp-content/plugins, lalu mengaktifkannya dari dashboard. Cara ini melewati seluruh batas upload HTTP, meskipun tetap tunduk pada kuota disk hosting Anda.

Kasus khusus ketiga adalah impor konten. File XML hasil ekspor WordPress untuk situs dengan ribuan artikel bisa berukuran puluhan MB. Bila impor gagal dengan 413, selain menaikkan batas, Anda juga bisa memecah file XML menjadi beberapa bagian atau memakai plugin importer yang mendukung impor bertahap. Hal yang sama berlaku untuk upload lewat REST API atau aplikasi mobile WordPress: semuanya memakai request HTTP yang sama dan tunduk pada batas yang sama.

12. Solusi Tanpa Menaikkan Limit: Kompres, Potong, dan Upload Bertahap

Menaikkan batas bukan satu-satunya jawaban — dan sering kali bukan jawaban terbaik. Untuk publisher, sebagian besar file yang memicu 413 sebenarnya tidak perlu sebesar itu. Mengecilkan file sebelum diunggah membuat situs lebih cepat, menghemat kuota disk, dan menghindari masalah batas di semua lapisan sekaligus.

Untuk gambar, kompres sebelum mengunggah. Foto hasil kamera ponsel modern bisa berukuran 5–10 MB per file, padahal untuk tampil di artikel web, gambar yang sudah dikompres ke 150–300 KB biasanya sudah cukup. Gunakan format WebP, yang umumnya menghasilkan file lebih kecil daripada JPEG pada kualitas visual yang sama. Panduan lengkapnya ada di artikel Optimasi Gambar WordPress untuk Publisher. Bila Anda mengunggah banyak gambar sekaligus, ingat juga batas max_file_uploads sebanyak 20 file per request — unggah dalam kelompok kecil.

Untuk video, jangan mengunggah file video mentah ke Media Library. Praktik yang lebih baik untuk publisher adalah mengunggah video ke YouTube atau platform video lain, lalu menyematkannya (embed) di artikel. Selain menghindari 413, cara ini menghemat bandwidth dan disk hosting, serta membuat video diputar lewat CDN platform tersebut. Bila video memang harus berada di server sendiri, kompres dengan alat seperti HandBrake dan pertimbangkan resolusi 720p, yang untuk sebagian besar artikel sudah memadai.

Untuk file yang memang harus besar — misalnya arsip ZIP berisi materi unduhan atau file PDF berisi ratusan halaman — ada dua teknik. Pertama, pecah file menjadi beberapa bagian (misalnya ZIP multipart atau PDF per bab) dan sediakan sebagai beberapa tautan unduhan. Kedua, gunakan upload bertahap (chunked upload): file dipecah menjadi potongan-potongan kecil di sisi klien, misalnya 5 MB per chunk, lalu potongan-potongan itu diunggah satu per satu dan disatukan kembali di server. Sebagai ilustrasi hitungan untuk artikel ini, file 200 MB yang dipecah menjadi chunk 5 MB menghasilkan 40 chunk, sedangkan file 120 MB dengan chunk 10 MB menghasilkan 12 chunk. Teknik chunked upload inilah yang dipakai oleh banyak plugin backup dan migrasi besar — dan alasannya juga teknis: setiap chunk berada jauh di bawah semua batas lapisan, sehingga tidak ada satu pun lapisan yang menolaknya.

Satu peringatan terkait teknik base64: sebagian plugin dan integrasi mengirim file sebagai teks base64 di dalam request JSON. Encoding base64 menambah ukuran sekitar 33% — file 10 MB menjadi sekitar 13,3 MB, file 50 MB menjadi sekitar 66,7 MB, dan file 100 MB menjadi sekitar 133,3 MB (hitungan dibuat untuk artikel ini). Bila Anda mengunggah lewat API atau plugin yang memakai base64, pastikan batas Anda memperhitungkan overhead ini, atau cari jalur upload yang memakai multipart biasa.

13. Checklist Setelah Perbaikan dan Kapan Harus Menghubungi Hosting

Setelah semua perubahan dilakukan, jalankan checklist berikut sebelum menyatakan masalah selesai.

1. Periksa Media › Add New dan pastikan angka “Maximum upload file size” sudah sesuai nilai baru.
2. Unggah file uji dengan ukuran bertahap — 5 MB, 10 MB, lalu ukuran file asli yang sebelumnya gagal — dan pastikan semuanya berhasil.
3. Periksa bahwa thumbnail terbentuk dengan benar untuk gambar yang diunggah; bila gambar berhasil diunggah tetapi thumbnail tidak terbentuk, periksa memory_limit dan max_execution_time.
4. Periksa log error server sekali lagi untuk memastikan tidak ada peringatan baru setelah perubahan.
5. Uji upload dari jaringan yang berbeda (misalnya tethering HP) untuk memastikan masalahnya bukan di proxy jaringan Anda.
6. Catat nilai akhir yang Anda pakai (PHP, Nginx/Apache, dan Cloudflare) di catatan internal Anda, agar saat pindah hosting atau terjadi reset konfigurasi, Anda tidak perlu mendiagnosis dari nol lagi.

Hubungi dukungan hosting bila: Anda sudah menaikkan limit PHP tetapi angka di Media › Add New tidak berubah setelah 15 menit; Anda mencurigai Nginx tetapi tidak memiliki akses ke konfigurasinya; error 413 tetap muncul setelah semua lapisan diperiksa dan tidak ada jejak di log; atau Anda memakai paket shared hosting yang batas maksimumnya lebih kecil dari kebutuhan Anda dan perlu didiskusikan opsi upgrade paketnya. Saat menghubungi dukungan, sertakan informasi berikut agar mereka bisa membantu dengan cepat: ukuran file yang gagal, pesan error persis yang muncul, waktu kejadian, dan nilai batas yang tercantum di Media › Add New serta Site Health. Informasi yang lengkap membuat tiket Anda ditangani lebih cepat daripada sekadar menulis “upload saya gagal”.

Sebagai langkah pencegahan jangka panjang, terapkan tiga kebiasaan: kompres semua gambar sebelum diunggah, tetapkan ukuran maksimum file yang boleh diunggah kontributor di panduan redaksi Anda, dan periksa nilai batas upload setiap kali pindah hosting atau setelah migrasi server — karena nilai-nilai ini tidak ikut berpindah bersama file WordPress Anda. Untuk migrasi yang aman tanpa kehilangan traffic, lihat panduan Memindahkan WordPress ke Domain Baru Tanpa Kehilangan Traffic dan Ranking dan Memilih Hosting WordPress untuk Traffic Indonesia. Bila Anda memakai CDN, panduan CDN dan Caching untuk WordPress Publisher menjelaskan cara mengonfigurasi caching tanpa merusak konten dinamis. Dan untuk keamanan menyeluruh — termasuk pembatasan login dan perlindungan formulir upload — baca Keamanan WordPress untuk Publisher.

FAQ

1. Apa bedanya error 413 dengan pesan “The uploaded file exceeds the upload_max_filesize directive in php.ini”?

Keduanya berhubungan dengan batas ukuran, tetapi berasal dari lapisan berbeda. Pesan “exceeds the upload_max_filesize directive” datang dari PHP ketika satu file melebihi upload_max_filesize — WordPress menampilkan pesan ini dengan jelas. Error 413 datang dari web server (Nginx atau Apache) atau CDN ketika keseluruhan request body melebihi batas lapisan itu. Bila Anda melihat pesan PHP, perbaiki PHP; bila Anda melihat halaman 413, periksa Nginx, Apache, atau Cloudflare terlebih dahulu.

2. Saya sudah menaikkan upload_max_filesize, tetapi Media › Add New masih menampilkan angka lama. Kenapa?

Kemungkinan penyebabnya ada tiga. Pertama, perubahan belum berlaku — file .user.ini dibaca ulang setiap sekitar lima menit, dan perubahan lewat panel hosting bisa butuh beberapa menit propagasi. Kedua, Anda mengubah file php.ini yang salah — file untuk CLI berbeda dengan file untuk web server. Ketiga, ada pengaturan lain yang lebih kecil yang membatasi, misalnya pengaturan pool PHP-FPM atau nilai maksimum paket hosting Anda. Periksa Site Health › Info › Server untuk melihat nilai yang benar-benar aktif, dan bila tetap tidak berubah setelah 15 menit, hubungi dukungan hosting.

3. Berapa nilai batas upload yang ideal untuk situs publisher?

Untuk sebagian besar publisher, upload_max_filesize 64M dan post_max_size 72M sudah cukup, dengan client_max_body_size Nginx yang diselaraskan di 64m atau 72m. Bila Anda rutin mengunggah video pendek atau PDF besar, 128M dan 160M adalah pilihan yang wajar. Nilai yang lebih besar dari itu jarang diperlukan untuk konten artikel, dan menaikkan batas tanpa alasan hanya memperlebar risiko keamanan bila ada celah upload di plugin atau formulir.

4. Apakah menaikkan batas upload berbahaya bagi keamanan situs?

Menaikkan batas ke nilai yang wajar (64–128 MB) dengan tetap membatasi jenis file yang diizinkan umumnya aman. Yang berbahaya adalah menonaktifkan batas sepenuhnya atau memasang nilai raksasa tanpa alasan, karena penyerang yang menemukan celah upload bisa mengunggah file besar untuk menghabiskan disk dan memori server. Pastikan hanya administrator dan peran tepercaya yang bisa mengunggah, batasi jenis file (MIME type) yang diizinkan, dan pasang plugin keamanan yang memindai upload. Panduan lengkapnya ada di artikel keamanan WordPress yang dirujuk di bagian sumber.

5. Kenapa upload file di atas 100 MB selalu gagal padahal server saya mengizinkan 256 MB?

Hampir pasti penyebabnya adalah Cloudflare. Paket Free dan Pro Cloudflare membatasi upload hingga 100 MB, dan batas ini ditegakkan di edge Cloudflare sebelum request sampai ke server Anda — jadi sebesar apa pun batas server Anda, tidak ada pengaruhnya. Solusinya: perkecil file, unggah lewat subdomain DNS-only yang tidak melewati proxy Cloudflare, atau naikkan paket Cloudflare ke Business (200 MB) atau Enterprise (hingga 5 GB).

6. Apakah error 413 memengaruhi SEO dan ranking situs saya?

Error 413 itu sendiri tidak langsung menurunkan ranking, karena ini adalah error pada proses upload di dashboard, bukan pada halaman yang diakses pengunjung atau crawler Google. Namun ada dampak tidak langsung: bila error ini membuat Anda tidak bisa memperbarui konten, mengunggah gambar, atau memasang plugin, kualitas dan kesegaran situs Anda akan menurun seiring waktu. Selain itu, bila 413 muncul pada endpoint publik — misalnya formulir kirim artikel dari pembaca — pengunjung akan mengalami kegagalan yang merusak pengalaman mereka. Karena itu, perbaiki segera setelah ditemukan, tetapi tidak perlu panik soal penalti SEO langsung.

Kesimpulan

Error 413 Request Entity Too Large bukan error yang misterius — ia adalah penolakan yang jelas dari salah satu lapisan server karena request Anda terlalu besar. Lima lapisan yang perlu Anda periksa adalah PHP (upload_max_filesize default 2 MB dan post_max_size default 8 MB), WordPress Multisite (batas jaringan default 1.500 KB), Nginx (client_max_body_size default hanya 1 MB), Apache (LimitRequestBody, default 1 GB sejak versi 2.4.54), dan Cloudflare (100 MB pada paket Free dan Pro). Batas yang berlaku adalah yang paling kecil di antara semuanya, jadi perbaikan harus dilakukan pada lapisan yang benar-benar menolak — bukan sekadar menaikkan satu angka dan berharap.

Alur kerja yang benar adalah: cek angka di Media › Add New dan Site Health, uji upload bertahap untuk menemukan titik gagalnya, periksa log error server untuk memastikan lapisan penolaknya, lalu perbaiki lapisan itu — PHP lewat hPanel atau .user.ini, Nginx lewat client_max_body_size, Apache lewat LimitRequestBody, atau Cloudflare dengan mengecilkan file atau memakai jalur DNS-only. Setelah itu, uji kembali dengan file yang sebelumnya gagal dan pastikan thumbnail terbentuk dengan benar.

Terakhir, ingat bahwa menaikkan batas hanyalah setengah solusi. Untuk publisher, kebiasaan yang lebih berharga adalah mengecilkan file sebelum diunggah: kompres gambar ke WebP, sematkan video lewat platform video alih-alih mengunggahnya ke Media Library, dan pecah file besar menjadi bagian-bagian yang masuk akal. Situs yang ringan bukan hanya terhindar dari error 413 — ia juga lebih cepat dimuat, lebih hemat kuota disk, dan lebih disukai pembaca maupun mesin pencari.

Sumber resmi yang dirujuk

1. Dokumentasi PHP — Description of core php.ini directives: nilai default upload_max_filesize 2M, post_max_size 8M, memory_limit 128M, max_file_uploads 20; post_max_size harus lebih besar dari upload_max_filesize; bila data POST melebihi post_max_size, $_POST dan $_FILES kosong. https://www.php.net/manual/en/ini.core.php
2. Dokumentasi Nginx — Module ngx_http_core_module, direktif client_max_body_size: nilai default 1m; bila ukuran request melebihi nilai yang dikonfigurasi, error 413 dikembalikan; nilai 0 menonaktifkan pemeriksaan. https://nginx.org/en/docs/http/ngx_http_core_module.html
3. Dokumentasi Cloudflare — Error 413: batas upload 100 MB (Free dan Pro), 200 MB (Business), hingga 5 GB (Enterprise); dapat diatur di halaman Network zona; bila melebihi, Cloudflare mengembalikan 413. https://developers.cloudflare.com/support/troubleshooting/http-status-codes/4xx-client-error/error-413/
4. Dokumentasi Apache HTTP Server — Direktif LimitRequestBody: membatasi ukuran request body dalam byte; nilai 0 berarti tanpa batas; default 1 GB pada Apache 2.4.54 ke atas. https://httpd.apache.org/docs/2.4/mod/core.html#limitrequestbody
5. Dokumentasi WordPress Developer — Network Admin Settings Screen: “Max upload file size” default 1.500 KB di Multisite; “Site upload space” default 50 MB. https://developer.wordpress.org/advanced-administration/multisite/admin/settings/
6. Hostinger Tutorials — How to Increase WordPress Maximum Upload Size: mengubah upload_max_filesize dan post_max_size lewat hPanel › PHP Configuration › PHP Options; post_max_size harus lebih besar dari upload_max_filesize. https://www.hostinger.com/au/tutorials/how-to-increase-the-maximum-file-upload-size-in-wordpress/
7. Hostinger Support — How to change WordPress upload limitation at Hostinger: nilai yang diatur tidak boleh melebihi batas maksimum paket hosting; bila lebih besar, batas paket yang berlaku. https://www.hostinger.com/support/1583347-how-to-change-wordpress-upload-limitation-at-hostinger/
8. Hostinger Support — How to edit PHP values via .htaccess at Hostinger: contoh php_value upload_max_filesize, php_value post_max_size, dan php_value memory_limit lewat .htaccess. https://www.hostinger.com/support/4622356-how-to-edit-php-values-via-htaccess-at-hostinger/
9. RFC 9110 — HTTP Semantics: status 413 “Content Too Large” menggantikan nama “Request Entity Too Large” dari RFC 7231. https://www.rfc-editor.org/rfc/rfc9110.html