HTTP 413 Request Entity Too Large: Penyebab Utama, Solusi, dan Panduan Konfigurasi Server

Kesalahan HTTP 413 Request Entity Too Large adalah kode status respons sisi server yang terjadi ketika isi permintaan yang masuk — paling umum berupa unggahan file — melebihi ukuran payload maksimum yang dikonfigurasi pada web server, reverse proxy, atau lapisan aplikasi. Server secara aktif menolak permintaan sebelum memprosesnya, mengembalikan status 413 ke klien.

Kesalahan ini bukan bug sisi klien. Ini adalah mekanisme penegakan yang disengaja yang dibangun ke dalam web server seperti Nginx dan Apache, konfigurasi runtime PHP, dan middleware tingkat aplikasi. Memahami dengan tepat lapisan mana yang memberlakukan batas — dan cara menargetkan direktif konfigurasi yang benar — adalah perbedaan antara perbaikan yang bersih dan berjam-jam pemecahan masalah.

Mengapa Kesalahan HTTP 413 Terjadi: Perincian Lapis per Lapis

Permintaan unggahan file melewati beberapa lapisan pemrosesan sebelum mencapai aplikasi Anda. Salah satu dari lapisan ini dapat secara independen menolak permintaan dengan respons 413. Mendiagnosis kesalahan dengan benar memerlukan identifikasi lapisan mana yang bertanggung jawab.

Lapisan 1: Direktif Web Server

Nginx memberlakukan batas ukuran unggahan melalui direktif client_max_body_size. Nilai defaultnya adalah 1MB, yang sangat rendah untuk sebagian besar aplikasi modern. Direktif ini dapat diatur dalam konteks blok http, server, atau location, dan blok yang paling spesifik yang berlaku.

Apache menggunakan direktif LimitRequestBody, yang defaultnya adalah 0 (tidak terbatas) di sebagian besar distribusi — tetapi penyedia hosting secara rutin mengganti ini dalam konfigurasi global atau virtual host mereka ke nilai yang lebih ketat. Apache juga memproses file .htaccess, yang berarti batas dapat diberlakukan di tingkat direktori tanpa menyentuh konfigurasi utama.

Lapisan 2: Konfigurasi Runtime PHP

PHP memperkenalkan dua direktif independen yang keduanya harus dipenuhi agar unggahan besar berhasil:

• upload_max_filesize — ukuran maksimum file yang diunggah tunggal
• post_max_size — ukuran maksimum seluruh isi permintaan POST, yang harus sama dengan atau lebih besar dari upload_max_filesize

Kesalahan konfigurasi yang umum adalah mengatur upload_max_filesize = 50M sambil membiarkan post_max_size pada defaultnya yaitu 8M. Batas isi POST dievaluasi terlebih dahulu, sehingga unggahan gagal secara diam-diam sebelum batas ukuran file bahkan diperiksa.

Ada juga direktif ketiga yang sering diabaikan: max_input_time, yang menentukan berapa lama PHP akan menunggu untuk menerima data input. Pada koneksi lambat yang mengunggah file besar, batas waktu ini dapat memicu kegagalan yang termanifestasi sebagai 413 atau respons kosong.

Lapisan 3: Reverse Proxy dan Load Balancer

Jika infrastruktur Anda menggunakan reverse proxy — HAProxy, Varnish, Cloudflare, atau instans Nginx yang bertindak sebagai proxy di depan server lain — lapisan proxy tersebut memiliki batas ukuran isi sendiri. 413 yang dikembalikan oleh Cloudflare, misalnya, memiliki batas keras 100MB pada paket gratis dan Pro, dan tidak ada konfigurasi sisi server yang akan mengesampingkannya. Selalu periksa header respons lapisan proxy Anda untuk mengidentifikasi asal 413.

Lapisan 4: Pembatasan Aplikasi dan CMS

Sistem manajemen konten dan framework menerapkan pembatasan unggahan mereka sendiri di atas lapisan server dan PHP. WordPress membaca batas unggahan efektif dari nilai runtime PHP tetapi juga memberlakukan batasan pustaka media sendiri. Beberapa plugin WordPress menambahkan lapisan validasi tambahan. Aplikasi PHP kustom mungkin menggunakan logika validasi $_FILES yang memberlakukan batas yang lebih ketat dari yang diizinkan server.

Konfigurasi Nginx: Memperbaiki 413 di Tingkat Web Server

