Anda menerima 403 — dan hal pertama yang biasanya dilakukan adalah mengganti proxy. Terkadang ini membantu, tetapi lebih sering tidak. Karena "anti-bot" bukanlah satu teknologi, melainkan setidaknya enam sistem berbeda dengan mekanisme deteksi yang berbeda, tingkat ketat yang berbeda, dan persyaratan yang berbeda untuk lalu lintas Anda. Apa yang menyelamatkan dari Imperva, tidak berguna melawan Kasada. Mari kita bahas siapa yang siapa di tahun 2026, bagaimana mengenali vendor dalam 30 detik dan apa yang perlu diubah dalam tumpukan proxy untuk masing-masing.
Kenapa "hanya mengganti proxy" tidak lagi bekerja
Logika klasiknya sederhana: jika IP diblokir — ambil yang lain. Itu berhasil selama deteksi dibangun berdasarkan reputasi alamat. Saat ini, IP hanyalah satu lapisan dari lima, dan bobotnya berbeda secara signifikan di antara vendor yang berbeda.
Set lengkap sinyal yang digunakan oleh semua orang:
- Fingerprint TLS (JA3/JA4) — urutan cipher suite dan ekstensi dalam handshake;
- urutan dan format header HTTP — pada klien Python tidak sama dengan Chrome;
- reputasi IP — ASN, kepemilikan pusat data, riwayat alamat;
- fingerprint browser — canvas, WebGL, sensor perangkat keras;
- biometrik perilaku — jalur mouse, kecepatan scroll, pola input.
Kesimpulan kunci yang diulang oleh semua peneliti topik ini: konsistensi sinyal itu penting. Kombinasi User-Agent dari Chrome dengan fingerprint TLS Python menandai Anda sebagai bot di mana saja oleh vendor — terlepas dari seberapa bersih IP Anda. Alamat residensial tidak "menutupi" lapisan browser yang bocor, dan sebaliknya.
Langkah pertama: mengenali vendor berdasarkan jejak
Sebelum mengubah apapun, lihat header respons dan cookies. Setiap sistem meninggalkan tanda tangan yang dapat dikenali — ini adalah cara tercepat untuk memahami dengan apa Anda berurusan.
- Cloudflare — header CF-RAY, cookies cf_clearance dan __cf_bm, memuat challenge.js; dalam build baru, header cf-mitigated dapat muncul.
- DataDome — cookies datadome dan _dd_s, skrip tags.js.
- Akamai — cookie _abck, header referensi akamai-grn.
- PerimeterX (HUMAN Security) — cookies _px3, _pxvid, _pxhd, skrip px.js atau d.js.
- Kasada — header keluarga x-kpsdk-* (ct — challenge token, dv — device validation, cd — challenge data, v — versi), cookie KP_UIDz, skrip ips.js atau p.js.
- Imperva (Incapsula) — cookies incap_ses_*, visid_incap_*, reese84.
- AWS WAF — cookie aws-waf-token, pemanggilan endpoint /challenge.js.
- F5 / Shape Security — cookies dengan awalan TS (misalnya, TS01a2b3c4).
Marker terpisah — karakter penolakan itu sendiri. Kasada menjawab dengan "telanjang" 429 tanpa tubuh respons: jika Anda melihat 403 atau 429 bersama dengan header x-kpsdk-*, pertanyaan sudah ditutup. DataDome lebih sering memberikan 403 dengan halaman CAPTCHA. Cloudflare — tantangan interaktif atau Turnstile.
Apa yang membedakan sistem secara mekanik
Tanda tangan menunjukkan "siapa", tetapi taktik menentukan "bagaimana". Secara arsitektural, vendor sangat berbeda.
Cloudflare — model global di tepi jaringan
Bekerja di tingkat edge CDN: keputusan dibuat sebelum permintaan mencapai aplikasi. Modelnya global, dilatih pada lalu lintas seluruh jaringan — sekitar seperlima dari situs web di internet. Plus untuk Anda: perilaku dapat diprediksi, pengalaman dari satu situs dapat diterapkan ke situs lain. Minus: jaringan melihat subnet Anda di ribuan sumber daya secara bersamaan, reputasi terakumulasi dengan cepat.
DataDome — model pribadi untuk setiap situs
Perbedaan kunci: platform ini memiliki sekitar 85.000 model ML klien, dilatih pada lalu lintas situs tertentu, dan memproses lebih dari 5 triliun sinyal per hari dengan waktu respons kurang dari 2 milidetik. Konsekuensi praktisnya sederhana dan tidak menyenangkan: setiap situs yang dilindungi adalah tugas terpisah. Kombinasi kerja untuk Etsy tidak dapat diterapkan pada sumber daya lain di bawah vendor yang sama. Pada tahun 2025, analisis niat ditambahkan (tujuan kunjungan dievaluasi, bukan hanya fakta otomatisasi) dan kategorisasi terpisah untuk crawler LLM.
Akamai — fokus pada TLS dan telemetri
Memeriksa sinyal handshake dan memvalidasi telemetri perilaku di pihaknya melalui cookie _abck. Menurut pengukuran independen tahun 2026, Akamai dan Imperva menantang klien otomatisasi default lebih jarang dibandingkan Cloudflare dengan DataDome — tetapi ini tidak berarti "lebih lemah": di tempat yang diatur secara agresif, penghindaran memerlukan lapisan TLS yang benar, bukan hanya mengganti IP.
PerimeterX / HUMAN — reputasi jaringan
Reputasi klien menyebar di seluruh jaringan vendor. Jika terdeteksi di satu situs — Anda akan datang ke situs lain dengan label. Situs yang umum: e-commerce dan real estat.
Kasada — interogasi aktif lingkungan
Sistem paling ketat di antara sistem massal. Tidak hanya mengumpulkan fingerprint, tetapi secara aktif menginterogasi lingkungan: memeriksa kode klien melalui Function.prototype.toString(), menerapkan anti-deobfuscation pada skripnya sendiri. Menurut penilaian gabungan, ia mendapatkan peringkat ekstrem baik dalam kecanggihan deteksi maupun dalam kesulitan penghindaran mandiri. Ini diterapkan pada tiket dan real estat.
Imperva (Incapsula) — logika WAF secara default
Berdasarkan IP dan aturan WAF; lapisan perilaku diaktifkan pada pengaturan yang lebih tinggi. Situs klasik — situs korporat dan papan pekerjaan.
Siapa yang lebih ketat: angka daripada perasaan
Ada benchmark independen Scrapeway: delapan layanan melawan sebelas tujuan, lebih dari 1000 permintaan per layanan per tujuan, dua laporan per bulan. Tujuan terikat pada vendor — Indeed di bawah Cloudflare, Etsy di bawah DataDome, Walmart dan Zillow di bawah PerimeterX, Realtor di bawah Kasada.
Apa yang ditunjukkan oleh pengukuran tahun 2026:
- Ketelitian tinggi — Cloudflare, DataDome, PerimeterX, Kasada: sebagian besar klien otomatisasi default yang tidak diatur mendapatkan tantangan.
- Sedang — Akamai dan Imperva: menantang klien default jauh lebih jarang.
- Terhadap tujuan Cloudflare, hanya sebagian kecil klien yang tidak diatur secara konsisten mendapatkan konten halaman.
Untuk perbandingan: di antara layanan penghindaran khusus, tingkat keberhasilan terhadap tujuan ini berada dalam kisaran 94–100% tergantung pada vendor — artinya tugas ini dapat diselesaikan, tetapi tidak dengan klien default dan tidak hanya dengan mengganti IP.
Apa yang perlu diubah dalam tumpukan proxy untuk masing-masing
Sekarang praktik. Di bawah ini — bukan resep penghindaran, tetapi logika pemilihan infrastruktur berdasarkan jenis deteksi.
- Imperva dan AWS WAF. Bobot IP tinggi, lapisan perilaku sering dimatikan. Di sini proxy pusat data masih ada — dengan syarat subnet bersih dan tarif yang wajar. Mulailah dari sini, ini adalah yang paling murah untuk lalu lintas.
- Akamai. Proxy kurang berfungsi dibandingkan lapisan TLS. Pertama, perbaiki handshake dan urutan header, dan hanya kemudian tingkatkan kelas IP. Mengganti proxy dengan fingerprint JA4 yang salah tidak akan memberikan hasil apapun.
- Cloudflare. Reputasi global berarti bahwa subnet cepat terbakar dan segera di mana-mana. Diperlukan proxy residensial dengan kumpulan yang luas dan rotasi yang wajar: bukan "IP baru untuk setiap permintaan", tetapi mempertahankan sesi selama waktu tugas logis, jika tidak, cf_clearance akan hancur.
- DataDome. Model ini dilatih pada lalu lintas situs tertentu, sehingga yang paling penting adalah konsistensi perilaku Anda di situs tersebut. IP residensial memberikan skor trust positif, karena orang nyata mengakses dari koneksi residensial — tetapi sendiri, tanpa pengelolaan fingerprint browser, tidak menjamin apapun. Jangan mentransfer pengaturan dari satu situs ke situs lain secara buta. Detail spesifik tentang vendor ini dapat ditemukan dalam analisis proxy untuk DataDome.
- PerimeterX / HUMAN. Karena reputasi bersifat jaringan, isolasi lebih penting daripada volume: proyek yang berbeda — kumpulan yang berbeda, agar label dari satu situs tidak terbawa ke situs lain.
- Kasada. Alamat pusat data dipotong di pintu masuk. Minimum yang bekerja — residensial, dan lebih baik proxy seluler: di balik satu IP seluler melalui CGNAT ada ratusan pelanggan hidup, dan sistem lebih mahal untuk memblokir alamat semacam itu. Plus, kesesuaian User-Agent dengan versi browser terkini adalah wajib — string yang usang segera mengungkapkan kombinasi.
Kesalahan utama: tumpukan yang tidak seragam
Kita ulangi apa yang telah kita mulai, karena ini adalah penyebab sebagian besar pemblokiran "tidak dapat dijelaskan". Semua enam sistem menangkap ketidaksinkronan antara lapisan. IP residensial dari Jerman + zona waktu sistem UTC + fingerprint TLS curl + Chrome terbaru di User-Agent — ini bukan "hampir berhasil", ini adalah profil bot yang siap. Proxy hanya bertanggung jawab untuk satu lapisan dari lima; empat lainnya ada di klien Anda.
Dari sini, urutan praktis kerja: pertama, identifikasi vendor berdasarkan tanda tangan, kemudian evaluasi lapisan mana yang paling lemah, dan perbaiki itu — bukan yang lebih mudah untuk diubah. Jika setelah memperbaiki tumpukan tujuan tetap tidak dapat diakses, pertanyaan berpindah ke "membangun sendiri atau membayar untuk yang sudah jadi" — percabangan ini telah kita bahas dalam materi proxy melawan scraping API dan web unblockers.
Singkatnya
Tidak ada "anti-bot" tunggal, dan tidak ada penghindaran universal — tidak ada teknik yang bekerja melawan semua delapan sistem sekaligus. Kenali vendor berdasarkan cookies dan header (ini 30 detik), pahami mekanismenya — bobot IP di Imperva, TLS di Akamai, reputasi global di Cloudflare, model pribadi situs di DataDome, label jaringan di PerimeterX, interogasi aktif lingkungan di Kasada — dan pilih jenis proxy untuk itu, bukan secara acak. Pusat data ada di mana IP dilihat secara formal; residensial ada di mana trust dihitung; seluler ada di mana jaringan secara ketat memotong semua yang server. Dan perhatikan konsistensi semua lapisan: inilah yang menyebabkan sebagian besar proyek yang tampaknya diatur dengan benar gagal.
```