Apa Itu Error 400 Bad Request dan Bagaimana Cara Memperbaikinya?

A 400 Bad Request adalah kode status error HTTP/1.1 yang didefinisikan dalam RFC 9110 yang menandakan server menerima permintaan yang tidak dapat atau tidak akan diproses karena permintaan itu sendiri tidak valid. Tidak seperti error 5xx yang berasal dari sisi server, error 400 menempatkan kesalahan sepenuhnya pada klien — artinya masalah ada pada permintaan yang dikirim, bukan pada kemampuan server untuk merespons.

Dalam praktiknya, error 400 terjadi sebelum server mencoba memenuhi permintaan. Server mengurai pesan HTTP yang masuk, mendeteksi sesuatu yang tidak valid secara struktural atau semantik — header yang rusak, URI yang tidak valid, payload yang terlalu besar, cookie yang buruk — dan segera mengembalikan 400 Bad Request tanpa melanjutkan. Mengetahui perbedaan ini adalah cara tercepat untuk diagnosis yang tepat.

Apa yang Sebenarnya Dimaksud Kode Status 400 di Tingkat Protokol

HTTP beroperasi berdasarkan kontrak permintaan-respons yang ketat. Setiap permintaan harus sesuai dengan tata bahasa yang didefinisikan dalam spesifikasi HTTP. Ketika klien mengirim pesan yang melanggar tata bahasa ini, server diizinkan dan diharapkan untuk menolaknya dengan respons 400.

Server tidak mencatat 400 sebagai kegagalannya sendiri. Server mencatatnya sebagai permintaan klien yang ditolak. Inilah mengapa me-restart server secara membabi buta atau menghapus cache CDN jarang memperbaiki 400 yang sebenarnya — akar penyebabnya hampir selalu ada pada konstruksi permintaan.

Varian error yang umum ditampilkan browser meliputi:

• 400 Bad Request
• HTTP Error 400
• Bad Request — Invalid URL
• 400. That's an error. Your client has issued a malformed or illegal request.
• 400 Bad Request. The server cannot or will not process the request due to something that is perceived to be a client error.

Semua ini merujuk pada kode status HTTP yang sama. Perbedaan kalimat bergantung pada perangkat lunak server (Apache, Nginx, IIS, Cloudflare) dan framework aplikasi.

Penyebab Error 400 Bad Request

Memahami pemicu yang tepat sangat penting sebelum mencoba perbaikan apa pun. Penyebabnya terbagi dalam dua kategori: sisi klien dan kesalahan konfigurasi sisi server.

Penyebab Sisi Klien

URL yang tidak valid atau tidak dikodekan dengan benar

URL yang mengandung spasi yang tidak dikodekan, karakter ilegal, atau urutan percent-encoding yang rusak akan langsung ditolak. Spesifikasi HTTP mengharuskan semua karakter di luar set yang tidak dicadangkan (A–Z, a–z, 0–9, -, _, ., ~) dikodekan dengan percent-encoding sebelum transmisi.

Cookie yang rusak atau terlalu besar

Cookie dikirimkan dalam header permintaan Cookie. Jika nilai cookie tidak valid, melebihi batas ukuran per-cookie browser (biasanya 4096 byte), atau mengandung karakter yang melanggar RFC 6265, server dapat menolak seluruh permintaan. Ini adalah salah satu penyebab error 400 intermiten yang paling sering diabaikan pada situs yang sebelumnya dikunjungi pengguna tanpa masalah.

Header permintaan yang tidak valid atau hilang

Beberapa API dan aplikasi web menerapkan validasi header yang ketat. Content-Type yang hilang pada permintaan POST, header Authorization yang tidak valid, atau header Accept dengan tipe media yang tidak didukung semuanya dapat memicu 400.

Payload permintaan yang terlalu besar

