3 นาที

การตั้งค่าโดเมนที่กำหนดเองสำหรับเว็บแอป: DNS, SSL และการย้ายแบบปลอดความเสี่ยง

Q: ควรใช้โดเมนหลักเป็น apex หรือ www?

Default to one canonical hostname and redirect everything else to it. - Choose either (apex) or as the “real” one. - Treat the other as a single 301 redirect. This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.

Q: ควรลด DNS TTL เมื่อไหร่ก่อนการสลับโดเมน?

Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out. - Common cutover TTL: 300–600 seconds - After the move is stable: raise TTL back up (often 1–4 hours ) Only lower TTL on the records you’re actually going to change.

Q: ควรใช้ระเบียน DNS แบบไหน: A, CNAME หรือ ALIAS?

For many app setups: - Use CNAME for subdomains like or when you’re pointing to a provider hostname. - Use A (or ALIAS/ANAME if your DNS supports it) for the apex . Avoid trying to force a CNAME at the apex if your DNS host doesn’t support an apex alias style record.

Q: ต้องเตรียม SSL ให้พร้อมก่อนเปลี่ยน DNS หรือไม่?

Don’t switch user traffic until HTTPS is valid on the new hostname(s) . A practical order: - Add the domain in your host/platform (for example, in Koder.ai custom domain settings) - Complete domain verification (often via TXT) - Wait until the certificate is issued for every hostname you’ll serve - Only then update DNS to send real users there This avoids browser warnings and blocked requests right at cutover.

Q: ต้องอัพเดตการตั้งค่า auth และ SSO อะไรก่อนเปลี่ยนโดเมน?

Update identity settings before cutover. Typical items that must match the new domain exactly: - OAuth/SSO redirect (callback) URLs - Allowed origins / CORS settings - Any allowlisted logout URLs If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.

การตั้งค่าโดเมนที่กำหนดเองสำหรับเว็บแอป พร้อมขั้นตอนเรคอร์ด DNS ชัดเจน การออก SSL กฎการเปลี่ยนเส้นทาง และแผนการย้ายแบบความเสี่ยงต่ำเพื่อหลีกเลี่ยงการหยุดทำงานและปัญหาคุกกี้

สิ่งที่การมีโดเมนที่กำหนดเองเปลี่ยนไป (และสิ่งที่อาจพัง)

โดเมนที่กำหนดเองไม่ใช่แค่ URL ที่สวยกว่าเท่านั้น ทันทีที่คุณย้ายจากที่อยู่ของแพลตฟอร์ม (เช่น แอปที่คุณสร้างบน Koder.ai ภายใต้ซับโดเมนของแพลตฟอร์ม) ไปยังโดเมนของตัวเอง เบราว์เซอร์และเครือข่ายจะถือว่าเป็นไซต์คนละตัว ซึ่งส่งผลต่อการนำทาง ความปลอดภัย และพฤติกรรมของเซสชันผู้ใช้

เมื่อคุณสลับมาใช้โดเมนที่กำหนดเอง จะมีสิ่งที่เปลี่ยนแปลงทันทีไม่กี่อย่าง:

การนำทาง DNS: ผู้ใช้จะไม่ไปยังโฮสต์เนมเก่าอีกต่อไป แต่จะไปยังเป้าหมายที่ DNS ของคุณชี้ไป
TLS/SSL: ใบรับรองต้องตรงกับโฮสต์เนมใหม่ และต้องพร้อมใช้งานก่อนที่ผู้ใช้จริงจะมาถึง
การเปลี่ยนเส้นทาง: คุณต้องตัดสินใจว่าผู้ใช้จะไปที่ www หรือโดเมน apex และต้องมีนโยบาย HTTP → HTTPS ที่สอดคล้อง
คุกกี้และเซสชัน: คุกกี้ถูกจำกัดขอบเขตตามโดเมน คุกกี้ล็อกอินสำหรับ old-platform.example จะไม่ทำงานโดยอัตโนมัติบน app.yourdomain.com
แคชและการแพร่กระจาย: เราโซลเวอร์ DNS และเบราว์เซอร์แคชผลลัพธ์ ดังนั้นจะไม่ใช่ทุกคนที่สลับพร้อมกัน

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

การเปลี่ยนเส้นทางยังอาจทำให้การเข้าสู่ระบบพังแบบละเอียดได้ การเปลี่ยนโฮสต์เนมระหว่างการเปลี่ยนเส้นทาง (apex → www หรือกลับกัน) อาจทำให้คุกกี้ถูกทิ้งได้ถ้าคุกกี้ถูกตั้งไว้สำหรับโฮสต์อื่น ผู้ให้บริการการพิสูจน์ตัวตนอาจล้มเหลวหาก URL ที่ส่งกลับยังชี้ไปที่โดเมนเก่า

การย้ายแบบความเสี่ยงต่ำหมายถึงการวางแผนเพื่อความทับซ้อน: ให้ URL เก่ายังคงใช้งานได้ นำโดเมนใหม่ขึ้นพร้อมกัน สลับทราฟฟิกในเวลาที่คาดการณ์ได้ และทำให้การย้อนกลับเป็นเรื่องง่ายเพียงแค่เปลี่ยน DNS กลับ

