Kode 302 (HTTP 302 Found): Arti, 302 vs 301, dan Penyebabnya

Apa Itu Kode Status 302?

HTTP 302 Found adalah pengalihan sementara. Server menjawab "yang Anda minta untuk sementara ada di tempat lain" dan menyebutkan URL lainnya di header Location. Browser langsung memuat URL itu, tetapi bookmark, tautan, dan mesin telusur seharusnya tetap memakai URL aslinya (RFC 9110 §15.4.3).

Kata "untuk sementara" itulah satu-satunya perbedaan dengan 301 Moved Permanently, yang menyatakan URL lama sudah hilang selamanya. HTTP/1.0 menamai 302 "Moved Temporarily" (RFC 1945); RFC 2616 mengubah namanya menjadi "Found" pada 1999, tetapi artinya tidak berubah.

Sebagai pengunjung, Anda hampir tidak pernah melihat 302, karena browser mengikutinya sebelum apa pun tampil. Anda bertemu 302 di DevTools, curl, klien API, dan audit SEO.

Anatomi Respons 302

Respons 302 itu kecil. Bagian-bagiannya:

• Baris status — HTTP/1.1 302 Found, atau cukup HTTP/2 302 (HTTP/2 tidak punya reason phrase)
• Location — URL tujuan. RFC 9110 menyatakan server SEBAIKNYA mengirimnya; tanpa itu, browser tidak punya tujuan dan menampilkan isi 302 itu sendiri, biasanya kosong
• Isi (body) — RFC 9110 menyebut isinya "biasanya berupa catatan hiperteks singkat" dengan sebuah tautan. Browser mengabaikannya; nginx, Apache, dan Express secara default mengirim catatan satu baris, sedangkan banyak situs besar mengirim body kosong
• Header cache — tidak diperlukan. Browser tidak menyimpan 302 di cache kecuali Anda menambahkan Cache-Control: max-age atau Expires; sebaliknya, 301 dan 308 disimpan secara default. CDN masih bisa menyimpannya (lihat "302 yang menempel" di bawah)

HTTP/1.1 302 Found
Location: https://www.example.com/login?next=%2Fdashboard
Content-Length: 0
Date: Mon, 26 Oct 2026 14:00:00 GMT

Location bisa berupa URL lengkap atau path relatif seperti /login: RFC 9110 mengizinkan referensi URI apa pun, dan browser menyelesaikannya terhadap URL yang diminta. Di kode aplikasi (misalnya Express), path relatif mencegah nama host internal atau http:// bocor dari balik proxy; nginx dan Apache tetap mengubahnya menjadi URL absolut kecuali Anda menetapkan absolute_redirect off atau RedirectRelative On.

Mengapa Saya Mendapat 302 Alih-alih 200?

Karena halaman itu menginginkan sesuatu yang tidak dibawa permintaan Anda, atau URL yang Anda pakai bukan URL yang disajikan situs. Penyebab yang paling umum:

• Anda belum login — halaman di balik login menjawab 302 ke halaman masuk, dengan halaman yang Anda tuju disimpan di parameter kembali. Tanpa login, github.com/settings mengalihkan Anda ke /login?return_to=…. Di curl atau klien API, kirim cookie sesi atau token.
• Klien Anda tidak mengikuti pengalihan — browser, fetch(), dan requests di Python mengikutinya secara otomatis. curl tidak, kecuali Anda menambahkan -L; ia berhenti di 302 dan hanya mencetak body-nya, sering kali kosong (tambahkan -i untuk melihat status dan Location).
• URL bukan yang disajikan situs — garis miring di akhir yang kurang atau berlebih, path bahasa, atau tautan pelacak yang melempar Anda ke tempat lain. res.redirect() di Express, return nginx yang hanya berisi URL, dan Redirect di Apache mengirim 302 kecuali Anda menentukan lain.
• Ada yang di depan server menambahkannya — jika server asal menjawab 200 saat Anda mengujinya langsung tetapi URL publiknya memberi 302, berarti aturan di CDN, load balancer, atau proxy yang melakukan pengalihan.

API biasanya menjawab login yang tidak ada dengan 401 Unauthorized, bukan pengalihan. Untuk melihat setiap lompatan dan kode statusnya, jalankan URL lewat Cek Redirect.

302 vs 301 vs 307 vs 308: Pengalihan Mana yang Harus Dipakai?

Lima kode pengalihan mencakup hampir semua kasus. Perbedaannya ada pada dua hal: apakah perpindahannya permanen, dan apakah POST tetap menjadi POST:

303 dan 307 ada karena 302. HTTP/1.1 menambahkan 303 pada 1997, dan pada 1999 RFC 2616 mengakui bahwa "sebagian besar implementasi user agent yang ada memperlakukan 302 seolah-olah respons 303", menambahkan 307, dan mengganti nama 302 menjadi "Found" (RFC 2616 §10.3.3). Jika pengalihan sementara mungkin menerima POST, gunakan 307 untuk mempertahankannya, atau 303 untuk memuat halaman berikutnya dengan GET.

Kapan Sebaiknya Memakai Pengalihan 302?

