นักพัฒนาที่ใช้ Playwright สำหรับการทำ web-scraping กำลังพบว่าคำขอแรกของพวกเขาถูกปฏิเสธ ทั้งที่สคริปต์ได้เปิดใช้งาน Chromium แบบเต็มรูปแบบ ตั้งค่า User-Agent ที่แท้จริง และใส่การหน่วงเวลาที่เหมือนมนุษย์แล้ว แต่เซิร์ฟเวอร์กลับบล็อกคำขอในระหว่างขั้นตอน TLS handshake ซึ่งเป็นเทคนิคที่เรียกว่า TLS fingerprinting

อธิบายเรื่อง TLS fingerprinting

เมื่อเบราว์เซอร์เปิดการเชื่อมต่อ HTTPS จะมีการส่งข้อความ ClientHello ไปยังเซิร์ฟเวอร์ โดยแพ็กเกจนี้จะระบุเวอร์ชันของ TLS, cipher suites ที่รองรับ, ชุดของ extensions (เช่น elliptic curves, signature algorithms) และฟิลด์อื่นๆ อีกจำนวนหนึ่ง ซึ่งการผสมผสานที่แน่นอนนี้จะระบุเอกลักษณ์ของ networking stack ได้อย่างเฉพาะเจาะจง

นักวิจัยจะนำฟิลด์ดิบเหล่านี้มาทำ hash ให้กลายเป็นตัวระบุที่กระชับซึ่งเรียกว่า JA3 (หรือเวอร์ชันใหม่กว่าอย่าง JA4) เบราว์เซอร์ Chrome ของจริงจะสร้าง hash หนึ่งแบบ ในขณะที่ไลบรารี HTTP ของ Python จะสร้างอีกแบบหนึ่ง หาก hash ของเซิร์ฟเวอร์ไม่ตรงกับ User-Agent ที่อ้างไว้ เซิร์ฟเวอร์จะระบุว่าคำขอนั้นมาจากสคริปต์

ทำไมเบราว์เซอร์ Playwright แบบมาตรฐานถึงยังถูกตรวจจับได้

โดยปกติแล้ว Chromium build เริ่มต้นของ Playwright จะส่งค่า Chrome fingerprint ที่ถูกต้อง แต่ผู้ทำ scraping หลายรายมักเพิ่มขั้นตอนที่ทำให้ความสอดคล้องเสียไป:

  1. กลยุทธ์การส่งคำขอแบบผสม (Mixed request strategies) – นักพัฒนามักปล่อยให้ Playwright เรนเดอร์หน้าเว็บที่มีความซับซ้อน ในขณะที่ใช้ HTTP client ที่มีน้ำหนักเบาในการดึงทรัพยากรเสริม (เช่น JSON, รูปภาพ และอื่นๆ) การเรียกข้อมูลที่รวดเร็วเหล่านี้จะพกพา fingerprint ของไลบรารีมาด้วย ไม่ใช่ของ Chrome และเซิร์ฟเวอร์จะตรวจพบความไม่สอดคล้องกันได้ทันที
  2. TLS-terminating proxies – บริการ proxy บางแห่งจะถอดรหัส TLS stream เพื่อตรวจสอบหรือแก้ไขทราฟฟิก จากนั้นจึงเข้ารหัสใหม่ ซึ่งท้ายที่สุดแล้วเซิร์ฟเวอร์จะเห็น fingerprint ของ proxy และอาจบล็อกเนื่องจากมองว่าเป็น client ที่ไม่ใช่เบราว์เซอร์
  3. เลเยอร์โปรโตคอลอื่นๆ – ระบบป้องกันการ scraping ยังมีการเปรียบเทียบการตั้งค่า HTTP/2, ลำดับของ header และชื่อเสียงของ IP (IP reputation) ความคลาดเคลื่อนในเลเยอร์ใดก็ตามสามารถกระตุ้นให้เกิดการบล็อกได้

จาก JA3 สู่ JA4: การแข่งขันทางเทคโนโลยี

JA3 เป็น TLS fingerprint แรกที่ได้รับการยอมรับอย่างแพร่หลาย แต่ปัจจุบัน Chrome ได้ทำการสุ่มลำดับของ extensions ในการเปิดใช้งานแต่ละครั้ง ทำให้ค่า JA3 hash ไม่เสถียรสำหรับเบราว์เซอร์จริง JA4 จึงเข้ามาแก้ปัญหานี้ด้วยการจัดเรียงรายการ extensions ก่อนที่จะทำ hash ทำให้ได้ตัวระบุที่เสถียรแม้ว่า Chrome จะสลับลำดับก็ตาม เครื่องมือตรวจจับที่นำ JA4 มาใช้จะสามารถแยกแยะระหว่าง Chrome instance ของจริง กับ client ที่ใช้สคริปต์ซึ่งเพียงแค่คัดลอกค่า JA3 hash แบบคงที่มาใช้ได้อย่างแม่นยำ

สิ่งที่นักพัฒนาสามารถทำได้ในปัจจุบัน

