สคริปต์ scraping ที่ทำงานได้ดีในเครื่องอาจถูกบล็อกหลังจากรันออนไลน์ไประยะหนึ่ง สาเหตุมักมาจากสัญญาณหลายอย่างซ้อนกัน เช่น ความถี่ของ request ลักษณะ request และสภาพแวดล้อมการ render เมื่อระบบ anti-bot พัฒนาอย่างต่อเนื่อง วิธีที่เสถียรกว่าคือเคารพกฎ robots ควบคุมอัตรา request และเก็บเฉพาะข้อมูลสาธารณะ
สคริปต์ scraping ที่ทำงานได้ปกติในเครื่องอาจหยุดทำงานหลังจากนำไปรันออนไลน์สักระยะ ไม่ว่าจะเป็นการได้รับ 403 ถูกส่งไปยังหน้าตรวจสอบ หรือได้ HTML ว่าง ๆ ก็มักมีสาเหตุเดียวกัน คือระบบป้องกันของเว็บไซต์ประเมินว่าการเข้าถึงครั้งนี้ไม่เหมือนพฤติกรรมของผู้ใช้ทั่วไป
ทำไมสคริปต์จึงค่อย ๆ ใช้งานไม่ได้
ระบบ anti-bot ไม่ใช่เทคโนโลยีเดียว แต่เป็นการประเมินหลายชั้นร่วมกัน สัญญาณที่มักเจอก่อนคือความถี่: IP เดิมส่ง request จำนวนมากไปยัง path เดิมในช่วงเวลาสั้น ๆ และมีช่วงห่างสม่ำเสมอเกินไป นี่เป็นรูปแบบที่ตรวจจับได้ง่ายที่สุดแบบหนึ่ง เมื่อถูก trigger เว็บไซต์อาจเริ่มจากการจำกัดความเร็ว และหากรุนแรงก็อาจบล็อก IP โดยตรง
ชั้นถัดมาคือเรื่องตัวตน Request อาจใช้ user agent เริ่มต้นของไลบรารีสคริปต์ ขาด header ที่เบราว์เซอร์ทั่วไปมักส่ง หรืออ้างว่าเป็น Chrome แต่ไม่มี JavaScript execution environment และผลการ render ที่สอดคล้องกัน สิ่งเหล่านี้ล้วนถูกนำไปใช้ประกอบการประเมินได้ เว็บไซต์ที่อยู่หลัง CDN ยังอาจเพิ่ม JavaScript challenge โดยส่งโค้ดที่ต้องรันก่อนจึงจะได้รับเนื้อหาจริง ไลบรารี HTTP แบบธรรมดาไม่สามารถสร้างผลลัพธ์ดังกล่าวได้ จึงหยุดอยู่ที่ด่านนั้น
สัญญาณด้านพฤติกรรมก็เห็นได้ชัด ผู้ใช้จริงจะโหลดรูปและ CSS เลื่อนหน้า และมีช่วงหยุด ส่วนสคริปต์มักดึงเฉพาะ HTML แล้วออกไป เว็บไซต์จะรวมสัญญาณเหล่านี้เป็นคะแนน และแสดง CAPTCHA เมื่อคะแนนต่ำกว่าเกณฑ์
กลไกเหล่านี้ยังพัฒนาต่อไป ทุกครั้งที่ผู้ให้บริการระบบป้องกันเปลี่ยน logic การตรวจจับ สคริปต์ที่พึ่งพาพารามิเตอร์คงที่และจังหวะคงที่ก็ต้องแก้ใหม่ ยิ่งเติมพารามิเตอร์มาก สคริปต์ยิ่งเทอะทะ และยิ่งรักษาพฤติกรรมให้ดูสมจริงได้ยาก สมมติฐานว่าสคริปต์เดียวจะใช้ได้กับทุกเว็บไซต์จึงไม่สมจริงตั้งแต่ต้น
ทำไมการข้ามระบบป้องกันจึงไม่ใช่ทางเลือก
มีบทความออนไลน์จำนวนมากที่อธิบายการข้ามระบบป้องกัน แต่เรื่องนี้ไม่ใช่เพียงตัวเลือกทางเทคนิค เพราะอาจเป็นการละเมิดเงื่อนไขของเว็บไซต์ Terms of service มักห้ามการหลีกเลี่ยงมาตรการความปลอดภัยและข้อจำกัดการเข้าถึงอย่างชัดเจน การทำได้ในทางเทคนิคไม่ได้หมายความว่าถูกต้องตามสัญญาหรือกฎหมาย
ผลกระทบก็เป็นเรื่องจริง การถูกบล็อก account และ IP เป็นผลที่ตรงที่สุด ในหลายเขตอำนาจศาล การได้มาซึ่งข้อมูลโดยข้ามมาตรการทางเทคนิคอาจผิดกฎหมายด้วย ข้อมูลที่ได้จากวิธีผิดปกติยังตรวจสอบที่มาและความครบถ้วนได้ยากขึ้น ทำให้มีความเสี่ยงมากกว่าเมื่อนำไปใช้ตัดสินใจต่อ การเปลี่ยนปัญหาทางเทคนิคให้เป็นปัญหาด้าน compliance จึงไม่คุ้ม
หลักพื้นฐานของการเก็บข้อมูลอย่างสอดคล้อง
เริ่มจากตรวจสอบกฎ robots และเงื่อนไขการใช้งาน robots.txt ระบุว่า path ใดที่เว็บไซต์อนุญาตให้ crawler เข้าถึง นี่ไม่ใช่เพียงคำแนะนำ แต่เป็นเจตนาที่ผู้ดูแลเว็บไซต์แสดงไว้ เงื่อนไขการใช้งานมักมีข้อจำกัดการใช้ข้อมูลที่ละเอียดกว่านี้ด้วย
หากมี official API ให้ใช้ก่อน โครงสร้างข้อมูลชัดเจน มีเอกสารและ quota ระบุไว้ และการปรับ front-end ก็ไม่ทำให้ integration ทั้งหมดพัง หาก quota ไม่พอ ให้ลดแผนการเก็บข้อมูลหรือขอ limit ที่สูงขึ้นผ่านช่องทางธุรกิจ ทั้งสองวิธีเสถียรกว่าการพยายามข้ามข้อจำกัด
ต้องควบคุมความถี่ การที่เว็บไซต์อนุญาตให้ crawl ไม่ได้หมายความว่าอนุญาตให้ใช้ bandwidth เต็มที่ ควรเว้นช่วง จำกัดจำนวน request ต่อหน่วยเวลา และหลีกเลี่ยงช่วงที่เว็บไซต์มีการใช้งานสูง หากทำได้ ปัญหาส่วนใหญ่ก็จะไม่เกิดขึ้นตั้งแต่แรก
เก็บเฉพาะข้อมูลสาธารณะและไม่แตะข้อมูลส่วนบุคคล อย่าเก็บเนื้อหาที่ต้อง login หรือข้อมูลที่เว็บไซต์ระบุชัดว่าห้าม crawl ข้อมูลส่วนบุคคลได้รับการคุ้มครองอย่างเข้มงวดตามกฎหมาย การเก็บข้อมูลประเภทนี้ต้องมีฐานทางกฎหมายที่ชัดเจนและความยินยอมของผู้ใช้เมื่อจำเป็น เรื่องนี้ไม่ใช่ปัญหาทางเทคนิค
ถ้าจำเป็นต้องใช้เนื้อหาหลัง render ควรทำอย่างไร
บางหน้าแสดงเนื้อหาหลังจาก JavaScript ทำงานแล้วเท่านั้น ดังนั้นไลบรารี request อย่างเดียวไม่พอ ในกรณีนี้สามารถใช้ browser automation เปิดหน้าและอ่าน rendered DOM ได้ แต่ยังต้องรักษาขอบเขตสำคัญ ได้แก่ เข้าถึงด้วยจังหวะปกติ ไม่เปิดหลายสิบ instance พร้อมกันเข้าเว็บไซต์เดียว และไม่ใช้ automation หากเว็บไซต์ห้าม automated access อย่างชัดเจน
มีเส้นแบ่งหนึ่งที่สับสนได้ง่าย เครื่องมือแบบ multi-environment มีการใช้งานที่ถูกต้อง เช่น แยกหลายบัญชีที่ใช้งานอย่างถูกกฎหมายออกจากกัน เพื่อให้ทีม login เข้าระบบหลังบ้านของลูกค้าหลายรายพร้อมกันได้ แต่ไม่ควรใช้เพื่อปลอมเป็นผู้ใช้จำนวนมากที่แตกต่างกันแล้ว scrape เว็บไซต์เดียว กรณีแรกคือการจัดการบัญชี ส่วนกรณีหลังคือการหลีกเลี่ยงข้อจำกัดการเข้าถึง
คำถามที่พบบ่อย
การเปลี่ยน IP เปลี่ยนเพียงสัญญาณหนึ่งในการประเมิน หาก header ความถี่ และลักษณะ fingerprint ยังเหมือนเดิม สคริปต์ก็จะชนกำแพงเดิมอีกอย่างรวดเร็ว การเปลี่ยน IP บ่อยมากเองก็อาจกลายเป็นสัญญาณผิดปกติได้
เมื่อ API quota ต่ำ ให้ลดปริมาณการเก็บข้อมูลตาม quota หรือขอ limit ที่สูงขึ้นผ่านช่องทางธุรกิจ วิธีนี้มักไม่ได้ช้ากว่าการข้ามข้อจำกัดมากนัก และแหล่งข้อมูลยังคงสะอาดและตรวจสอบย้อนกลับได้
การมองเห็นได้แบบสาธารณะกับการนำไปใช้ได้อย่างเสรีเป็นคนละเรื่อง ยังต้องดูเงื่อนไขของเว็บไซต์ สถานะลิขสิทธิ์ของข้อมูล และวัตถุประสงค์ในการใช้งานต่อ หากเกี่ยวข้องกับข้อมูลส่วนบุคคลต้องระมัดระวังเป็นพิเศษ
สรุป
เมื่อ scraping ถูกบล็อก แสดงว่าเว็บไซต์ตัดสินแล้วว่าการเข้าถึงไม่เหมือนพฤติกรรมของผู้ใช้ทั่วไป มีสองทางที่ทำได้จริง: ทำให้พฤติกรรมการเข้าถึงกลับมาอยู่ในช่วงปกติ หรือเปลี่ยนไปใช้ interface อย่างเป็นทางการ การข้ามระบบป้องกันอาจดูเหมือนทางลัด แต่จริง ๆ แล้วเป็นเพียงการย้ายความเสี่ยงจากชั้นเทคนิคไปสู่ชั้น compliance
