บทที่ 52: Cloudflare คืออะไร

Cloudflare ไม่ได้มีบทบาทเดียว ถ้าเว็บอยู่บน Vercel หรือเซิร์ฟเวอร์เดิม Cloudflare DNS/Proxy สามารถเป็น ด่านหน้าระหว่างลูกค้ากับ Hosting ได้.[2] แต่ถ้า Deploy เว็บขึ้น Cloudflare Workers ตัว Cloudflare เองก็ทำหน้าที่เป็น runtime และที่เสิร์ฟไฟล์ของเว็บได้

Workers Static Assets รองรับการอัปโหลด HTML, CSS, รูปภาพ และไฟล์อื่นพร้อม Worker โดย Cloudflare ช่วย cache และเสิร์ฟไฟล์เหล่านั้นให้เบราว์เซอร์ และตอน Deploy สามารถส่งทั้ง Worker code กับ static assets ขึ้นไปในครั้งเดียว.[8] Workers Builds ยังเชื่อม GitHub หรือ GitLab เพื่อ Build และ Deploy อัตโนมัติเมื่อ Push ได้.[9]

คำถามที่ถูกจึงไม่ใช่ “Cloudflare เป็น Hosting หรือไม่” แต่คือ โปรเจกต์นี้ใช้ Cloudflare แบบ Proxy หน้า Hosting เดิม หรือใช้ Cloudflare เป็นที่ Host/Deploy เอง

สไลด์ 1 — 4 คำนี้ต้องแยกให้ออก

• DNS คือสมุดบอกทาง ชื่อโดเมนนี้ต้องไปที่ไหน Cloudflare DNS เป็น authoritative DNS ที่ใช้จัดการ records ของโดเมน.[1]
• Proxy คือด่านรับทราฟฟิก เมื่อเปิดเมฆสีส้ม คำขอ HTTP/HTTPS จะผ่าน Cloudflare ก่อนถึงต้นทาง.[2]
• CDN / Cache คือสำเนาไฟล์ที่เก็บไว้ใกล้ผู้ใช้ เพื่อลดภาระต้นทางและช่วยให้ส่งไฟล์เดิมได้เร็วขึ้น.[3]
• WAF คือยามกรองคำขอเว็บและ API ตาม rulesets เช่น IP, URL path และ headers.[4]

จำศัพท์ให้ถูกก่อน แล้วเวลามีปัญหาจะรู้ว่าเว็บช้าหรือพังอยู่ที่ชั้นไหน

สไลด์ 2 — Cloudflare อยู่ได้ 2 บทบาท

แบบที่ 1: Proxy หน้า Hosting เดิม

ลูกค้า → Cloudflare DNS / Proxy → Vercel หรือ Hosting เดิม

ในโหมดนี้ Cloudflare อยู่ระหว่างผู้ใช้กับ Origin เพื่อช่วย route, cache และป้องกัน HTTP/HTTPS traffic.[2] ถ้า Origin ล่ม งาน dynamic ที่ต้องกลับไปต้นทางยังล่มตาม

แบบที่ 2: Host และ Deploy บน Cloudflare

Git หรือ CLI → Cloudflare Workers → เว็บออนไลน์

ในโหมดนี้ Worker code และ static assets ถูก Deploy เป็นหน่วยเดียวบนเครือข่าย Cloudflare จึงไม่ต้องมี Vercel หรือเว็บเซิร์ฟเวอร์ภายนอกเป็นอีก Stage สำหรับแอปนั้น.[8] แต่ฐานข้อมูลหรือบริการภายนอกที่แอปเรียกใช้ยังเป็น dependency ที่ต้องดูแลแยก

Cloudflare เป็นได้ทั้งด่านหน้า และที่ Deploy เว็บ

สไลด์ 3 — เมฆสีเทากับเมฆสีส้ม

A, AAAA และ CNAME ที่ใช้เสิร์ฟเว็บสามารถเปิด Proxy ได้ แต่ records อย่าง MX และ TXT ไม่ได้ใช้เสิร์ฟ HTTP/HTTPS และควรคงตามหน้าที่ของมัน.[2]

อย่าเปิดเมฆสีส้มทุก record แบบเดา ๆ โดยเฉพาะ record ของอีเมลหรือ record ที่ใช้ยืนยันเจ้าของโดเมน

สไลด์ 4 — Cache ช่วยเว็บเร็วขึ้นยังไง

