CDN คืออะไร? Cloudflare ช่วยเว็บ SME ได้แค่ไหน ก่อนย้าย DNS

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

วันหนึ่งมีคนแนะนำเจ้าของร้านว่า ลองเปิดคลังย่อยตามหัวเมืองดูไหม เอาขนมที่ขายดีและหน้าตาเหมือนกันทุกกล่องไปวางไว้ใกล้ลูกค้าก่อน ใครสั่งก็หยิบจากคลังที่ใกล้ที่สุด แถมที่หน้าคลังย่อยยังมีพนักงานคอยกรองคนที่มาต่อแถวเล่นๆ ไม่ได้ตั้งใจซื้อ ไม่ให้ไปเบียดลูกค้าจริง

ฟังดูดีใช่ไหมครับ เว็บไซต์ก็มีของแบบนี้เหมือนกัน เราเรียกมันว่า CDN และชื่อที่เจ้าของธุรกิจไทยได้ยินบ่อยที่สุดก็คือ Cloudflare วันไหนทีมเว็บเดินมาบอกว่า "ย้าย DNS ไป Cloudflare กันเถอะ" หรือ "เปิด CDN ให้หน่อย" บทความนี้จะช่วยให้คุณรู้ว่ามันช่วยอะไรได้จริง ช่วยอะไรไม่ได้ และต้องถามอะไรก่อนตอบตกลงครับ

เช็กเว็บตัวเองก่อน ใช้เวลาไม่ถึงสองนาที

เปิดเบราว์เซอร์ขึ้นมา พิมพ์ชื่อเว็บของคุณแล้วต่อท้ายด้วย /cdn-cgi/trace เช่น www.ชื่อร้าน.com/cdn-cgi/trace แล้วกด Enter ครับ

ถ้าหน้าจอขึ้นข้อความสั้นๆ หลายบรรทัด และมีบรรทัดหนึ่งเขียนว่า colo= ตามด้วยตัวอักษรสามตัว แปลว่าเว็บของคุณวิ่งผ่าน Cloudflare อยู่แล้ว ตัวอักษรสามตัวนั้นคือรหัสสนามบินของเมืองที่ data center ของ Cloudflare ตั้งอยู่ ถ้าคุณเปิดจากในไทยแล้วเห็น BKK ก็แปลว่าคำขอของคุณถูกตอบจาก data center ในกรุงเทพฯ ถ้าขึ้นหน้า 404 หรือหน้าไม่พบ แปลว่าเว็บยังไม่ได้อยู่หลัง Cloudflare

จากนั้นลองถามทีมเว็บดูว่า บัญชี Cloudflare ของเว็บเราเปิดด้วยอีเมลของใคร แล้วบัญชีที่จดโดเมนไว้ (ที่คนในวงการเรียกว่า registrar) ใครเป็นคนถือรหัสผ่าน ถ้าคำตอบคือ "อีเมลส่วนตัวของน้องที่ลาออกไปแล้ว" หรือ "ไม่แน่ใจ" ให้จดไว้ก่อนครับ เดี๋ยวเราจะกลับมาคุยเรื่องนี้กันอีกที

CDN ทำงานยังไง ถ้าเล่าแบบคนขายของ

เว็บไซต์ทุกเว็บมี "ครัวกลาง" ของมันเอง ในภาษาเทคนิคเรียกว่า origin server หรือก็คือ hosting ที่เก็บเว็บของคุณไว้ ปกติเวลาลูกค้าเปิดเว็บ เบราว์เซอร์จะวิ่งไปขอของจากครัวกลางโดยตรงทุกครั้ง ไม่ว่าจะอยู่ใกล้หรือไกลแค่ไหน

CDN (Content Delivery Network) คือเครือข่าย server ที่กระจายอยู่ในหลายเมืองทั่วโลก พอเปิดใช้ ลูกค้าจะไม่ได้คุยกับครัวกลางโดยตรงอีกแล้ว แต่คุยกับ server ของ CDN ที่อยู่ใกล้ตัวที่สุดก่อน ถ้า server ตัวนั้นมีของชิ้นที่ลูกค้าขออยู่แล้ว ก็ส่งให้ได้ทันที ถ้ายังไม่มี มันจะวิ่งไปเอาจากครัวกลางมาให้ แล้วเก็บสำเนาไว้เผื่อคนถัดไป การเก็บสำเนาแบบนี้เรียกว่า cache ครับ

