Kode Status HTTP

Referensi kode status HTTP yang lengkap dan bisa dicari

Referensi kode status HTTP ini menempatkan setiap kode standar dalam satu tempat yang bisa dicari. Ketik angka seperti 404, nama seperti unauthorized, atau kata kunci seperti redirect, dan kode yang cocok langsung muncul dengan arti dalam bahasa sederhana. Setiap entri menampilkan warna kelasnya, referensi RFC resmi, dan — untuk error — penyebab umum serta cara mengatasinya.

Berbeda dari halaman daftar kode status HTTP statis, ini interaktif: filter berdasarkan kelas, alihkan ke cheat sheet yang ringkas, atau langsung lompat ke satu kode. Karena seluruh dataset dikirim bersama halamannya, pencarian instan dan bekerja offline. Tanpa daftar, tanpa batas rate, tanpa iklan yang harus dimuat sebelum Anda bisa melihat jawabannya.

Lima kelas kode status HTTP

Setiap kode masuk ke salah satu dari lima kelas yang ditentukan oleh digit pertamanya. 1xx Informational berarti permintaan diterima dan sedang berlanjut (100 Continue, 101 Switching Protocols). 2xx Success berarti berhasil (200 OK, 201 Created, 204 No Content). 3xx Redirection mengirim Anda ke tempat lain (301, 302, 304, 307, 308).

4xx Client error berarti permintaan Anda salah (400, 401, 403, 404, 429), dan 5xx Server error berarti server yang gagal (500, 502, 503, 504). Mengetahui kelasnya langsung memberi tahu siapa yang salah bahkan sebelum Anda membaca kodenya: 4xx adalah tanggung jawab Anda untuk diperbaiki, 5xx tanggung jawab server. Perbedaan tunggal itu adalah hal paling berguna yang bisa Anda ketahui tentang penanganan error HTTP — memberi tahu Anda ke mana harus mencari sebelum menggali log.

Kode status HTTP paling umum dan artinya

Segelintir kode mencakup hampir semua yang akan Anda lihat saat membangun atau men-debug web. Di sisi sukses, 200 OK dan 201 Created mengonfirmasi permintaan berhasil. Di antara redirect, 301 (permanen) dan 302 (sementara) adalah pasangan utama, dengan 304 Not Modified menggerakkan caching browser.

Di antara client error, 400, 401, 403, 404, dan 429 mendominasi; di antara server error, 500, 502, 503, dan 504. Alihkan 'Common only' di atas untuk menyaring seluruh registry menjadi daftar pendek penting ini, lengkap dengan penyebab dan cara mengatasi masing-masing.

4xx vs 5xx: client error versus server error

Perbedaan antara error 4xx dan 5xx memberi tahu Anda ke mana harus mencari. 4xx adalah error klien — permintaannya cacat, tidak terautentikasi, terlarang, atau menunjuk ke sumber daya yang hilang — sehingga mengirim ulang tanpa perubahan tidak akan membantu. Baca body dan header responsnya, perbaiki permintaannya, lalu coba lagi.

5xx adalah error server — permintaan Anda mungkin valid tapi server gagal memenuhinya. 500 biasanya berarti exception yang tidak tertangani, 502 berarti upstream yang mati di belakang proxy, dan 503 berarti overload sementara atau maintenance. Untuk 5xx, perbaikannya ada di log server, bukan di permintaan Anda. Ini juga berarti logika retry seharusnya hanya berlaku untuk respons 5xx, dengan exponential backoff — mencoba ulang 4xx hanya menghabiskan kuota permintaan tanpa manfaat.

Kode 5xx Cloudflare (520–530) yang tidak akan Anda temukan di spesifikasi

Jika situs Anda berada di belakang Cloudflare, Anda akan berjumpa dengan keluarga kode 5xx non-standar yang tidak pernah didefinisikan spesifikasi HTTP resmi. 520 berarti origin mengembalikan respons kosong atau tak terduga, 521 berarti origin menolak koneksi (sedang offline atau memblokir IP Cloudflare), 522 adalah timeout koneksi TCP, 523 berarti origin tidak terjangkau (sering karena DNS buruk), dan 524 berarti origin terhubung tapi tidak membalas dalam jendela 100 detik Cloudflare.

