Cloudflare ฉบับเริ่มต้น: เข้าใจ DNS, Cache, WAF และ Workers ใน 10 นาที

Cloudflare กลายเป็นชั้นหน้าบ้านของเว็บจำนวนมากทั่วโลก แต่เมนูตั้งค่าหลายร้อยรายการทำให้ผู้เริ่มต้นถอดใจ บทความนี้สรุปแนวคิดหลักจากเอกสารทางการของ Cloudflare อธิบาย DNS, Proxy, Cache, WAF และ Workers ด้วยภาษาที่เข้าใจง่าย พร้อมคำแนะนำว่าเว็บแบบไหนควรใช้หรือยังไม่จำเป็น

Cloudflare เกิดมาแก้ปัญหาอะไร

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

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

จุดเริ่มต้น: DNS และโหมด Proxy

การใช้งาน Cloudflare เริ่มจากย้ายการจัดการ DNS ของโดเมนมาไว้ที่ Cloudflare โดยเปลี่ยน Nameserver ที่ผู้ให้บริการโดเมน จากนั้นแต่ละเรคคอร์ดจะเลือกได้ว่าจะเปิดโหมด Proxy (ไอคอนเมฆสีส้ม) หรือปล่อยเป็น DNS Only (เมฆสีเทา)

ความต่างอยู่ตรงนี้ ถ้าเป็นเมฆสีเทา Cloudflare แค่บอกทางแล้วผู้ใช้ยิงตรงเข้าเซิร์ฟเวอร์เรา ทั้ง IP จริงและภาระโหลดจะเปิดเผยตามเดิม แต่ถ้าเป็นเมฆสีส้ม ทราฟฟิกจะวิ่งผ่านเครือข่าย Cloudflare ทำให้ได้ทั้ง Cache, WAF, ใบรับรอง SSL ฟรี และการซ่อน IP ต้นทาง ฟีเจอร์ส่วนใหญ่ที่คนคาดหวังจาก Cloudflare จะทำงานเฉพาะกับเรคคอร์ดที่เปิด Proxy ไว้เท่านั้น

Cache: หัวใจของความเร็วที่ได้มาแทบฟรี

โดยค่าเริ่มต้น Cloudflare จะเก็บสำเนาไฟล์แบบ Static เช่น รูปภาพ, CSS, JavaScript และฟอนต์ ไว้ที่ศูนย์ข้อมูลใกล้ผู้ใช้ คำขอครั้งถัดไปจึงได้คำตอบจากจุดนั้นทันที (สถานะ HIT) ผลคือหน้าเว็บเร็วขึ้นชัดเจนสำหรับผู้ใช้ที่อยู่ไกล และแบนด์วิดท์ที่เซิร์ฟเวอร์ต้นทางลดลงมาก

สิ่งที่ผู้เริ่มต้นต้องระวังคือ Cloudflare จะไม่แคชหน้า HTML แบบไดนามิกให้เองโดยอัตโนมัติ เพราะเสี่ยงกับหน้าที่แสดงข้อมูลเฉพาะผู้ใช้ที่ล็อกอิน ถ้าต้องการแคชหน้าเพจด้วยต้องตั้ง Cache Rules เอง และอย่าลืมสองเรื่องสำคัญ คือกำหนดอายุแคชผ่านส่วนหัว Cache-Control ให้ชัดเจน และสั่ง Purge Cache ทุกครั้งที่ปล่อยเวอร์ชันใหม่ ไม่เช่นนั้นผู้ใช้บางส่วนจะยังเห็นของเก่า

WAF และ DDoS Protection: เกราะชั้นแรกของระบบ