ของที่วางไว้ที่คลังย่อยได้ กับของที่ต้องกลับไปทำที่ครัวกลาง

ตรงนี้คือจุดที่หลายคนเข้าใจคลาดเคลื่อนมากที่สุด ของที่ CDN เก็บไว้ใกล้ลูกค้าได้ดีคือของที่ "หน้าตาเหมือนกันทุกกล่อง" เช่น รูปภาพ ไฟล์ CSS ที่คุมหน้าตาเว็บ ไฟล์ JavaScript ฟอนต์ หรือไฟล์ PDF แคตตาล็อก ของพวกนี้ใครเปิดก็ได้ไฟล์เดียวกัน วางไว้ที่คลังย่อยได้สบาย

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

พูดง่ายๆ คือ ของสำเร็จรูปส่งจากคลังย่อยได้ แต่ของสั่งทำยังต้องกลับไปทำที่ครัวกลางเหมือนเดิม

พนักงานหน้าประตูที่คอยกรองคน

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

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

สิ่งที่ CDN ช่วยไม่ได้ ต่อให้เปิดครบทุกปุ่ม

ผมอยากพูดตรงนี้ให้ชัด เพราะเคยเห็นหลายครั้งที่เจ้าของธุรกิจคาดหวังว่าเปิด Cloudflare แล้วเว็บที่ช้าอยู่จะเร็วขึ้นทันที

ถ้าครัวกลางทำอาหารช้า คลังย่อยก็ช่วยไม่ได้ครับ คู่มือแก้ปัญหาเว็บช้าของ Cloudflare เองเขียนไว้ว่า คำขอที่ไม่ได้อยู่ใน cache ต้องเดินทางจากผู้เข้าชมไปที่ Cloudflare แล้วต่อไปที่ origin server และกลับมาอีกรอบ ถ้า hosting ประมวลผลช้า ฐานข้อมูลหนัก หรือปลั๊กอินเยอะจนหน้าเว็บต้องรอนาน ส่วนนั้นยังช้าเท่าเดิม

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

ถ้าอยากเข้าใจว่าความเร็วเว็บส่งผลกับยอดขายและอันดับ Google ยังไง ผมเคยเขียนไว้ใน บทความเรื่องเว็บโหลดเร็วส่งผลต่อ SEO และยอดขายอย่างไร ครับ ส่วนการอ่านรายงาน PageSpeed Insights ทีละส่วน เป็นเรื่องที่ควรแยกไปคุยกันอีกบทหนึ่ง ในบทนี้ขอให้จำไว้แค่ว่า CDN คือการย้ายของไปวางใกล้ลูกค้า ไม่ได้ทำให้ของเบาลงหรือทำให้ครัวทำงานเร็วขึ้น

แพ็กเกจฟรีของ Cloudflare พอสำหรับเว็บ SME ไหม

สำหรับเว็บบริษัท เว็บร้านค้า หรือเว็บคลินิกทั่วไป ผมมองว่าแพ็กเกจฟรีเพียงพอในเกือบทุกกรณีครับ

ตามหน้าแพ็กเกจของ Cloudflare ที่ผมเปิดดูเมื่อวันที่ 29 กันยายน 2569 แพ็กเกจ Free มี CDN, Universal SSL Certificate (ใบรับรองที่ทำให้เว็บขึ้น https), DDoS protection แบบ unmetered และ Web Application Firewall (WAF) มาให้ ส่วนแพ็กเกจ Pro ที่สูงขึ้นมาหนึ่งขั้น ราคา 20 ดอลลาร์ต่อเดือนถ้าจ่ายรายปี หรือ 25 ดอลลาร์ถ้าจ่ายรายเดือน ราคานี้เป็นราคาในหน้าเว็บของ Cloudflare เอง ผมไม่ทราบว่ารวมภาษีในไทยแล้วหรือยัง ถ้าจะสมัครจริงให้ดูยอดสุดท้ายในหน้าชำระเงินอีกทีนะครับ

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

"ลูกค้าเราอยู่ในไทยหมด จะใช้ CDN ไปทำไม"

คำถามนี้มีเหตุผลครับ ผมเห็นด้วยเลย

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

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

ส่วนเรื่องความพร้อมของ hosting สำหรับวันที่คนเข้าพร้อมกันเยอะ เป็นคนละเรื่องกับ CDN และต้องคุยกับผู้ให้บริการ hosting โดยตรง ผมเขียนแยกไว้ใน บทความเรื่องอ่านใบเสนอราคาโฮสติ้งก่อนเซ็น ครับ

