Cara Mengatasi Nginx 413 Request Entity Too Large saat Upload Media WordPress

The Last Digital
Update: ... minutes read

Error 413 Request Entity Too Large muncul ketika ukuran body request yang dikirim browser melebihi batas maksimum yang diizinkan server. Pada WordPress di Nginx, kasus yang paling umum adalah gagal mengunggah media: Anda memilih file di Media Library, proses upload berjalan, lalu muncul pesan error — atau halaman hanya menampilkan pesan 413 yang samar, karena menurut dokumentasi resmi Nginx, browser tidak selalu bisa menampilkan error ini dengan benar.

Penting untuk memahami satu hal sejak awal: pada Nginx, error ini hampir selalu berasal dari Nginx sendiri, bukan dari WordPress. Secara default, Nginx membatasi body request hanya 1 MB. File media modern — foto berkualitas tinggi, PDF multi-halaman, atau video pendek — dengan mudah melampaui 1 MB. WordPress bahkan belum sempat menerima file tersebut; Nginx sudah menolaknya di gerbang depan.

Jawaban Singkat

Tambahkan client_max_body_size 64M; di blok server situs Anda di Nginx, uji dengan sudo nginx -t, lalu muat ulang Nginx dengan sudo systemctl reload nginx. Setelah itu, samakan batas di PHP: upload_max_filesize = 64M dan post_max_size = 72M di php.ini yang dipakai PHP-FPM, lalu restart PHP-FPM. Jika hanya satu lapisan yang diubah, lapisan yang lebih kecil tetap menjadi batas — dan upload tetap gagal.

Tiga Lapisan Batas yang Harus Selaras

Upload media WordPress di Nginx melewati tiga lapisan batas. Kegagalan di lapisan mana pun menghasilkan gejala yang berbeda, dan inilah alasan banyak orang "sudah mengubah pengaturan tetapi tetap gagal": mereka hanya mengubah satu lapisan.

LapisanPengaturanDefault yang terverifikasiGejala bila dilampaui
Nginxclient_max_body_size1m (1 MB)Error 413, request ditolak sebelum sampai ke PHP
PHP — ukuran fileupload_max_filesize2M menurut manual PHPUpload ditolak PHP; WordPress menampilkan pesan file terlalu besar
PHP — ukuran POSTpost_max_sizeHarus lebih besar dari upload_max_filesize (manual PHP)$_POST dan $_FILES kosong; upload gagal tanpa pesan yang jelas

Menurut dokumentasi resmi Nginx (modul ngx_http_core_module), direktif client_max_body_size menetapkan ukuran maksimum body request klien, berlaku pada konteks http, server, dan location, dan bila ukuran request melampaui nilai tersebut, error 413 dikembalikan ke klien. Menyetel nilainya ke 0 menonaktifkan pemeriksaan ukuran body — sesuatu yang tidak disarankan untuk server publik, karena menghilangkan perlindungan terhadap request raksasa yang bisa menghabiskan sumber daya. Sementara itu, manual PHP menegaskan aturan urutan: post_max_size harus lebih besar dari upload_max_filesize, dan memory_limit umumnya harus lebih besar dari post_max_size. Bila data POST melebihi post_max_size, variabel $_POST dan $_FILES akan kosong — gejala yang sering disalahartikan sebagai bug plugin.

Tabel Diagnosis: Lapisan Mana yang Menolak Upload Anda?

GejalaLapisan yang dicurigaiCara memastikan
Pesan 413 di browser, atau halaman error Nginx polosNginxCek error log Nginx: frasa “client intended to send too large body”
WordPress menampilkan “file melebihi batas unggahan” atau pesan ukuranPHP (upload_max_filesize)Cek Media > Tambah Baru: WordPress menampilkan “Ukuran file maksimum” yang berlaku
Upload gagal diam-diam, formulir kembali kosong tanpa pesan jelasPHP (post_max_size)Cek php.ini: post_max_size lebih kecil dari upload_max_filesize
Upload file kecil berhasil, file besar gagal di atas ambang tertentuSalah satu dari tiga lapisanUji bertahap dengan file berukuran 2 MB, 10 MB, 50 MB untuk menemukan ambang batasnya
Error hanya muncul untuk satu situs di server yang samaBlok server situs tersebutBandingkan blok server situs yang bermasalah dengan situs yang normal
Error muncul setelah melewati Cloudflare atau proxy lainLapisan di depan NginxUji upload langsung dengan melewati proxy bila memungkinkan; periksa batas di lapisan tersebut