ตัดสินใจโดเมนและโฮสต์เนมก่อนแตะ DNS

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

เริ่มจากการเลือกใหญ่: apex (example.com) หรือ www (www.example.com) เป็นหลัก ทั้งสองทำงานได้ แต่ให้เลือกหนึ่งและถืออีกอันเป็น redirect สิ่งนี้สำคัญสำหรับคุกกี้ด้วย: เซสชันมักง่ายที่สุดเมื่อแอปอยู่บนโฮสต์ที่สอดคล้องกัน

ถัดไป ตัดสินใจว่าคุณต้องการซับโดเมนใดตอนนี้ และอันไหนรอได้ รูปแบบทั่วไปคือ app.example.com สำหรับเว็บแอป และ api.example.com สำหรับ API โดยเพิ่ม admin.example.com หรือ assets.example.com ภายหลัง หากคุณกำลังตั้งค่าโดเมนที่กำหนดเองบนแพลตฟอร์มอย่าง Koder.ai ตัวเลือกเหล่านี้จะสะท้อนตรงกับสิ่งที่คุณต้องตรวจสอบสำหรับ SSL และสิ่งที่คุณจะชี้ใน DNS

รู้ว่าใครเป็นผู้ควบคุม DNS จริง ๆ

หลายคนซื้อโดเมนจากผู้จดทะเบียน แต่ DNS อาจโฮสต์ที่อื่น ยืนยันว่าระเบียนถูกแก้ไขที่ไหน วันนี้ใครมีสิทธิ์เข้าใช้งาน และมีระบบอัตโนมัติใด ๆ ควบคุมการเปลี่ยนแปลงหรือไม่ (IT ของบริษัท เอเจนซี หรือผู้ให้บริการ DNS ที่จัดการ) หากคุณไม่สามารถล็อกอินและดูเรคอร์ดปัจจุบันได้ ให้หยุดและแก้ไขเรื่องนั้นก่อน

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

ก่อนดำเนินการ จดการตัดสินใจเหล่านี้เป็นลายลักษณ์อักษร:

โฮสต์เนมหลัก (apex หรือ www) และทิศทางการเปลี่ยนเส้นทาง
ซับโดเมนที่จำเป็นตอนนี้ (app, api, admin) เทียบกับไอเดียภายหลัง
ที่ที่ DNS โฮสต์และใครสามารถเผยแพร่การเปลี่ยนแปลง
เรคอร์ดสำคัญที่มีอยู่แล้ว (MX, SPF, DKIM, DMARC, TXT ยืนยัน)
ความคาดหวังเรื่องคุกกี้และการพิสูจน์ตัวตน (โฮสต์เดียวเทียบกับแชร์ข้ามซับโดเมน)

ถ้าทีมการตลาดใช้เมลบน example.com อยู่ ให้เก็บเรคอร์ดที่เกี่ยวกับเมลไว้ไม่ต้องแตะในขณะที่คุณเพิ่มเฉพาะสิ่งที่แอปต้องการ

เรคอร์ด DNS ที่คุณจะใช้และทำไมมันสำคัญ

ความเสี่ยงส่วนใหญ่ในการย้ายโดเมนที่กำหนดเองไม่ใช่ตัวแอป แต่เป็นการเปลี่ยนแปลง DNS ผิดตัวที่ส่งทราฟฟิกไปยังที่ว่าง ทำให้อีเมลพัง หรือทำให้การตรวจสอบ SSL ล้มเหลว

เรคอร์ดหลัก (A, CNAME และที่เกี่ยวข้อง)

A record ชี้ชื่อไปยังที่อยู่ IP พูดง่าย ๆ ว่า: “ส่งคนไปยังเซิร์ฟเวอร์นี้” มักใช้สำหรับ apex (example.com) เมื่อผู้ให้บริการให้ IP คงที่

CNAME record ชี้ชื่อนึงไปยังอีกชื่อหนึ่ง พูดง่าย ๆ ว่า: “ถือชื่อนี้เป็นนามแฝงของโฮสต์นั้น” มักใช้กับ www.example.com ที่ชี้ไปยังโฮสต์เนมของแพลตฟอร์ม

ผู้ให้บริการ DNS บางรายยังมี ALIAS/ANAME สำหรับ apex ซึ่งทำงานเหมือน CNAME แต่ใช้ได้กับ example.com ถ้าผู้ให้บริการรองรับ มันอาจจัดการได้ง่ายกว่าเพราะเป้าหมายสามารถเปลี่ยนได้โดยไม่ต้องแก้ IP

โมเดลง่าย ๆ ในใจ:

A: name -> IP (ตรง)
CNAME: name -> name (นามแฝง)
TXT: name -> ข้อความ (เพื่อพิสูจน์และนโยบาย)
MX: name -> เซิร์ฟเวอร์อีเมล (อย่าแตะถ้าไม่ได้ตั้งใจ)