Server web dan reverse proxy menerapkan batas ukuran body maksimum. Nginx menggunakan client_max_body_size (default: 1 MB); Apache menggunakan LimitRequestBody. Melebihi ambang batas ini menghasilkan respons 400 atau 413 tergantung pada konfigurasi.

Cache DNS yang usang atau salah

Meskipun kegagalan resolusi DNS biasanya menghasilkan error koneksi daripada HTTP 400, cache DNS yang diracuni atau usang yang mengarahkan permintaan ke server yang salah — yang tidak mengenali header Host — dapat mengakibatkan 400 dikembalikan oleh origin yang salah.

Ekstensi browser yang mengganggu header permintaan

Pemblokir iklan, alat privasi, dan ekstensi pengembang tertentu memodifikasi header HTTP keluar. Jika ekstensi menyuntikkan header yang tidak valid atau duplikat, server dapat menolak permintaan tersebut.

Penyebab Sisi Server

Aturan .htaccess yang salah dikonfigurasi (Apache)

Aturan penulisan ulang, direktif pengalihan, atau entri kontrol akses dengan kesalahan sintaks dapat menyebabkan Apache menghasilkan 400 sebelum permintaan mencapai lapisan aplikasi.

Kesalahan konfigurasi Nginx

Direktif server_name yang tidak valid, blok location yang rusak, atau pengaturan proxy_pass yang salah dapat menyebabkan Nginx mengembalikan 400 untuk permintaan yang tidak dapat dirutekan.

WAF atau plugin keamanan yang terlalu memblokir

Web Application Firewall — baik di tingkat server (ModSecurity), tingkat CDN (Cloudflare WAF), atau tingkat aplikasi (plugin keamanan WordPress) — dapat menandai permintaan yang sah sebagai berbahaya dan mengembalikan 400 atau 403. Ini umum terjadi ketika parameter permintaan mengandung string yang cocok dengan tanda tangan SQL injection atau XSS.

Kegagalan validasi di tingkat aplikasi

Framework seperti Laravel, Django, atau Express.js mengembalikan 400 ketika validasi input gagal — misalnya, field JSON yang diperlukan tidak ada, field tanggal dalam format yang salah, atau parameter numerik menerima nilai string.

Cara Memperbaiki Error 400 Bad Request: Langkah Sisi Klien

1. Validasi dan Perbaiki URL

Periksa URL karakter demi karakter. Perhatikan khususnya:

• Spasi yang tidak dikodekan: Spasi harus berupa %20, bukan spasi literal atau + (di luar data formulir).
• Garis miring ganda atau garis miring yang hilang: https://example.com//path atau https://example.com/path? dengan tanda tanya yang menggantung.
• Percent-encoding yang rusak: % yang tidak diikuti tepat dua digit heksadesimal adalah ilegal.
• Karakter non-ASCII: Nama domain dengan karakter Unicode harus menggunakan Punycode; segmen path dengan Unicode harus dikodekan dengan percent-encoding dalam UTF-8.

URL yang dikodekan dengan benar terlihat seperti ini:

https://example.com/search?q=hello%20world&lang=en

Bukan seperti ini:

https://example.com/search?q=hello world&lang=en

2. Hapus Cookie dan Cache Browser

Ini menyelesaikan sebagian besar error 400 yang ditemui pada situs yang sebelumnya dikunjungi pengguna.

Google Chrome:

1. Buka chrome://settings/clearBrowserData
2. Atur rentang waktu ke Semua waktu
3. Centang Cookie dan data situs lainnya dan Gambar dan file yang di-cache
4. Klik Hapus data

Mozilla Firefox:

1. Buka about:preferences#privacy
2. Di bawah Cookie dan Data Situs, klik Hapus Data
3. Pilih kedua opsi dan konfirmasi

Safari (macOS):

1. Buka Safari > Pengaturan > Privasi
2. Klik Kelola Data Situs Web, lalu Hapus Semua