Kelompok SSL — 525 SSL Handshake Failed dan 526 Invalid SSL Certificate — muncul saat sertifikat di origin Anda hilang, kedaluwarsa, atau tidak cocok dengan mode Full (Strict) Cloudflare. 530 hampir selalu disertai error 1xxx di body-nya, biasanya kegagalan DNS origin (Error 1016). Kebanyakan situs referensi sepenuhnya melewatkan kode-kode ini, yang justru menjadi alasan developer akhirnya mencarinya di tengah insiden — kode-kode itu bisa dicari di sini dengan perlakuan penyebab-dan-solusi yang sama seperti kode standar.

Bagaimana ini dibandingkan dengan MDN, httpstatuses.com, dan referensi lain

Alternatif paling banyak dipakai untuk pencarian kode status HTTP adalah MDN Web Docs. Cakupan MDN menyeluruh dan otoritatif, tapi Anda menavigasi satu halaman per kode — tidak ada kolom pencarian yang menyaring semua kode sekaligus, tidak ada filter kelas, dan tidak ada mode cheat sheet ringkas. Jika Anda sudah tahu sedang melihat 429 dan ingin definisi spesifikasinya, MDN sangat baik. Jika Anda men-debug angka yang belum pernah Anda lihat, referensi yang bisa dicari lebih cepat.

httpstatuses.com menampilkan kode dalam grid berwarna dengan deskripsi singkat tapi tidak menjelaskan penyebab umum atau cara memperbaiki error. restapitutorial.com dan w3schools sama-sama membahas kode HTTP dalam tabel statis tanpa filter. HTTP.cat adalah situs meme yang menyenangkan (setiap kode dipetakan ke foto kucing) tapi tidak praktis untuk debugging sungguhan. Alat ini menggabungkan pencarian langsung, filter berdasarkan kelas, mode cheat sheet, penyebab, solusi, kode Cloudflare 5xx, dan tautan RFC — semuanya dalam satu halaman yang berjalan offline tanpa iklan.

Kode status HTTP dan SEO

Kode status diam-diam membentuk cara mesin pencari merayapi dan me-ranking sebuah situs. Setiap halaman yang ingin Anda indeks harus mengembalikan 200 OK. Saat Anda mengubah URL secara permanen, gunakan 301 Moved Permanently agar sinyal ranking ikut berpindah; gunakan 302 hanya untuk perpindahan sementara agar URL asli tetap memegang otoritasnya.

Untuk konten yang dihapus, 404 Not Found dan 410 Gone sama-sama menghapus halaman dari indeks — 410 lebih cepat, karena menjanjikan sumber daya itu hilang secara permanen. Selama downtime terencana, kembalikan 503 Service Unavailable dengan header Retry-After agar crawler kembali lagi nanti alih-alih men-de-indeks halaman Anda. Menerapkan kode ini dengan benar adalah salah satu kemenangan termurah yang tersedia selama migrasi situs — hanya butuh beberapa menit untuk dikonfigurasi, dan dampak SEO-nya langsung terasa.

Kode 1xx, 2xx, dan 3xx secara mendalam: gambaran lengkap sukses dan redirect

Kelas 1xx Informational adalah protokol HTTP yang berbicara pada dirinya sendiri. 100 Continue ada untuk menghindari pemborosan bandwidth: saat klien ingin mengirim body permintaan yang besar, ia lebih dulu mengirim header saja dengan header Expect: 100-continue; server membalas 100 jika bersedia menerima payload-nya, atau error 4xx untuk menolaknya sebelum body-nya tiba. 101 Switching Protocols adalah jabat tangan yang menggerakkan koneksi WebSocket — browser mengirim header Upgrade: websocket, dan 101 mengonfirmasi server beralih dari HTTP ke protokol WebSocket pada koneksi TCP yang sama itu. Anda jarang menulis kode yang menghasilkan kode 1xx, tapi memahaminya menjelaskan mengapa library WebSocket Anda bekerja seperti itu.