TXT records: การยืนยัน ความปลอดภัยของ SSL และอีเมล

คุณมักจะเพิ่ม TXT สำหรับการตรวจสอบความเป็นเจ้าของโดเมน (การยืนยันแพลตฟอร์ม) และสำหรับ การตรวจสอบใบรับรอง SSL (CA บางแห่งยืนยันผ่านโทเค็น TXT) TXT ยังใช้สำหรับนโยบายอีเมลเช่น SPF การลบหรือเขียนทับ SPF ที่มีอยู่โดยไม่ได้ตั้งใจอาจทำให้การส่งเมลพัง

TTL: ปรับความเร็วการเปลี่ยนของคุณ

TTL ควบคุมว่าระบบอื่น ๆ จะแคชคำตอบ DNS นานเท่าไร หนึ่งวันก่อนการย้าย ให้ลด TTL สำหรับเรคอร์ดที่จะเปลี่ยน (โดยทั่วไป 300–600 วินาที) หลังทุกอย่างเสถียร ให้เพิ่มกลับเพื่อลดโหลดการสืบค้น

หลีกเลี่ยงการเขียนทับเรคอร์ดที่มีอยู่ และบันทึกแผนการย้อนกลับ

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

เรื่องนี้สำคัญที่สุดเมื่อโดเมนของคุณมี MX, DKIM หรือ TXT อื่น ๆ สำหรับอีเมล

การออก SSL: การยืนยัน เวลา และความครอบคลุม

SSL (ไอคอนรูปกุญแจ) เข้ารหัสการสื่อสารระหว่างเบราว์เซอร์กับแอปของคุณ เบราว์เซอร์สมัยใหม่และ API จำนวนมากคาดหวัง HTTPS เป็นค่าเริ่มต้น หากไม่มี HTTPS คุณอาจเจอคำเตือน บล็อกคำขอ และฟีเจอร์บางอย่างจะหยุดทำงาน

เพื่อออกใบรับรอง CA ต้องยืนยันว่าคุณควบคุมโดเมน วิธีการยืนยันทั่วไปคือการยืนยันผ่าน HTTP และ TXT ใน DNS:

HTTP validation วางไฟล์ชั่วคราวหรือตอบที่ URL ที่กำหนดบนแอปของคุณ
DNS TXT validation เพิ่มเรคอร์ด TXT ในโซน DNS ของคุณ

การยืนยันผ่าน DNS มักง่ายกว่าเมื่อคุณใช้ CDN หรือเมื่อแอปของคุณยังไม่สามารถเข้าถึงโดเมนใหม่ได้

ที่ไหนออกใบรับรองขึ้นกับการตั้งค่าของคุณ บางทีมออกใบรับรองตรงบนสแตกโฮสติ้ง บางทีมออกที่ CDN และบางแพลตฟอร์มที่รองรับโดเมนกำหนดเองจะจัดการให้ (เช่น Koder.ai สามารถจัดการใบรับรองระหว่างการตั้งค่าโดเมน) สิ่งสำคัญคือรู้ว่าใครเป็นเจ้าของวงจรชีวิตของใบรับรอง รวมถึงการต่ออายุ

เวลาและการลองซ้ำ

การออกใบรับรองไม่เสมอไปทันที การแพร่กระจาย DNS การตรวจสอบ และข้อจำกัดอัตราอาจช้าลง วางแผนสำหรับการลองซ้ำและหลีกเลี่ยงการตั้งเวลา cutover ในวินาทีสุดท้าย

แผนเวลาที่ใช้ได้จริง:

ลด TTL ล่วงหน้าหนึ่งวันเพื่อให้การเปลี่ยนแปลงใช้เร็วขึ้น
เพิ่มเรคอร์ดยืนยันล่วงหน้า (DNS TXT หรือโทเค็น HTTP)
รอจนกว่าใบรับรองแสดงว่าออกแล้วสำหรับทุกโฮสต์เนม
จากนั้นค่อยชี้ทราฟฟิกไปยังเป้าหมายใหม่

ความครอบคลุม: ตรวจสอบให้แน่ใจว่าโฮสต์เนมที่ถูกต้องถูกรวม

ใบรับรองต้องครอบคลุมทุกโฮสต์เนมที่ผู้ใช้จะเข้าถึง ตรวจสอบรายการ SAN (Subject Alternative Names) หากแอปของคุณจะเปิดทั้ง example.com และ www.example.com ใบรับรองต้องรวมทั้งสอง

ไวด์การ์ด (เช่น *.example.com) ช่วยสำหรับหลายซับโดเมน แต่จะไม่ครอบคลุมโดเมน apex (example.com)

ตัวอย่างที่ชัดเจน: ถ้าคุณออกใบรับรองเฉพาะสำหรับ www.example.com ผู้ใช้ที่พิมพ์ example.com จะเห็นคำเตือนเว้นแต่คุณจะเปลี่ยนเส้นทางที่ชั้นที่มีใบรับรองถูกต้องสำหรับ example.com อยู่แล้ว

