Custom domain สำหรับ SaaS: ให้ลูกค้าใช้โดเมนของตัวเองด้วย Cloudflare for SaaS

คำตอบสั้น ๆ

หากต้องการให้ลูกค้าใช้แอปของคุณบนโดเมนของตนเอง เช่น portal.customer.com คุณต้องลงทะเบียนโดเมนนั้นเป็น custom hostname ใน zone Cloudflare ของคุณ ลูกค้าเพิ่มเรกคอร์ด CNAME หนึ่งรายการที่ชี้มาหาคุณ Cloudflare ตรวจสอบว่าลูกค้าเป็นเจ้าของ hostname จริง จากนั้นcertificate authority จะออกใบรับรองให้ และคำขอก็จะเริ่มเข้าสู่แอปของคุณ

ณ เดือนตุลาคม 2026 หน้าแผนของ Cloudflare for SaaS ระบุว่าแผน Free, Pro และ Business รวม custom hostname 100 รายการ คิดค่าบริการ hostname เพิ่มเติมรายการละ $0.10 และจำกัดแผนเหล่านี้ไว้ที่ 50,000 hostname

ข้อจำกัดสองข้อที่กำหนดทุกการออกแบบ คือ ลูกค้าไม่สามารถชี้โดเมน apex เปล่า ๆ (customer.com) มาหาคุณได้ หากไม่ซื้อส่วนเสริม Enterprise แบบชำระเงิน และ wildcard custom hostname, ใบรับรองแบบกำหนดเอง และการเลือก certificate authority มีเฉพาะแผน Enterprise การตั้งค่าบน Cloudflare มีเพียงไม่กี่ขั้นตอน แต่งานด้านผลิตภัณฑ์ที่เกี่ยวข้องใช้เวลามากกว่า และคู่มือนี้ส่วนใหญ่จะพูดถึงเรื่องนั้น

Custom hostname คืออะไร

Custom hostname คือโดเมนที่ลูกค้าของคุณเป็นเจ้าของ และ Cloudflare ส่งทราฟฟิกเข้าสู่ zone ของคุณ คู่มือการตั้งค่าประกอบด้วยสี่ส่วน:

• SaaS zone โดเมนของคุณเองบน Cloudflare ที่เปิดใช้ Cloudflare for SaaS zone บนแผน Free ก็เพียงพอสำหรับการเริ่มต้น
• Fallback origin เรกคอร์ด DNS แบบ proxied เช่น proxy-fallback.yourapp.com ซึ่งเป็นปลายทางของทราฟฟิก custom hostname
• CNAME target ชื่อที่เป็นมิตรกว่าให้ลูกค้าชี้มาหา เช่น customers.yourapp.com (ไม่บังคับ)
• Custom hostname โดเมนของลูกค้า สร้างผ่าน API หรือแดชบอร์ด และมีสถานะการตรวจสอบของตัวเอง Cloudflare ออกใบรับรองสองใบสำหรับแต่ละรายการ คือใบหลัก ECDSA P-256 และใบสำรอง RSA 2048 บิตสำหรับไคลเอนต์รุ่นเก่า