Untuk Nginx, perbaikan memerlukan modifikasi client_max_body_size dalam konteks konfigurasi yang benar. Mengedit blok http menerapkan batas secara global; mengedit blok server atau location hanya menerapkannya pada virtual host atau endpoint tersebut.

# Global setting — applies to all virtual hosts
http {
    client_max_body_size 100M;
}

# Per-virtual-host setting — preferred for multi-tenant environments
server {
    listen 80;
    server_name example.com;
    client_max_body_size 100M;

    # Granular control — apply only to the upload endpoint
    location /wp-admin/async-upload.php {
        client_max_body_size 256M;
    }
}

Setelah mengedit, validasi sintaks konfigurasi sebelum memuat ulang:

nginx -t && systemctl reload nginx

Kasus tepi kritis: Jika Nginx bertindak sebagai reverse proxy di depan PHP-FPM atau server aplikasi lain, Anda juga harus memeriksa direktif proxy_read_timeout dan proxy_send_timeout. Unggahan besar yang membutuhkan waktu lebih lama dari batas waktu akan dihentikan di tengah transfer, menghasilkan kesalahan 413 atau 504 tergantung pada perilaku proxy.

Konfigurasi Apache: Memperbaiki 413 di Tingkat Web Server

Direktif LimitRequestBody Apache menerima nilai dalam byte. Direktif dapat ditempatkan di httpd.conf, blok VirtualHost, blok Directory, atau file .htaccess.

# In httpd.conf or VirtualHost block
LimitRequestBody 104857600

# In .htaccess (if AllowOverride is enabled for the directory)
LimitRequestBody 104857600

Nilai 104857600 sama dengan 100MB (100 × 1024 × 1024). Setelah memodifikasi httpd.conf atau file virtual host, restart Apache:

apachectl configtest && systemctl restart apache2

Nuansa penting: Pada lingkungan shared hosting, modifikasi .htaccess mungkin diabaikan jika penyedia hosting telah mengatur AllowOverride None dalam konfigurasi tingkat server mereka. Dalam hal ini, hanya penyedia hosting yang dapat mengubah batas. Ini adalah salah satu alasan teknis utama untuk mempertimbangkan beralih ke lingkungan VPS Hosting di mana Anda memiliki akses root penuh ke konfigurasi server.

Konfigurasi PHP: Memperbaiki 413 di Tingkat Runtime

File php.ini adalah sumber otoritatif untuk batas unggahan PHP. File yang benar untuk diedit bergantung pada model eksekusi PHP Anda (mod_php, PHP-FPM, CLI). Gunakan phpinfo() atau php --ini untuk mengidentifikasi php.ini mana yang sebenarnya dimuat.

; Minimum required changes for large file uploads
upload_max_filesize = 128M
post_max_size = 128M
max_input_time = 300
max_execution_time = 300
memory_limit = 256M

Setelah mengedit php.ini, restart layanan yang sesuai:

# For PHP-FPM
systemctl restart php8.2-fpm

# For Apache with mod_php
systemctl restart apache2

Metode alternatif ketika php.ini tidak dapat diakses:

Jika Anda menggunakan paket shared hosting tanpa akses php.ini langsung, Anda mungkin dapat mengganti pengaturan PHP menggunakan:

1. File .user.ini di web root (berfungsi dengan PHP-FPM):

upload_max_filesize = 64M
post_max_size = 64M

1. Direktif .htaccess (hanya berfungsi dengan mod_php):

php_value upload_max_filesize 64M
php_value post_max_size 64M

1. Kode PHP runtime (efektivitas terbatas, tidak direkomendasikan untuk produksi):

@ini_set('upload_max_filesize', '64M');
@ini_set('post_max_size', '64M');

Perhatikan bahwa ini_set() tidak dapat mengganti upload_max_filesize atau post_max_size saat runtime di PHP 7.x dan yang lebih baru — direktif ini dievaluasi sebelum eksekusi skrip dimulai. Metode .user.ini atau .htaccess jauh lebih andal.

Perbaikan Khusus WordPress untuk Kesalahan 413

WordPress menampilkan batas unggahan efektifnya di layar Media > Tambah Baru. Jika batas yang ditampilkan lebih rendah dari yang telah Anda konfigurasi di php.ini, masalahnya biasanya adalah WordPress membaca dari proses PHP yang berbeda atau lapisan caching menyajikan data konfigurasi yang sudah usang.

Tambahkan berikut ini ke wp-config.php untuk secara eksplisit mendefinisikan ukuran unggahan:

