ระบบอัตโนมัติผ่านเบราว์เซอร์ในระดับใหญ่โดยไม่ถูกบล็อก

คู่มือ Playwright และ Puppeteer มีมากมาย ครอบคลุมการติดตั้ง กำหนดตัวเลือกองค์ประกอบ จัดการงานอะซิงโครนัสและถ่ายภาพหน้าจอ แต่ส่วนใหญ่ไม่กล่าวถึงสิ่งที่เกิดขึ้นเมื่อใช้ระบบอัตโนมัติกับเว็บไซต์จริงที่พยายามป้องกันการเข้าถึงเช่นนี้ หรือสิ่งที่ต้องทำให้ระบบทำงานต่อเนื่องได้หลายสัปดาห์หรือหลายเดือน ไม่ใช่แค่ต้นแบบพิสูจน์แนวคิดในบ่ายเดียว

บทความนี้กล่าวถึงช่องว่างระหว่างสคริปต์ที่ทำงานได้กับระบบที่ดำเนินงานได้จริง โดยรวบรวมบทเรียนจากการใช้ระบบอัตโนมัติผ่านเบราว์เซอร์ในการใช้งานจริง แทนการสอนขั้นตอนที่มีในเอกสารแล้ว

เมื่อใดควรใช้ระบบอัตโนมัติผ่านเบราว์เซอร์

ก่อนใช้ Playwright ควรตรวจว่ามี API หรือไม่ บ่อยครั้งมีและเหมาะกว่า เพราะเร็วกว่า ถูกกว่าในการดูแล เชื่อถือได้กว่า และมีความคลุมเครือทางกฎหมายน้อยกว่าการดึงข้อมูลจากส่วนแสดงผล

กรณีที่ต้องใช้ระบบอัตโนมัติผ่านเบราว์เซอร์มีน้อยกว่าที่มักกล่าวกัน เช่น ระบบไม่มี API สาธารณะและไม่มีแผนสร้าง มี API แต่ขีดจำกัดอัตราหรือต้นทุนไม่รองรับปริมาณที่ต้องการ ข้อมูลอยู่หลังเซสชันที่ยืนยันตัวตนบน SaaS ที่ส่งออกได้จำกัด ระบบเก่าที่ไม่ได้ออกแบบให้โปรแกรมเข้าถึง หรือการทดสอบการเชื่อมต่อที่ต้องใช้พฤติกรรมเบราว์เซอร์จริงแทนจำลองคำขอ HTTP

กรณีที่พบบ่อยที่สุดคือข้อมูลมีในหน้าจอเบราว์เซอร์ ไม่มีวิธีอื่นเข้าถึง และต้นทุนจากการไม่มีข้อมูลสูงกว่าภาระดูแลระบบอัตโนมัติ นี่คือเกณฑ์ที่ควรใช้ หากมี API ที่เหมาะสมก็ควรใช้ ระบบอัตโนมัติผ่านเบราว์เซอร์เหมาะเมื่อไม่มีทางเลือกอื่น

ระบบตรวจจับทำงานอย่างไร

ระบบตรวจจับบอตสมัยใหม่ทำงานหลายชั้นพร้อมกัน จึงไม่น่าแปลกที่มาตรการรับมือเพียงชั้นเดียวมักล้มเหลว

ในชั้นเครือข่าย การตรวจลักษณะเฉพาะของ TLS ระบุระบบอัตโนมัติจากข้อความ ClientHello ทั้งลำดับ cipher suite ส่วนขยายและ elliptic curve ที่ไคลเอนต์ส่ง ผู้ให้บริการ CDN รายใหญ่ใช้ลักษณะเฉพาะ JA3 และ JA4 ในระบบจริงมาหลายปี เบราว์เซอร์จริงที่ควบคุมด้วย Playwright ส่ง ClientHello ของเบราว์เซอร์นั้นเอง ชั้น TLS จึงตรวจพบความไม่สอดคล้องเป็นหลัก เช่น ลักษณะเฉพาะที่ไม่ตรงกับเบราว์เซอร์และเวอร์ชันที่ user agent ระบุ หรือคำขอที่ส่งจากไคลเอนต์ HTTP ที่ไม่ใช่เบราว์เซอร์ควบคู่กับคำขอจากเบราว์เซอร์