กฎการเปลี่ยนเส้นทาง: www, apex, HTTP → HTTPS และค่าเริ่มต้นที่ปลอดภัย

Own your stack

Keep full control by exporting source code anytime, even after you move domains.

Export Code

การเปลี่ยนเส้นทางฟังดูง่าย แต่มักเป็นจุดที่ปัญหาโดเมนปรากฏ: การวนลูป เนื้อหาผสม (mixed content) และผู้ใช้ถูกล็อกออกเพราะเด้งระหว่างโฮสต์เนม

เลือกโฮสต์หลักเพียงตัวเดียวและยึดตามมัน: www.example.com หรือ example.com (apex) อีกทางเข้าอื่นควรถูกเปลี่ยนเส้นทางไปยังโฮสต์หลักเพื่อให้สัญญาณ SEO คุกกี้และเซสชันสอดคล้องกัน

ค่าเริ่มต้นที่ปลอดภัย:

โฮสต์หลักหนึ่งตัว พร้อมการเปลี่ยนเส้นทาง 301 เดียวจากโฮสต์อื่น
301 จาก http:// ไป https:// สำหรับทุกคำขอ
รักษา path และ query string เต็มรูปแบบระหว่างการเปลี่ยนเส้นทาง (deep link ต้องยังใช้งานได้)
เปลี่ยนเส้นทางเพียงครั้งเดียว (หลีกเลี่ยง chain เช่น http -> https -> www)

สำหรับ HTTP → HTTPS ให้หลีกเลี่ยงกฎที่ทำให้ผู้ใช้เด้งกลับไปมา วิธีที่ง่ายที่สุดคืออิงการตัดสินใจตามสิ่งที่คำขอเป็นจริง หากแอปของคุณอยู่หลังพร็อกซีหรือ CDN ให้ตั้งค่าให้เคารพ forwarded headers (เช่น header ที่บอกว่าสกีมเดิมคือ HTTP) มิฉะนั้นแอปของคุณอาจคิดว่าคำขอทุกอันเป็น HTTP และเปลี่ยนเส้นทางตลอดเวลา

ระหว่างการย้าย ให้คงเส้นทางเก่าไว้ หากคุณเปลี่ยนเส้นทางเส้นทาง (เช่น /login → /sign-in) ให้เพิ่มการเปลี่ยนเส้นทางเฉพาะสำหรับเส้นทางนั้น อย่าพึ่งพาการเปลี่ยนเส้นทางรวมไปยังหน้าแรก มันทำลายบุ๊กมาร์กและลิงก์ที่แชร์

เลื่อนการเปิดใช้งาน HSTS ไว้ก่อน ถ้าคุณเปิดใช้เร็วเกินไปและต่อมาจำเป็นต้องให้บริการ HTTP เพื่อการตรวจสอบหรือแก้ปัญหา เบราว์เซอร์อาจปฏิเสธ รอจนกว่า HTTPS จะเสถียรและยืนยันความครอบคลุมซับโดเมนแล้ว

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

แผนการย้ายทีละขั้นตอนแบบความเสี่ยงต่ำ (ไม่มีเวลาหยุดทำงาน)

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

1) เตรียมและทดสอบก่อนแตะ DNS ผลิตจริง

ลด DNS TTL (สำหรับเรคอร์ดที่จะเปลี่ยน) ล่วงหน้า ทำได้วันที่ก่อนหน้าถ้าเป็นไปได้ แล้วรอให้ช่วง TTL เก่าหมดเพื่อให้แคชมีเวลาปรับ

จากนั้นเพิ่มโดเมนที่กำหนดเองในโฮสต์/ผู้ให้บริการของคุณและทำการยืนยันตามที่พวกเขาต้องการ หากคุณใช้แพลตฟอร์มอย่าง Koder.ai ให้เพิ่มโดเมนที่นั่นก่อนเพื่อให้แพลตฟอร์มยืนยันความเป็นเจ้าของและเตรียมการนำทาง

ออก SSL ให้เร็ว ใบรับรองอาจใช้เวลาหลายนาทีหรือนานกว่านั้นตามการยืนยัน และคุณไม่ต้องการความล่าช้านั้นในระหว่างการสลับ

ก่อนทำให้โดเมนเป็นสาธารณะ ให้ทดสอบแบบส่วนตัว: เข้าถึง endpoint ใหม่โดยไม่พึ่งพา DNS สาธารณะ (เช่น ใช้ host entry ชั่วคราวบนเครื่องของคุณ) และยืนยันว่าไซต์โหลดผ่าน HTTPS ด้วยใบรับรองที่ถูกต้อง

2) ย้ายเป็นขั้นตอนเล็ก ๆ ที่ย้อนกลับได้

ใช้วิธีแบบเป็นขั้นตอนเพื่อให้คุณหยุดได้อย่างรวดเร็วหากมีอะไรผิดพลาด:

ลด TTL ล่วงหน้า แล้วรอจนกว่าช่วง TTL เดิมจะหมด
ทำการยืนยันโดเมนในโฮสต์ของคุณและยืนยันว่าโดเมนชี้ไปยังแอปที่ถูกต้องภายใน
ยืนยันว่า SSL พร้อมใช้งานสำหรับทุกโฮสต์เนมที่คุณจะให้บริการ (apex และ/หรือ www) ก่อนสลับผู้ใช้
เปลี่ยน DNS ในทางที่ควบคุมได้: เริ่มจากซับโดเมน หนึ่งภูมิภาค หรือเส้นทางผู้ใช้กลุ่มเล็ก ๆ หากเป็นไปได้
ให้โดเมนเก่ายังคงออนไลน์และเปลี่ยนเส้นทางในขณะที่คุณเฝ้าดูทราฟฟิกและอัตราข้อผิดพลาดให้เสถียร

ถ้าคุณไม่สามารถทำ canary จริง ๆ ในระดับ DNS ได้ คุณยังสามารถสเตจโดยการสลับโฮสต์เนมเดียวก่อน (เช่น www) และปล่อยให้ apex อยู่จนกว่าคุณมั่นใจ

3) วางแผนการย้อนกลับขณะที่คุณยังใจเย็น

จดให้ชัดว่าอะไรที่จะย้อนกลับ (เรคอร์ดไหน ค่าอะไร) และใครจะทำ การย้อนกลับมักเป็นการคืนค่า DNS ให้เหมือนเดิม

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

หลีกเลี่ยงคุกกี้ เซสชัน และการพิสูจน์ตัวตนที่พังหลังย้าย

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

การตั้งค่าคุกกี้เป็นสาเหตุหลัก:

Domain กำหนดว่าโฮสต์เนมไหนจะได้รับคุกกี้ คุกกี้ที่ตั้งไว้สำหรับ app.old.com จะไม่ถูกส่งไปยัง app.new.com คุกกี้ที่ตั้งไว้สำหรับ .example.com สามารถทำงานข้าม app.example.com และ www.example.com ได้
Path จำกัดที่ที่คุกกี้ถูกส่ง ถ้าแคบเกินไป (เช่น /api) UI เว็บของคุณอาจมองไม่เห็น
Secure หมายความว่าคุกกี้ถูกส่งเฉพาะผ่าน HTTPS หลังย้ายเป็น HTTPS เท่านั้น คำขอ HTTP จะไม่รวมคุกกี้
SameSite มีผลต่อการเปลี่ยนเส้นทางข้ามไซต์และฟลว์ฝังตัว Lax มักโอเค แต่ SSO หรือการชำระเงินบางแบบอาจต้อง None พร้อม Secure

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

หากคุณใช้ SSO หรือ OAuth ให้ปรับการตั้งค่าก่อนการย้าย: callback URLs, allowed origins และ allowlists ของ redirect URI มิฉะนั้นการล็อกอินอาจสำเร็จที่ผู้ให้บริการแต่ล้มเหลวเมื่อกลับมายังแอปของคุณ

ทดสอบฟลว์ที่มักพังก่อน: ลงทะเบียน (และการยืนยันอีเมล), เข้าสู่ระบบ/ออก, รีเซ็ตรหัสผ่าน, เช็คเอาต์หรือการคืนค่าชำระเงิน และการใช้งานแบบหลายแท็บ

ตัวอย่าง: ถ้าคุณเปลี่ยน www.example.com ไปที่ example.com ให้แน่ใจว่าคุกกี้ถูกตั้งสำหรับ .example.com (หรือใช้โฮสต์เดียวอย่างสม่ำเสมอ) มิฉะนั้นผู้ใช้จะเด้งระหว่างโฮสต์และเสียเซสชัน

ความผิดพลาดทั่วไปที่ทำให้เกิดการหยุดทำงานหรือพฤติกรรมแปลก ๆ

Build the app first

Turn your plan into a React web app with a Go backend through a simple chat.

Create App

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

กับดักง่าย ๆ คือโดเมน apex (example.com) ผู้ให้บริการ DNS หลายรายไม่อนุญาตให้ใช้ CNAME ที่ apex หากคุณพยายามชี้ apex เป็น CNAME อาจล้มเหลวเงียบ ๆ แก้ไม่สม่ำเสมอ หรือพังเฉพาะบนเครือข่ายบางแห่ง ใช้สิ่งที่โฮสต์ DNS ของคุณรองรับ (มักเป็น A/AAAA หรือ ALIAS/ANAME)

สาเหตุทั่วไปอีกอย่างของการหยุดทำงานคือการพลิก DNS ก่อนที่ SSL จะพร้อมบน endpoint ใหม่ ผู้ใช้มาถึง แอปโหลดได้ แล้วเบราว์เซอร์ก็บล็อกเพราะใบรับรองหายไปหรือครอบคลุมแค่บางโฮสต์เนม ในทางปฏิบัติ คุณมักต้องการให้ใบรับรองครอบคลุมทั้ง example.com และ www.example.com แม้ว่าคุณจะวางแผนเปลี่ยนเส้นทางอันหนึ่งไปยังอีกอันก็ตาม