Persiapan dan Backup

  1. Backup konfigurasi. Sebelum mengedit, salin file konfigurasi Nginx dan php.ini: sudo cp /etc/nginx/sites-available/nama-situs /etc/nginx/sites-available/nama-situs.bak dan salinan serupa untuk php.ini.
  2. Tentukan batas yang Anda butuhkan. Jangan menaikkan ke angka raksasa "supaya aman". Perkirakan file terbesar yang benar-benar perlu diunggah (misalnya foto 20 MB, PDF 50 MB), lalu tambahkan sedikit ruang. Untuk kebanyakan blog WordPress, 64M sudah lebih dari cukup; situs dengan video mungkin butuh 128M atau 256M.
  3. Siapkan akses SSH. Perubahan konfigurasi server tidak bisa dilakukan dari wp-admin; Anda butuh akses SSH dengan hak sudo.

Langkah 1: Temukan dan Periksa Error Log Nginx

Sebelum mengubah apa pun, konfirmasi bahwa Nginx memang sumber masalahnya:

sudo tail -n 50 /var/log/nginx/error.log
sudo grep -i "too large body" /var/log/nginx/error.log

Jika Anda menemukan baris berisi “client intended to send too large body”, diagnosis terkonfirmasi: client_max_body_size yang membatasi. Jika log kosong untuk momen upload, periksa apakah situs memakai blok server yang berbeda, atau apakah request ditahan di lapisan lain (proxy, Cloudflare, atau PHP).

Periksa juga konfigurasi Nginx yang sedang aktif dan lokasi file situs Anda:

sudo nginx -T | grep -n "client_max_body_size"
ls /etc/nginx/sites-enabled/

Perintah nginx -T menampilkan seluruh konfigurasi efektif. Bila tidak ada baris client_max_body_size sama sekali, berarti nilai default 1m yang berlaku.

Langkah 2: Naikkan client_max_body_size di Nginx

Tempat yang tepat untuk kebanyakan situs WordPress adalah blok server situs tersebut, sehingga perubahan hanya berlaku untuk satu situs dan tidak memengaruhi situs lain di server yang sama. Buka file konfigurasi situs:

sudo nano /etc/nginx/sites-available/nama-situs

Ganti nama-situs dengan nama file konfigurasi situs Anda. Tambahkan direktif di dalam blok server:

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    client_max_body_size 64M;

    # ... konfigurasi lain (root, index, location, fastcgi_pass) ...
}

Catatan tentang konteks: menurut dokumentasi Nginx, direktif ini bisa ditulis di konteks http (berlaku untuk semua situs), server (satu situs), atau location (satu jalur, misalnya hanya /wp-admin/). Blok yang lebih spesifik mengalahkan yang lebih umum. Untuk keamanan, hindari nilai 0 (tanpa batas) di server publik; nilai 0 hanya masuk akal untuk lingkungan internal yang terkendali.

Setelah menyimpan, selalu uji sintaks sebelum reload — kesalahan sintaks bisa membuat Nginx gagal reload dan situs tidak terlayani:

sudo nginx -t
sudo systemctl reload nginx

Perintah reload menerapkan konfigurasi baru tanpa memutus koneksi yang sedang berjalan, berbeda dengan restart yang menghentikan dan memulai ulang proses. Jika nginx -t melaporkan kesalahan, perbaiki dulu — jangan reload dalam keadaan konfigurasi bermasalah.

Langkah 3: Samakan Batas di PHP (php.ini)

Setelah Nginx mengizinkan body 64 MB, giliran PHP. Buka file php.ini untuk PHP-FPM yang dipakai situs Anda (sesuaikan versi PHP):

php -i | grep -i "Loaded Configuration File"
sudo nano /etc/php/8.3/fpm/php.ini

Ubah tiga nilai berikut dengan memperhatikan urutan yang diwajibkan manual PHP — post_max_size lebih besar dari upload_max_filesize, dan memory_limit lebih besar dari post_max_size:

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