Untuk pendekatan yang lebih terarah — terutama berguna ketika Anda tidak ingin kehilangan semua data sesi — gunakan alat pengembang browser untuk menghapus hanya cookie untuk domain tertentu:

1. Buka DevTools (F12 atau Cmd+Option+I)
2. Navigasi ke Application > Storage > Cookies
3. Pilih domain dan hapus cookie individual

3. Flush Cache DNS

Windows:

ipconfig /flushdns

macOS (Ventura, Sonoma, Sequoia):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

Linux (nscd):

sudo service nscd restart

Setelah flushing, verifikasi resolusi sudah benar sebelum mencoba lagi:

nslookup example.com

4. Nonaktifkan Ekstensi Browser

Ekstensi yang memodifikasi header HTTP adalah yang paling mungkin menjadi penyebabnya. Daripada menonaktifkan semua ekstensi sekaligus, gunakan mode penyamaran atau mode privat browser terlebih dahulu — sebagian besar ekstensi dinonaktifkan secara default di jendela privat. Jika halaman dimuat dengan benar dalam mode penyamaran, berarti ada ekstensi yang bertanggung jawab.

Untuk mengisolasi ekstensi tertentu di Chrome:

1. Navigasi ke chrome://extensions/
2. Nonaktifkan semua ekstensi
3. Aktifkan kembali satu per satu, muat ulang halaman setelah masing-masing

5. Uji di Browser, Perangkat, atau Jaringan yang Berbeda

Langkah ini dengan cepat menentukan apakah masalah bersifat spesifik pada lingkungan tertentu. Jika halaman dimuat di perangkat seluler menggunakan data seluler tetapi gagal di desktop Anda, masalahnya kemungkinan bersifat lokal — baik konfigurasi browser, proxy tingkat jaringan, atau firewall perusahaan yang memodifikasi header permintaan.

Cara Memperbaiki Error 400 Bad Request: Langkah Sisi Server

Langkah-langkah ini berlaku untuk pemilik situs web, pengembang, dan administrator sistem yang memiliki akses ke server atau panel kontrol hosting.

6. Analisis Log Akses dan Error Server

Log server adalah alat diagnostik yang definitif. Entri 400 dalam log akses akan menampilkan baris permintaan mentah yang ditolak.

Log error Nginx (path default):

tail -n 100 /var/log/nginx/error.log | grep " 400 "

Log error Apache:

tail -n 100 /var/log/apache2/error.log

Log akses Nginx — filter untuk respons 400:

awk '$9 == 400' /var/log/nginx/access.log | tail -20

Cari pola: apakah 400 berasal dari endpoint tertentu, user agent tertentu, atau parameter tertentu? Ini mempersempit akar penyebab secara dramatis.

Jika Anda menjalankan lingkungan VPS Hosting, Anda memiliki akses SSH langsung ke log ini. Pada Shared Web Hosting yang dikelola, log akses biasanya tersedia melalui bagian Errors cPanel atau melalui unduhan log Raw Access.

7. Audit File .htaccess (Apache)

Satu kesalahan sintaks dalam .htaccess dapat menyebabkan Apache mengembalikan error 400 atau 500 untuk setiap permintaan. Validasi sintaks file tanpa me-restart Apache:

apachectl -t

Masalah .htaccess umum yang menghasilkan error 400:

• Pola RewriteRule dengan karakter khusus yang tidak di-escape

LimitRequestBody diatur ke nilai yang terlalu rendah
Direktif Header yang tidak valid