เพราะทราฟฟิกวิ่งผ่านชั้นนี้อยู่แล้ว Cloudflare จึงคัดกรองคำขอที่เป็นอันตรายได้ก่อนถึงเซิร์ฟเวอร์ Web Application Firewall (WAF) มีชุดกฎสำเร็จรูปที่ครอบคลุมช่องโหว่ยอดนิยมอย่าง SQL Injection และ XSS พร้อมให้เราเขียนกฎเองได้ เช่น อนุญาตให้เข้าหน้าแอดมินเฉพาะช่วง IP ของออฟฟิศ หรือบล็อกทราฟฟิกจากประเทศที่ธุรกิจเราไม่ได้ให้บริการ

คู่กันคือการจำกัดอัตราคำขอ (Rate Limiting) ซึ่งช่วยกันการเดารหัสผ่านและการยิงถล่ม API ส่วนการป้องกัน DDoS ระดับเครือข่ายเปิดใช้งานให้อัตโนมัติทุกแพลนตั้งแต่แพลนฟรี ทั้งหมดนี้ไม่ได้แทนที่การเขียนโค้ดให้ปลอดภัย แต่ช่วยซื้อเวลาและตัดทราฟฟิกขยะออกไปได้มากตั้งแต่ด่านแรก

Workers และ Pages: รันโค้ดและโฮสต์เว็บที่ขอบเครือข่าย

นอกจากงานป้องกันและเร่งความเร็ว Cloudflare ยังให้เรารันโค้ดของตัวเองบนเครือข่ายเดียวกันได้ผ่าน Workers ซึ่งเป็นแบบ Serverless ไม่ต้องดูแลเซิร์ฟเวอร์ ไม่ต้องคิดเรื่องการขยายระบบ และโค้ดจะทำงานที่ศูนย์ข้อมูลใกล้ผู้ใช้ งานที่เหมาะมากคือ API เบา ๆ, การตรวจสอบสิทธิ์, การทำ A/B Test หรือ Redirect ที่มีเงื่อนไขซับซ้อน

ส่วน Pages เหมาะกับเว็บ Static และเว็บที่สร้างด้วยเฟรมเวิร์กสมัยใหม่ เชื่อมกับ Git แล้วสั่ง Build อัตโนมัติทุกครั้งที่ Push พร้อมได้ลิงก์พรีวิวแยกต่อสาขา ทำให้ทีมรีวิวงานก่อนขึ้นจริงได้สะดวก และเมื่อจับคู่กับ R2 สำหรับเก็บไฟล์ที่ไม่มีค่าธรรมเนียมขาออก ก็ช่วยลดค่าใช้จ่ายก้อนใหญ่ของเว็บที่มีสื่อจำนวนมากได้

เว็บของคุณควรใช้ Cloudflare หรือยัง

สำหรับเว็บที่มีผู้ใช้จริงและเปิดสู่สาธารณะ คำตอบมักเป็นควรใช้ เพราะแพลนฟรีให้ทั้ง DNS, ใบรับรอง SSL, CDN และการป้องกัน DDoS พื้นฐานครบแล้ว งานที่ต้องทำมีเพียงย้าย Nameserver และตรวจการตั้งค่าอีกไม่กี่จุด ส่วนแพลนเสียเงินจะคุ้มเมื่อต้องการกฎ WAF ที่ละเอียดขึ้น รายงานเชิงลึก หรือระดับ SLA ที่องค์กรกำหนด

สิ่งที่ควรพิจารณาก่อนคือระบบภายในองค์กรที่ไม่ได้เปิดสู่อินเทอร์เน็ต หรือระบบที่มีข้อกำหนดว่าข้อมูลต้องไม่ผ่านตัวกลางภายนอก กรณีเหล่านี้ควรประเมินร่วมกับฝ่ายความปลอดภัยก่อนเสมอ เส้นทางเริ่มต้นที่แนะนำคือ ย้าย DNS มาก่อนโดยยังไม่เปิด Proxy ตรวจว่าเว็บทำงานปกติ แล้วค่อยเปิดเมฆส้มทีละเรคคอร์ด จากนั้นจึงเพิ่ม Cache Rules, WAF และ Rate Limiting ตามลำดับ