หากแอปของคุณทำงานบน Cloudflare Workers ซึ่งเป็นแพลตฟอร์มที่ Dardo ใช้สร้างงาน Worker ก็สามารถเป็น fallback origin ได้ route แบบ */* จะรับคำขอของทุก custom hostname และโค้ดของคุณอ่าน header Host เพื่อระบุ tenant Cloudflare ยังมี custom metadata ต่อ hostname ด้วย แต่เป็นส่วนเสริม Enterprise แบบชำระเงิน ดังนั้นในแผนอื่นการค้นหานี้จึงอยู่ในฐานข้อมูลของคุณเอง เช่น D1

ขั้นตอนการทำงาน

1. ลูกค้ากรอกโดเมนในหน้าตั้งค่าของแอปคุณ แบ็กเอนด์ของคุณปรับรูปแบบให้เป็นมาตรฐาน แล้วเรียก endpoint Create Custom Hostname พร้อมวิธีตรวจสอบใบรับรอง
2. ลูกค้าเพิ่มเรกคอร์ด DNSที่คุณแสดงให้ เช่น portal.customer.com CNAME customers.yourapp.com
3. Cloudflare ตรวจสอบความเป็นเจ้าของ hostname Real-time validation จะทำงานเมื่อ CNAME ปรากฏ ซึ่งอาจทำให้เกิดช่วงหยุดให้บริการสั้น ๆ ส่วน pre-validation ใช้เรกคอร์ด TXT หรือโทเคน HTTP ก่อนเปลี่ยน DNS สำหรับโดเมนที่ใช้งานอยู่แล้ว Pre-validation ไม่รองรับเมื่อ zone ของลูกค้าเองก็อยู่บน Cloudflare เช่นกัน (การตั้งค่าแบบ "Orange-to-Orange")
4. Certificate authority ตรวจสอบการควบคุมโดเมนและออกใบรับรอง
5. hostname พร้อมใช้งานเมื่อ status และ ssl.status เป็น active ทั้งคู่ และ DNS ชี้มาที่ปลายทางของคุณ Cloudflare เตือนว่า TLS handshake อาจสำเร็จก่อนที่ ssl.status จะเป็น active จึงควรถือ endpoint รายละเอียด custom hostname เป็นแหล่งข้อมูลที่เชื่อถือได้

วิธีตรวจสอบใบรับรอง

คู่มือการตรวจสอบของ Cloudflare มีตัวเลือกดังนี้:

การตรวจสอบไม่ได้รอไปตลอด Cloudflare ลองตรวจสอบ hostname ซ้ำ 75 ครั้งในเจ็ดวัน และตามตารางการ backoff "หากการตรวจสอบไม่สำเร็จ custom hostname จะถูกลบ" โทเคนของใบรับรองก็หมดอายุเช่นกัน: 7 วันกับ Let's Encrypt และ 14 วันกับ Google Trust Services หรือ SSL.com

ค่าใช้จ่าย ณ เดือนตุลาคม 2026

หน้าแผนระบุ $0.10 โดยไม่ได้บอกรอบเวลา ประกาศเมื่อปี 2022 ของ Cloudflare อธิบายว่าเป็นการลดราคา "จาก $2 เหลือ $0.10 ต่อเดือน" ที่อัตรารายเดือนนี้ โดเมนลูกค้า 1,000 โดเมนหมายถึง 900 รายการที่เกินจาก 100 รายการที่รวมอยู่ หรือ $90 ต่อเดือน

กฎการเรียกเก็บเงินสองข้อที่สำคัญต่อการออกแบบผลิตภัณฑ์ ตามหน้าโควตาและการเรียกเก็บเงินของ Cloudflare ทุก hostname จะนับรวมในการใช้งานจนกว่าคุณจะลบ รวมถึง "hostname ที่รอการตรวจสอบหรือรอการเปิดใช้งาน" และแผนที่ไม่ใช่ Enterprise มีเกณฑ์บังคับใช้ของ API ซึ่งเมื่อเกินแล้ว hostname ใหม่จะถูกปฏิเสธ

จุดที่มักมีปัญหา

โดเมน apex

คู่มือการตั้งค่าของ Cloudflare ระบุไว้ชัดเจนว่า "By default, using an A record to point to the target is not a supported setup." ผู้ให้บริการ DNS ส่วนใหญ่ไม่อนุญาตให้ใช้ CNAME ที่ root ของโดเมน ลูกค้าจึงต้องใช้ซับโดเมน เช่น www.customer.com หรือ app.customer.com Apex proxying จะกำหนด static IP prefix ให้กับบัญชีของคุณ เพื่อให้ลูกค้าใช้ A record ได้ แต่เป็นส่วนเสริมสำหรับ Enterprise ที่มีค่าใช้จ่ายเพิ่มเติม หากไม่ใช้ ให้ขอซับโดเมนจากลูกค้า และอธิบายวิธีส่งต่อโดเมนเปล่าไปยังซับโดเมนนั้นที่ผู้ให้บริการ DNS ของลูกค้า

Certificate authority และ CAA record

เอกสารอ้างอิง certificate authority ของ Cloudflare ระบุว่าสำหรับ custom hostname มี Let's Encrypt (ใบรับรองอายุ 90 วัน), Google Trust Services และ SSL.com (14, 30 หรือ 90 วัน) การเลือก CA ทำได้เฉพาะ Enterprise เท่านั้น นอกจากนี้ Cloudflare จะใช้ค่าเริ่มต้นและตรวจสอบ CAA record ก่อน หาก CAA record ของลูกค้าไม่อนุญาต CA นั้น การออกใบรับรองจะล้มเหลวพร้อมข้อความ "CAA records block issuance" และมีเพียงลูกค้าเท่านั้นที่แก้ไขได้ การค้นหา CAA จะตามไปตามสาย CNAME ดังนั้น CAA record ของโดเมนปลายทางของคุณเองก็มีผลด้วย คู่มือแก้ไขปัญหา ระบุข้อผิดพลาดอื่นๆ ที่เกิดจากฝั่งลูกค้า ได้แก่ DNSSEC ที่ใช้งานไม่ได้ และเซิร์ฟเวอร์ DNS ที่ตอบกลับ SERVFAIL

การต่ออายุ

ใบรับรองของ custom hostname มีอายุ 90 วัน และสามารถต่ออายุได้ก่อนหมดอายุ 30 วัน hostname ที่ยังใช้งานอยู่และไม่ใช่ wildcard จะต่ออายุอัตโนมัติผ่าน HTTP หาก hostname ไม่ได้ใช้งานแล้ว เช่น เพราะลูกค้าเปลี่ยน DNS ลูกค้าต้องวางโทเคนใหม่ และคุณมีหน้าที่ส่งโทเคนนั้นให้ลูกค้า ส่วน wildcard ต่ออายุได้ผ่าน TXT เท่านั้น ซึ่งเป็นสิ่งที่ Delegated DCV ทำให้อัตโนมัติ

ลูกค้าที่ใช้ CDN อื่นหรือใช้ Cloudflare

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

Worker ที่อยู่หน้าเส้นทางการตรวจสอบ

หาก Worker เป็น fallback origin ของคุณ จะต้องส่ง /.well-known/pki-validation/* และ /.well-known/acme-challenge/* ผ่านไปโดยไม่เปลี่ยนแปลง route แบบ catch-all ที่ตอบกลับด้วยหน้า 404 ของแอปจะทำให้การตรวจสอบผ่าน HTTP ล้มเหลว

งานด้านผลิตภัณฑ์ที่เกี่ยวข้อง

• การบังคับใช้ตามแพ็กเกจ กำหนดว่าแพ็กเกจใดของคุณรวมโดเมนที่กำหนดเองและได้กี่โดเมน แล้วตรวจสอบก่อนเรียก Cloudflare โควตาและเกณฑ์ของ Cloudflare เป็นเพียงเพดาน ไม่ใช่ราคาของคุณ
• หน้าจอ onboarding ใช้ช่องกรอกเดียว แปลงเป็นตัวพิมพ์เล็ก ตัดโปรโตคอลและพาธออก ปฏิเสธโดเมน apex เปล่า เว้นแต่คุณซื้อ apex proxying และปฏิเสธชื่อ zone ของคุณเอง ซึ่ง Cloudflare ระบุว่าไม่ควรสร้างเป็น custom hostname จากนั้นแสดง record ที่ต้องเพิ่มอย่างชัดเจน พร้อมปุ่มคัดลอก
• สองสถานะด้วยภาษาที่เข้าใจง่าย hostname และใบรับรองตรวจสอบแยกกัน จึงควรแสดงทั้งสองอย่าง แปลง ssl.validation_errors เป็นคำแนะนำ: "CAA record ของโดเมนคุณไม่อนุญาต certificate authority ของเรา โปรดเพิ่ม record นี้" ดีกว่า "pending_validation" คำตอบจากการสร้างอาจยังไม่มี validation record จึงควรดึงข้อมูล hostname อีกครั้งหลังหน่วงเวลาสั้นๆ การแจ้งเตือนผ่าน webhook ของ Cloudflare รายงานเหตุการณ์การตรวจสอบและการออกใบรับรอง ซึ่งดีกว่าการ polling
• การเฝ้าติดตามการต่ออายุ งานที่รันทุกวันเพื่อแจ้งเตือน hostname ที่ใบรับรองไม่ active หรือ DNS ไม่ชี้มาที่คุณแล้ว เพื่อให้ทีมของคุณรู้ก่อนลูกค้า
• การล้างข้อมูล ลบ hostname ที่ไม่เคยผ่านการตรวจสอบ และของลูกค้าที่เลิกใช้บริการ ทั้งสองแบบยังคิดค่าบริการจนกว่าจะลบ
• การแยก tenant ระบุ tenant จาก hostname ที่ active ในฐานข้อมูลของคุณเท่านั้น หาก tenant ได้ซับโดเมนของโดเมนคุณด้วย เอกสารเรื่องโดเมน ของ Vercel ชี้ว่าคุกกี้ที่ tenant หนึ่งตั้งไว้ที่โดเมนหลักจะส่งไปถึง tenant อื่นด้วย จึงควรแยกแดชบอร์ดและหน้าล็อกอินไว้อีกโดเมนหนึ่ง
• คู่มือฝ่ายซัพพอร์ต หน้าสั้นๆ สำหรับทีมของคุณที่จับคู่ข้อผิดพลาดแต่ละแบบกับผู้แก้ไข: CNAME ที่หายไป, CAA, DNSSEC และ SERVFAIL เป็นหน้าที่ของลูกค้า ส่วนโทเคน ขีดจำกัดอัตราของ CA และ route ของ Worker เป็นหน้าที่ของคุณ

นี่คืองานประเภทที่ Dardo ทำในด้านการพัฒนาเว็บแอป และพอร์ทัลลูกค้าแบบ white-label คือที่ที่ลูกค้าขอใช้โดเมนที่กำหนดเองบ่อยที่สุด

ทางเลือกอื่น: Vercel และ Netlify

หากแอปของคุณรันอยู่ที่อื่นอยู่แล้ว ทั้งสองโฮสต์รองรับโดเมนของลูกค้าได้ โดยมีขีดจำกัดตามที่เอกสารระบุ ณ เดือนตุลาคม 2026

การรองรับ apex ของ Vercel คือความแตกต่างที่ชัดเจนที่สุด: ลูกค้าสามารถชี้โดเมนเปล่ามาที่ Vercel ด้วย A record ได้ โปรดทราบว่าแพ็กเกจ Hobby จำกัดไว้สำหรับ "non-commercial, personal use only" ตามแนวปฏิบัติการใช้งานที่เป็นธรรมของ Vercel ดังนั้น SaaS ที่มีลูกค้าจ่ายเงินต้องเริ่มที่ Pro ส่วนคำแนะนำของ Netlify ที่ให้ใช้ไม่เกิน 50 alias ทำให้ไม่เหมาะกับการ deploy ชุดเดียวที่ให้บริการโดเมนของลูกค้าหลายร้อยโดเมน

เมื่อไรควรสร้างระบบนี้

หากมีลูกค้าขอสองถึงสามราย ให้เพิ่ม hostname ของพวกเขาใน Cloudflare dashboard แล้วทำเช็กลิสต์ไว้ ควรสร้างขั้นตอนแบบให้ลูกค้าทำเองเมื่อโดเมนที่กำหนดเองกลายเป็นส่วนหนึ่งของแพ็กเกจที่คุณขาย หรือของข้อเสนอแบบ white-label หากลูกค้าต้องการโดเมน apex เปล่าหรือ wildcard ในระดับใหญ่ ควรคุยกับ Cloudflare เรื่อง Enterprise ก่อนออกแบบระบบรอบขีดจำกัดเหล่านั้น

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