Contoh direktif yang bermasalah:
# This will cause a 400 if the header value is malformed
RequestHeader set X-Custom-Header "value with "quotes""
Versi yang diperbaiki:
RequestHeader set X-Custom-Header "value with escaped quotes"
8. Periksa Konfigurasi Nginx
Validasi seluruh konfigurasi Nginx sebelum menerapkan perubahan:
nginx -t
Perhatikan client_max_body_size jika pengguna mengunggah file:
http {
    client_max_body_size 50M;
}
Tinjau juga large_client_header_buffers — jika header permintaan (termasuk cookie) melebihi ukuran buffer, Nginx mengembalikan 400:
http {
    large_client_header_buffers 4 16k;
}
Setelah mengedit, muat ulang tanpa downtime:
nginx -s reload
9. Tingkatkan Batas Unggah File
Jika error 400 terjadi khusus saat mengunggah file, body permintaan kemungkinan melebihi batas yang dikonfigurasi server.
PHP (php.ini):
upload_max_filesize = 50M
post_max_size = 55M
Apache (httpd.conf atau .htaccess):
LimitRequestBody 52428800
Nginx (nginx.conf):
client_max_body_size 50M;
Perhatikan bahwa post_max_size dalam PHP harus selalu lebih besar dari upload_max_filesize, atau PHP akan diam-diam membuang unggahan dan aplikasi mungkin mengembalikan 400.
10. Tinjau Aturan WAF dan Plugin Keamanan
Jika Anda menjalankan ModSecurity, Cloudflare WAF, atau plugin keamanan WordPress (Wordfence, iThemes Security), nonaktifkan sementara set aturan WAF dan uji apakah 400 menghilang. Jika ya, tinjau log audit WAF untuk mengidentifikasi aturan mana yang memicu:
tail -f /var/log/modsec_audit.log
Jangan sekadar menonaktifkan WAF secara permanen. Sebaliknya, buat pengecualian yang ditargetkan untuk pola permintaan yang sah yang sedang diblokir.
400 Bad Request vs. Kode Error HTTP Terkait
Memahami posisi 400 dalam taksonomi error HTTP mencegah kesalahan diagnosis.



Kode Status
Nama
Lokasi Kesalahan
Penyebab Umum








—
—
—
—








400
Bad Request
Klien
Sintaks permintaan tidak valid, header tidak valid, encoding buruk








401
Unauthorized
Klien
Kredensial autentikasi hilang atau tidak valid








403
Forbidden
Kebijakan server
Permintaan valid, tetapi akses ditolak oleh aturan server








404
Not Found
Server
Sumber daya tidak ada di URI yang diminta








413
Content Too Large
Klien
Body permintaan melebihi batas ukuran yang dikonfigurasi server








414
URI Too Long
Klien
URI permintaan melebihi panjang URI maksimum server








422
Unprocessable Content
Klien
Sintaks valid tetapi semantik salah (umum dalam REST API)








431
Request Header Fields Too Large
Klien
Ukuran header individual atau total melebihi batas server








500
Internal Server Error
Server
Pengecualian yang tidak ditangani atau kesalahan konfigurasi pada server








502
Bad Gateway
Server/Proxy
Server upstream mengembalikan respons yang tidak valid





Perbedaan operasional utama: 413 (Content Too Large) adalah kode yang lebih tepat secara semantik untuk unggahan yang terlalu besar, tetapi banyak server — terutama konfigurasi Apache dan Nginx yang lebih lama — mengembalikan 400 sebagai gantinya. Jika Anda melihat 400 saat mengunggah file, selalu periksa batas ukuran body terlebih dahulu.
Error 400 dalam Konteks API
REST dan GraphQL API menggunakan 400 secara ekstensif sebagai respons standar untuk kegagalan validasi input. Jika Anda membangun atau menggunakan API, body respons 400 biasanya akan berisi payload error terstruktur:
{
  "error": "Bad Request",
  "message": "The 'email' field must be a valid email address.",
  "field": "email",
  "code": 400
}
Saat men-debug error 400 API:

Verifikasi header Content-Type sesuai dengan format body (application/json untuk payload JSON, multipart/form-data untuk unggahan file)
Konfirmasi field dan header yang diperlukan ada dan diketik dengan benar
Periksa bahwa nilai string tidak melebihi batasan panjang maksimum
Validasi format tanggal dan waktu terhadap spesifikasi API (ISO 8601 adalah standar: 2024-01-15T10:30:00Z)
Periksa format header Authorization — token Bearer harus diawali dengan Bearer , tidak diteruskan secara mentah

