Dua browser yang menjalankan script identik bisa mendapat tantangan reCAPTCHA yang jauh berbeda tingkat kesulitannya — akar masalahnya biasanya satu: cookie.
Browser dengan cookie Google yang "matang" mendapat tantangan yang jauh lebih ringan dibanding browser yang benar-benar kosong — apalagi kalau Anda baru saja deploy browser profile baru di VPS.
Artikel ini membedah cookie yang dibaca dan ditulis reCAPTCHA, kenapa itu mengubah tingkat kesulitan tantangan, dan cara mengelolanya di automation Anda — lewat browser automation maupun API CaptchaAI yang tidak bergantung pada cookie Anda.
Kenapa cookie menentukan tingkat kesulitan tantangan
Cookie hanyalah satu dari banyak sinyal yang dipakai mesin penilaian risiko Google, tapi bobotnya cukup besar:
- Masuk ke akun Google → kesulitan paling rendah — sinyal identitas yang kuat.
- Ada cookie Google, tidak login → rendah–sedang — menunjukkan riwayat browsing yang wajar.
- Browser baru, tanpa cookie Google → sedang–tinggi — tidak ada riwayat untuk dinilai.
- Cookie diblokir atau dihapus → tinggi — mencurigakan, browser normal biasanya punya cookie.
- Mode penyamaran / private → tinggi — tidak ada identitas yang persisten.
Dari checkbox saja sampai tantangan berlapis
- Skenario terbaik: browser membawa
SID,HSID,NIDdari sesi Google yang sedang login → sering lolos hanya dengan klik kotak centang. - Skenario cukup baik: browser punya
NIDdan1P_JARdari kebiasaan browsing normal → tantangan gambar ringan atau langsung lolos di checkbox. - Skenario terburuk: tidak ada cookie Google sama sekali, sesi benar-benar baru → tantangan gambar berlapis, bisa beberapa putaran.
Cookie apa saja yang dipakai reCAPTCHA
reCAPTCHA sebenarnya membaca tiga lapis cookie yang berbeda sumber dan tujuannya.
Dua lapis pertama datang dari Google sendiri, satu lapis lagi dari situs yang memasang widget-nya.
Cookie di domain Google
Cookie berikut di-set di .google.com dan dibaca oleh iframe reCAPTCHA:
| cookie | Domain | Tujuan | Seumur hidup |
|---|---|---|---|
NID |
.google.com |
Preferensi Google dan ID unik | 6 bulan |
SID / HSID / SSID |
.google.com |
Sesi akun Google (jika masuk) | 2 tahun |
APISID / SAPISID |
.google.com |
Otentikasi Google API | 2 tahun |
1P_JAR |
.google.com |
Personalisasi iklan Google | 1 bulan |
CONSENT |
.google.com |
Preferensi persetujuan cookie | 17 tahun |
Cookie khusus reCAPTCHA
| cookie | Domain | Tujuan | Seumur hidup |
|---|---|---|---|
_GRECAPTCHA |
.google.com / .recaptcha.net |
Pelacakan sesi reCAPTCHA | Sesi |
rc::a |
Penyimpanan lokal | Data analisis risiko | Persisten |
rc::b |
Penyimpanan lokal | Data timestamp | Sesi |
rc::c |
Penyimpanan lokal | Data khusus tantangan | Sesi |
rc::d-<id> |
Penyimpanan lokal | Data per widget | Sesi |
Cookie milik situs target
Situs yang memasang reCAPTCHA biasanya juga punya cookie sendiri untuk sesi dan CSRF:
- ID Sesi (
PHPSESSID,session_id) — mengikat solve CAPTCHA ke sesi pengguna. - Token CSRF (
csrf_token,_token) — diperlukan saat submit formulir. - Pelacakan khusus situs (beda-beda per situs) — bisa memengaruhi kapan CAPTCHA muncul.
Cara mengelola cookie dalam automation
Ada dua jalur, masing-masing dengan trade-off berbeda.
Opsi 1: otomatisasi browser (Playwright/Puppeteer)
Browser automation otomatis menangani cookie selama context-nya tetap sama. Untuk mempertahankannya lintas sesi:
# Save cookies after session
cookies = page.context.cookies()
import json
with open("cookies.json", "w") as f:
json.dump(cookies, f)
# Restore cookies in next session
with open("cookies.json") as f:
cookies = json.load(f)
page.context.add_cookies(cookies)
Opsi 2: API CaptchaAI tanpa browser
Ini jalur yang paling sering dipakai freelancer dan tim automation di Indonesia yang men-deploy scraper ke VPS baru — AWS ap-southeast-1 (Singapura), GCP asia-southeast2 (Jakarta), atau instance lain yang masih bersih. Profile sekosong itu kena tantangan berlapis persis skenario terburuk di atas.
Solusinya: lewatkan masalah cookie sepenuhnya. Saat memakai CaptchaAI tanpa browser, cookie Anda tidak memengaruhi solve-nya secara langsung — CaptchaAI mengelola lingkungan solve-nya sendiri, terlepas dari histori browser profile Anda.
Catatan: menyamakan cookie identik di banyak sesi paralel untuk "mempercepat" pematangan profile justru jadi sinyal mencurigakan. Biarkan tiap profile membangun histori cookie-nya sendiri.
Kalau situs target tetap butuh cookie untuk kesinambungan sesi, Anda bisa meneruskannya sebagai konteks tambahan lewat parameter opsional:
POST https://ocr.captchaai.com/in.php
key=YOUR_API_KEY
&method=userrecaptcha
&googlekey=SITE_KEY
&pageurl=https://staging.example.com/qa-login
&cookies=NID=12345;1P_JAR=2026-04-04-12
Parameter cookies opsional — dipakai kalau situs target butuh konteks sesi tambahan, bukan syarat wajib untuk solve-nya.
Kenapa cookie pihak ketiga sering diblokir browser modern
reCAPTCHA dimuat lewat iframe dari google.com, dan browser modern makin ketat soal itu:
- SameSite=Lax (default) — cookie Google tidak otomatis terkirim di dalam iframe reCAPTCHA.
- Pemblokiran cookie pihak ketiga — reCAPTCHA fallback ke
recaptcha.netatau mode pihak pertama. - ITP (Safari) — cookie Google lebih cepat expired, tantangan sulit jadi lebih sering.
Cara Google menyiasatinya
- Memakai
recaptcha.netsebagai domain alternatif. - Memakai Penyimpanan lokal (entri
rc::*) untuk status di sisi client. - Memakai opsi pemuatan script pihak pertama khusus pelanggan Enterprise.
Penyimpanan lokal: cadangan yang sering diabaikan
reCAPTCHA menyimpan data penilaian risiko di Penyimpanan lokal dengan awalan kunci rc:::
| Pola kunci | Data |
|---|---|
rc::a |
Payload analisis risiko yang di-encode |
rc::b |
Timestamp tantangan terakhir |
rc::c |
Data sesi tantangan yang sedang berjalan |
rc::d-<hash> |
Data instance per widget |
Entri ini membuat reCAPTCHA mempertahankan status lintas page load tanpa cookie pihak ketiga. Banyak setup automation rajin menyimpan cookie tapi lupa Penyimpanan lokal — padahal sama pentingnya untuk menurunkan kesulitan tantangan:
# Save localStorage
storage = page.evaluate("() => JSON.stringify(localStorage)")
with open("localstorage.json", "w") as f:
f.write(storage)
# Restore localStorage
with open("localstorage.json") as f:
storage = f.read()
page.evaluate(f"Object.entries(JSON.parse('{storage}')).forEach(([k,v]) => localStorage.setItem(k,v))")
Praktik terbaik menjaga cookie tetap "matang"
- Pertahankan browser profile antar-run — membangun riwayat browsing → tantangan lebih ringan.
- Jangan hapus cookie antar-task — menjaga kesinambungan penilaian risiko Google.
- Pakai
recaptcha.netkalaugoogle.comdiblokir — layanan sama, domain beda. - Pertahankan entri Penyimpanan lokal
rc::— mempertahankan status sesi reCAPTCHA. - Sesekali kunjungi properti Google — menyegarkan validitas cookie.
Troubleshooting cepat
- Selalu dapat tantangan gambar sulit — biasanya karena tidak ada cookie / profile baru; bangun browser profile dengan cookie Google dulu.
- reCAPTCHA menampilkan error "cookies required" — cookie pihak ketiga diblokir; aktifkan cookie untuk google.com atau pakai recaptcha.net.
- Token valid tapi sesi tidak cocok — cookie situs (
PHPSESSID) tidak dijaga; simpan dan restore semua cookie, bukan cuma cookie Google. - Terus diminta gambar tambahan (loop) — Penyimpanan lokal terhapus antar-percobaan; pertahankan entri Penyimpanan lokal
rc::*.
Kalau semua langkah di atas sudah dicoba dan tantangan tetap berat, penyebabnya kemungkinan besar reputasi IP, bukan cookie — pertimbangkan API CaptchaAI, yang tidak bergantung pada histori browser sama sekali.
FAQ seputar cookie reCAPTCHA
Apakah API CaptchaAI tetap butuh cookie browser saya untuk menyelesaikan reCAPTCHA?
Tidak. CaptchaAI menyelesaikan reCAPTCHA secara independen lewat infrastrukturnya sendiri. Anda boleh meneruskan cookie sebagai konteks tambahan, tapi itu opsional, bukan syarat wajib.
Kenapa reCAPTCHA di VPS cloud terasa lebih sulit dibanding laptop kerja sehari-hari?
Karena dua sinyal negatif menumpuk sekaligus: IP pusat data (bukan IP residensial) yang reputasinya lebih rendah di mata Google, ditambah browser profile baru tanpa histori cookie sama sekali. Kombinasinya membuat tantangan di VPS baru terasa lebih berat daripada di browser harian Anda.
Bolehkah cookie yang sama dipakai ulang di banyak sesi automation paralel sekaligus?
Sebaiknya tidak dipaksakan. Cookie identik dari banyak IP dan browser context berbeda dalam waktu bersamaan justru jadi sinyal mencurigakan. Lebih aman membiarkan tiap profile membangun histori cookie-nya sendiri, atau — untuk volume besar — pakai jalur API CaptchaAI yang tidak bergantung pada cookie sama sekali.
Berapa lama cookie NID dan 1P_JAR bertahan sebelum harus disegarkan?
Cookie NID milik Google bertahan sekitar 6 bulan, sedangkan 1P_JAR jauh lebih pendek, sekitar 1 bulan saja. Memakai browser profile secara rutin — bukan cuma disimpan tapi benar-benar dipakai — yang membuat cookie-cookie ini tetap segar.
Baca juga
- cara menyelesaikan callback reCAPTCHA v2 lewat API
- menangani Turnstile dan reCAPTCHA v2 di situs yang sama
- cara kerja mekanisme callback reCAPTCHA v2
Langkah berikutnya
Tidak perlu pusing membangun histori cookie dari nol di setiap VPS baru — dapatkan API key CaptchaAI Anda dan biarkan solve reCAPTCHA berjalan lewat infrastruktur CaptchaAI sendiri, terlepas dari cookie browser Anda.