ในชั้น HTTP ลำดับและค่าของส่วนหัวต่างจากเบราว์เซอร์ปกติเล็กน้อย Chrome ส่งส่วนหัวตามลำดับเฉพาะที่ระบบอัตโนมัติมักเลียนแบบได้ไม่ครบ ส่วนหัว Accept-Language, Accept-Encoding และ Sec-Fetch-* ส่งสัญญาณที่เมื่อรวมกันแล้วแยกแยะได้

ในชั้น JavaScript navigator.webdriver เป็นร่องรอยชัดเจน เพราะ Chromium ตั้งค่านี้เมื่อถูกโปรแกรมควบคุม แต่ยังมีจำนวนเธรดฮาร์ดแวร์ ปลั๊กอิน ขนาดหน้าจอและ API ที่มีหรือไม่มีซึ่งประกอบเป็นลักษณะเฉพาะ Canvas และ WebGL ให้ผลการวาดคงที่ตามฮาร์ดแวร์ กลุ่มเบราว์เซอร์ที่ใช้ฮาร์ดแวร์เสมือนเหมือนกันจึงให้ผลเหมือนกัน ซึ่งเป็นอีกสัญญาณหนึ่ง

การวิเคราะห์พฤติกรรมตรวจระดับที่สูงขึ้น ทั้งเวลาระหว่างโหลดหน้ากับโต้ตอบครั้งแรก เส้นทางเมาส์ การเลื่อนและจังหวะพิมพ์ มนุษย์มีความสม่ำเสมอภายในความแปรผันตามธรรมชาติ ส่วนระบบอัตโนมัติสม่ำเสมอในลักษณะที่ต่างออกไป ความแตกต่างนี้ตรวจพบได้ทางสถิติ

บริการตรวจจับเชิงพาณิชย์รวมสัญญาณทุกชั้นและใช้โมเดลที่ฝึกจากทราฟฟิกมนุษย์และบอตจำนวนมาก การผ่านสัญญาณหนึ่งแต่ไม่ผ่านที่เหลือจึงไม่ช่วย

โปรไฟล์ถาวร: การเปลี่ยนแปลงที่สำคัญที่สุด

ความผิดพลาดช่วงแรกคือถือว่าบริบทเบราว์เซอร์ใช้แล้วทิ้งได้ บริบทใหม่แต่ละครั้งดูเหมือนการเยี่ยมชมแรกจากเครื่องใหม่ ไม่มีประวัติ คุกกี้หรือลักษณะเฉพาะที่ระบบรู้จัก โปรไฟล์ใหม่ถูกตรวจเข้มกว่าโดยค่าเริ่มต้น การเริ่มจากศูนย์ทุกครั้งจึงเริ่มจากการถูกตรวจเข้มทุกครั้ง

วิธีแก้คือเก็บโปรไฟล์เบราว์เซอร์ถาวรผ่านไดเรกทอรีข้อมูลผู้ใช้ของ Chrome แทนเปิดบริบทแยกใหม่ในทุกเซสชัน ให้เก็บสถานะทั้งหมด ทั้งคุกกี้ localStorage, IndexedDB ใบรับรองในแคชและประวัติการท่องเว็บ จึงดูเป็นผู้ใช้เดิมแทนการติดตั้งใหม่

การสร้างประวัติการใช้งานให้โปรไฟล์มีผลมากกว่าการเก็บถาวร โปรไฟล์ที่เข้าเฉพาะเว็บเป้าหมายตามลำดับสมบูรณ์แบบและไม่ทำอย่างอื่นยังดูผิดธรรมชาติ โปรไฟล์จริงมีประวัติหลากหลาย ข้อมูลรับรองหลายบริการ ทรัพยากรจากหลายโดเมนและสถานะที่สะสมจากการใช้งานหลายเดือน การสร้างประวัติเช่นนี้แม้บางส่วนทำให้รูปแบบทางสถิติใกล้ผู้ใช้ปกติมากขึ้น

