400 Bad Request: Arti dan Cara Mengatasinya

Apa Itu Error 400 Bad Request?

400 Bad Request adalah kode status HTTP yang berarti server menerima permintaan Anda tetapi tidak mau memprosesnya karena ada yang tampak salah pada permintaan itu sendiri. Standar HTTP (RFC 9110, bagian 15.5.1) mendefinisikannya sebagai kondisi ketika server tidak bisa atau tidak mau memproses permintaan "due to something that is perceived to be a client error" (karena sesuatu yang dianggap sebagai kesalahan klien), misalnya sintaks yang rusak, framing pesan yang tidak valid, atau perutean permintaan yang menipu.

Berbeda dengan error 500 yang berarti server bermasalah, error 400 menunjuk ke permintaannya: URL, header, cookie, atau data yang dikirim browser atau aplikasi Anda. Situsnya sendiri biasanya berjalan normal bagi orang lain.

Itu kabar baik bagi pengunjung, karena solusinya biasanya ada di sisi Anda dan hanya butuh semenit: tautan yang salah ketik atau cookie yang rusak adalah penyebab sebagian besar error 400.

Seperti Apa Tampilan Error 400

Pesannya bergantung pada perangkat lunak server, dan teks tambahannya sering menjadi petunjuk terbaik tentang penyebabnya:

Apa Penyebab 400 Bad Request?

• URL yang rusak. Tanda % yang nyasar, spasi, karakter yang seharusnya di-encode, atau tautan yang terpotong atau tertempel dua kali.

• Cookie yang korup atau terlalu besar. Situs yang memasang banyak cookie (login, uji A/B, analitik) bisa membuat header Cookie melampaui batas server. Cookie yang rusak saat pembaruan juga bisa ditolak.

• Header permintaan yang terlalu besar. Selain cookie, token autentikasi yang panjang atau header yang ditambahkan ekstensi dan proxy ikut menambah ukurannya.

• Data tidak valid yang dikirim ke API. Field wajib yang hilang, JSON yang rusak, atau header Content-Type yang salah.

• HTTP dikirim ke port HTTPS. Sering terjadi di belakang load balancer dan reverse proxy.

• File yang terlalu besar. Banyak server membalas dengan 413 Content Too Large, tetapi sebagian aplikasi dan framework justru mengembalikan 400.

Solusi 1: Periksa URL-nya

Perhatikan address bar dengan saksama. Masalah yang perlu diwaspadai:

• Tanda % yang tidak diikuti dua karakter heksadesimal (%20 benar, %2 atau %zz salah).

• Spasi, { }, |, \ atau karakter tidak lazim lainnya, terutama pada tautan yang disalin dari email, PDF, atau aplikasi chat.

