Sistem anti-bot adalah perangkat lunak di depan sebuah situs web yang memperkirakan, untuk setiap permintaan, seberapa besar kemungkinan permintaan tersebut berasal dari otomatisasi daripada manusia, dan bertindak berdasarkan perkiraan itu — membiarkannya lewat, memperlambatnya, menantangnya, atau memblokirnya. Perkiraan tersebut tidak dibuat dari satu fakta tunggal. Ini adalah skor yang disusun dari empat lapisan: dari mana permintaan berasal (IP), bagaimana koneksi dibuat (sidik jari TLS dan HTTP), apa yang diungkapkan browser tentang dirinya (sidik jari JavaScript), dan apa yang dilakukan pengunjung seiring waktu (perilaku). Memahami lapisan-lapisan ini menjelaskan dua hal yang paling membingungkan pengguna proxy: mengapa IP residensial yang “sempurna” masih bisa ditantang, dan mengapa pengaturan yang sama berhasil di satu situs tetapi gagal di situs lain.
Vendor, dan produknya
Sebagian besar situs yang dilindungi menggunakan salah satu dari beberapa produk: Cloudflare Bot Management (dan tantangan Turnstile-nya), DataDome, Akamai Bot Manager, HUMAN (sebelumnya PerimeterX), Imperva (Incapsula), Kasada, dan AWS WAF Bot Control. Mereka berbeda dalam penekanan dan seberapa agresif pengaturan default mereka, tetapi mereka dibangun di atas empat lapisan yang sama, dan lapisan-lapisan itulah yang menjadi fokus artikel ini. Semua yang dijelaskan di bawah ini berlaku untuk semuanya dalam proporsi tertentu.
Lapisan 1: Reputasi IP
Pemeriksaan pertama dan termurah. Sebelum permintaan bahkan diurai, IP dicari:
- ASN dan tipe — apakah ini perusahaan hosting (pusat data), ISP konsumen (residensial), atau operator seluler? ASN hosting mulai dengan penalti di sebagian besar situs; alasannya dijelaskan dalam Residensial vs pusat data vs seluler.
- Intelijen ancaman — apakah IP ada dalam daftar penyalahgunaan, dikenal sebagai pintu keluar VPN/proxy, atau terlihat menyerang pelanggan lain dari vendor yang sama? Vendor menggabungkan sinyal di seluruh basis pelanggan mereka, jadi IP yang terbakar di satu situs yang dilindungi DataDome dicurigai di semua situs tersebut.
- Kecepatan — berapa banyak permintaan yang dibuat IP ini ke situs ini baru-baru ini, dan ke berapa banyak jalur yang berbeda? Penghitung per-IP adalah sinyal bot tertua yang ada dan masih salah satu yang paling efektif.
- Geografi — apakah negara cocok dengan audiens situs? Apakah cocok dengan bahasa dan zona waktu yang akan dilaporkan browser nanti?
Ini adalah satu-satunya lapisan yang dikendalikan langsung oleh proxy. IP residensial atau seluler tanpa riwayat di target melewatinya. Tetapi melewati lapisan 1 hanya berarti permintaan melanjutkan ke lapisan 2–4 dengan skor netral, bukan skor yang baik.
Lapisan 2: Sidik jari jaringan (TLS, HTTP/2, TCP)
Sebelum konten halaman apa pun disajikan, server sudah melihat bagaimana koneksi dibuka, dan cara pembukaannya mengidentifikasi perangkat lunak klien:
- Sidik jari TLS (JA3/JA4) — ClientHello mengungkapkan pustaka TLS: Chrome, Firefox, OpenSSL-in-Python, Go. Dijelaskan dalam Sidik jari TLS.
- Sidik jari HTTP/2 — nilai bingkai SETTINGS, ukuran jendela awal, bingkai prioritas, dan urutan header dan pseudo-header. Browser memiliki pola yang khas dan stabil; pustaka HTTP memiliki pola yang berbeda. Penelitian Akamai membuat teknik ini terkenal.
- Sidik jari TCP/IP — ukuran jendela, TTL, opsi; membedakan sistem operasi, dan User-Agent “Windows” dari tumpukan TCP Linux adalah ketidakcocokan.
Logika penilaian di sini adalah konsistensi: apakah identitas tingkat jaringan cocok dengan apa yang diklaim oleh header HTTP? Proxy tidak menyentuh sidik jari ini — ia meneruskannya — jadi skrip di belakang IP residensial diidentifikasi sebagai skrip di lapisan ini terlepas dari kualitas IP. Di sinilah sebagian besar pertanyaan “mengapa proxy bersih saya diblokir?” dijawab.
Lapisan 3: Sidik jari browser dan tantangan JavaScript
Jika permintaan mencapai titik penyajian HTML, JavaScript vendor berjalan di browser pengunjung dan melaporkan kembali. Dua jenis hal terjadi.
Pembuatan sidik jari
Skrip mengumpulkan properti yang sama yang dibangun untuk dikendalikan oleh browser antideteksi: hash kanvas dan WebGL, font, dimensi layar dan jendela, konkurensi perangkat keras, zona waktu, bahasa, konteks audio, IP yang terlihat WebRTC, daftar plugin, dan puluhan sinyal yang lebih kecil. Ini juga menyelidiki artefak otomatisasi: navigator.webdriver disetel ke true, objek khusus Chrome yang hilang atau tidak konsisten, keanehan mode headless dalam rendering, sejumlah API yang tidak biasa ditimpa (tanda plugin siluman yang menambal browser). Dan ia memeriksa konsistensi: apakah platform yang dilaporkan JavaScript cocok dengan OS sidik jari TCP? Apakah zona waktu cocok dengan negara IP? Lihat apa yang dikendalikan browser antideteksi.
Tantangan
Vendor juga mengeluarkan tugas bukti kerja atau bukti kemanusiaan. Turnstile Cloudflare dan interstisial “memeriksa browser Anda” menjalankan beban kerja JavaScript yang hasilnya harus dikirim kembali; klien yang tidak dapat menjalankan JavaScript sama sekali — setiap pustaka HTTP biasa — gagal dan tidak pernah melihat halaman. CAPTCHA yang terlihat adalah upaya terakhir, ditampilkan ketika skornya buruk tetapi tidak cukup buruk untuk diblokir sepenuhnya. Melewati tantangan biasanya menghasilkan cookie atau token yang berlaku untuk periode tertentu; otomatisasi yang membersihkan cookie pada setiap permintaan menghadapi tantangan setiap kali, yang merupakan sinyal tersendiri.
Lapisan 4: Perilaku
Selama sesi — dan lintas sesi yang dapat dihubungkan vendor dengan sidik jari atau IP — sistem mengamati apa yang dilakukan pengunjung:
- Pola permintaan: halaman per menit, apakah gambar dan skrip yang direferensikan oleh halaman diambil (browser manusia mengambilnya; scraper naif tidak), apakah navigasi mengikuti tautan atau langsung melompat ke URL dalam, apakah jalur yang sama dipukul dalam urutan yang sama setiap sesi.
- Waktu: interval seragam antara permintaan seperti mesin; manusia bersifat semburan dan tidak teratur.
- Interaksi: gerakan mouse, gulir, peristiwa tombol — kehadirannya, dan bentuknya (jalur mouse asli melengkung dan melampaui; yang dibuat skrip adalah garis lurus atau busur sempurna).
- Bentuk sesi: login yang diikuti langsung oleh tindakan massal; checkout tanpa menjelajah; pembuatan akun dari sidik jari yang membuat lima akun kemarin.
Perilaku adalah alasan mengapa pengaturan yang secara teknis sempurna — browser asli, proxy yang cocok, sidik jari bersih — masih bisa tertangkap jika bertindak seperti mesin. Ini juga merupakan lapisan di mana reputasi terakumulasi hidup: identitas yang telah berperilaku normal selama berminggu-minggu mendapatkan toleransi yang tidak dimiliki yang baru. Itulah arti “pemanasan” dalam praktik.
Bagaimana lapisan-lapisan digabungkan: skor
Setiap lapisan menyumbang bukti; produk menggabungkannya menjadi skor bot (Cloudflare mengekspos skor mereka sebagai 1–99; yang lain menyimpannya secara internal) dan pemilik situs mengonfigurasi ambang batas: di atas X, izinkan; antara X dan Y, tantang; di bawah Y, blokir atau sajikan umpan. Dua properti desain ini penting bagi siapa pun yang menggunakan proxy:
- Lapisan-lapisan harus setuju. Skor bukanlah jumlah dari nilai baik yang independen; kontradiksi diberi bobot berat. IP residensial (baik) ditambah sidik jari TLS Python (buruk) ditambah User-Agent Chrome (kontradiksi) menghasilkan skor lebih buruk daripada IP pusat data dengan UA
python-requestsyang jujur, karena yang kedua setidaknya koheren. - Tidak ada yang diperiksa secara terpisah. Melewati reputasi IP membeli Anda masuk ke pemeriksaan berikutnya, bukan izin. Setiap klaim yang Anda buat — melalui IP, jabat tangan, header, JavaScript, perilaku — diperiksa silang terhadap yang lain.
Apa artinya ini untuk pilihan proxy
| Lapisan | Apa yang menentukannya | Bisakah proxy memperbaikinya? |
|---|---|---|
| 1. Reputasi IP | Tipe IP, riwayat, kecepatan, geo | Ya — ini adalah tugas utama proxy |
| 2. Sidik jari jaringan | Klien HTTP / browser Anda | Tidak — diteruskan tanpa perubahan |
| 3. Sidik jari browser / tantangan JS | Browser Anda dan konfigurasinya | Tidak — tetapi geo/zona waktu harus cocok dengan proxy |
| 4. Perilaku | Logika otomatisasi dan kecepatan Anda | Tidak — meskipun rotasi memengaruhi kecepatan per-IP |
Jadi: pilih jenis proxy yang dituntut oleh kebijakan lapisan-1 target (pusat data jika ditoleransi, residensial atau seluler jika tidak), lalu habiskan upaya Anda pada lapisan 2–4, yang tidak disentuh proxy. Praktisnya itu berarti browser asli atau yang ditiru untuk target yang dilindungi, konsistensi sidik jari per-identitas, geo/zona waktu yang cocok dengan IP, dan kecepatan yang berbentuk manusia. Strategi rotasi berinteraksi dengan kecepatan lapisan 1 dan bentuk sesi lapisan 4 sekaligus — lihat memilih interval rotasi.
Cara mengetahui lapisan mana yang menghentikan Anda
- Diblokir seketika, tanpa HTML, bahkan dari browser asli di IP yang sama → lapisan 1: IP atau ASN adalah masalahnya. Ganti jenis proxy atau penyedia.
- Browser lolos, skrip di IP yang sama tidak → lapisan 2: sidik jari TLS/HTTP. Pindah ke browser asli atau klien yang meniru.
- Interstisial yang tidak pernah selesai, atau CAPTCHA di setiap kunjungan → lapisan 3: tantangan JavaScript gagal atau sidik jari tidak konsisten. Periksa flag otomatisasi, WebRTC, zona waktu vs IP.
- Berhasil untuk sementara, lalu menurun; atau akun mati setelah tindakan → lapisan 4: perilaku atau kecepatan. Perlambat, variasikan pola, panaskan identitas.
Vendor mengembalikan respons yang khas (halaman 403 Cloudflare, header x-datadome DataDome dan titik akhir CAPTCHA, cookie _abck Akamai), jadi mengidentifikasi produk mana yang digunakan situs biasanya hanya dengan melihat header dan cookie — dan mengetahui produk mana memberi tahu Anda lapisan mana yang ditekankannya.
Pertanyaan yang sering diajukan
Apa itu skor bot?
Perkiraan per-permintaan, dihasilkan dengan menggabungkan reputasi IP, sidik jari jaringan dan browser, serta sinyal perilaku, tentang seberapa besar kemungkinan permintaan itu otomatis. Pemilik situs menetapkan ambang batas untuk mengizinkan, menantang, atau memblokir.
Mengapa proxy residensial masih mendapatkan CAPTCHA?
Karena reputasi IP hanyalah satu dari empat lapisan. Jika sidik jari TLS/HTTP mengatakan “skrip,” browser gagal atau tidak memiliki tantangan JavaScript, atau perilakunya seperti mesin, skornya buruk terlepas dari IP.
Apakah sistem anti-bot berbagi data antar situs web?
Dalam satu vendor, ya: IP atau sidik jari yang ditandai di situs satu pelanggan meningkatkan risikonya di situs pelanggan lain. Itulah sebabnya kumpulan proxy yang banyak digunakan terhadap satu target yang dilindungi Cloudflare mungkin berkinerja buruk pada target yang dilindungi Cloudflare yang tidak terkait.
Bisakah pustaka HTTP biasa melewati tantangan JavaScript?
Tidak. Tantangan memerlukan eksekusi JavaScript di lingkungan seperti browser. Opsinya adalah browser otomatis asli, atau layanan pemecah yang menjalankan tantangan untuk Anda dan mengembalikan cookie/token yang dihasilkan — yang memiliki biaya dan risiko deteksi.
Apa perbedaan antara tantangan dan CAPTCHA?
Tantangan sering kali tidak terlihat — beban kerja JavaScript atau attestation yang diselesaikan browser secara otomatis. CAPTCHA adalah teka-teki yang terlihat untuk manusia, ditampilkan ketika skornya cukup buruk sehingga sistem menginginkan bukti eksplisit.
Apakah mungkin untuk sepenuhnya tidak terdeteksi?
Tidak sebagai jaminan. Deteksi bersifat probabilistik dan vendor terus memperbarui. Yang dapat dicapai adalah konsistensi di keempat lapisan ditambah perilaku berbentuk manusia, yang menjaga skor dalam kisaran “izinkan” sebagian besar waktu. Siapa pun yang menjanjikan tidak terdeteksi hanya dari proxy hanya menjual lapisan 1.