สไลด์นี้อธิบาย Proxy mode: เมื่อ Cloudflare ยังไม่มีสำเนาใน Cache ระบบต้องขอไฟล์จาก Hosting เดิมก่อน ถ้าไฟล์นั้นแคชได้ ระบบจะเก็บสำเนาไว้ในศูนย์ข้อมูลที่ใกล้ผู้ใช้กว่าเดิม เมื่อมีคำขอถัดไปจึงส่งสำเนานั้นได้เร็วขึ้นและลดภาระต้นทาง.[3]

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

Cache ลดงานต้นทางได้ แต่ข้อมูลสดยังต้องกลับไปที่ Hosting

สไลด์ 5 — WAF กับ DDoS ช่วยคนละแบบ

WAF ตรวจคำขอที่เข้ามาตาม rulesets คำขอปกติจึงผ่านต่อ ส่วนคำขอที่ตรงเงื่อนไขอันตรายสามารถถูกบล็อกหรือท้าทายได้.[4]

DDoS Protection มองอีกปัญหาหนึ่ง คือทราฟฟิกโจมตีปริมาณมหาศาล Cloudflare มีระบบตรวจจับและบรรเทาการโจมตีแบบ DDoS อัตโนมัติ.[6]

หลังเปิดกฎความปลอดภัยต้องทดสอบหน้าเว็บ ฟอร์ม API และ webhook ของจริงด้วย เพื่อให้แน่ใจว่ากฎไม่กันลูกค้าหรือระบบที่ถูกต้องออกไป

WAF กรองตามกติกา · DDoS Protection รับมือปริมาณโจมตี

สไลด์ 6 — HTTPS ต้องปลอดภัยทั้งเส้น

เมื่อมี Cloudflare เส้นทาง HTTPS แบ่งเป็นสองช่วง คือ ผู้เข้าชม ↔ Cloudflare และ Cloudflare ↔ Hosting ต้นทาง โดย SSL/TLS Encryption Mode เป็นตัวกำหนดว่าช่วงหลังถูกเข้ารหัสและตรวจสอบอย่างไร.[5]

ถ้าต้นทางรองรับ HTTPS และมี certificate ที่ถูกต้อง ให้ใช้โหมดที่ตรวจสอบต้นทางอย่างเข้มงวด เช่น Full (strict) หรือใช้ Automatic SSL/TLS เมื่อมีในบัญชี แทนการลดความปลอดภัยเพื่อให้เว็บขึ้นชั่วคราว.[5]

หลังเปลี่ยนค่า ให้ทดสอบทั้งหน้าแรก ล็อกอิน ฟอร์ม API และการชำระเงินจริงในโหมดทดสอบ ไม่ใช่ดูแค่ว่าหน้าแรกเปิดได้

Full (strict) ตรวจ certificate ของต้นทาง ไม่ใช่แค่ทำให้เบราว์เซอร์มีรูปกุญแจ

สไลด์ 7 — เริ่ม Cloudflare ให้ถูกทาง

ให้เลือกสถาปัตยกรรมก่อนแตะ DNS หรือ Deploy

ทาง A — มี Hosting อยู่แล้ว: ใช้ DNS / Proxy

1. ทำให้เว็บต้นทางเปิดผ่าน HTTPS ได้และจด DNS เดิม 2. เพิ่ม Domain แล้วตรวจ records โดยแยกเว็บ อีเมล และบริการอื่น ตั้ง web records เป็น DNS only ชั่วคราว หากต้องการทยอยเปิด เพราะ dashboard เปิด Proxy เป็นค่าเริ่มต้นได้.[2] 3. ถ้า DNSSEC เปิดอยู่ ให้ปิดที่ registrar ก่อนเปลี่ยน nameservers มิฉะนั้นโดเมนอาจเข้าไม่ได้.[7] 4. เปลี่ยน nameservers รอ zone เป็น Active แล้วเปิด DNSSEC ใหม่หากเคยใช้.[7] 5. ตั้ง SSL/TLS ให้ตรงกับ Origin และเปิด Proxy ทีละ hostname พร้อมทดสอบ/rollback.[2][5]

ทาง B — จะ Host บน Cloudflare: ใช้ Workers

1. เลือก Workers สำหรับโปรเจกต์ใหม่ แล้วตัดสินใจว่าจะ Deploy ผ่าน Git หรือ CLI 2. ทาง Git: เชื่อม GitHub/GitLab กับ Worker แล้วใช้ Workers Builds เพื่อ Build และ Deploy อัตโนมัติเมื่อ Push พร้อมตรวจ Preview ก่อนขึ้น Production.[9] 3. ทาง CLI: รัน wrangler deploy จากโปรเจกต์ไปยัง Workers โดยตรง ไม่ได้วิ่งผ่าน Workers Builds.[11] 4. ทั้งสองทางต้องทดสอบหน้าเว็บ API, environment variables และ dependencies ก่อนผูก Custom Domain