Dalam kelas 2xx Success, kode-kodenya menyampaikan bentuk sukses yang berbeda-beda. 200 OK adalah sukses paling luas — untuk GET ia mengembalikan sumber daya, untuk POST ia mengembalikan apa pun yang dihasilkan aksinya. 201 Created lebih sempit: ia menandakan bahwa POST atau PUT secara spesifik membuat sumber daya baru, dan server sebaiknya menyertakan header Location yang menunjuknya (misalnya, Location: /users/42). 204 No Content berarti sukses tapi sengaja tidak ada body respons — pilihan yang tepat untuk endpoint DELETE atau update PUT di mana klien tidak perlu melihat hasilnya. 206 Partial Content adalah tulang punggung streaming media dan unduhan yang bisa dilanjutkan: saat klien mengirim header Range: bytes=0-1048575, server membalas 206 dengan hanya potongan file itu, memungkinkan pemutar video melakukan seek tanpa mengunduh dari awal.

Kode 3xx Redirection membentuk kosakata presisi untuk memberi tahu klien ke mana harus pergi. 301 Moved Permanently dan 308 Permanent Redirect sama-sama menandakan perpindahan selamanya; bedanya 301 secara historis mengizinkan browser menurunkan POST menjadi GET pada URL baru, sementara 308 menjamin metode aslinya dipertahankan. Serupa, 302 Found dan 307 Temporary Redirect sama-sama menandakan perpindahan sementara, tapi 307 mengunci metodenya. Dalam praktik: gunakan 301 untuk perubahan URL halaman, gunakan 308 saat mengarahkan ulang target POST sebuah formulir secara permanen. 304 Not Modified sebenarnya bukan redirect — ia adalah server yang memberi tahu browser selama permintaan validasi cache bahwa salinan cache-nya masih terkini, sehingga tidak ada body yang dikirim, menghemat bandwidth. Browser mengirim header If-None-Match atau If-Modified-Since; jika sumber dayanya tidak berubah, server membalas 304 dan browser menyajikan dari cache lokalnya.

Kode 4xx dan 5xx kritis yang wajib diketahui setiap developer

Dalam kelas 4xx client error, beberapa kode konsisten disalahgunakan atau disalahpahami. 400 Bad Request adalah respons yang benar saat permintaannya cacat secara sintaksis — JSON tidak valid, parameter query wajib yang hilang, atau field dengan tipe data yang salah. 401 Unauthorized penamaannya kurang tepat: sebenarnya berarti unauthenticated (belum terautentikasi). Permintaannya tidak memiliki kredensial yang valid, dan server sebaiknya membalas dengan header WWW-Authenticate yang menjelaskan cara autentikasi; jika Anda memberikan token yang valid, permintaan yang sama bisa berhasil. 403 Forbidden berarti Anda sudah terautentikasi tapi tidak diotorisasi — Anda sudah membuktikan siapa diri Anda dan server mengetahuinya, tapi akun Anda tidak punya izin. Memberikan kredensial lain tidak akan membantu; Anda butuh izin yang berbeda. 405 Method Not Allowed spesifik: endpoint-nya ada tapi tidak mendukung metode HTTP yang Anda pakai. Endpoint GET /users yang hanya menerima POST akan mengembalikan 405 dan harus menyertakan header Allow yang mencantumkan metode yang diterima.

408 Request Timeout berarti server menutup koneksi karena klien terlalu lama mengirim permintaan lengkap — umum terjadi pada koneksi seluler lambat atau upload file besar. 409 Conflict menandakan konflik keadaan: permintaannya valid tapi tidak bisa diselesaikan mengingat keadaan sumber daya saat ini — contoh klasiknya adalah membuat sumber daya yang sudah ada (username duplikat, pemesanan kalender yang bentrok). 410 Gone adalah alternatif eksplisit dari 404: ia memberi tahu crawler dan klien bahwa sumber dayanya pernah ada, sengaja dihapus, dan tidak akan kembali. Mesin pencari menghapus halaman 410 dari indeks mereka lebih cepat daripada 404 karena 404 bisa jadi hanya gangguan sementara. 422 Unprocessable Entity mencakup permintaan yang valid secara semantik tapi gagal validasi logika bisnis — JSON-nya terbentuk dengan baik dan permintaannya terautentikasi, tapi nilai-nilainya sendiri tidak valid. 429 Too Many Requests adalah kode rate-limiting; sebaiknya selalu menyertakan header Retry-After yang memberi jumlah detik atau tanggal-HTTP setelah mana klien boleh mencoba lagi.