Untuk tim yang menjalankan layanan API di Dedicated Server, mengaktifkan logging permintaan terperinci di lapisan aplikasi (bukan hanya lapisan server web) sangat penting untuk mendiagnosis pola 400 dalam skala besar.
Mendiagnosis Error 400 dengan Alat Pengembang Browser
Panel Network browser adalah alat diagnostik sisi klien yang paling tepat yang tersedia.

Buka DevTools (F12)
Navigasi ke tab Network
Reproduksi permintaan yang memicu 400
Klik pada permintaan yang gagal di waterfall
Periksa tab Headers — tinjau Request Headers dan Response Headers
Periksa tab Response untuk detail error yang dikembalikan server

Panel Request Headers akan menampilkan persis apa yang dikirim browser. Bandingkan ini dengan apa yang diharapkan server. Perhatikan khususnya:

Nilai header Host

Mencegah Error 400 dalam Aplikasi Web

Bagi pengembang dan administrator server, tindakan proaktif secara signifikan mengurangi kejadian error 400.

Sanitasi dan validasi input di lapisan aplikasi — Validasi semua input yang disediakan pengguna sebelum mencapai lapisan routing server. Kembalikan respons 400 yang deskriptif dengan pesan error tingkat field daripada kegagalan generik.

Terapkan encoding URL yang tepat dalam kode klien — Gunakan fungsi encoding bawaan daripada manipulasi string manual:

// JavaScript — correct approach
const query = encodeURIComponent("hello world & more");
const url = `https://example.com/search?q=${query}`;

# Python — correct approach
from urllib.parse import urlencode
params = urlencode({"q": "hello world & more"})
url = f"https://example.com/search?{params}"

Tetapkan batas ukuran body yang eksplisit dan wajar — Jangan biarkan client_max_body_size pada default 1 MB jika aplikasi Anda menerima unggahan file. Sama halnya, jangan atur ke tidak terbatas — ini menciptakan vektor denial-of-service.

Pantau tingkat 400 dalam produksi — Lonjakan tiba-tiba dalam error 400 sering kali menjadi indikator pertama bot yang memindai kerentanan, formulir sisi klien yang rusak, atau deployment yang memperkenalkan perubahan API yang merusak. Siapkan peringatan pada tingkat error 4xx Anda dalam stack pemantauan (Grafana, Datadog, CloudWatch).

Gunakan HTTPS dengan sertifikat SSL yang valid — Beberapa error 400 muncul ketika klien mengirim permintaan HTTPS ke server yang tidak dikonfigurasi dengan benar untuk TLS, atau ketika ketidakcocokan sertifikat menyebabkan handshake TLS gagal sebelum lapisan HTTP bahkan tercapai. Memastikan Sertifikat SSL Anda valid, terpasang dengan benar, dan mencakup semua subdomain yang diperlukan menghilangkan kelas error ini sepenuhnya.

Konfigurasi lingkungan panel kontrol dengan benar — Jika Anda mengelola beberapa situs melalui panel kontrol, definisi virtual host yang salah dikonfigurasi adalah sumber umum error 400. Lingkungan yang menggunakan VPS dengan cPanel harus memverifikasi bahwa document root, binding SSL, dan aturan penulisan ulang setiap domain dikonfigurasi dengan benar untuk menghindari kontaminasi permintaan lintas domain.

Matriks Keputusan: Mendiagnosis Error 400 Berdasarkan Gejala

Daftar Periksa Teknis: Menyelesaikan 400 Bad Request

Untuk pengguna akhir:

• Periksa dan ketik ulang URL secara manual, perbaiki masalah encoding apa pun
• Hapus cookie dan cache khusus untuk domain yang terpengaruh
• Uji di jendela privat/penyamaran untuk menyingkirkan ekstensi
• Flush cache DNS lokal
• Uji di browser, perangkat, dan koneksi jaringan yang berbeda