Angka 72M untuk post_max_size memberi ruang untuk field formulir tambahan di samping file itu sendiri. Nilai memory_limit 256M memberi ruang pemrosesan (misalnya pembuatan thumbnail WordPress) tanpa menyentuh batas memori — pembahasan batas memori secara khusus ada di artikel terpisah tentang Allowed Memory Size Exhausted.

Simpan, lalu restart PHP-FPM (nama layanan mengikuti versi PHP Anda):

sudo systemctl restart php8.3-fpm
sudo systemctl status php8.3-fpm

Verifikasi nilai yang berlaku:

php -i | grep -E "upload_max_filesize|post_max_size|memory_limit"

Perlu diingat: php -i di terminal menampilkan konfigurasi CLI, yang bisa berbeda dari FPM. Verifikasi paling meyakinkan dari sisi WordPress adalah membuka Media > Tambah Baru di wp-admin dan membaca “Ukuran file maksimum” yang tercantum di sana.

Langkah 4: Periksa Pengaturan Tambahan Bila Masih Gagal

Batas ukuran unggahan WordPress multisite

Pada instalasi multisite, ada pengaturan jaringan terpisah untuk ukuran file maksimum. Periksa Network Admin > Settings dan pastikan nilainya tidak lebih kecil dari batas server yang baru Anda tetapkan.

Plugin dan tema yang membatasi ukuran

Beberapa plugin keamanan atau plugin optimasi media menetapkan batasnya sendiri. Jika batas server sudah benar tetapi WordPress tetap menolak, nonaktifkan sementara plugin yang terkait unggahan/media dan uji ulang.

Timeout untuk file besar

File besar pada koneksi lambat bisa gagal bukan karena ukuran, melainkan karena waktu. Bila upload besar selalu gagal di tengah jalan, pertimbangkan menaikkan max_execution_time dan max_input_time di php.ini (misalnya ke 300 detik), serta client_body_timeout di Nginx bila perlu — tetapi lakukan ini hanya setelah batas ukuran terbukti benar.

Lapisan di depan Nginx

Jika situs berada di belakang Cloudflare atau load balancer, lapisan tersebut memiliki batasnya sendiri. Uji dengan mengunggah file yang sama lewat koneksi langsung (bila memungkinkan) untuk memastikan apakah masalahnya ada di Nginx atau di lapisan depan.

Verifikasi Hasil

Perbaikan dinyatakan berhasil bila semua hal berikut terpenuhi:

  • sudo nginx -t melaporkan konfigurasi valid dan Nginx sudah di-reload.
  • Media > Tambah Baru di wp-admin menampilkan ukuran maksimum baru (misalnya 64 MB).
  • File yang sebelumnya gagal (dengan ukuran yang sama) berhasil diunggah dan muncul di Media Library.
  • Error log Nginx tidak lagi mencatat “client intended to send too large body” untuk upload tersebut.
  • Unggahan file kecil tetap berjalan normal — tidak ada regresi.

Troubleshooting Lanjutan

Sudah mengubah Nginx tetapi WordPress tetap menampilkan batas lama

Itu tanda lapisan PHP yang membatasi, bukan Nginx. Periksa upload_max_filesize dan post_max_size di php.ini FPM yang benar, pastikan PHP-FPM sudah di-restart, dan pastikan Anda mengedit file php.ini untuk versi PHP yang dipakai situs (bukan versi CLI yang lain).

Sudah mengubah php.ini tetapi tidak ada perubahan

Kemungkinan Anda mengedit php.ini yang salah (CLI vs FPM, atau versi PHP yang salah), atau PHP-FPM belum di-restart. Gunakan perintah php -i | grep "Loaded Configuration File" untuk CLI, dan periksa pool FPM situs Anda untuk memastikan versi dan file konfigurasinya.

Error 413 hanya untuk file di atas ukuran tertentu, misalnya 8 MB

Ambangnya memberi petunjuk: 1 MB menandakan default Nginx; 2 MB menandakan default PHP upload_max_filesize; 8 MB menandakan post_max_size yang belum diubah. Samakan ketiga nilai dengan urutan yang benar.

Upload berhasil dari wp-admin tetapi gagal dari formulir frontend