ความผิดพลาดทั่วไปที่ทำให้หยุดทำงานหรือพฤติกรรมแปลก ๆ:

เปลี่ยน DNS โดยไม่ลด TTL ล่วงหน้า แล้วต้องรอนานกว่าจะหมดอายุคำตอบเก่า
เก็บกฎเปลี่ยนเส้นทางที่สร้างลูป (www → apex แล้ว apex กลับไป www) หรือบังคับ HTTP ในที่หนึ่งและ HTTPS ในอีกที่หนึ่ง
ส่งเนื้อหาผสมโดยการ hardcode http:// สำหรับแอสเซ็ต ซึ่งทำให้เกิดคำเตือนของเบราว์เซอร์และฟีเจอร์พัง
ลืมเรคอร์ด DNS ที่ไม่ใช่เว็บ โดยเฉพาะ MX และ TXT ซึ่งอาจทำให้อีเมลและการยืนยันโดเมนพัง
ทดสอบแค่เบราว์เซอร์เดียวและพลาด HSTS หรือปัญหาคุกกี้ที่ผู้ใช้จริงจะเจอ

การตรวจสอบสั้น ๆ: เปิดทั้งสองโฮสต์เนม (www และ apex) ผ่าน HTTPS ลงชื่อเข้าใช้ รีเฟรช และยืนยันว่าที่อยู่ในแถบไม่เปลี่ยนกลับเป็น HTTP

ถ้าคุณทำสิ่งนี้บนแพลตฟอร์มอย่าง Koder.ai ให้ยืนยันว่าโดเมนที่กำหนดเองเชื่อมต่อและ SSL ถูกออกก่อนแตะ DNS ผลิตจริง และเตรียมตัวเลือกการย้อนกลับไว้เพื่อให้การเปลี่ยนเส้นทางหรือการเปลี่ยนเรคอร์ดที่ไม่ดีไม่ค้างคาอยู่

เช็คลิสต์ด่วน ก่อน ระหว่าง และหลังการย้าย

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

ก่อนการย้าย

ทำสิ่งเหล่านี้เมื่อทราฟฟิกยังไปที่โดเมนเก่า ให้เวลาอย่างน้อยหนึ่งวันถ้าเป็นไปได้เพื่อให้การเปลี่ยนแปลง DNS ตั้งตัว

ลด DNS TTL (สำหรับเรคอร์ดที่จะเปลี่ยน) และจดค่าปัจจุบันไว้เพื่อคืนค่าได้เร็ว
จดทุกโฮสต์เนมที่จะให้บริการ (apex, www, api ฯลฯ) และเลือกวิธีการยืนยัน SSL (DNS หรือ HTTP)
เตรียมกฎการเปลี่ยนเส้นทางและทดสอบในสเตจ: HTTP → HTTPS, www → apex (หรือกลับกัน), และโฮสต์หลักเดียว
อัพเดตการตั้งค่า auth ที่ขึ้นกับ URL ที่แน่นอน: OAuth callback URLs, allowed origins, การตั้งค่าคุกกี้ และ SSO ที่เกี่ยวข้อง
ตัดสินใจว่าใครเฝ้าดูอะไรในระหว่างการย้าย (ล็อก, การตรวจสอบสถานะ, กล่องจดหมายสนับสนุน) และตั้งช่วงเวลาสั้น ๆ สำหรับการเปลี่ยนแปลง

ระหว่างและหลังการย้าย

เมื่อคุณพลิก DNS ให้ถือชั่วโมงแรกเหมือนการซ้อมรับมือเหตุ ดูฟลว์ผู้ใช้จริง ไม่ใช่แค่แดชบอร์ดสถานะ

ระหว่าง: เฝ้าดูการพุ่งของ 4xx/5xx, ลูปการเปลี่ยนเส้นทาง และความล้มเหลวในการเข้าสู่ระบบ (โดยเฉพาะข้อความ “invalid redirect URI” หรือการตกของเซสชันอย่างฉับพลัน)
หลัง: ยืนยันโซ่ใบรับรองถูกต้องในหลายเบราว์เซอร์ และหน้าสำคัญโหลดผ่าน HTTPS โดยไม่มี mixed content
หลัง: ยืนยันพฤติกรรมโฮสต์หลัก (เหลือแค่โฮสต์เดียวในแถบที่อยู่) และคุกกี้สำคัญถูกตั้งและส่ง
หลัง: ปล่อยให้โดเมนเก่ายังคงเปลี่ยนเส้นทางไว้นานหน่อย ผู้ใช้หลายคนจะกลับมาจากบุ๊กมาร์ก อีเมล หรือแคช

แม้ว่า Koder.ai (หรือแพลตฟอร์มอื่น) จะจัดการโดเมนกำหนดเองและ SSL ให้คุณ เช็คลิสต์นี้ก็ยังสำคัญ ปัญหาส่วนใหญ่มาจาก DNS และการเปลี่ยนเส้นทาง ไม่ใช่โค้ดแอป