Cloudflare Pages ยัง Deploy full-stack application ผ่าน Git, Direct Upload หรือ CLI ได้ แต่เอกสารปัจจุบันระบุว่า Workers รองรับ use case ส่วนใหญ่ของ Pages มี feature กว้างกว่า และเป็นแพลตฟอร์มหลักสำหรับโปรเจกต์ใหม่.[10] โปรเจกต์ Pages เดิมไม่จำเป็นต้องย้ายเพียงเพราะมี Workers; ให้ย้ายเมื่อ feature หรือ workflow มีเหตุผลรองรับ

ลองทำเลย

เลือกหนึ่งโปรเจกต์แล้วตอบให้ได้ก่อนว่าเป็น ทาง A: Proxy หน้า Hosting เดิม หรือ ทาง B: Host บน Workers ถ้าเป็นทาง A ให้แยก web/email records โดยยังไม่เปลี่ยนค่า ถ้าเป็นทาง B ให้ระบุ Repository, Build command, Deploy command, Preview และ Rollback ก่อนเชื่อม Production domain

กับดักที่เจอบ่อย

• คิดว่า Cloudflare เป็นแค่ Proxy — จะพลาด Workers ซึ่ง Host และ Deploy แอปได้
• คิดว่าเปลี่ยน Nameservers แล้วโค้ดจะ Deploy เอง — DNS setup กับ Workers deployment เป็นคนละ workflow
• เปิด Proxy ทุก record — อีเมลหรือการยืนยันโดเมนอาจมีปัญหา
• เปิด Cache แล้วคิดว่าทุกอย่างเร็วเอง — งานที่คุยกับฐานข้อมูลยังต้องกลับต้นทาง
• คิดว่า Host บน Workers แล้ว dependency ไม่มีวันล่ม — Database และ API ภายนอกยังต้องตรวจแยก
• เปลี่ยนหลายค่าในครั้งเดียว — พอเว็บพังจะไม่รู้ว่าจุดไหนเป็นสาเหตุ

ใน บทที่ 16 Vercel คืออะไร เราเรียนว่า Vercel รับโค้ดไป Build และเปิดเว็บออนไลน์ ปัจจุบัน Cloudflare Workers ก็เป็นอีกทางเลือกสำหรับ Host/Deploy เว็บ ไม่ใช่แค่ชั้น Domain และ Proxy

ลำดับที่ควรจำจึงมีสองแบบ: Vercel/Hosting เดิม → Cloudflare Proxy หรือ Git/CLI → Cloudflare Workers → Domain เลือกให้ชัดแล้วค่อยตั้งค่า

เช็คลิสต์ก่อนไปบทถัดไป

• อธิบาย Proxy mode กับ Host mode ของ Cloudflare ได้
• รู้ว่าโค้ดของโปรเจกต์นี้รันบน Hosting เดิมหรือ Workers
• อธิบาย Proxied กับ DNS only ได้
• รู้ว่า Workers สามารถ Deploy code และ static assets ได้
• รู้ว่า Pages ยังใช้ได้ แต่ Cloudflare แนะนำ Workers สำหรับโปรเจกต์ใหม่
• รู้ว่า record ของเว็บกับอีเมลทำหน้าที่ไม่เหมือนกัน
• เข้าใจว่า HTTPS มีสองช่วงเมื่อมี Cloudflare อยู่กลางทาง
• ทดสอบหน้าเว็บ ฟอร์ม API และ webhook หลังเปลี่ยนค่า
• จดค่าเดิมและมี rollback ก่อนแก้ DNS หรือ SSL/TLS

Sources

[1] https://developers.cloudflare.com/dns — Cloudflare DNS docs [2] https://developers.cloudflare.com/dns/proxy-status — Cloudflare DNS proxy status [3] https://developers.cloudflare.com/cache — Cloudflare Cache docs [4] https://developers.cloudflare.com/waf — Cloudflare WAF docs [5] https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes — Cloudflare SSL/TLS encryption modes [6] https://developers.cloudflare.com/ddos-protection — Cloudflare DDoS Protection docs [7] https://developers.cloudflare.com/dns/zone-setups/full-setup/setup — Cloudflare DNS full setup [8] https://developers.cloudflare.com/workers/static-assets — Cloudflare Workers Static Assets [9] https://developers.cloudflare.com/workers/ci-cd/builds — Cloudflare Workers Builds [10] https://developers.cloudflare.com/pages — Cloudflare Pages overview [11] https://developers.cloudflare.com/workers/wrangler/commands — Cloudflare Wrangler commands