@ini_set( 'upload_max_size', '128M' );
@ini_set( 'post_max_size', '128M' );
define( 'WP_MEMORY_LIMIT', '256M' );

Untuk instalasi WordPress Multisite, ukuran unggahan tingkat jaringan dikontrol secara terpisah di bawah Network Admin > Settings > Network Settings > Max upload file size. Pengaturan ini independen dari batas PHP dan harus dikonfigurasi selain perubahan tingkat server.

Perbandingan: Di Mana Memperbaiki 413 Berdasarkan Lingkungan Hosting

Mendiagnosis Lapisan Mana yang Mengembalikan 413

Sebelum menerapkan perbaikan apa pun, konfirmasikan sumber respons 413. Gunakan curl dengan output verbose untuk memeriksa header respons:

curl -v -X POST -F "file=@/path/to/largefile.zip" https://example.com/upload

Periksa header respons Server dan header X-Powered-By atau CF-RAY apa pun. Header CF-RAY menunjukkan bahwa 413 berasal dari Cloudflare, bukan server Anda. Respons dari nginx/1.x.x menunjuk ke lapisan Nginx. Tidak ada header Server mungkin mengindikasikan load balancer atau WAF di hulu aplikasi Anda.

Juga periksa log kesalahan server Anda segera setelah memicu 413:

# Nginx
tail -f /var/log/nginx/error.log

# Apache
tail -f /var/log/apache2/error.log

# PHP-FPM
tail -f /var/log/php8.2-fpm.log

Ketika Konfigurasi Server Tidak Cukup: Pertimbangan Infrastruktur

Untuk aplikasi yang secara rutin menangani transfer file besar — platform video, sistem backup, pencitraan medis, katalog produk e-commerce skala besar — mengkodekan batas unggahan tinggi ke dalam konfigurasi server bersama bukanlah arsitektur yang berkelanjutan. Pertimbangkan alternatif berikut:

• Unggahan terpotong (chunked uploads): Pisahkan file besar menjadi potongan-potongan kecil di sisi klien menggunakan pustaka seperti Resumable.js atau Uppy. Setiap potongan berada dalam batas server, dan server merakitnya kembali. Ini sepenuhnya melewati 413.
• Unggahan langsung ke penyimpanan objek: Buat URL yang ditandatangani sebelumnya untuk penyimpanan yang kompatibel dengan S3 dan biarkan klien mengunggah langsung, melewati web server Anda sepenuhnya. Web server hanya menangani transaksi metadata.
• Endpoint unggahan khusus: Konfigurasikan blok location terpisah di Nginx dengan client_max_body_size yang lebih tinggi khusus untuk rute unggahan, menjaga batas default tetap ketat untuk semua endpoint lainnya.

Untuk beban kerja yang intensif komputasi yang melibatkan pemrosesan file besar — transcoding video, inferensi machine learning pada data yang diunggah — lingkungan GPU Hosting menyediakan kapasitas pemrosesan untuk menangani unggahan dan komputasi berikutnya tanpa hambatan.

Jika aplikasi Anda memerlukan lingkungan panel kontrol terkelola dengan akses konfigurasi PHP penuh, VPS dengan cPanel memberi Anda MultiPHP INI Editor di WHM, memungkinkan penggantian direktif PHP per domain tanpa menyentuh baris perintah.

Pertimbangan Keamanan Saat Meningkatkan Batas Unggahan

Meningkatkan batas unggahan tanpa penguatan keamanan yang sesuai memperkenalkan permukaan serangan nyata. Server yang menerima permintaan POST 500MB adalah target yang layak untuk serangan denial-of-service yang menguras I/O disk, memori, atau kumpulan koneksi.

Terapkan kontrol berikut bersamaan dengan peningkatan batas apa pun:

• Pembatasan laju pada endpoint unggahan: Di Nginx, gunakan limit_req_zone untuk membatasi frekuensi unggahan per IP.
• Validasi jenis file: Jangan pernah mengandalkan jenis MIME yang disediakan klien. Validasi tanda tangan file (magic bytes) di sisi server.
• Izin direktori unggahan: Direktori yang menerima unggahan tidak boleh dapat diakses web atau dapat dieksekusi. Simpan unggahan di luar document root.
• Pemindaian virus: Integrasikan ClamAV atau pemindai serupa ke dalam pipeline unggahan untuk setiap endpoint unggahan yang dapat diakses publik.
• Unggahan hanya untuk yang terautentikasi: Wajibkan autentikasi sebelum menerima payload besar. Endpoint unggahan besar yang tidak terautentikasi mudah disalahgunakan.

