Turnstile หรือ reCAPTCHA: ฟรีเหมือนกัน แต่เพดานและแรงเสียดทานไม่เท่ากัน

เว็บที่ตรวจการส่งฟอร์มจำนวนมากและใช้จุดติดตั้งไม่ซับซ้อนมักคาดการณ์ต้นทุนได้ง่ายกว่าด้วย Cloudflare Turnstile เพราะ แผนฟรีของ Turnstile ไม่จำกัดคำขอตรวจสอบ แต่จำกัด 20 widget ต่อบัญชีและ 10 hostname ต่อ widget เพดานที่ต้องระวังจึงเป็นโครงสร้างเว็บไซต์ มากกว่าจำนวนครั้งที่ผู้ใช้ส่งฟอร์ม

reCAPTCHA ยังใช้ฟรีได้เมื่อปริมาณอยู่ในโควตา แต่ต้องนับการใช้งานร่วมกันทุกเว็บไซต์ในองค์กร เงื่อนไขค่าบริการของ Google ให้ฟรี 10,000 assessments ต่อเดือนต่อองค์กร; Premium คิด 8 ดอลลาร์เมื่อยอดอยู่ที่ 10,001–100,000 ครั้ง แล้วเพิ่ม 1 ดอลลาร์ต่อ 1,000 ครั้งเหนือระดับนั้น หากใช้ Essentials โดยไม่เปิดบิลลิง คำขอที่เกินโควตาจะได้รับข้อผิดพลาดด้านโควตา ส่วนแรงเสียดทานของทั้งสองระบบต้องดูจากรูปแบบการตรวจที่เลือกและผลบนฟอร์มจริง ไม่อาจตัดสินจากราคาอย่างเดียว

เว็บสามขนาดจ่ายต่างกันอย่างไร

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

• เว็บขนาดเล็กมี 8,000 assessments ต่อเดือน: reCAPTCHA อยู่ในโควตาฟรี ส่วน Turnstile ไม่คิดค่าบริการตามจำนวนคำขอตรวจสอบ ราคาจึงยังไม่ใช่เหตุผลเพียงพอที่จะเปลี่ยนระบบ หากระบบเดิมทำงานได้ดีและผู้ใช้ส่งฟอร์มได้ตามปกติ
• เว็บขนาดกลางมี 50,000 assessments ต่อเดือน: reCAPTCHA Premium มีค่าใช้จ่าย 8 ดอลลาร์ต่อเดือนตามช่วงราคาเดียวกัน ขณะที่ Turnstile ยังใช้ฟรีภายใต้เพดานจุดติดตั้ง ความต่างด้านค่าบริการเริ่มเห็นได้ แต่ต้องรวมงานย้ายระบบและการติดตามผลหลังเปลี่ยนด้วย
• เว็บขนาดใหญ่มี 250,000 assessments ต่อเดือน: reCAPTCHA Premium คิด 8 ดอลลาร์สำหรับช่วงถึง 100,000 ครั้ง และอีก 150 ดอลลาร์สำหรับ 150,000 ครั้งที่เกิน รวม 158 ดอลลาร์ต่อเดือน ส่วน Turnstile ไม่มีค่าบริการที่เพิ่มตามจำนวนคำขอตรวจสอบในแผนฟรี

ตัวเลขดังกล่าวเป็นค่าใช้บริการในสกุลดอลลาร์สหรัฐตามสมมติฐาน ไม่ใช่ใบเสนอราคาสำหรับเว็บไซต์ไทย และยังไม่รวมต้นทุนพัฒนา หากองค์กรมีหลายเว็บ ต้องนำ assessments ของทุกเว็บมารวมก่อนเทียบกับโควตาของ reCAPTCHA การสร้างคีย์หรือโปรเจกต์เพิ่มไม่ได้ทำให้แต่ละเว็บได้รับโควตาฟรีแยกกัน ตัวอย่างเช่น เว็บหนึ่งใช้ 6,000 ครั้งและอีกเว็บใช้ 6,000 ครั้งในเดือนเดียวกัน ยอดรวม 12,000 ครั้งย่อมข้ามโควตาฟรีขององค์กรแล้ว

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

เพดาน widget และ hostname สำคัญกับเว็บแบบไหน

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

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

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

แรงเสียดทานวัดจากการส่งฟอร์ม ไม่ใช่ชื่อผลิตภัณฑ์

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

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

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

เอเจนต์ AI เปลี่ยนวิธีประเมินความทนทาน

การผ่านหรือไม่ผ่าน CAPTCHA ขึ้นอยู่กับเครื่องมือของผู้โจมตีและสภาพแวดล้อมที่มันทำงานด้วย งานวิจัย Broken Gates ทดสอบบริการรับแก้ CAPTCHA 7 รายและเอเจนต์ 6 แบบกับ hCaptcha, reCAPTCHA v2, reCAPTCHA v3 และ Turnstile ผลพบว่าบริการรับแก้โจทย์ผ่านด่านแบบโต้ตอบได้ในระดับสูง และเอเจนต์ที่มีโมดูลช่วยแก้โจทย์ก็อาจผ่านได้ ส่วนผลของระบบแบบไม่ต้องโต้ตอบอย่าง reCAPTCHA v3 ต่างออกไป โดยสภาพแวดล้อมที่เอเจนต์ทำงานมีบทบาทสำคัญต่อผลทดสอบ

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

ย้ายระบบอย่างไรให้การตรวจไม่หยุดที่หน้าเว็บ

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

1. รวบรวมฟอร์มและ endpoint ทุกจุดที่ใช้ reCAPTCHA เดิม พร้อม hostname, action และกฎที่ใช้ตัดสินผล หากระบบเดิมอาศัยคะแนนความเสี่ยง ให้บันทึกเกณฑ์และการดำเนินการที่ผูกกับแต่ละช่วงคะแนนไว้ก่อนเปลี่ยน
2. จัดกลุ่มฟอร์มตามการตั้งค่าและ hostname ที่ใช้ร่วมกันได้ แล้วสร้าง widget กับคีย์ให้พอดีกับเพดาน เก็บ secret key ไว้ฝั่งเซิร์ฟเวอร์และส่งเฉพาะ token จากหน้าเว็บเข้ามาพร้อมคำขอ
3. ให้เซิร์ฟเวอร์เรียก Siteverify และยอมรับคำขอเมื่อผลสำเร็จเท่านั้น ตรวจ hostname และ action ในผลตอบกลับกับค่าที่คาดไว้เมื่อมีการกำหนดค่าเหล่านั้น อย่านำเกณฑ์คะแนนของ reCAPTCHA มาใช้แทนผลสำเร็จของ Turnstile เพราะเป็นสัญญาณคนละชนิด
4. ทดสอบกรณีไม่มี token, token หมดอายุ, ใช้ token ซ้ำ และบริการตรวจตอบช้า กำหนดข้อความให้ผู้ใช้ลองใหม่โดยข้อมูลที่กรอกไม่หาย และบันทึกสาเหตุความล้มเหลวให้ทีมแยกปัญหาการตั้งค่าจากคำขอที่น่าสงสัยได้

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

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

อ่านเพิ่มเติม:

• AWS Lambda หรือ Cloudflare Workers: งานรอ I/O คิดเงินคนละนาฬิกา
• Cloudflare R2 หรือ Amazon S3: egress ฟรีแลกกับอัปโหลดที่ช้ากว่า
• Cloudflare Workers หรือ Vercel Functions: cold start ไม่ใช่ต้นทุนเดียว