reese84?Jawaban singkat: reese84 adalah cookie yang diterbitkan Imperva (dahulu Incapsula) setelah sensor JavaScript-nya berjalan di browser dan lolos. Umurnya pendek — umumnya lima sampai lima belas menit — dan terikat pada sesi, User-Agent, serta IP yang menghasilkannya. Cookie ini menggantikan pasangan incap_ses / visid_incap sebagai sinyal deteksi bot utama, meski keduanya masih muncul di situs berproteksi Imperva.
Kalau Anda sampai di sini dengan 403 dan Incapsula incident ID, langsung ke bagian 403. Kalau Anda sedang memilih antara menjalankan browser atau memanggil API penyelesaian, baca dua cara menanganinya.
Nilai reese84 adalah string buram, biasanya beberapa ratus karakter, mirip base64 yang aman untuk URL — huruf, angka, dan kadang + / =. Tidak ada stempel waktu yang bisa dibaca dan tidak ada user id yang bisa dibaca. Anda tidak bisa mendekodenya menjadi sidik jari; tidak ada yang bisa dipelajari dari decode base64 selain derau. Yang dikodekan diverifikasi di sisi server terhadap hash berkunci.
Dua konsekuensi praktis:
Di Chrome DevTools, cookie ini muncul di Application → Cookies untuk host yang dilindungi dengan Path bernilai /, dan biasanya — tidak selalu — dengan HttpOnly. Jika HttpOnly aktif, document.cookie di halaman tidak bisa melihatnya. Bacalah dari header respons atau dari konteks browser, bukan dari JavaScript yang disuntikkan ke halaman. Di sinilah banyak orang menyimpulkan "cookienya tidak bisa diambil" padahal hanya salah tempat membaca.
Halaman memuat skrip sensor — sering disajikan dari path yang memuat _Incapsula_Resource, atau dari URL UT.mvc per situs. Skrip itu mengumpulkan sinyal browser, mengenkripsinya dengan kunci per situs, lalu POST ke endpoint yang menjawab dengan Set-Cookie. Tiga konsekuensi mengikuti langsung:
Poin ketiga adalah tempat sebagian besar proyek patah. Cookie ini bukan bearer token; ia adalah putusan yang menempel pada satu klien tertentu. Menyalinnya ke IP lain, User-Agent lain, atau tumpukan TLS lain langsung membatalkannya.
| Ikatan | Gejala saat dilanggar |
|---|---|
| Alamat IP | Tantangan ulang langsung pada permintaan berikutnya, bahkan beberapa detik kemudian. |
| User-Agent dan sidik jari TLS | Cookie tampak valid, tetapi endpoint mengembalikan 403 dengan halaman blokir Imperva. |
| Masa hidup cookie (menit) | Sempat berjalan, lalu mati di tengah proses. Pekerjaan panjang harus menyegarkan, bukan menyimpan. |
| Laju permintaan | Cookie dicabut lebih awal; nilai yang tahan 50 permintaan gagal pada permintaan ke-200. |
Umur pendek itu disengaja. Jendela lima menit memaksa setiap klien otomatis terus membuktikan bahwa ia bisa menjalankan sensor — tepat hal yang tidak bisa dilakukan kebun bot secara massal. Bagi pengikis data, ini berubah menjadi persyaratan arsitektur: bukan login, melainkan lingkaran penyegaran.
Sebelum mengoptimalkan apa pun, pastikan vendornya — solusi untuk Imperva bukan solusi untuk Cloudflare atau Akamai.
X-CDN: Incapsula, dan sering X-Iinfo dengan tuple berpemisah titik dua._Incapsula_Resource, dan URL skrip UT.mvc.reese84, incap_ses_*, visid_incap_*, nlbi_*.Jika yang muncul justru __cf_bm / cf_clearance, itu Cloudflare → cf_clearance. Jika _abck / bm_sz, itu Akamai → _abck. Jika _px3, itu PerimeterX. Jika datadome, itu DataDome.
Respons blokir Imperva bukan error JSON. Ia halaman HTML penuh, biasanya dengan HTTP 403, memuat incident ID seperti Request unsuccessful. Incapsula incident ID: 123-000000000-000000000000000. Incident ID itu pegangan korelasi milik Imperva; ia mengidentifikasi peristiwa blokir di sisi mereka dan bukan kode yang bisa Anda cari. Yang diberitahukannya adalah lapisan mana yang memblokir:
| Asal 403 | Yang biasanya memperbaikinya |
|---|---|
Tidak ada reese84 sama sekali | Selesaikan sekali untuk mendapatkannya, lalu kirim di setiap permintaan dengan IP yang sama. |
reese84 ada tetapi basi | Segarkan. Jangan ulangi nilai yang sama; kegagalannya deterministik. |
| Cookie ada dan segar, tetap diblokir | Ketidakcocokan sidik jari — cookie diterbitkan untuk klien lain. Selesaikan ulang dari klien yang akan memakainya. |
| Berhasil, lalu diblokir setelah N permintaan | Laju. Perlambat atau sebar ke beberapa exit, dan perkirakan pencabutan lebih awal. |
incap_ses_* — pengenal sesi, satu per sesi, bersufiks per zona.visid_incap_* — pengenal pengunjung, umurnya lebih panjang, dipakai untuk penilaian pengunjung berulang.nlbi_* — afinitas penyeimbang beban, bukan cookie keamanan, tetapi berguna untuk kestabilan sesi.__utmvc — pembukuan sensor, muncul bersama yang lain di sebagian properti.Simpan semuanya dalam satu toples cookie yang dikunci per IP exit. Mencampur cookie dari dua penyelesaian dalam satu toples adalah blokir yang Anda sebabkan sendiri.
Jalankan sendiri sensornya. Browser sungguhan di IP tetap lolos tantangan dan memegang cookie selama umurnya yang pendek. Inilah yang dilakukan kumpulan browser untuk pengikisan data: jujur tetapi mahal. Di Playwright bentuknya seperti ini:
ctx = browser.new_context(proxy=PROXY) # exit yang sama setiap kali page = ctx.new_page() page.goto(url) # sensor berjalan di sini jar = await ctx.cookies() # reese84 sudah ada # pakai jar yang sama untuk panggilan HTTP langsung, hanya lewat PROXY, # dan ulangi blok ini begitu muncul 403
Dua kesalahan yang harus dihindari: merotasi proxy di dalam satu konteks (cookie terikat pada exit yang menerbitkannya), dan menyimpan cookie antar-run (saat itu nilainya sudah mati).
Minta cookienya. API penyelesaian menerima URL situs — dan URL skrip bila situs menyembunyikannya — lalu mengembalikan reese84 baru bersama exit proxy yang harus dipakai dengannya. SolveHub mengekspos ini lewat satu endpoint REST dan menagih per tugas yang selesai; detail yang penting adalah permintaan nyata harus keluar lewat exit yang sama yang menghasilkan cookie.
Ada jalur ketiga yang sering terlewat: situs berproteksi Imperva biasanya membiarkan sitemap, feed RSS, aset statis, dan sebagian API JSON sepenuhnya tanpa proteksi. Jika data yang Anda mau bisa dijangkau di sana, tidak perlu cookie sama sekali.
reese84 sama dengan incap_ses?Tidak. incap_ses adalah ID sesi; reese84 membawa putusan bot dari sensor.
Sebentar, asalkan semuanya berbagi IP dan sidik jari yang sama. Fan-out agresif justru menjadi pemicu pencabutan.
Cookie sudah kedaluwarsa atau sesinya bergeser. Selesaikan ulang, jangan ulangi nilai yang sama.
reese84 bisa dipakai hanya dengan requests atau httpx?Bisa, begitu Anda punya nilai yang hidup — tetapi hanya jika sidik jari TLS dan header klien HTTP itu cocok dengan klien yang menerbitkannya. requests biasa umumnya tidak cocok, itulah sebabnya cookie tampak "tidak berfungsi" padahal sebenarnya hanya tidak serasi.
Anggap enam sampai sepuluh menit sebagai batas aman, dan perlakukan setiap 403 sebagai sinyal penyegaran langsung, bukan sinyal pengulangan.
Glosarium lengkap · _abck · cf_clearance · English edition · 日本語版
Catatan penulis: saya mengembangkan SolveHub, API penyelesaian CAPTCHA dan anti-bot untuk pengujian yang diizinkan; alur reese84 dijelaskan di dokumentasi Imperva.