สามจุดที่ตั้งผิดแล้วเว็บหรืออีเมลหยุดทำงาน

การย้ายเว็บมาอยู่หลัง Cloudflare ส่วนใหญ่จะเริ่มจากการย้าย DNS ครับ DNS ก็เหมือนสมุดที่อยู่ของโดเมน บอกโลกว่าเว็บอยู่ที่ไหน อีเมลต้องส่งไปที่ไหน ตอนย้าย เราไม่ได้ย้ายแค่ที่อยู่ของเว็บ แต่ย้ายสมุดที่อยู่ทั้งเล่ม และนี่คือที่มาของความเสี่ยงสามจุดที่ผมเจอบ่อยที่สุด

อีเมลของร้านเงียบไปหลังย้าย DNS

ตอนเพิ่มโดเมนเข้า Cloudflare ระบบจะสแกนหาข้อมูล DNS เดิมให้อัตโนมัติ แต่คู่มือการตั้งค่าของ Cloudflare เขียนไว้ตรงๆ ว่าการสแกนไม่รับประกันว่าจะเจอครบทุก record และให้ตรวจเอง โดยเฉพาะ record ที่เกี่ยวกับอีเมล ถ้า MX record (บรรทัดที่บอกว่าอีเมลของโดเมนนี้ต้องส่งไปที่ไหน) หรือ record ยืนยันตัวตนอีเมลหล่นหายระหว่างทาง อีเมล info@ชื่อร้าน ก็จะเริ่มรับไม่ได้หรือเข้าสแปม และมักไม่มีใครรู้ตัวจนลูกค้าโทรมาถาม

อีกกรณีที่เจอบ่อยคือ subdomain สำหรับอีเมล เช่น mail.ชื่อร้าน.com ถูกเปิด proxy (ไอคอนเมฆสีส้ม) ไปด้วย เอกสารแก้ปัญหาอีเมลของ Cloudflare อธิบายว่าโปรโตคอลอีเมลอย่าง SMTP, IMAP และ POP3 ใช้งานผ่าน HTTP proxy ของ Cloudflare ไม่ได้ hostname ที่ใช้รับส่งอีเมลจึงต้องตั้งเป็น DNS only (เมฆสีเทา)

หน้าเว็บวนไม่จบ ขึ้นว่า redirect มากเกินไป

Cloudflare มีโหมดเข้ารหัส SSL/TLS ให้เลือกหลายแบบ ที่ต้องรู้จักมีสามแบบ Flexible คือเข้ารหัสแค่ช่วงลูกค้ากับ Cloudflare ส่วนช่วง Cloudflare ไปถึง hosting ไม่เข้ารหัส Full คือเข้ารหัสทั้งสองช่วงแต่ไม่ตรวจใบรับรองฝั่ง hosting และ Full (strict) คือเข้ารหัสทั้งสองช่วงและตรวจใบรับรองด้วย

ปัญหาเกิดตอนที่เลือก Flexible แต่ hosting ถูกตั้งไว้ให้เปลี่ยนทุกคำขอเป็น https อยู่แล้ว หน้าแก้ปัญหา ERR_TOO_MANY_REDIRECTS ของ Cloudflare อธิบายว่า Cloudflare ส่งคำขอแบบ http ไปหา hosting แล้ว hosting ก็สั่งให้ไป https วนกลับมาไม่รู้จบ ลูกค้าจะเห็นหน้าจอว่าเปิดเว็บไม่ได้ ทั้งที่เว็บเองไม่ได้พัง ทางแก้ที่ Cloudflare แนะนำคือเปลี่ยนเป็น Full หรือ Full (strict) ซึ่งต้องมีใบรับรองฝั่ง hosting ด้วย

DNSSEC ที่ต้องปิดก่อนเปลี่ยน nameserver

ถ้าโดเมนของคุณเปิด DNSSEC ไว้ (ระบบลงลายมือชื่อให้ข้อมูล DNS) คู่มือตัวเดียวกันของ Cloudflare บอกว่าต้องปิดที่ registrar ก่อนเปลี่ยน nameserver เพราะถ้าเปลี่ยนทั้งที่ยังเปิดอยู่ โดเมนอาจเข้าไม่ได้เลย และเมื่อโดเมนย้ายเสร็จแล้ว ค่อยเปิด DNSSEC กลับได้ผ่าน Cloudflare ครับ เรื่องนี้เจอไม่บ่อยเท่าเรื่องอีเมลกับเรื่อง SSL แต่พอเกิดแล้วแก้ยากกว่า เพราะต้องมีคนที่ล็อกอิน registrar ได้มาจัดการ