• Tautan yang tertempel dua kali (https://example.com/https://example.com/...) atau terpotong di tengah.

• URL yang sangat panjang dengan parameter pelacakan. Hapus semua bagian mulai dari tanda ? lalu coba lagi.

Jika Anda mengikuti tautan dari situs lain, buka halaman utama situsnya lalu navigasikan ke halaman tersebut dari sana.

Solusi 2: Hapus Cookie untuk Situs Itu Saja

Langkah ini mengatasi sebagian besar error 400 di situs yang pernah Anda buka, terutama pesan yang menyebut cookie atau header yang "too large" atau "too long". Anda tidak perlu menghapus cookie semua situs, cukup situs yang bermasalah:

• Chrome / Edge: klik ikon di sebelah kiri address bar → Cookie dan data situs (atau Setelan situs) → hapus data situs tersebut, lalu muat ulang.

• Firefox: klik ikon gembok → Hapus cookie dan data situs… (Clear cookies and site data…).

• Safari (Mac): Safari → Pengaturan → Privasi → Kelola Data Situs Web… → cari situsnya → Hapus.

• iPhone: Pengaturan → App → Safari → Lanjutan (Advanced) → Data Situs Web → geser ke kiri pada situs tersebut untuk menghapusnya.

Solusi 3: Coba Incognito, Lalu Hapus Cache

Buka halaman di jendela Incognito/Private (Ctrl + Shift + N di Chrome dan Edge, Ctrl + Shift + P di Firefox, Cmd + Shift + N di Safari). Jendela pribadi dimulai tanpa cookie dan tanpa ekstensi, jadi jika halaman terbuka di sana, Solusi 2 atau Solusi 4 akan mengatasinya secara permanen.

Jika Incognito juga gagal, hapus cache browser (Ctrl + Shift + Delete → Gambar dan file dalam cache), dan sebagai langkah terakhir, flush cache DNS Anda. DNS jarang menjadi penyebab error 400, tetapi setelah situs pindah server, alamat lama bisa membawa Anda ke server yang menolak permintaan Anda.

Solusi 4: Nonaktifkan Ekstensi dan Periksa Ukuran File

Ekstensi yang mengubah permintaan, seperti alat privasi, editor header, pencari kupon, dan sebagian pemblokir iklan, bisa menambah atau mengubah header dengan cara yang ditolak server. Nonaktifkan semuanya, muat ulang, lalu aktifkan kembali satu per satu untuk menemukan pelakunya.

Jika error muncul saat mengunggah, coba file yang lebih kecil. Kompres gambar atau pecah file besar. Dari situ Anda tahu apakah server menolak ukurannya, meskipun yang dilaporkan adalah 400, bukan 413.

Untuk Pemilik Situs: Menemukan Penyebab Error 400

Jika pengguna melaporkan error 400 di situs Anda, mulailah dari pesan persis yang mereka lihat dan dari log server. nginx dan Apache mencatat alasannya di level info, jadi naikkan level error log untuk sementara jika alasannya tidak muncul, sedangkan access log menunjukkan URL mana yang mengembalikan 400. Alat HTTP Headers dari DNS Robot menampilkan kode status, perangkat lunak server, dan setiap header Set-Cookie yang dikirim halaman, sehingga Anda bisa menemukan cookie yang terus membesar.

# Permintaan mana yang mendapat 400? (format log combined nginx)
sudo awk '$9 == 400 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Alasan yang dicatat nginx (butuh error_log ... info;)
sudo grep -i "client sent\|too large\|bad request" /var/log/nginx/error.log | tail -20

"Request Header Or Cookie Too Large"

nginx membaca header permintaan ke dalam buffer yang diatur oleh large_client_header_buffers, secara default 4 buffer berukuran 8 KB. Satu baris header, biasanya header Cookie, yang tidak muat dalam satu buffer akan memicu error 400 ini. Batas yang setara di Apache adalah LimitRequestFieldSize, defaultnya 8.190 byte.

Solusi yang tepat adalah mengirim lebih sedikit: hapus cookie yang tidak lagi diperlukan, jaga cookie sesi tetap kecil, dan batasi cakupan cookie hanya ke path dan subdomain yang memakainya. Jika Anda benar-benar butuh header yang lebih besar, misalnya untuk token single sign-on yang besar, naikkan batasnya:

# nginx (blok http atau server)
large_client_header_buffers 4 16k;

# Padanan di Apache (httpd.conf / vhost)
# LimitRequestFieldSize 16380

"The plain HTTP request was sent to HTTPS port"

nginx mengembalikan error 400 ini ketika ada yang mengirim HTTP biasa ke port tempat nginx mengharapkan TLS, biasanya 443. Penyebab umumnya adalah load balancer atau proxy yang meneruskan lalu lintas http:// ke port 443, tautan dengan http://example.com:443, atau pengaturan lama ssl on; yang membuat sebuah port mengharapkan TLS padahal seharusnya tidak.

Pastikan setiap baris listen sesuai dengan lalu lintas yang datang ke port itu: listen 443 ssl; untuk HTTPS dan listen 80; untuk HTTP biasa, dengan redirect dari 80 ke 443. Pastikan juga proxy di depannya berbicara HTTPS ke port 443 (atau HTTP ke port 80).

Error 400 dari API

API memakai kode 400 untuk permintaan yang gagal validasi. Jika Anda memanggil API, baca body respons, karena sebagian besar API menjelaskan field mana yang salah. Lalu pastikan Anda mengirim JSON yang valid, header Content-Type: application/json yang benar, dan semua parameter wajib.

Jika Anda membangun API, kembalikan body yang menyebutkan masalahnya (misalnya {"error": "email is required"}), dan pertimbangkan 422 Unprocessable Content untuk permintaan yang formatnya benar tetapi isinya tidak valid secara semantik, sementara kode 400 disimpan untuk permintaan yang sama sekali tidak bisa di-parse.

400 vs 401, 403, 404, 413, 429, dan 431

Panduan kami untuk kode-kode tetangganya: 403 Forbidden, 401 Unauthorized, dan 429 Too Many Requests. Untuk redirect yang berputar-putar alih-alih gagal, lihat ERR_TOO_MANY_REDIRECTS, dan Redirect Checker menampilkan setiap hop-nya.