Gunakan 302 saat Anda memperkirakan pengalihannya akan hilang. Kasus yang umum:

• Pengalihan login — mengirim pengguna yang belum login dari /dashboard ke /login, lalu kembali setelah masuk
• Uji A/B — mengirim sebagian pengunjung ke halaman varian; panduan pengujian dari Google sendiri menyarankan 302, bukan 301, di sini (Google Search Central)
• Halaman yang sedang diperbaiki — mengarahkan pengunjung ke halaman pemberitahuan selama beberapa hari saat sebuah halaman dibangun ulang
• URL kampanye singkat — /black-friday yang menuju halaman promo tahun ini hanya selama promo berlangsung
• Pemeliharaan — hanya untuk pengunjung; untuk mesin telusur, 503 dengan Retry-After adalah jawaban yang lebih baik saat ada downtime terencana

Jika salah satunya menjadi permanen, ganti ke 301.

Cara Mengirim Kode Status 302

Sebagian besar server dan framework punya cara satu baris untuk mengirim 302. Masing-masing contoh di bawah mengirim 302 Found dengan header Location, semua yang dibutuhkan sebuah 302.

Nginx

Di nginx, gunakan return dengan kodenya. return yang hanya berisi URL juga mengirim 302 (dokumentasi nginx):

server {
    listen 80;
    server_name example.com;

    # Temporary redirect (302 Found)
    location /old-page {
        return 302 https://example.com/new-page;
    }
}

Apache (.htaccess)

Di Apache, gunakan Redirect (302 adalah defaultnya bila Anda tidak memberi status) atau RewriteRule dengan [R=302,L]:

# Simple temporary redirect
Redirect 302 /old-page https://example.com/new-page

# Or with mod_rewrite for pattern matching
RewriteEngine On
RewriteRule ^maintenance$ /maintenance.html [R=302,L]

Node.js (Express)

res.redirect() di Express secara default memakai 302 bila tidak ada kode status yang diberikan:

// Temporary redirect (302 Found by default)
app.get('/dashboard', (req, res) => {
  if (!req.user) {
    return res.redirect('/login') // sends 302
  }
  // ...render dashboard
})

// Or be explicit:
res.redirect(302, '/login')

Cara Menguji Kode Status 302

Cara tercepat untuk memeriksa adalah curl dari terminal: ia menampilkan kode status dan header Location tanpa terhalang cache browser.

# Status and headers, without following the redirect
curl -sI https://example.com/old-page

# -I sends HEAD, which some servers answer differently; this sends a real GET
curl -s -o /dev/null -D - https://example.com/old-page

# Expected:
# HTTP/2 302
# location: https://example.com/new-page

# Follow the whole chain and print each hop's status and Location
curl -sL -o /dev/null -D - https://example.com/old-page | grep -iE '^(HTTP/|location:)'

Tidak punya terminal? Cek Redirect DNS Robot mengikuti setiap lompatan (301, 302, 303, 307, 308, dan meta refresh) dari server kami dan menampilkan setiap kode status serta URL akhir, dan Cek HTTP Header menampilkan header mentah setiap lompatan di bagian Redirects.

Pengalihan 302 dan SEO

Google memperlakukan kedua jenis pengalihan sebagai instruksi yang berbeda. Untuk pengalihan sementara (302, 303, 307), Googlebot mengikutinya, tetapi Google tidak menganggapnya sebagai sinyal bahwa target harus menjadi URL kanonis, sehingga halaman sumber biasanya tetap ada di hasil penelusuran. Target tetap bisa diindeks jika sinyal lain mengarah ke sana (Google Search Central).

Pengalihan permanen (301, 308) menyatakan sebaliknya: tampilkan URL baru. Jadi pertanyaan sebenarnya bukan "apakah 302 meneruskan PageRank?" melainkan "URL mana yang saya inginkan di hasil penelusuran?". Tag rel=canonical adalah salah satu sinyal lainnya; Cek Meta Tag menunjukkan URL mana yang dinyatakan sebuah halaman.

• Gunakan 301 atau 308 untuk perpindahan permanen — domain baru, struktur URL baru, halaman yang digabung
• Gunakan 302 untuk yang sementara — login, uji A/B, kampanye
• Jangan biarkan perpindahan permanen tetap 302 — Google mungkin terus menampilkan URL lama
• Jaga rantai tetap pendek — setiap lompatan menambah satu kali bolak-balik, dan Googlebot secara default mengikuti hingga 10 lompatan (Google)

Mengapa 302 Mengubah Permintaan POST Menjadi GET

Inilah bagian 302 yang paling mengejutkan. Spesifikasi awal tidak pernah mengizinkan klien mengubah metode, tetapi browser tetap mengubah POST menjadi GET pada 302. Kini Fetch Standard yang diimplementasikan browser mencatat kebiasaan itu: pada 301 atau 302, POST menjadi GET dan body-nya dibuang (Fetch Standard).