ใครควรถือกุญแจบัญชี Cloudflare

พอเว็บอยู่หลัง Cloudflare บัญชีนั้นจะกลายเป็นหนึ่งในกุญแจที่สำคัญที่สุดของธุรกิจครับ ใครล็อกอินได้ ก็เปลี่ยนได้ว่าเว็บชี้ไปที่ไหน อีเมลส่งไปที่ไหน

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

เรื่องนี้เราเจอกับตัวเองมาแล้วในอีกเครื่องมือหนึ่ง ตอนที่ TumWebSME ทำเว็บใหม่ เราพบว่า GA4 ตัวเก่าเป็น property ที่ไม่มีใครในทีมปัจจุบันมีสิทธิ์เข้าถึงเลย สุดท้ายต้องสร้าง property ของเราเองภายใต้บัญชี Analytics ของบริษัทเอง ข้อมูลเก่าก็ต้องปล่อยไป บัญชี Cloudflare ก็เสี่ยงแบบเดียวกันครับ เพียงแต่ถ้าเข้าไม่ได้ สิ่งที่หลุดมือไปคือการควบคุมเว็บและอีเมลทั้งหมด ซึ่งหนักกว่ารายงานมาก

ทำไมตั้งให้ถูกตั้งแต่วันแรกถึงคุ้มกว่า

การย้าย DNS ครั้งแรกคือช่วงเวลาที่ทุกอย่างถูกเขียนลงสมุดที่อยู่เล่มใหม่ ถ้าตอนนั้นมีคนนั่งเทียบ record ทีละบรรทัด เลือกโหมด SSL ให้ตรงกับ hosting และเปิดบัญชีในชื่อบริษัท งานที่เหลือหลังจากนั้นแทบจะไม่ต้องแตะอีกเลย

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

ขั้นต่ำที่เว็บ SME ควรมี

ถ้าให้ผมสรุปสิ่งที่พอดีสำหรับเว็บธุรกิจขนาดเล็กถึงกลาง ผมว่าไม่ต้องไปไกลกว่านี้ครับ ใช้แพ็กเกจฟรี เปิด proxy (เมฆสีส้ม) เฉพาะ record ที่เป็นเว็บ ตั้ง record อีเมลทุกตัวเป็น DNS only ใช้โหมด SSL แบบ Full (strict) ถ้า hosting มีใบรับรองอยู่แล้ว บัญชีอยู่ในอีเมลบริษัทและมีคนในทีมอย่างน้อยสองคนเข้าได้ และจดวันที่ย้ายไว้ เผื่อต้องย้อนดูว่าอะไรเปลี่ยนไปตอนไหน

แค่นี้ก็ได้ประโยชน์หลักของ CDN ครบแล้ว ฟีเจอร์ที่เหลือค่อยเปิดเมื่อมีปัญหาจริงที่ต้องแก้

ตัวอย่างจริงที่คุณเปิดดูได้เอง

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

อีกตัวอย่างหนึ่งเป็นเรื่องที่คนมักถามต่อ คือถ้า Cloudflare ล่มล่ะ คำตอบคือเคยเกิดขึ้นจริงครับ บล็อกของ Cloudflare เองเขียนรายงานเหตุการณ์ไว้ว่า วันที่ 18 พฤศจิกายน 2568 เวลาประมาณ 18:20 น. ตามเวลาไทย เครือข่ายของ Cloudflare เริ่มส่งทราฟฟิกไม่ได้ในวงกว้าง และทราฟฟิกหลักกลับมาเกือบปกติราว 21:30 น. สาเหตุมาจากไฟล์ตั้งค่าของระบบจัดการบอตที่ใหญ่ผิดปกติหลังมีการเปลี่ยนสิทธิ์ในฐานข้อมูล และ Cloudflare ยืนยันว่าไม่ได้เกิดจากการโจมตี ช่วงนั้นเว็บจำนวนมากที่อยู่หลัง Cloudflare ได้รับผลกระทบไปพร้อมกัน

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

เว็บของเราเองก็อยู่หลัง Cloudflare