ในทางปฏิบัติควรดูแลโปรไฟล์เป็นทรัพยากรถาวร สร้างและสะสมประวัติด้วยกิจกรรมหลากหลายก่อนมอบหมายงานเฉพาะ เมื่อโปรไฟล์เจอหน้าตรวจสอบหรือถูกทำเครื่องหมาย ให้เลิกใช้แทนลองใหม่ทันที การดูแลชุดโปรไฟล์พร้อมสถานะและประวัติกลายเป็นงานโครงสร้างพื้นฐานอีกส่วน

Patchright และเครื่องมือรุ่นแยกสำหรับหลีกเลี่ยงการตรวจจับ

Playwright มาตรฐานทิ้งร่องรอยระบบอัตโนมัติที่ระบบตรวจจับบอตเจาะตรวจ ตั้งแต่ค่าธงตอนเปิดโปรแกรมอย่าง --enable-automation ไปจนถึงผลข้างเคียงของคำสั่ง CDP เช่น Runtime.enable ปลั๊กอินพรางตัวระดับ JavaScript พยายามแก้ navigator.webdriver เปลี่ยน navigator.plugins และปลอมลักษณะเฉพาะ canvas ขณะรัน แต่ร่องรอยที่ปิดบังยังตรวจได้จากเวลา ความไม่สอดคล้องของพร็อพเพอร์ตีและการตรวจระดับต่ำกว่า JavaScript คุณซ่อนค่าธงได้ แต่ซ่อนการที่มีบางอย่างกำลังปิดบังไม่ได้

Patchright ใช้อีกแนวทาง โดยแก้ไดรเวอร์ Playwright เอง ทั้งหลีกเลี่ยง Runtime.enable ปิดโดเมน Console และเปลี่ยนค่าธงเริ่มต้นตอนเปิดโปรแกรม เพื่อลบร่องรอยเหล่านี้ที่ต้นทางแทนปิดบังภายหลัง ความต่างนี้มีผลจริง: ไม่มีการแก้ไขระดับ JavaScript ให้ระบบตรวจจับค้นพบ แต่ Patchright ไม่ได้พ้นจากการตรวจจับ ผู้ดูแลโครงการเองระบุว่าการแทรกสคริปต์เริ่มต้นของมันยังตรวจพบได้ด้วยการโจมตีโดยวิเคราะห์เวลา

ระบบนิเวศ playwright-extra พร้อมปลั๊กอินพรางตัวเป็นทางเลือกระดับ JavaScript ที่ดูแลง่ายกว่า ใช้กับเครื่องมือ Playwright มาตรฐานได้และตั้งค่าได้รวดเร็ว มักพอสำหรับเป้าหมายที่ตรวจจับซับซ้อนปานกลาง ส่วนระบบตรวจจับระดับองค์กรหรือระบบป้องกันบอตเฉพาะที่ตรวจระดับต่ำกว่า JavaScript การแก้ระดับไดรเวอร์เชื่อถือได้กว่า

ทั้งสองวิธีไม่ใช่คำตอบถาวร ระบบตรวจจับพัฒนาตามเครื่องมือที่พบ สิ่งที่ผ่านได้วันนี้อาจกลายเป็นลักษณะเฉพาะในข้อมูลฝึกภายในไม่กี่เดือน ภาระดูแลเครื่องมือหลีกเลี่ยงการตรวจจับจึงต่อเนื่อง ไม่ใช่ตั้งค่าครั้งเดียว

พฤติกรรมเหมือนมนุษย์ไม่ได้เกิดจากการสุ่มอย่างเดียว

ข้อผิดพลาดที่พบบ่อยคือคิดว่า “เหมือนมนุษย์” หมายถึง “เพิ่มเวลารอแบบสุ่ม” การสุ่มช่วงเวลาจากการแจกแจงสม่ำเสมอแยกจากมนุษย์ได้ง่าย เพราะพฤติกรรมมนุษย์มีโครงสร้าง จังหวะและรูปแบบความแปรผันตามข้อจำกัดด้านการคิดและร่างกาย

การขยับเมาส์เป็นตัวอย่างชัด มนุษย์ไม่ได้เคลื่อนเป็นเส้นตรงจากจุดปัจจุบันไปเป้าหมาย แต่มีเส้นทางตามโมเมนตัม ขนาดเป้าหมายและการปรับใกล้ปลายทาง การประมาณด้วยเส้นโค้ง Bezier ใกล้เคียงกว่าเส้นตรงหรือการสั่นสุ่ม รูปแบบความเร็วก็สำคัญ ทั้งเร่งเข้าหาเป้าหมาย ชะลอและปรับเล็กน้อยเมื่อถึง นี่คือคุณลักษณะที่ระบบตรวจจับวัด