Formulir frontend bisa memakai endpoint atau plugin berbeda dengan batasnya sendiri (misalnya batas pada plugin form). Periksa pengaturan plugin tersebut, dan periksa apakah endpoint itu berada di blok location Nginx yang memiliki client_max_body_size berbeda.

Situs memakai Apache, bukan Nginx

Artikel ini khusus Nginx. Pada Apache, direktif yang setara adalah LimitRequestBody, dan pengaturan PHP lewat .htaccess hanya berlaku untuk mod_php, bukan PHP-FPM. Jangan mencampur panduan Nginx dan Apache — tentukan dulu web server yang Anda pakai.

Alternatif Bila Anda Tidak Bisa Mengubah Konfigurasi Server

  • Kompres sebelum mengunggah. Perkecil dan kompres gambar (misalnya dengan alat kompresi gambar) sehingga ukurannya di bawah batas yang berlaku. Ini sering menjadi solusi tercepat untuk blog yang jarang mengunggah file besar.
  • Unggah lewat SFTP. Letakkan file langsung ke wp-content/uploads/ lewat SFTP, lalu daftarkan ke Media Library dengan plugin "Add From Server" atau perintah WP-CLI wp media import. Cara ini melewati batas upload HTTP sepenuhnya.
  • Gunakan penyimpanan eksternal. Untuk video dan file besar, hosting file di platform video atau penyimpanan khusus, lalu sematkan di artikel — jauh lebih ringan bagi server daripada menaikkan batas tanpa batas.
  • Minta penyedia hosting menaikkan batas. Di shared hosting tanpa akses SSH, satu-satunya jalur adalah meminta penyedia hosting mengubah batas atau pindah ke paket/VPS dengan kontrol penuh.

FAQ

Berapa nilai client_max_body_size yang sebaiknya dipakai?

Sesuaikan dengan file terbesar yang benar-benar perlu diunggah. Untuk blog WordPress pada umumnya, 64M sudah memadai. Nilai yang terlalu besar meningkatkan risiko penyalahgunaan (request raksasa yang menghabiskan sumber daya), jadi jangan memakai 0 atau 1G tanpa alasan.

Apakah cukup mengubah Nginx saja?

Tidak, bila file Anda juga melampaui batas PHP. Nginx dan PHP adalah dua gerbang berurutan: keduanya harus mengizinkan ukuran tersebut. Ubah Nginx, lalu samakan upload_max_filesize dan post_max_size di PHP.

Mengapa error 413 tidak selalu tampil jelas di browser?

Dokumentasi Nginx sendiri mencatat bahwa browser tidak dapat menampilkan error ini dengan benar. Karena itu, jangan hanya mengandalkan pesan di browser — periksa error log Nginx untuk konfirmasi.

Apakah reload Nginx cukup, atau harus restart?

Untuk perubahan konfigurasi, reload sudah cukup dan lebih aman karena tidak memutus koneksi berjalan. Restart hanya diperlukan bila proses Nginx bermasalah atau reload gagal.

Apakah perubahan ini memengaruhi semua situs di server?

Hanya bila Anda menaruh direktif di blok http. Bila ditaruh di blok server satu situs, hanya situs itu yang terpengaruh — dan itulah penempatan yang disarankan di artikel ini.

Apakah menaikkan batas ini memperbaiki error upload di semua plugin?

Sebagian besar, ya — karena batas server berlaku untuk semua request. Tetapi plugin bisa memiliki batas internalnya sendiri; bila satu plugin tetap menolak, periksa pengaturan plugin tersebut.

Kesimpulan

Error Nginx 413 saat mengunggah media WordPress hampir selalu berarti satu dari tiga gerbang menolak file Anda: client_max_body_size Nginx (default 1 MB), upload_max_filesize PHP (default 2 MB), atau post_max_size PHP. Perbaiki ketiganya secara berurutan — Nginx di blok server, PHP di php.ini FPM, dengan urutan nilai yang benar — lalu uji sintaks, reload Nginx, restart PHP-FPM, dan verifikasi lewat halaman Tambah Media dan error log. Dengan ketiga lapisan yang selaras, file yang sebelumnya ditolak akan berhasil diunggah, tanpa perlu menaikkan batas secara berlebihan.

Tags:

Related Posts

Memuat…
Cookie Consent