Untuk pengembang dan konsumen API:

• Validasi Content-Type sesuai dengan format body permintaan
• Konfirmasi semua field dan header yang diperlukan ada dan diketik dengan benar
• Periksa bahwa nilai string, tanggal, dan tipe numerik sesuai dengan kontrak API
• Gunakan curl dengan output verbose untuk memeriksa pertukaran HTTP mentah:

curl -v -X POST https://api.example.com/endpoint 
  -H "Content-Type: application/json" 
  -H "Authorization: Bearer YOUR_TOKEN" 
  -d '{"key": "value"}'

Untuk administrator server:

• Ambil dan grep log error server untuk entri 400
• Validasi sintaks konfigurasi server web (nginx -t / apachectl -t)
• Periksa client_max_body_size (Nginx) dan LimitRequestBody (Apache)
• Tinjau large_client_header_buffers di Nginx jika permintaan dengan banyak cookie gagal
• Audit aturan WAF dan periksa log audit ModSecurity
• Verifikasi validitas dan cakupan sertifikat SSL/TLS
• Konfirmasi aturan penulisan ulang .htaccess sudah benar secara sintaks

—

FAQ

Apa perbedaan antara error 400 dan error 404?

Error 400 berarti server tidak dapat memahami permintaan karena tidak valid — kesalahannya ada pada cara permintaan dikonstruksi. Error 404 berarti permintaan valid dan dipahami, tetapi sumber daya yang diminta tidak ada di server. Keduanya memerlukan perbaikan yang sepenuhnya berbeda.

Apakah error 400 Bad Request bisa disebabkan oleh server, bukan klien?

Ya, secara tidak langsung. Kesalahan konfigurasi server — seperti aturan WAF yang terlalu ketat, pengaturan large_client_header_buffers Nginx yang salah, atau direktif .htaccess yang rusak — dapat menyebabkan server menolak permintaan yang secara teknis valid. Dalam kasus ini, spesifikasi HTTP tetap diikuti (server menolak apa yang dianggapnya sebagai permintaan buruk), tetapi kesalahan sebenarnya ada pada konfigurasi server, bukan permintaan klien.

Mengapa menghapus cookie memperbaiki error 400?

Cookie dikirim dalam header permintaan Cookie pada setiap permintaan ke domain yang relevan. Jika cookie yang tersimpan di browser tidak valid, kedaluwarsa dengan cara yang tidak diterima server, atau telah tumbuh terlalu besar (melebihi batas large_client_header_buffers di Nginx), server menolak seluruh permintaan dengan 400 sebelum memprosesnya. Menghapus cookie yang rusak menghilangkan data buruk dari header.

Bagaimana cara memperbaiki error 400 saat mengunggah file ke situs web saya?

Unggahan melebihi batas ukuran body server web atau batas ukuran unggahan PHP. Di Nginx, tingkatkan client_max_body_size di nginx.conf. Di Apache, sesuaikan LimitRequestBody di .htaccess atau httpd.conf. Untuk aplikasi PHP, perbarui upload_max_filesize dan post_max_size di php.ini, pastikan post_max_size lebih besar dari upload_max_filesize. Restart layanan yang relevan setelah melakukan perubahan.

Bagaimana cara mengetahui apakah error 400 berasal dari CDN atau WAF daripada server origin saya?

Periksa header respons. Cloudflare menambahkan header cf-ray dan server: cloudflare. AWS CloudFront menambahkan x-amz-cf-id. Jika header ini ada pada respons 400, penolakan terjadi di edge, bukan di origin Anda. Tinjau log WAF CDN atau dashboard acara firewall untuk mengidentifikasi aturan mana yang memicu pemblokiran, lalu buat pengecualian yang ditargetkan untuk pola lalu lintas yang sah.