Dalam kelas 5xx server error, nuansanya penting untuk debugging. 500 Internal Server Error adalah tampungan umum untuk exception yang tidak tertangani — periksa log server Anda untuk stack trace. 502 Bad Gateway berarti reverse proxy (Nginx, load balancer, edge node CDN) menerima respons tidak valid dari server aplikasi upstream Anda — proses aplikasinya kemungkinan crash atau mengembalikan data rusak. 503 Service Unavailable menandakan server untuk sementara tidak bisa menangani permintaan karena overload atau maintenance terencana; sertakan header Retry-After agar klien dan crawler mundur dengan sopan alih-alih terus membebani server. 504 Gateway Timeout berbeda dari 502 karena server upstream terjangkau tapi sekadar tidak membalas dalam jendela timeout proxy — query database yang lambat atau microservice yang tidak responsif sering jadi penyebabnya. Saat on-call, urutan yang perlu dicek adalah: 500 → log aplikasi, 502 → apakah proses aplikasinya masih hidup, 503 → apakah servernya sedang overload atau mode maintenance, 504 → panggilan upstream mana yang menggantung.

Kode status HTTP dalam desain REST API: konvensi yang penting

Desain REST API bergantung pada pemakaian kode status untuk membawa makna yang jika tidak akan membengkakkan body respons. Perbedaan 200 vs 201 adalah konvensi yang paling sering dilewatkan: endpoint POST /users yang membuat user seharusnya mengembalikan 201 Created dengan header Location: /users/42, bukan 200. Mengembalikan 200 untuk setiap respons sukses memaksa konsumen API memeriksa body untuk memahami apa yang terjadi, yang membuat penanganan error terprogram lebih sulit dan merusak alat yang mengandalkan semantik HTTP — dasbor monitoring, API gateway, dan integration test semuanya bekerja lebih baik saat kode status membawa makna yang tepat. Stripe, GitHub, dan Twilio semuanya mengikuti konvensi ini dengan presisi, dan SDK mereka mendapat manfaat darinya.

Pertanyaan 204 vs 200 untuk DELETE adalah keputusan desain yang nyata. 204 No Content menandakan penghapusan bersih tanpa body — ketiadaan body itu sendiri adalah konfirmasinya, dan klien HTTP menanganinya secara efisien. Sebagian tim lebih suka mengembalikan 200 dengan body JSON seperti {"deleted": true, "id": 42} untuk memberi konfirmasi eksplisit ke klien frontend tanpa mengharuskan mereka mempercayai body yang hilang. Tidak satu pun pendekatan melanggar spesifikasi, tapi 204 adalah pilihan REST yang lebih idiomatis, dan mencampur keduanya di endpoint yang berbeda dalam satu API menimbulkan kebingungan. Pilih salah satu dan dokumentasikan. Satu nuansa: jika Anda mengembalikan 204 untuk sumber daya yang sudah hilang, itu benar — DELETE yang idempotent berarti memanggilnya dua kali seharusnya tidak mengembalikan 404 pada panggilan kedua.

Batas 422 vs 400 untuk error validasi secara efektif sudah diselesaikan oleh penyedia API besar. 400 Bad Request seharusnya berarti permintaannya cacat secara sintaksis — JSON yang tidak bisa di-parse, Content-Type yang salah, header HTTP wajib yang hilang. 422 Unprocessable Entity seharusnya berarti permintaannya terbentuk dengan baik tapi tidak valid secara semantik — field email yang bukan email valid, rentang tanggal di mana akhir sebelum awal, referensi ke foreign key yang tidak ada. Stripe, GitHub, dan kebanyakan REST API modern mengembalikan 422 untuk error validasi, memasangkannya dengan body error terstruktur yang mencantumkan field yang bermasalah. Alternatifnya — mengembalikan 200 dengan error di body — adalah pola terburuk dalam desain API: ini merusak monitoring level-HTTP (200 tidak akan memicu aturan alert), membuat tidak mungkin mendeteksi error tanpa mem-parse setiap body respons, dan menjadi alasan mengapa pemakaian HTTP 200 secara blanket oleh GraphQL untuk semua respons (termasuk error yang membawa array errors tingkat atas) kontroversial — men-debug API GraphQL lewat alat monitoring HTTP standar buta terhadap kegagalan level aplikasi.