← Kembali ke blog
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

Mengapa parser terdeteksi melalui sidik jari TLS bahkan dengan IP residensial bersih: cara memeriksa dan memperbaiki

IP residensial tidak melindungi dari pemblokiran jika sidik jari TLS parser berbeda dari sidik jari browser biasa. Kami membahas cara memeriksa dan mengaturnya dengan benar.

📅28 September 2026

Anda telah mengambil IP residensial yang mahal, mengatur rotasi, memasukkan User-Agent yang realistis — tetapi parser tetap saja terjebak dalam captcha atau mendapatkan respons kosong. Masalahnya hampir selalu bukan pada IP, tetapi pada jejak TLS: pustaka yang Anda gunakan untuk mengirim permintaan HTTPS "terdengar" tidak seperti browser yang sebenarnya. Sistem anti-bot Wildberries, Ozon, Cloudflare, dan Akamai melihat ini sebelum memeriksa alamat IP Anda.

Apa itu jejak TLS dan mengapa itu lebih penting daripada IP

Ketika klien membuat koneksi HTTPS, ia mengirimkan paket ClientHello — bagian dari handshake TLS. Di dalamnya terenkripsi daftar versi TLS yang didukung, kumpulan cipher (cipher suites), urutan ekstensi (extensions), kurva eliptik, dan algoritma kompresi. Set parameter ini unik untuk setiap kombinasi "pustaka + sistem operasi + versi tumpukan TLS".

Chrome, Firefox, dan Safari membentuk ClientHello dengan cara mereka sendiri, dan set ini hampir tidak berubah dari permintaan ke permintaan — berbeda dengan IP atau User-Agent, yang mudah dipalsukan dengan teks. Namun, pustaka HTTP standar — requests, urllib3, HttpClient standar di Java, tumpukan TLS bawaan Node.js — membentuk ClientHello yang sama sekali berbeda, karena menggunakan OpenSSL atau pustaka lain dengan cara yang berbeda dari browser.

Itulah sebabnya Anda dapat menghubungkan IP residensial yang "bersih" dengan sempurna, memasukkan User-Agent terbaru dari Chrome yang sebenarnya — dan tetap mendapatkan pemblokiran. Server melihat IP pengguna dari rumah residensial, melihat header "Chrome 124", tetapi handshake TLS mengatakan: "ini adalah skrip Python". Ketidaksesuaian ini adalah sinyal langsung untuk anti-bot.

Bagaimana sistem anti-bot mendeteksi parser berdasarkan JA3/JA4

Untuk mengubah parameter ClientHello menjadi pengidentifikasi yang ringkas, digunakan algoritma JA3 (dan versi lebih barunya JA4). Algoritma ini mengambil versi TLS, daftar cipher, ekstensi, dan kurva, menggabungkannya menjadi string, dan menghash-nya melalui MD5. Hasilnya adalah hash pendek seperti 769,47-53-5-10...,0-23-65281...,29-23-24,0, yang secara unik mengidentifikasi "jejak" klien.

Penyedia antibot (Cloudflare, Akamai, PerimeterX, DataDome — dan analog mereka yang digunakan oleh Wildberries dan Ozon) menyimpan basis data hash JA3/JA4 yang dikenal dari pustaka HTTP populer: requests, aiohttp, Scrapy, Node fetch, Java HttpClient, Go net/http. Jika hash cocok dengan tanda tangan "skrip" yang dikenal, dan bukan dengan tanda tangan Chrome/Firefox/Safari — permintaan ditandai sebagai mencurigakan bahkan sebelum analisis perilaku.

Selanjutnya, sistem melihat kecocokan jejak TLS dengan User-Agent yang dinyatakan. Jika di header tertulis "Chrome 124 di Windows", tetapi jejak TLS sesuai dengan OpenSSL 1.1.1 dari pustaka standar Python — ini disebut TLS/HTTP mismatch, salah satu sinyal paling andal untuk mendeteksi otomatisasi. Inilah cara parser terdeteksi bahkan dengan IP residensial yang sempurna dan header yang benar.

Cara memeriksa jejak TLS Anda: alat

Sebelum memperbaiki masalah, Anda perlu melihat apa yang dilihat server. Ada beberapa layanan publik yang menunjukkan hash JA3/JA4 Anda dan seluruh set parameter ClientHello:

  • tls.peet.ws — menunjukkan JA3, JA4, daftar cipher dan ekstensi dalam format JSON, nyaman untuk pemeriksaan otomatis dengan skrip.
  • ja3er.com — basis data hash JA3 yang dikenal dengan keterikatan pada pustaka dan browser tertentu.
  • browserleaks.com/tls — perbandingan visual jejak Anda dengan jejak browser yang khas.
  • Wireshark lokal — jika Anda ingin melihat paket ClientHello mentah saat mengirim permintaan dari skrip Anda.