ไม่มี "magic string" ใดที่จะหลอกเซิร์ฟเวอร์ได้ตลอดกาล วิธีที่เชื่อถือได้คือการทำให้ ทุก เลเยอร์ของคำขอเล่าเรื่องราวเดียวกัน:

  • ปรับ User-Agent, TLS handshake, HTTP/2 settings และ header order ให้สอดคล้องกับเวอร์ชันของเบราว์เซอร์และ OS เดียวกัน
  • เลิกใช้เครื่องมือ browser automation แบบเต็มรูปแบบผสมกับ HTTP client แยกต่างหาก หากความเร็วเป็นเรื่องสำคัญ ให้ใช้ Playwright จัดการการเรียกเครือข่ายทั้งหมด แม้จะเป็นการเรียกข้อมูลเล็กๆ น้อยๆ ก็ตาม
  • เลือก proxy ที่สามารถ pass TLS through โดยไม่ตัดการเชื่อมต่อ (terminate) หรือกำหนดค่าให้ส่งต่อ TLS handshake ต้นฉบับโดยไม่มีการเปลี่ยนแปลง
  • ตรวจสอบบริการ IP-reputation; การมีกลุ่ม IP ที่สะอาดจะช่วยลดโอกาสในการถูกบล็อกจากการใช้งานที่ผิดกฎหมายในอดีต

ต้นทุนของการละเลยความสอดคล้องของ fingerprint

เมื่อ scraper ถูกบล็อกในขั้นตอน handshake มันจะไม่สามารถเข้าถึง logic ของหน้าเว็บได้เลย ทำให้ไม่มีการเก็บข้อมูลและไม่ต้องเสียเวลาในการรัน JavaScript องค์กรที่พึ่งพาการเก็บข้อมูลขนาดใหญ่จะพบว่าต้นทุน cloud-compute สูงขึ้นเนื่องจากการวนลูปลองใหม่ (retry loops) การถูกบล็อกซ้ำๆ ยังอาจนำไปสู่การแบน IP ซึ่งส่งผลกระทบต่อทราฟฟิกที่ถูกต้องอื่นๆ จากเครือข่ายเดียวกันด้วย

มุมมองต่าง: ทำไมเว็บไซต์ต่างๆ ถึงใช้ TLS fingerprinting

เจ้าของเว็บไซต์มองว่า TLS fingerprinting เป็นการป้องกันที่ชอบธรรม การทำ automated scraping สามารถทำให้เซิร์ฟเวอร์ทำงานหนักเกินไป ข้าม paywalls หรือเก็บข้อมูลส่วนบุคคลในวงกว้าง การตรวจสอบว่า TLS fingerprint ตรงกับเบราว์เซอร์ที่อ้างไว้หรือไม่ ช่วยให้เว็บไซต์สามารถคัดกรองบอทที่ทำงานแบบง่ายๆ ออกไปได้จำนวนมากโดยไม่กระทบต่อผู้ใช้งานจริง เทคนิคนี้รบกวนผู้ใช้น้อยกว่า CAPTCHAs และช่วยรักษาประสบการณ์การใช้งานที่ดีไว้ได้

สิ่งที่ควรจับตามองต่อไป

  • การนำ JA4 มาใช้ – คาดว่าผู้ให้บริการด้านความปลอดภัยและ CDN จะเริ่มนำการตรวจจับที่ใช้ JA4 มาใช้มากขึ้นในอีกไม่กี่เดือนข้างหน้า
  • การสุ่มในระดับเบราว์เซอร์ – Chrome และเบราว์เซอร์อื่นๆ อาจมีการเปลี่ยนแปลงพารามิเตอร์ TLS อย่างต่อเนื่อง ซึ่งจะผลักดันให้เครื่องมือ fingerprinting ต้องหันไปใช้สัญญาณที่ซับซ้อนมากขึ้น เช่น จังหวะเวลาของทราฟฟิก (traffic timing) หรือรูปแบบการรัน JavaScript
  • การตอบสนองของตลาด Proxy – มีแนวโน้มที่จะเกิดบริการที่สัญญาว่าจะให้การกำหนดเส้นทางแบบ “TLS-transparent” เพื่อตอบสนองความต้องการของชุมชนการทำ scraping ที่ต้องการให้ handshake ไม่มีการเปลี่ยนแปลง

บทสรุป

หาก Playwright scraper ของคุณถูกปฏิเสธก่อนที่หน้าเว็บจะโหลดขึ้นมา สาเหตุเกือบจะแน่นอนว่าเกิดจากความไม่สอดคล้องกันของ TLS fingerprint การแก้ไขไม่ใช่เพียงการแก้ปัญหาเฉพาะหน้าแบบชั่วคราว แต่ต้องอาศัยการปรับจูนทุกเลเยอร์ของโปรโตคอลให้สอดคล้องกับโปรไฟล์เบราว์เซอร์ที่ระบุไว้อย่างเป็นระบบ ความสอดคล้องกันทั้งในส่วนของ User-Agent, TLS handshake, การตั้งค่า HTTP/2, ลำดับของ header และพฤติกรรมของ proxy คือวิธีเดียวที่เชื่อถือได้ในการหลบเลี่ยงการตรวจจับของระบบป้องกันการสแครปข้อมูล (anti-scraping) สมัยใหม่