การพิมพ์มีหลักคล้ายกัน ความเร็วต่างตามความคุ้นเคยกับคำ คู่ตัวอักษรที่ขยับนิ้วยากและการหยุดคิดระหว่างคำ การเว้น 80ms เท่ากันทุกแป้นไม่สะท้อนการกระจายนี้ การจำลองเวลาหน่วงตามคู่ตัวอักษรและผังแป้นพิมพ์ให้ความแปรผันสมจริงกว่าค่าคงที่หรือการสุ่มสม่ำเสมอ

เวลาที่อ่านหน้าก่อนโต้ตอบสัมพันธ์กับความซับซ้อนของเนื้อหา หน้ายาวที่ถูกคลิกหลังโหลดเพียง 300ms เป็นสัญญาณ การกำหนดเวลารอตามความยาวเนื้อหาที่แสดงแทนสุ่มล้วนใกล้พฤติกรรมอ่านจริงกว่า

เป้าหมายคือให้แยกจากการกระจายพฤติกรรมมนุษย์ที่โมเดลเรียนรู้ไม่ได้ในเชิงสถิติ ไม่ใช่เลียนแบบมนุษย์ได้สมบูรณ์ทุกด้าน การเข้าใจว่าโมเดลฝึกให้ตรวจอะไรมีประโยชน์กว่าจำลองพฤติกรรมทุกอย่าง

จัดการเซสชันระหว่างรอบการทำงาน

ระบบอัตโนมัติจริงทำงานต่อเนื่องหลายรอบ เซสชันหมดอายุ การเข้าสู่ระบบหมดเวลา ขีดจำกัดอัตราสะสม และสถานะเปลี่ยนระหว่างรอบ วิธีจัดการกำหนดว่าระบบจะลดความสามารถอย่างเหมาะสมหรือล้มเหลวเงียบ ๆ

คำถามคือใช้เซสชันยาวที่ยืนยันตัวตนครั้งเดียวแล้วต่ออายุตามจำเป็น หรือเซสชันสั้นที่ยืนยันใหม่ทุกรอบ เซสชันยาวลดความถี่เข้าสู่ระบบ ซึ่งบางระบบมองความถี่สูงเป็นสัญญาณบอต ส่วนเซสชันสั้นดูแลง่ายกว่าแต่เพิ่มเหตุการณ์เข้าสู่ระบบ คำตอบขึ้นกับสิ่งที่เป้าหมายตรวจและรูปแบบการดำเนินงานที่ดูแลไหว

การเก็บสถานะระหว่างรอบไม่ใช่แค่บันทึกคุกกี้หลัก พื้นที่เก็บของเบราว์เซอร์ การตอบกลับในแคชและโทเคนข้ามโดเมนล้วนเป็นส่วนของโปรไฟล์ การบันทึกและกู้สถานะครบช่วยรักษาความสม่ำเสมอ โปรไฟล์ที่สูญเสียสถานะแล้วสร้างใหม่ทุกครั้งจะไม่รักษาประวัติที่สะสมไว้

ต้องยืนยันตัวตนใหม่โดยไม่เพิ่มการตรวจเข้ม การพยายามเข้าสู่ระบบติดกันบ่อยจากโปรไฟล์เดียวถูกทำเครื่องหมายได้ ควรเว้นระยะตามธรรมชาติและถือว่าการยืนยันล้มเหลวเป็นสัญญาณให้พักแทนลองทันที เพื่อลดสัญญาณตรวจจับในขั้นเข้าสู่ระบบ

ปัญหาเมื่อใช้งานจริงที่คู่มือมักไม่กล่าวถึง