Uji praktisnya sederhana: buka tls.peet.ws di Chrome biasa dan catat hash JA4. Kemudian kirim permintaan GET ke alamat yang sama dari parser Anda (melalui requests, curl_cffi, atau pustaka lain) melalui proxy yang sama dan bandingkan hash-nya. Jika berbeda — server melihat perbedaan antara "browser" dan "skrip" pada setiap permintaan, terlepas dari seberapa bersih IP tersebut.

Pemeriksaan di Python: requests, httpx, curl_cffi

Mari kita bahas secara praktis mengapa pustaka standar Python menghasilkan parser. Permintaan biasa melalui requests: 

import requests

resp = requests.get("https://tls.peet.ws/api/all", proxies={
    "https": "http://user:pass@proxy_host:port"
})
print(resp.json()["tls"]["ja4"])
# Hasilnya akan berbeda dari JA4 Chrome yang sebenarnya,
# karena requests menggunakan modul ssl standar Python

Masalahnya adalah bahwa requests dan httpx menggunakan OpenSSL sistem melalui modul ssl, dan urutan serta set ekstensi TLS-nya terikat secara ketat dan tidak cocok dengan Chrome/Firefox. Solusinya adalah pustaka curl_cffi, yang menggunakan curl yang dipatch dengan profil TLS nyata dari browser: 

from curl_cffi import requests as cffi_requests

resp = cffi_requests.get(
    "https://tls.peet.ws/api/all",
    impersonate="chrome124",
    proxies={"https": "http://user:pass@proxy_host:port"}
)
print(resp.json()["tls"]["ja4"])
# Hash akan identik dengan Chrome 124 yang sebenarnya di desktop

Parameter impersonate memaksa curl_cffi untuk mereproduksi tidak hanya ClientHello, tetapi juga urutan header HTTP/2 (frame order), yang juga termasuk dalam jejak. Pendekatan serupa digunakan oleh pustaka tls-client untuk Go dan undetected-chromedriver untuk mereka yang melakukan parsing melalui browser nyata, bukan melalui klien HTTP.

Jika parsing dilakukan melalui browser headless (Playwright, Puppeteer, Selenium), jejak TLS dibentuk oleh mesin Chromium/Firefox dan secara default cocok dengan browser nyata. Namun, di sini muncul masalah lain — tanda tangan otomatisasi pada tingkat JS (webdriver-flags, canvas fingerprint), sehingga untuk skenario headless, patch tambahan seperti playwright-stealth diperlukan.

TLS + HTTP/2 + header: mengapa kombinasi ini penting

Jejak TLS hanyalah satu lapisan deteksi. Sistem anti-bot membandingkan beberapa level secara bersamaan:

  • TLS ClientHello (JA3/JA4) — kumpulan cipher dan ekstensi.
  • Jejak HTTP/2 — urutan pseudo-header (:method, :path, :authority), pengaturan frame SETTINGS, ukuran jendela.
  • Header HTTP — urutan dan kumpulan header biasa (Accept-Language, Sec-Ch-Ua, Sec-Fetch-*).
  • User-Agent — harus sesuai dengan versi profil TLS: jika UA mengatakan "Chrome 124", tetapi TLS sesuai dengan Chrome 110, itu juga mencurigakan.

Kesalahan umum adalah memperbarui User-Agent ke versi terbaru Chrome, tanpa memperbarui profil TLS di curl_cffi atau pustaka lain. Ketidaksesuaian versi seperti itu terlihat oleh anti-bot dengan jelas, sama seperti tidak adanya penyamaran. Periksa bahwa versi impersonate dan versi di User-Agent cocok, dan perbarui kedua parameter secara bersamaan saat versi baru browser dirilis.

Satu hal lagi — urutan header. Browser mengirimkan header dalam urutan yang sangat ditentukan, sedangkan banyak pustaka HTTP mengurutkannya secara alfabetis atau berdasarkan urutan penambahan dalam kode. Bahkan jika set header identik dengan browser, urutan yang salah adalah sinyal tambahan untuk sistem anti-bot canggih seperti DataDome.

Peran proxy: mengapa IP bersih tidak menyelamatkan