สถานการณ์ตัวอย่าง: ย้ายจาก URL ของแพลตฟอร์มไปยังโดเมนที่กำหนดเอง

Ship with a real domain

Build your app on Koder.ai, then connect a custom domain when you are ready to go live.

Start Free

แอปของคุณรันบนที่อยู่ชั่วคราวของแพลตฟอร์ม เช่น myapp.koder.ai มันใช้งานได้ แต่คุณต้องการให้ลูกค้าใช้ example.com โดยให้ www.example.com เปลี่ยนเส้นทางไปที่ apex และบังคับให้เป็น HTTPS ทั้งหมด

แผน DNS ง่าย ๆ ช่วยลดความเสี่ยง ก่อนเปลี่ยนอะไร ให้บันทึกสถานะการทำงานปัจจุบัน (ถ้าแพลตฟอร์มรองรับ ให้ถ่ายสแน็ปช็อตอย่างที่ Koder.ai ทำได้) และลด TTL เป็นค่าสั้น ๆ หนึ่งวันก่อนการย้าย

เพิ่มเรคอร์ดใหม่โดยยังปล่อยให้ URL ของแพลตฟอร์มเดิมทำงาน:

example.com: A/ALIAS ชี้ไปยังเป้าหมายโฮสติ้งที่แพลตฟอร์มของคุณให้มา
www.example.com: CNAME ชี้ไปที่ example.com (หรือชี้ไปยังเป้าหมายของแพลตฟอร์ม ขึ้นกับผู้ให้บริการ)
เก็บ myapp.koder.ai ไว้ตามเดิมเพื่อให้คุณมีทางสำรองที่รู้ว่าทำงานได้

เมื่อ DNS อยู่ในที่แล้ว ขอใบรับรองสำหรับทั้งสองโฮสต์เนม (example.com และ www.example.com) อย่าสลับทราฟฟิกจนกว่าใบรับรองจะออกและใช้งานได้ มิฉะนั้นผู้ใช้จะเจอคำเตือนของเบราว์เซอร์

ไทม์ไลน์การย้ายพร้อมจุดตรวจชัดเจน:

T-24h: ลด TTL ยืนยันว่าคุณย้อนกลับได้เร็ว
T-0: เปิดใช้งานโดเมนในแอปโฮสต์ ยืนยัน SSL พร้อม
T+15m: ทดสอบ example.com ในหน้าต่าง incognito (หน้าแรก แอสเซ็ตคงที่ คำขอ API)
T+30m: เปิดการเปลี่ยนเส้นทาง (HTTP → HTTPS และ www → apex)
ช่วงย้อนกลับ: ถ้าการเข้าสู่ระบบหรือคำขอ API ล้มเหลว ให้คืนค่า DNS ไปยังเป้าหมายก่อนหน้าและปล่อย URL ของแพลตฟอร์มให้ทำงาน

หลังการย้าย ให้ตรวจพฤติกรรมคุกกี้ ลงชื่อเข้าใช้ รีเฟรช และตรวจว่าคุณยังคงล็อกอินทั้งบน www และ apex หากเซสชันขาดหาย มักเป็นการตั้งค่าโดเมนคุกกี้หรือ SameSite ที่ยังสมมติฐานว่าเป็นโฮสต์เก่า

ขั้นตอนถัดไป: เฝ้าดู บันทึก และทำให้การเปลี่ยนแปลงในอนาคตปลอดภัยขึ้น

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

ตั้งรูทีนการเฝ้าดูเล็ก ๆ ที่คุณจะทำจริง คุณไม่จำเป็นต้องเครื่องมือระดับองค์กรเพื่อเริ่มต้น แต่ต้องมีสัญญาณเชื่อถือได้สองสามอย่าง: การตรวจสอบความพร้อมของหน้าสำคัญ (หน้าแรก เข้าสู่ระบบ และหน้าที่ต้องพิสูจน์ตัวตน), แจ้งเตือนวันหมดอายุใบรับรอง (เช่น 30 วัน และอีกครั้ง 7 วันก่อน), การติดตามอัตราข้อผิดพลาด (เฝ้าดูการเพิ่มขึ้นของ 4xx/5xx ไม่ใช่แค่ uptime), และการตรวจสอบการเปลี่ยนเส้นทางเป็นครั้งคราว (HTTP ไป HTTPS และโฮสต์หลักชนะ)

เก็บหน้าต่างย้อนกลับสั้น ๆ ไว้ แม้ว่าทุกอย่างดูเรียบร้อย สำหรับ 24–72 ชั่วโมง ให้เก็บการตั้งค่าเดิมพร้อม (เป้าหมาย DNS เก่า การตั้งค่าโฮสต์เก่า การตั้งค่า TLS เก่า) เพื่อให้คุณย้อนกลับได้อย่างรวดเร็วหากมีปัญหาที่ซ่อนอยู่ เช่น callback ของการชำระเงินหรือผู้ให้บริการ OAuth ที่ยังชี้ไปที่โดเมนเก่า