Jadi ketika browser mengirim POST /submit-form dan server menjawab 302 Found, browser mengikutinya dengan GET /thank-you, dan data formulir hilang. Browser membiarkan PUT dan DELETE apa adanya; klien lain berbeda: requests di Python mengubah setiap metode kecuali HEAD menjadi GET pada 302, dan curl -L mengubah POST menjadi GET pada 301, 302, dan 303 (--post302 mempertahankan POST pada 302).

# What you send:
POST /submit-form HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

name=Alice&email=alice@example.com

# Server responds with 302:
HTTP/1.1 302 Found
Location: /thank-you

# Browser follows with GET (form data dropped!):
GET /thank-you HTTP/1.1
Host: example.com

Jika pengalihan harus mempertahankan metode asli (POST tetap POST, PUT tetap PUT), gunakan 307 Temporary Redirect. Jika Anda memang ingin membuang body dan beralih ke GET — pola klasik POST/Redirect/GET — gunakan 303 See Other. Keduanya jelas; 302 tidak.

Error 302 yang Umum dan Cara Memperbaikinya

Jika 302 bermasalah, biasanya salah satu dari ini:

• 302 alih-alih 200 — halaman yang memerlukan login, klien yang tidak mengikuti pengalihan, atau variasi URL (lihat "Mengapa saya mendapat 302" di atas)
• 302 tanpa header Location — tidak ada yang bisa mengikutinya, dan browser menampilkan isi 302 itu sendiri, biasanya kosong. Tetapkan Location sebelum mengirim status
• 302 yang menunjuk ke dirinya sendiri — loop pengalihan: aturan terpicu pada targetnya sendiri. Tambahkan kondisi yang kurang
• Formulir yang kehilangan datanya — POST → 302 → GET membuang body. Gunakan 303 untuk sengaja menampilkan halaman hasil, atau 307 untuk mempertahankan POST
• 302 yang menempel — server mengirim Cache-Control: max-age atau Expires bersamanya sehingga browser menyimpannya di cache, atau CDN Anda yang menyimpannya (pada konten yang di-cache Cloudflare, ia menyimpan 302 selama 20 menit kecuali header menyatakan lain, dokumentasi Cloudflare). Hapus header itu, bersihkan cache CDN, dan hapus cache browser
• 302 di produksi tetapi tidak di lokal — sering kali aturan CDN, load balancer, atau proxy yang menambahkan pengalihan. Uji server asal secara langsung untuk memastikannya

Loop Pengalihan 302: Cara Mendiagnosis

Loop pengalihan terjadi saat URL A mengirim Anda ke B dan B mengirim Anda kembali ke A. Setelah 20 pengalihan, batas dalam Fetch Standard, Chrome menyerah dengan ERR_TOO_MANY_REDIRECTS dan Firefox dengan "Laman tidak teralihkan dengan benar".

Penyebab klasiknya adalah mode enkripsi Flexible di Cloudflare: Cloudflare mengakses server Anda lewat HTTP biasa, server mengalihkan HTTP ke HTTPS, lalu Cloudflare meminta lewat HTTP lagi (dokumentasi Cloudflare).

# Trace the full redirect chain (limit to 10 hops to avoid infinite loops)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# Example of a loop:
# HTTP/2 302
# location: http://example.com/
# HTTP/1.1 302 Found
# Location: https://example.com/
# HTTP/2 302
# location: http://example.com/  <-- loop confirmed

Jika URL yang sama terus muncul di Location, baik menunjuk ke dirinya sendiri maupun dua URL yang saling bergantian, berarti Anda mengalami loop (pada mode Flexible Cloudflare, https://example.com/ dialihkan ke dirinya sendiri). Untuk perbaikan lengkap, lihat panduan ERR_TOO_MANY_REDIRECTS kami. Cek Redirect DNS Robot menelusuri rantai dari server kami dan berhenti di titik terjadinya loop.

Praktik Terbaik Kode Status 302

Beberapa kebiasaan menghindarkan sebagian besar masalah 302:

• Selalu kirim header Location — tanpa itu, tidak ada yang mengikuti pengalihan
• Jangan tambahkan header cache — 302 tanpa max-age atau Expires tidak di-cache, dan itulah yang Anda inginkan
• Waspadai URL absolut di balik proxy — di kode aplikasi, /login yang relatif mencegah nama host internal atau http:// bocor ke Location; nginx dan Apache membentuk URL absolut dari pengaturan mereka sendiri
• Batasi hanya satu lompatan — A → B tidak masalah; A → B → C menambah satu kali bolak-balik untuk setiap pengunjung
• Jangan pernah 302 sebuah POST ke halaman lain — gunakan 303 untuk menampilkan halaman hasil, atau 307 untuk mempertahankan POST
• Tinjau pengalihan sementara yang lama — sering kali bertahan lebih lama dari alasannya. Periksa dengan Cek Redirect
• Ganti ke 301 begitu perpindahannya permanen

Cara Browser dan Alat Menangani 302

Semua klien sepakat untuk mengikuti 302, tetapi berbeda dalam batas dan perlakuan terhadap metode:

Untuk redaksi persisnya, lihat definisi 302 di RFC 9110 dan halaman MDN tentang 302.