IP residensial menyelesaikan tugas tertentu — mengurangi kecurigaan berdasarkan geografi, ASN, dan reputasi alamat. IP dari pusat data sering masuk dalam daftar hitam, karena dari sana mengalir trafik otomatisasi secara massal, sedangkan IP residensial dimiliki oleh penyedia nyata dan pengguna biasa. Untuk parsing Wildberries, Ozon, atau Avito, ini sangat penting: tanpa IP bersih, permintaan diblokir hanya berdasarkan kriteria ini, bahkan tanpa memeriksa TLS.

Namun, IP dan jejak TLS adalah dua lapisan perlindungan yang independen, dan mereka menyelesaikan masalah yang berbeda. IP memberi tahu server "dari mana" permintaan datang, jejak TLS memberi tahu "dengan apa" ia dikirim. Oleh karena itu, kombinasi IP bersih dan profil TLS yang benar adalah set minimum untuk parsing yang stabil. Untuk tugas dengan frekuensi permintaan tinggi dan anti-bot yang agresif, lebih baik menggunakan proxy residensial, mereka memberikan persentase pemblokiran yang rendah berdasarkan reputasi IP, tetapi pastikan untuk menggabungkannya dengan pustaka yang secara benar mereproduksi profil TLS dari browser nyata.

Untuk memantau harga di marketplace, di mana kecepatan dan volume permintaan penting, sering digunakan proxy pusat data dikombinasikan dengan penyamaran TLS melalui curl_cffi — ini lebih murah daripada residensial dan cukup efektif, jika sistem anti-bot situs tidak terlalu agresif. Dan untuk tugas di mana situs secara aktif memeriksa jaringan seluler (misalnya, parsing versi mobile aplikasi melalui API), digunakan proxy seluler — mereka memberikan tingkat kepercayaan tambahan berdasarkan reputasi jaringan operator.

Checklist pengaturan parser tanpa deteksi

Kumpulkan pemeriksaan dalam satu proses sebelum menjalankan parser di produksi:

  1. Ukur hash JA4 skrip Anda melalui tls.peet.ws dan bandingkan dengan browser nyata dari versi yang sama.
  2. Gunakan pustaka yang mendukung impersonasi TLS: curl_cffi (Python), tls-client (Go), CycleTLS (Node.js).
  3. Sinkronkan versi profil TLS (impersonate) dengan versi di User-Agent.
  4. Periksa urutan header HTTP — harus cocok dengan browser nyata, bukan urutan alfabetis.
  5. Hubungkan IP residensial atau seluler yang bersih sesuai dengan geo tugas Anda.
  6. Atur rotasi IP terpisah dari profil TLS — jangan mengikat satu sama lain secara ketat.
  7. Secara teratur perbarui profil TLS saat versi baru Chrome dirilis — tanda tangan lama lebih cepat masuk ke basis data anti-bot daripada yang terlihat.
  8. Untuk skenario dengan pemeriksaan JS (Cloudflare Challenge), gunakan browser headless dengan patch stealth daripada klien HTTP yang bersih.

Perbandingan pustaka dan alat

Alat Jejak TLS browser Kecepatan Kapan digunakan
requests / httpx Tidak, menghasilkan skrip Tinggi Situs tanpa deteksi TLS, API internal
curl_cffi Ya, salinan yang tepat Tinggi Marketplace, anti-bot Cloudflare/Akamai
tls-client (Go) Ya Sangat tinggi Beban tinggi, parsing massal
Playwright / Puppeteer Ya, mesin nyata Rendah JS-render, Cloudflare Challenge, SPA kompleks
Scrapy (standar) Tidak Tinggi Situs tanpa perlindungan anti-bot yang ketat

Kesimpulan

Jejak TLS adalah lapisan perlindungan yang diabaikan oleh banyak parser, menghabiskan sumber daya untuk mencari IP dan User-Agent yang sempurna, tetapi melupakan bahwa struktur handshake TLS itu sendiri mengungkapkan otomatisasi sebelum server melihat header. Solusinya adalah menggunakan pustaka yang mendukung impersonasi TLS (curl_cffi, tls-client), menyinkronkan versi profil dengan User-Agent, dan memeriksa hash JA4 akhir sebelum menjalankan pada skala.

IP tetap menjadi faktor penting — tanpa alamat bersih, bahkan jejak TLS yang sempurna tidak akan membantu menghindari pemblokiran berdasarkan reputasi jaringan. Untuk parsing marketplace dan pemantauan harga, bijaksana untuk menggabungkan pengaturan TLS yang benar dengan proxy residensial — kombinasi ini menutup kedua lapisan deteksi dan secara signifikan mengurangi persentase pemblokiran selama sesi parsing yang panjang.