การตรวจจับการฉ้อโกงที่ Edge: Cloudflare Workers + tracio.ai
รันการตรวจสอบ device fingerprint ใน Cloudflare Workers ก่อนที่คำขอจะถึง origin ของคุณ ตัดสินใจเรื่องการฉ้อโกงที่ edge ในเวลาต่ำกว่า 5ms
การตรวจจับการฉ้อโกงแบบดั้งเดิมเกิดขึ้นที่ application layer: คำขอมาถึง server ของคุณ คุณเรียกใช้ fraud detection API รอการตอบกลับ แล้วจึงตัดสินใจว่าจะอนุญาตหรือบล็อก การไป-กลับนี้เพิ่ม latency 50-200ms ให้กับทุกคำขอ — ยอมรับได้สำหรับการโหลดหน้าเว็บ แต่สร้างปัญหาสำหรับ API endpoint, การเรียก AJAX และการโต้ตอบแบบเรียลไทม์
จะเป็นอย่างไรถ้าคุณสามารถตัดสินใจเรื่องการฉ้อโกงได้ก่อนที่คำขอจะไปถึง origin server ของคุณ นั่นคือสิ่งที่ edge computing ทำให้เป็นไปได้ และ Cloudflare Workers คือแพลตฟอร์มที่เราใช้เพื่อสาธิตรูปแบบนี้
สถาปัตยกรรม
การตั้งค่ามีสามองค์ประกอบ: tracio.ai JS SDK (@tracio/sdk) ที่รันในเบราว์เซอร์, Cloudflare Worker ที่อยู่ระหว่างไคลเอนต์กับ origin ของคุณ และ webhook ของ tracio.ai ที่ลงลายเซ็นซึ่งส่งการวิเคราะห์สัญญาณแบบเต็มไปยัง backend ของคุณ
การทำงานเป็นดังนี้: JS SDK รวบรวมสัญญาณของอุปกรณ์และส่งไปยัง tracio.ai ระหว่างการโหลดหน้าเว็บ แล้วส่ง visitorId กลับไปยังเบราว์เซอร์ Backend ของคุณรับผลการระบุตัวตนแบบเต็ม — การจำแนกบอท, smart signals, ความเชื่อมั่น — ผ่าน webhook ที่ลงลายเซ็น และเขียน verdict ลงใน edge cache เบราว์เซอร์จะแนบ visitorId ไปในคำขอ API ครั้งถัดไป (ผ่าน header หรือ cookie) Cloudflare Worker จะดักจับแต่ละคำขอ ค้นหา verdict ที่ถูกแคชไว้สำหรับ visitorId นั้น และตัดสินใจอนุญาต/บล็อกในเวลาต่ำกว่า 5ms
การนำ Worker ไปใช้
Worker ดูแลแคชแบบเบาของผลการยืนยันอุปกรณ์ล่าสุดโดยใช้ KV storage ของ Cloudflare ซึ่งถูกเติมข้อมูลโดย backend ของคุณเมื่อ webhook ที่ลงลายเซ็นของ tracio.ai เข้ามา เมื่อคำขอมาถึงพร้อมกับ header visitorId Worker จะตรวจสอบแคช หาก verdict ถูกแคชไว้และผู้เข้าชมสะอาด (bot score ต่ำ, ไม่มี VPN, ความเชื่อมั่นสูงกว่าเกณฑ์) คำขอจะผ่านไปทันที หากยังไม่มี verdict ถูกแคชไว้ Worker จะใช้นโยบายสำรองของคุณ — ปล่อยผ่านด้วยการจำกัดอัตราแบบระมัดระวัง หรือท้าทาย — จนกว่าแคชที่ขับเคลื่อนด้วย webhook จะตามทัน
ข้อมูลเชิงลึกที่สำคัญคือแคชการยืนยันถูกเติมข้อมูลเชิงรุก การโหลดหน้าครั้งแรกจะกระตุ้นการเก็บสัญญาณและแคชผลลัพธ์ การเรียก API ครั้งถัดไปทั้งหมดจากผู้เข้าชมรายนั้นจะเข้าถึงแคช — ไม่จำเป็นต้องไป-กลับหา tracio.ai TTL ของแคชสามารถกำหนดค่าได้ เราแนะนำ 5 นาทีสำหรับ endpoint ที่มีความปลอดภัยสูง และ 30 นาทีสำหรับเนื้อหาทั่วไป
ตัวเลขประสิทธิภาพ
เราทดสอบสถาปัตยกรรมนี้กับลูกค้าที่ประมวลผล 50,000 คำขอต่อนาทีผ่าน Cloudflare Workers ผลลัพธ์:
อัตราการ cache hit: 94% (คำขอส่วนใหญ่มาจากผู้เข้าชมที่โหลดหน้าเว็บไปแล้ว) Latency การตัดสินใจที่ edge (cache hit): ค่ามัธยฐาน 1.2ms, 3.8ms p99 Latency การตัดสินใจที่ edge (cache miss): ค่ามัธยฐาน 45ms (รวมการเรียก API ไปยัง tracio.ai) การประหยัด latency ของ origin: ค่ามัธยฐาน 120ms ต่อคำขอ (ขจัดการตรวจสอบการฉ้อโกงฝั่ง server)
อัตราการ cache hit 94% หมายความว่า 94% ของการตัดสินใจเรื่องการฉ้อโกงเกิดขึ้นในเวลาต่ำกว่า 4ms ที่ edge โดยไม่มีการเกี่ยวข้องกับ origin ส่วนที่เหลืออีก 6% คือคำขอจากการเข้าชมครั้งแรกที่ต้องการการไป-กลับ API แบบเต็ม
กลยุทธ์การบล็อก
Worker รองรับกลยุทธ์การบล็อกสามแบบ ซึ่งกำหนดค่าได้ต่อ route:
Hard block: ส่งคืน 403 ทันทีสำหรับผู้เข้าชมที่มีความเสี่ยงสูง (bot score > 0.9, เฟรมเวิร์กการทำงานอัตโนมัติที่รู้จัก) Soft block: เพิ่ม header X-Tracio-Risk แล้วให้ origin เป็นผู้ตัดสินใจ วิธีนี้มีประโยชน์เมื่อคุณต้องการบริบทระดับแอปพลิเคชันสำหรับการตัดสินใจ Challenge: เปลี่ยนเส้นทางผู้เข้าชมที่น่าสงสัย (bot score ปานกลาง, ตรวจพบ VPN) ไปยังหน้าท้าทายที่ต้องการการยืนยันเพิ่มเติม
เราแนะนำให้เริ่มด้วย soft blocking ใน production ติดตามการกระจายความเสี่ยงเป็นเวลาหนึ่งสัปดาห์ แล้วจึงเปิดใช้ hard blocking สำหรับกรณีที่ชัดเจน (บอทที่รู้จัก, เบราว์เซอร์แบบ headless, การทำงานอัตโนมัติที่มีความเชื่อมั่นสูง)
การวิเคราะห์ต้นทุน
ราคาของ Cloudflare Workers อิงตามจำนวนคำขอและเวลาประมวลผล ที่ 50K คำขอ/นาที (2.16 พันล้าน/เดือน) ต้นทุนของ Worker อยู่ที่ประมาณ $500/เดือน เปรียบเทียบกับการประหยัด latency: การขจัดการตรวจสอบการฉ้อโกงฝั่ง origin 120ms ลดการใช้งาน CPU ของ server ลง 15-20% ซึ่งโดยทั่วไปประหยัดได้มากกว่าต้นทุนของ Worker ในด้านการประมวลผล
คุณค่าที่แท้จริงอยู่ที่การป้องกันการฉ้อโกง: การจับบอทและคำขอที่เป็นการฉ้อโกงก่อนที่พวกมันจะใช้ทรัพยากรของ origin, การเชื่อมต่อฐานข้อมูล และการเรียก API ปลายทาง ลูกค้ารายหนึ่งลดจำนวน origin server จาก 12 เหลือ 8 หลังนำการตรวจจับการฉ้อโกงแบบ edge มาใช้ — บอทที่เคยกิน 30% ของการประมวลผลของพวกเขาไม่เคยไปถึง origin เลย