ชื่อเสียงของ IP อาจทำให้ระบบที่แก้ปัญหาชั้นอื่นหมดแล้วยังถูกตรวจพบ ช่วง IP ศูนย์ข้อมูลมีชื่อเสียงไม่ดีในมุมมองของผู้ให้บริการตรวจบอตส่วนใหญ่ และมักถูกขอให้ผ่านการตรวจสอบเพิ่มเติมหรือถูกบล็อกโดยตรง ระบบจึงอาจใช้ได้ในเครื่องแต่ล้มเหลวเงียบเมื่อใช้งานจริง เพราะทราฟฟิกมาจากช่วง IP ที่ถูกทำเครื่องหมายมาหลายปี นี่ไม่ใช่กรณีหายาก แต่เป็นผลที่มักพบกับโครงสร้างพื้นฐานคลาวด์มาตรฐาน

พร็อกซีที่ใช้ IP ที่พักอาศัยช่วยแก้เรื่องชื่อเสียง แต่เพิ่มเรื่องความน่าเชื่อถือ ตำแหน่งภูมิศาสตร์ที่สม่ำเสมอ การคง IP ตลอดเซสชันและต้นทุน โครงสร้างพื้นฐานพร็อกซีจึงต้องได้รับการดูแลตามระดับที่ระบบอัตโนมัติพึ่งพา

ความล้มเหลวเงียบอันตรายกว่าการบล็อกชัดเจน หน้าตรวจสอบที่คืน HTTP 200 หรือหน้าเว็บที่โหลดได้แต่แสดงเนื้อหาตรวจบอตแทนข้อมูลจริงไม่กระตุ้นตัวจัดการข้อผิดพลาด ต้องเฝ้าติดตามโดยตรวจเนื้อหาข้อมูล ไม่ใช่เพียงคำขอจบ สคริปต์ที่บันทึกว่าสำเร็จแต่คืนผลว่างพบได้บ่อยและอันตราย

บางระบบบล็อกแบบลดทอนข้อมูลแทนปฏิเสธตรง ๆ โดยคืนผลน้อยลง ฟิลด์หายหรือข้อมูลผิดเล็กน้อย ตรวจยากกว่าการบล็อกชัดเพราะทุกอย่างดูทำงานได้ การตรวจรูปทรงข้อมูลที่คาดไว้แทนตรวจเพียงรหัส HTTP สำเร็จช่วยจับปัญหานี้

การแข่งขันระหว่างระบบอัตโนมัติกับการตรวจจับเป็นความจริงในการดำเนินงาน ค่าที่ใช้ได้หลายเดือนอาจเสียเมื่อผู้ให้บริการอัปเดตโมเดล ซึ่งเกิดบ่อย การเฝ้าติดตาม แจ้งเมื่อคุณภาพการดึงข้อมูลลดลง และประเมินวิธีหลีกเลี่ยงการตรวจจับใหม่เป็นระยะคือการบำรุงรักษาที่ระบบจริงต้องมี

ประเมินความคุ้มค่าอย่างตรงไปตรงมา

ระบบอัตโนมัติผ่านเบราว์เซอร์ในการใช้งานจริงเป็นงานวิศวกรรมที่มีความซับซ้อนจริง ช่องว่างจากต้นแบบสู่ระบบระยะยาวครอบคลุมโครงสร้างพื้นฐาน IP ลักษณะเฉพาะเบราว์เซอร์ แบบจำลองพฤติกรรม เซสชันและการดูแลเมื่อระบบตรวจจับเปลี่ยน ทีมที่ประเมินต่ำมักเรียนรู้จากระบบล้มเหลวแทนวางแผน

เหตุผลที่ทำแล้วคุ้มคือข้อมูลเข้าถึงทางอื่นไม่ได้และมีมูลค่าสูงพอรับภาระดูแล ต้องคำนวณเป็นรายกรณี ความซับซ้อนที่อธิบายนี้ค่อนข้างคงที่ไม่ว่าดึงอะไร คำถามจึงเป็นว่าข้อมูลที่ดึงคุ้มกับภาระนั้นหรือไม่

สำหรับทีมที่สร้างระบบประเภทนี้ หรือกำลังตัดสินใจเรื่องเบราว์เซอร์ headless พร็อกซีและการเก็บสถานะเซสชัน บริการให้คำปรึกษาด้านเทคนิคของ tva ครอบคลุมประเด็นเหล่านี้จากประสบการณ์ใช้งานจริง มีคำถามเรื่องโครงสร้างพื้นฐานเบราว์เซอร์อัตโนมัติหรือปัญหาในการพัฒนาระบบ? ติดต่อผ่าน tva.sg/contact