Untuk lingkungan produksi yang menangani data unggahan sensitif, memasangkan infrastruktur hosting Anda dengan SSL Certificates yang dikonfigurasi dengan benar memastikan bahwa transfer file dienkripsi saat transit, mencegah intersepsi konten yang diunggah.

Matriks Keputusan Teknis: Memilih Perbaikan yang Tepat

Daftar Periksa Praktis untuk Menyelesaikan HTTP 413

• Identifikasi lapisan yang mengembalikan 413 menggunakan curl -v dan log kesalahan server sebelum membuat perubahan apa pun
• Di Nginx, atur client_max_body_size di blok yang paling spesifik yang berlaku (location lebih diutamakan dari server dari http)
• Pastikan post_max_size selalu lebih besar dari atau sama dengan upload_max_filesize di php.ini
• Tingkatkan max_input_time dan max_execution_time untuk file besar pada koneksi lambat
• Verifikasi bahwa penggantian .htaccess diizinkan (AllowOverride All atau AllowOverride Options) sebelum mengandalkannya
• Periksa semua lapisan proxy secara independen — CDN, load balancer, dan server aplikasi masing-masing memberlakukan batas secara terpisah
• Setelah perubahan konfigurasi apa pun, muat ulang (bukan hanya restart) layanan yang relevan dan hapus cache opcode atau halaman apa pun
• Untuk WordPress Multisite, konfigurasikan batas unggahan tingkat jaringan selain direktif PHP
• Terapkan pembatasan laju dan validasi jenis file sebelum meningkatkan batas pada endpoint unggahan yang menghadap publik
• Jika shared hosting mencegah akses konfigurasi, migrasikan ke lingkungan VPS Hosting atau Dedicated Servers untuk kontrol penuh

Pertanyaan yang Sering Diajukan

Berapa batas unggahan default di Nginx yang menyebabkan kesalahan 413?

Nginx mengatur default client_max_body_size ke 1MB. Setiap isi permintaan yang melebihi 1MB akan mengembalikan 413 kecuali direktif ini secara eksplisit ditingkatkan dalam konfigurasi Nginx.

Bisakah saya memperbaiki kesalahan 413 tanpa akses root server?

Pada shared hosting, Anda dapat mencoba perbaikan melalui .htaccess (hanya Apache, jika AllowOverride mengizinkan) atau file .user.ini (hanya PHP-FPM). Namun, jika penyedia hosting telah menetapkan batas global yang ketat, metode ini tidak akan efektif dan Anda perlu menghubungi dukungan atau meningkatkan ke paket VPS.

Mengapa unggahan saya gagal meskipun sudah meningkatkan upload_max_filesize di php.ini?

Penyebab paling umum adalah post_max_size tetap pada nilai default yang lebih rendah. PHP mengevaluasi batas ukuran isi POST sebelum batas ukuran file individual, sehingga unggahan ditolak sebelum upload_max_filesize bahkan diperiksa. Selalu tingkatkan kedua direktif secara bersamaan.

Apakah Cloudflare menyebabkan kesalahan 413?

Ya. Cloudflare memberlakukan batas ukuran isi permintaan sendiri: 100MB pada paket Free dan Pro, 200MB pada Business, dan 500MB pada Enterprise. Jika permintaan Anda melebihi batas ini, Cloudflare mengembalikan 413 sebelum permintaan mencapai server asal Anda. Tidak ada perubahan konfigurasi sisi server yang akan menyelesaikan ini — Anda harus meningkatkan paket Cloudflare Anda, menggunakan bypass unggahan langsung (URL yang ditandatangani sebelumnya), atau mengimplementasikan unggahan terpotong.

Bagaimana cara memperbaiki 413 secara permanen di WordPress pada server cPanel?

Gunakan MultiPHP INI Editor WHM untuk meningkatkan upload_max_filesize dan post_max_size untuk versi PHP dan domain tertentu. Kemudian verifikasi perubahan tercermin di WordPress di bawah Media > Tambah Baru. Untuk WordPress Multisite, perbarui juga ukuran unggahan maksimum di bawah Network Admin > Settings. Tidak diperlukan perubahan .htaccess atau wp-config.php saat menggunakan editor INI WHM secara langsung.