Pembangun yang menggunakan Playwright untuk pengikisan web (web-scraping) mendapati permintaan pertama mereka ditolak walaupun skrip melancarkan instans Chromium yang lengkap, menetapkan User-Agent yang tulen dan memasukkan lengah masa seperti manusia. Pelayan menyekat permintaan tersebut semasa jabat tangan (handshake) TLS, satu teknik yang dipanggil cap jari TLS (TLS fingerprinting).

Penjelasan cap jari TLS

Apabila pelayar membuka sambungan HTTPS, ia menghantar mesej ClientHello. Paket tersebut menyenaraikan versi TLS, suite penyulitan (cipher suites) yang disokong, satu set sambungan (elliptic curves, algoritma tandatangan) dan beberapa medan lain. Gabungan tepat tersebut mengenal pasti timbunan rangkaian (networking stack) secara unik.

Penyelidik melakukan pengisihan (hash) pada medan mentah tersebut menjadi pengenal pasti ringkas yang dipanggil JA3 (atau versi terbaharunya, JA4). Pelayar Chrome yang tulen menghasilkan satu hash; perpustakaan HTTP Python menghasilkan hash yang lain. Jika hash pelayan tidak sepadan dengan User-Agent yang didakwa, ia akan menandakan permintaan tersebut sebagai skrip.

Mengapa pelayar Playwright biasa masih boleh ditandakan

Binaan Chromium lalai Playwright biasanya menghasilkan cap jari Chrome yang betul, tetapi banyak pengikis (scrapers) menambah langkah yang merosakkan konsistensi:

  1. Strategi permintaan bercampur – Pembangun sering membiarkan Playwright memaparkan halaman yang berat sementara klien HTTP ringan mengambil sumber tambahan (JSON, imej, dll.). Panggilan pantas tersebut membawa cap jari perpustakaan, bukan Chrome, dan pelayan akan mengesan ketidakpadanan itu dengan serta-merta.
  2. Proksi penamat TLS (TLS-terminating proxies) – Sesetengah perkhidmatan proksi menyahsulit aliran TLS, memeriksa atau mengubah suai trafik, kemudian menyulitkannya semula. Pelayan akhirnya melihat cap jari proksi tersebut dan mungkin menyekatnya sebagai klien bukan pelayar.
  3. Lapisan protokol lain – Sistem anti-pengikisan juga membandingkan tetapan HTTP/2, urutan pengepala (header), dan reputasi IP. Sebarang percanggahan dalam mana-mana lapisan boleh mencetuskan sekatan.

Daripada JA3 ke JA4: perlumbaan senjata

JA3 adalah cap jari TLS pertama yang diterima pakai secara meluas. Chrome kini merawakkan urutan sambungannya pada setiap pelancaran, menjadikan hash JA3 tidak stabil untuk pelayar sebenar. JA4 menyelesaikan masalah ini dengan menyusun senarai sambungan sebelum melakukan pengisihan, menghasilkan pengenal pasti yang stabil walaupun Chrome mengacak urutannya. Alat pengesanan yang menggunakan JA4 boleh membezakan instans Chrome sebenar daripada klien skrip yang sekadar menyalin hash JA3 statik.

Apa yang boleh dilakukan oleh pembangun hari ini

Tiada "rentetan ajaib" (magic string) yang boleh memperdaya pelayan selama-lamanya. Pendekatan yang boleh dipercayai adalah dengan memastikan setiap lapisan permintaan menceritakan perkara yang sama:

  • Selaraskan User-Agent, jabat tangan TLS, tetapan HTTP/2, dan urutan pengepala dengan versi pelayar dan OS yang sama.
  • Berhenti mencampurkan alat automasi pelayar penuh dengan klien HTTP berasingan. Jika kelajuan penting, biarkan Playwright mengendalikan semua panggilan rangkaian, walaupun yang remeh.
  • Pilih proksi yang menyalurkan TLS (pass TLS through) tanpa menamatkan sambungan, atau konfigurasikan mereka untuk memajukan jabat tangan TLS asal tanpa perubahan.
  • Pantau perkhidmatan reputasi IP; kumpulan IP yang bersih mengurangkan kemungkinan sekatan berdasarkan penyalahgunaan sejarah.

Kos mengabaikan konsistensi cap jari

Apabila pengikis disekat pada peringkat jabat tangan, ia tidak akan sampai ke logik halaman, jadi tiada data yang dituai dan tiada masa yang dihabiskan untuk melaksanakan JavaScript. Perusahaan yang bergantung pada pengumpulan data skala besar akan melihat kos pengkomputeran awan meningkat apabila gelung cubaan semula (retry loops) bermula. Sekatan berulang juga boleh menyebabkan sekatan IP yang menjejaskan trafik sah lain dari rangkaian yang sama.

Hujah balas: mengapa laman web menggunakan cap jari TLS

Pemilik laman web melihat cap jari TLS sebagai pertahanan yang sah. Pengikisan automatik boleh membebankan pelayan, memintas dinding berbayar (paywalls), atau menuai data peribadi secara besar-besaran. Dengan menyemak sama ada cap jari TLS sepadan dengan pelayar yang didakwa, sesebuah laman web menapis sebahagian besar bot tahap rendah tanpa menjejaskan pengguna sebenar. Teknik ini kurang mengganggu berbanding CAPTCHA, sekali gus mengekalkan pengalaman pengguna.

Apa yang perlu diperhatikan seterusnya

  • Penerapan JA4 – Jangkakan lebih banyak vendor keselamatan dan penyedia CDN untuk melancarkan pengesanan berasaskan JA4 dalam bulan-bulan mendatang.
  • Pengrawakan pada tahap pelayar – Chrome dan pelayar lain mungkin akan terus mempelbagaikan parameter TLS, mendorong alat cap jari ke arah isyarat yang lebih kompleks seperti pemasaan trafik atau corak pelaksanaan JavaScript.
  • Respons pasaran proksi – Perkhidmatan yang menjanjikan penghalaan "telus TLS" (TLS-transparent) berkemungkinan akan muncul, memenuhi keperluan komuniti pengikisan untuk jabat tangan yang tidak berubah.

Kesimpulan

Jika scraper Playwright anda ditolak sebelum sebarang halaman dimuatkan, puncanya hampir pasti adalah ketidakpadanan dalam TLS fingerprint. Penyelesaiannya bukanlah sekadar tampalan pantas; ia memerlukan penyelarasan yang berdisiplin bagi setiap lapisan protokol dengan profil pelayar yang dinyatakan. Ketekalan merentasi User-Agent, TLS handshake, tetapan HTTP/2, urutan pengepala dan tingkah laku proksi adalah satu-satunya cara yang boleh dipercayai untuk kekal di bawah radar pertahanan anti-scraping moden.