เมื่อคุณมั่นใจแล้ว ให้เพิ่มค่า TTL กลับขึ้น ค่าต่ำมีประโยชน์ในช่วงเปลี่ยน แต่จะเพิ่มโหลดให้เรโซลเวอร์และเพิ่มผลกระทบของความผิดพลาดเล็ก ๆ ในภายหลัง เลือก TTL ปกติที่เข้ากับความถี่ที่คุณคาดว่าจะเปลี่ยน (ทีมหลายทีมเลือก 1–4 ชั่วโมง)

สุดท้าย จดเอกสารสภาพสุดท้ายขณะยังสด: เรคอร์ดที่มีอยู่ (type, name, value, TTL), โฮสต์เนมที่รองรับ, และกฎการเปลี่ยนเส้นทางที่แน่นอน รวมถึงที่ออกใบรับรองและสิ่งที่ครอบคลุม (apex, www, ซับโดเมน) และผู้รับผิดชอบการต่ออายุ

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

คำถามที่พบบ่อย

ควรใช้โดเมนหลักเป็น apex หรือ www?

Default to one canonical hostname and redirect everything else to it.

Choose either example.com (apex) or www.example.com as the “real” one.
Treat the other as a single 301 redirect.

This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.

ควรลด DNS TTL เมื่อไหร่ก่อนการสลับโดเมน?

Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out.

Common cutover TTL: 300–600 seconds
After the move is stable: raise TTL back up (often 1–4 hours)

Only lower TTL on the records you’re actually going to change.

ควรใช้ระเบียน DNS แบบไหน: A, CNAME หรือ ALIAS?

For many app setups:

Use CNAME for subdomains like www.example.com or app.example.com when you’re pointing to a provider hostname.
Use A (or ALIAS/ANAME if your DNS supports it) for the apex example.com.

Avoid trying to force a CNAME at the apex if your DNS host doesn’t support an apex alias style record.

ต้องเตรียม SSL ให้พร้อมก่อนเปลี่ยน DNS หรือไม่?

Don’t switch user traffic until HTTPS is valid on the new hostname(s).

A practical order:

Add the domain in your host/platform (for example, in Koder.ai custom domain settings)
Complete domain verification (often via TXT)
Wait until the certificate is issued for every hostname you’ll serve
Only then update DNS to send real users there

This avoids browser warnings and blocked requests right at cutover.

จะหลีกเลี่ยงการทำให้เมลพังเมื่อเพิ่มเรคอร์ดเว็บได้อย่างไร?

Most email breakage happens when people delete or overwrite MX and TXT records.

Before changing anything:

Identify existing MX, SPF, DKIM, DMARC, and verification TXT records
Add only the new records you need for the app
Don’t “replace” an existing SPF TXT unless you know how to merge values

A quick safety step is exporting or screenshotting the current zone so you can restore it fast.

จะหลีกเลี่ยงลูปการเปลี่ยนเส้นทางเมื่อบังคับ HTTPS และ www/apex ได้อย่างไร?

Redirect chains and loops usually come from conflicting rules between your CDN/proxy and your app.

Use these safe defaults:

Exactly one redirect from non-canonical host → canonical host
Exactly one redirect from http:// → https://
Preserve path and query string

If you’re behind a proxy/CDN, make sure your app respects forwarded scheme headers; otherwise it may think every request is HTTP and keep redirecting forever.

การเปลี่ยนมาใช้โดเมนใหม่จะทำให้ผู้ใช้ถูกตัดการเข้าสู่ระบบหรือไม่?

Yes, it’s common if cookies were scoped to the old hostname.

What to check:

Cookie Domain: cookies set for old-host won’t be sent to new-host
Cookie SameSite: SSO/payment redirects can fail if it’s too strict
Cookie Secure: cookies won’t be sent over HTTP

A low-risk approach is keeping the old hostname working during a transition so users can refresh sessions on the new domain.

ต้องอัพเดตการตั้งค่า auth และ SSO อะไรก่อนเปลี่ยนโดเมน?

Update identity settings before cutover.

Typical items that must match the new domain exactly:

OAuth/SSO redirect (callback) URLs
Allowed origins / CORS settings
Any allowlisted logout URLs

If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.

แผนการย้อนกลับที่ง่ายที่สุดถ้าการย้ายล้มเหลวควรเป็นอย่างไร?

A rollback is usually just restoring the previous DNS values.

Keep it simple:

Write down the “old” record values (and TTL) before you edit anything
Keep the old endpoint live long enough to receive traffic again
Decide who will revert the records and how you’ll confirm it worked

If your platform supports snapshots/rollback (Koder.ai does), take one before cutover so you can quickly undo related configuration changes too.

ควรทดสอบอะไรทันทีหลังการย้ายโดเมน?

Focus on real user paths, not just the homepage.

Test these on both the canonical host and the redirecting host:

Login/logout, password reset, email verification
A deep link with a query string
An authenticated page refresh (session stays valid)
API calls your frontend depends on

Also verify the address bar ends on one hostname and always on HTTPS, with no mixed-content warnings.