เว็บ tumwebsme.com ที่คุณอ่านอยู่นี้วิ่งผ่าน Cloudflare ครับ วันที่ 29 กันยายน 2569 ผมลองเช็กจากเครื่องในทีม ข้อมูลที่ server ส่งกลับมาขึ้นว่า server: cloudflare และหน้า /cdn-cgi/trace ขึ้น colo=BKK แปลว่าคำขอถูกตอบจาก data center ในกรุงเทพฯ

ที่น่าสนใจคือตอนขอไฟล์ CSS ที่คุมหน้าตาเว็บครั้งแรก ค่า cf-cache-status ขึ้นว่า MISS คือคลังย่อยยังไม่มีของ ต้องวิ่งไปเอาจากครัวกลาง พอขอซ้ำทันที ค่าเดียวกันเปลี่ยนเป็น HIT คือหยิบจากคลังย่อยได้เลย ส่วนหน้าแรกของเว็บขึ้นว่า REVALIDATED ซึ่งในเอกสารของ Cloudflare หมายถึง origin ยืนยันแล้วว่าของไม่เปลี่ยน จึงส่งสำเนาที่เก็บไว้ให้ได้ นี่คือภาพเดียวกับคลังย่อยในร้านขนมเป๊ะเลยครับ

นอกจากเรื่อง cache เรายังใช้ Cloudflare ช่วยส่ง Google tag ผ่านเส้นทางของโดเมนเราเอง (Google tag gateway) คู่กับ Consent Mode v2 ด้วย แต่นั่นเป็นเรื่องของการวัดผลโฆษณา ขอยกไว้คุยวันหลังนะครับ

แผนห้าขั้น ถ้าทีมเว็บเสนอให้ย้ายไป Cloudflare

1. ถามก่อนว่าจะเปิดเพื่อแก้ปัญหาอะไร เว็บช้าเพราะอะไร โดนบอตหรือเปล่า แพลตฟอร์มที่ใช้อยู่มี CDN ให้แล้วหรือยัง

2. ให้ทีมเว็บจดรายการ DNS record เดิมทั้งหมดเก็บไว้ก่อนย้าย โดยเฉพาะ MX และ record ยืนยันตัวตนอีเมล แล้วเทียบกับที่ Cloudflare สแกนได้ทีละบรรทัด

3. เปิดบัญชี Cloudflare ด้วยอีเมลบริษัท แล้วเพิ่มทีมเว็บเป็นสมาชิก เช็กด้วยว่าคุณล็อกอิน registrar ได้เอง และ DNSSEC ปิดอยู่ก่อนเปลี่ยน nameserver

4. เลือกโหมด SSL ให้ตรงกับ hosting (Full หรือ Full (strict)) และนัดช่วงเวลาย้ายที่คนเข้าเว็บน้อย ไม่ใช่วันก่อนโปร

5. หลังย้ายเสร็จ ส่งอีเมลเข้าออกทดสอบ เปิดเว็บทั้งจากมือถือและคอมพิวเตอร์ แล้วเปิด /cdn-cgi/trace ดูว่ามี colo ขึ้น

วัดผลยังไงหลังเปิด

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

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

และถ้าวันไหนมีโปรใหญ่ ลองเปิด dashboard ดูในวันนั้น คุณจะเห็นเองว่าคลังย่อยช่วยรับคนไปได้มากแค่ไหนครับ

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

ถ้าคุณกำลังจะทำเว็บใหม่ และอยากให้เรื่อง hosting การตั้งค่า และการส่งมอบบัญชีต่างๆ อยู่ในมือทีมเดียวตั้งแต่วันแรก ลองดูรายละเอียดแพ็กเกจทำเว็บไซต์ของ TumWebSME ได้ครับ หรือถ้าเว็บเดิมกำลังจะย้าย DNS แล้วอยากมีคนช่วยดูรายการ record ก่อนกดเปลี่ยน ทักมาเล่าให้เราฟังได้เลย ผมยินดีช่วยดูด้วยกันครับ

ช่องทางการติดตาม TumWebSME

ติดตามสาระความรู้เรื่องการทำเว็บไซต์และการตลาดออนไลน์ได้ที่:

• Facebook: TumWebSME รับทำเว็บไซต์ธุรกิจ

• Instagram: @tumwebsme

• TikTok: @tumwebsme

• YouTube: TumWebSME

ติดต่องานและสอบถามบริการ

• 088-983-9386 (คุณพลอย)

• 099-856-3198 (คุณแสนนาน)