เช็คลิสต์แก้ปัญหาโดเมนกำหนดเอง สำหรับปัญหา DNS และ SSL

ความหมายโดยทั่วไปของ “โดเมนกำหนดเองใช้ไม่ได้”

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

อาการทั่วไปได้แก่:

• หน้า “ไม่พบโดเมน”
• โดเมนโหลดเว็บไซต์ผิด
• เตือนความไม่ปลอดภัยแม้เปิด HTTPS แล้ว
• วงจรการเปลี่ยนเส้นทาง (เด้งระหว่าง http และ https หรือระหว่าง root domain กับ www)

ส่วนใหญ่แล้ว มักมีสิ่งเดียวที่ผิดพลาด:

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

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

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

แนวคิด DNS เล็กๆ ที่สำคัญ (แบบไม่ใช้ศัพท์เทคนิคมาก)

ปัญหาโดเมนส่วนใหญ่เกิดจากความไม่ตรงกันระหว่าง (1) ชื่อโฮสต์ที่คุณทดสอบ, (2) ที่ที่จัดการ DNS, และ (3) สิ่งที่ระเบียนชี้ไป เมื่อทั้งสามตรงกัน SSL มักเป็นขั้นตอนสุดท้าย

โดเมนมีรูปแบบสองแบบที่พบบ่อย: root domain (example.com หรือเรียกว่า apex) และซับโดเมน (www.example.com, app.example.com) ทั้งสองเกี่ยวข้องกันแต่สามารถมีระเบียน DNS ต่างกัน ดังนั้นจึงเป็นปกติที่ www จะใช้งานได้แต่ apex ล้มเหลว หรือในทางกลับกัน

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

ประเภทระเบียน DNS แบบเข้าใจง่าย

นี่คือหน้าที่ของระเบียนหลักๆ:

• A: ชี้ชื่อไปยังที่อยู่ IPv4 (เช่น 203.0.113.10)
• AAAA: ชี้ชื่อไปยังที่อยู่ IPv6
• CNAME: ชี้ชื่อไปยังชื่อโฮสต์อีกชื่อ (มักใช้กับ www)
• TXT: เก็บข้อความที่ใช้ยืนยันและด้านความปลอดภัย (เช่นการตรวจสอบความเป็นเจ้าของ, SPF)

TTL คือ "เวลาที่จะเก็บค่าในแคช" ยิ่ง TTL ต่ำ แคชจะรีเฟรชเร็วขึ้น ยิ่งสูงคุณอาจต้องรอนานขึ้นหลังแก้ระเบียน เห็นค่ายังคงเก่าอยู่สักพักเป็นเรื่องปกติ

ขั้นตอนทีละขั้น: ต้นไม้ตัดสินใจง่ายๆ เพื่อหาต้นเหตุ

เมื่อโดเมนกำหนดเองล้มเหลว คุณมักจะจัดให้อยู่ในสี่กลุ่ม: DNS ไม่แก้ชื่อ, DNS ชี้ไปที่ผิด, SSL ยังไม่พร้อม, หรือมันล้มเหลวเฉพาะบางคนเพราะแคช

ใช้ต้นไม้ตัดสินใจนี้:

1. โดเมนแก้ชื่อได้ไหม? ถ้าเห็น NXDOMAIN (หรือ “domain not found”) ระเบียนอาจขาดหาย คุณกำลังแก้โซน DNS ผิด หรือ nameservers ไม่ใช่ตามที่คิด
2. ถ้ามันแก้ชื่อได้ มันชี้ไปยังเป้าหมายที่ถูกต้องหรือเปล่า? ถ้าเพจโหลดแต่เป็นไซต์ผิด หน้า parking หรือเซิร์ฟเวอร์เก่า ระเบียน A/AAAA/CNAME ชี้ผิดหรือมีระเบียนเก่าที่กินลำดับความสำคัญ
3. ถ้ามันชี้ถูก ความล้มเหลวเกิดเฉพาะ HTTPS ไหม? ถ้า HTTP ใช้งานได้แต่ HTTPS เตือนใบรับรอง อาจเป็นว่า SSL ยังออกไม่เสร็จ ชื่อโฮสต์บนใบรับรองไม่ตรง หรือแพลตฟอร์มรอให้ DNS นิ่ง
4. มันใช้ได้บนอุปกรณ์หรือเครือข่ายหนึ่งแต่ไม่ใช่อีกหรือเปล่า? ให้ถือว่าเป็นแคชหรือการเผยแพร่
5. การเปลี่ยนเส้นทางพังไหม (www กับ apex)? ถ้า www ใช้ได้แต่ root domain ไม่ได้ (หรือกลับกัน) คุณอาจตั้งค่าเพียงชื่อโฮสต์เดียว หรือมีกฎ redirect ขัดแย้ง

ทำงานเร็วขึ้นโดยจดชื่อโฮสต์ที่ล้มเหลว (apex vs www) และข้อความผิดพลาดที่เห็น ในแพลตฟอร์มที่อัตโนมัติการจัดการโดเมนและใบรับรอง ความต่างระหว่าง “ไม่พบ host” กับ “certificate pending” บอกได้ว่าควรแก้ DNS หรือรอ SSL หลัง DNS มองเห็น

ขั้นตอนที่ 1: ยืนยันชื่อโฮสต์และเป้าหมายที่คาดหวัง

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

ก่อนอื่น จดชื่อโฮสต์ที่คุณต้องการให้ใช้งาน ชื่อโดเมน root เป็นแบบ example.com ซับโดเมนเป็น www.example.com หรือ app.example.com เรื่องนี้ต้องมีระเบียน DNS แยกกัน ดังนั้น “www ใช้ได้” ไม่ได้แปลว่า root จะใช้ได้

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

ก่อนเปลี่ยนอะไร ให้เก็บข้อมูลที่ตั้งอยู่ตอนนี้ไว้แบบง่ายๆ:

• คัดลอกระเบียน DNS ปัจจุบันสำหรับชื่อโฮสต์ที่คุณแก้
• จดระเบียน A, AAAA, CNAME และ TXT ที่มีอยู่
• บันทึกค่า TTL

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

ขั้นตอนที่ 2: เลือกประเภทระเบียน DNS ให้ถูก (A, AAAA, CNAME, TXT)

ปัญหาหลายครั้งมาจากการใช้ประเภทระเบียนไม่ถูกกับชื่อโฮสต์ที่พยายามเชื่อม แยกสองกรณีคือ root domain (example.com) และซับโดเมน (www.example.com) เพราะพฤติกรรมต่างกันที่ผู้ให้บริการ DNS หลายราย

A record ชี้ชื่อไปยังที่อยู่ IPv4 หลายการตั้งใช้ A record สำหรับ root domain เพราะผู้ให้บริการบางรายไม่อนุญาต CNAME ที่ apex ถ้าโฮสต์ให้ IP ให้สร้าง A record

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

CNAME ชี้ซับโดเมนไปยังชื่อโฮสต์อีกชื่อ (มักใช้กับ www) มีประโยชน์เมื่อโฮสต์ต้องการให้คุณชี้ไปยัง endpoint ที่เป็นชื่อซึ่งสามารถเปลี่ยนหลังฉากได้

TXT ใช้สำหรับการยืนยันและ challenges (รวมถึงการตรวจสอบ SSL บางรูปแบบ) ข้อผิดพลาดทั่วไปคือสร้าง TXT บนชื่อผิด (root vs _acme-challenge vs ซับโดเมน), ใส่ช่องว่างเพิ่ม, หรือวางค่าผิด

ก่อนไปต่อ มองหาความขัดแย้ง เหล่านี้คือสาเหตุปัญหาหลัก:

• มี CNAME บนชื่อเดียวกับที่มีระเบียนประเภทอื่นด้วย
• มี A หรือ AAAA หลายรายการสำหรับชื่อเดียวเมื่อคุณตั้งใจให้มีแค่รายการเดียว
• ระเบียนเก่าที่ยังอยู่สำหรับ www หรือ root domain
• TXT ถูกสร้างบนชื่อผิด

ขั้นตอนที่ 3: ยืนยัน nameservers เพื่อให้แน่ใจว่าคุณแก้จุดที่ถูก

หลายกรณี “โดเมนกำหนดเองใช้ไม่ได้” ไม่ได้เกี่ยวกับค่าระเบียนเลย แต่เกิดเพราะระเบียนถูกเพิ่มในที่ผิด ถ้าโดเมนของคุณใช้ nameservers ของ Provider A การเปลี่ยนระเบียนที่แดชบอร์ด Provider B จะไม่มีผลแม้ระเบียนในที่นั้นจะดูถูกต้อง

ยืนยัน nameservers ที่เป็น authoritative

ตรวจดูว่าโดเมนใช้ nameservers ใดจริงๆ คุณมักเห็นสิ่งนี้ในการตั้งค่าที่ registrar ภายใต้ “Nameservers” เพื่อความแน่ใจอีกทาง ให้ถาม DNS โดยตรงจากคอมพิวเตอร์ของคุณ:

dig NS example.com

nameservers ที่คำสั่งนี้คืนมาคือ authoritative

การตรวจสอบเบื้องต้นสั้นๆ:

• ถ้าผู้ให้บริการ DNS ให้ nameservers เช่น ns1... และ ns2... ค่าตรงนั้นต้องปรากฏที่ registrar ด้วย
• ถ้าคุณเพิ่งเปลี่ยนผู้ให้บริการ DNS ให้ยืนยันว่าการเปลี่ยนเสร็จสมบูรณ์ก่อนทำการแก้ระเบียนเพิ่มเติม
• ถ้าแพลตฟอร์มโชว์ “ระเบียนที่แนะนำ” นั่นเป็นเพียงคำแนะนำ: คุณยังต้องเพิ่มระเบียนที่ผู้ให้บริการ DNS ที่เป็น authoritative

ทำไมถึงเกิด “อัปเดตแล้วแต่ไม่มีอะไรเปลี่ยน”

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

นอกจากนี้ให้ระวังดีเลย์หลังเปลี่ยน nameservers ที่ registrar ระหว่างหน้าต่างเปลี่ยนผ่าน ผลลัพธ์อาจดูไม่สอดคล้องกันขึ้นอยู่กับที่ที่คุณทดสอบ ถ้า nameservers ยังเปลี่ยนแปลง อยู่เฉยๆ จนกว่าเซ็ต nameserver จะนิ่ง แล้วค่อยแก้ระเบียน

ขั้นตอนที่ 4: การตรวจสอบการเผยแพร่และแคชที่ช่วยจริงๆ

“Propagation” ไม่ใช่สวิตช์เดียว มันคือโซ่ของแคช DNS (ISP, เครือข่ายมือถือ, public resolvers, และอุปกรณ์ของคุณ) ที่อัปเดตไม่พร้อมกัน นั่นคือเหตุผลที่โดเมนอาจใช้ได้สำหรับเพื่อนร่วมงานแต่ล้มเหลวสำหรับคุณ

TTL บอกว่าแคชจะเก็บคำตอบไว้นานเท่าไร ถ้า TTL เก่าเป็น 1 ชั่วโมง บางคนอาจเห็นค่าที่เก่าใกล้เคียงหนึ่งชั่วโมง การลด TTL ช่วยได้ก็ต่อเมื่อคุณลดก่อนทำการเปลี่ยน

เพื่อแยกความล่าช้าจากแคชออกจากข้อผิดพลาดจริง ให้ทำการตรวจสอบด่วนเหล่านี้:

• ทดสอบบน Wi‑Fi ที่บ้านหรือที่ทำงาน แล้วทดสอบบนข้อมูลมือถือ
• ให้คนอื่นบนเครือข่ายต่างลองทดสอบ
• ใช้หน้าต่างส่วนตัว (เพื่อตัดการแคช redirect ของเบราว์เซอร์)
• รีสตาร์ทอุปกรณ์หรือ flush local DNS cache ถ้าคุณรู้วิธี
• ยืนยันชื่อโฮสต์อย่างแม่นยำ (root vs www)

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

ขั้นตอนที่ 5: เวลาในการออก SSL และทำไมบางครั้งต้อง "รอหน่อย"

ใบรับรอง SSL มักล้มเหลวด้วยเหตุผลพื้นฐาน: ผู้ให้บริการใบรับรองไม่สามารถยืนยันโดเมนจนกว่า DNS จะชี้ไปยังที่ถูกต้องอย่างสม่ำเสมอ

ลำดับปกติคือ:

1. ตั้งระเบียน DNS ให้ถูกต้อง
2. รอจนกว่าระเบียนจะสามารถแก้ได้จากหลายที่
3. ทำการยืนยันที่ต้องการ (มักเป็น TXT)
4. ให้การออกใบรับรองเสร็จ

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

ใช้สัญญาณอาการเพื่อแยก “ยังออกอยู่” ออกจาก “ตั้งค่าไม่ถูก”:

• ยังออกอยู่: HTTP อาจใช้งานได้ แต่ HTTPS แสดงใบรับรองชั่วคราวหรือข้อความแบบ “not valid yet” ชั่วคราว
• ตั้งค่าไม่ถูก: คุณเห็นเว็บไซต์อื่น, หน้า ISP parking, หรือการค้นหา DNS ล้มเหลว (NXDOMAIN)

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

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

วิธียืนยันแต่ละขั้นตอน (ไม่ต้องเดา)

การแก้ปัญหาดีๆ มักเป็นการเปรียบเทียบ: สิ่งที่คุณเห็นเทียบกับสิ่งที่คาดหวัง อย่าเชื่อแค่ว่า “มันโหลดบนโทรศัพท์ของฉัน” ใช้การตรวจสอบที่ทำซ้ำได้

ตรวจคำตอบ DNS กับเป้าหมายที่คาดไว้

ใช้เครื่องมือค้นหา DNS (เช่น nslookup หรือ dig) และยืนยันว่าค่าที่คืนมาตรงกับสิ่งที่คุณตั้งใจ (IP สำหรับ A หรือ AAAA, ชื่อโฮสต์สำหรับ CNAME, โทเค็นสำหรับ TXT)

# Apex (root) domain
dig example.com A

dig example.com AAAA

# www subdomain
dig www.example.com CNAME

# TXT (often used for verification)
dig example.com TXT

ตรวจทั้งชื่อที่คุณอาจใช้: apex (example.com) และ www (www.example.com). เป็นเรื่องปกติที่อันหนึ่งถูกและอีกอันชี้ไปที่เก่า

ตรวจพฤติกรรมเบราว์เซอร์ (HTTP, HTTPS และการ redirect)

เปิดทั้ง http:// และ https:// สำหรับทั้ง apex และ www คุณต้องการโดเมนหลักที่ชัดเจนหนึ่งชื่อและการ redirect ที่สะอาดหนึ่งแบบ

• เลือกโดเมน canonical หนึ่งชื่อ (apex หรือ www) แล้ว redirect ฝั่งตรงข้ามไปยังมัน
• หลีกเลี่ยงวงจร redirect (A redirect ไป B แล้ว B redirect กลับไป A)
• ถ้า HTTP ใช้งานได้แต่ HTTPS ล้มเหลว SSL อาจยังออกอยู่หรือ DNS ยังชี้ไปที่ที่ไม่คาด

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

ข้อผิดพลาดทั่วไปที่กินเวลาหลายชั่วโมง

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

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

ปัญหาคลาสสิกอีกอย่างคือพยายามใส่ CNAME ที่ root domain กับผู้ให้บริการที่ไม่รองรับ อาจต้องใช้ A record หรือ ALIAS/ANAME ถ้าผู้ให้บริการ DNS มีให้

IPv6 ก็สร้างปัญหาได้ การทิ้ง AAAA เก่าๆ ไว้สามารถส่งผู้เยี่ยมชมบางส่วนไปเซิร์ฟเวอร์ผิดขณะที่คนอื่นไปยัง IPv4 ที่ถูกต้อง

ระวังการเพิ่มระเบียนแบบ “กันไว้ก่อน” A records หลายรายการอาจทำให้เกิดพฤติกรรมเหมือน load balancing โดยไม่ได้ตั้งใจถ้าเป้าหมายหนึ่งผิด โดยเฉพาะเมื่อต่อโดเมนกำหนดเองกับแอปโฮสต์

กฎสุดท้าย: หยุดการรีเซ็ตนาฬิกา

• อย่าเปลี่ยนระเบียนทุกไม่กี่นาที
• อย่าใช้เป้าหมายเก่าและใหม่ผสมกัน
• รอให้แคชนิ่งก่อนตัดสิน

การเปลี่ยนเล็กๆ อย่างใจเย็นมักชนะการปรับอยู่ตลอดเวลา

ตัวอย่างสมจริง: www ใช้ได้ แต่ root domain ไม่ได้

คุณเปิดตัวแอปใหม่และตั้งทั้ง example.com และ www.example.com ไม่กี่นาทีต่อมา www.example.com โหลดได้ดี แต่ root domain แสดงข้อผิดพลาด DNS, โหลดไซต์เก่า หรือ HTTPS ค้างรอ รูปแบบนี้พบบ่อยและมักมีสาเหตุเล็กๆ

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

ถัดไป เปรียบเทียบสองชื่อโฮสต์ www มักเป็น CNAME ส่วน root ยากกว่า: ผู้ให้บริการหลายรายไม่อนุญาต CNAME ที่ apex จึงต้องใช้ A record ไปยัง IP หรือ ALIAS/ANAME ถ้าผู้ให้บริการรองรับ

เส้นทางตัดสินใจที่ใช้งานได้จริง:

• nameservers ผิดหรือไม่คาดคิด? แก้ก่อน
• nameservers ถูกแต่ example.com ไม่มีระเบียน (หรือชี้ที่อื่น)? แก้ระเบียน apex
• ระเบียนดูถูกแต่พฤติกรรมต่างกันตามอุปกรณ์หรือเครือข่าย? รอ propagation และล้างแคช
• DNS แก้ได้แต่ HTTPS ล้มเหลวหรือค้าง? SSL กำลังรอ DNS ที่สม่ำเสมอ

ผลลัพธ์ที่ถูกต้องคือความน่าเบื่อ: ทั้ง example.com และ www.example.com นำไปยังแอปเดียวกัน หนึ่งชื่อเป็น canonical (อีกชื่อ redirect) และ HTTPS ใช้งานได้

เช็คลิสต์ด่วนที่ทำได้ภายใน 5 นาที

เมื่อการตั้งค่าโดเมนล้มเหลว การแก้ส่วนใหญ่มาจากการตรวจสอบไม่กี่อย่าง ดำเนินการเหล่านี้ก่อนเปลี่ยนอะไรอื่น

• ยืนยันว่าคุณแก้ DNS ในที่ถูก (จับคู่แดชบอร์ดกับ nameservers ที่เป็น authoritative)
• ยืนยันชื่อโฮสต์และเป้าหมายให้ตรง (ไม่มีซับโดเมนขาด ไม่มีจุดเกิน) เปรียบเทียบประเภทระเบียน (A, AAAA, CNAME, TXT) กับสิ่งที่โฮสต์คาดหวัง
• เอาความขัดแย้งออก (CNAME พร้อมกับระเบียนอื่นบนชื่อเดียวกัน หรือ A/AAAA เก่าที่ไม่ต้องการ)
• ตรวจสอบจากสองมุมมอง (ข้อมูลมือถือและ Wi‑Fi). ถ้าอันหนึ่งทำงาน อีกอันไม่ทำ มักเป็นแคชหรือ propagation
• ให้ความเคารพกับ TTL ถ้า TTL เป็น 300 วินาที รอ 5–10 นาทีก่อนตัดสิน ถ้า TTL เป็น 3600 คาดใกล้ชั่วโมง

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

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

ขั้นตอนถัดไป: ทำให้การตั้งค่าโดเมนทำซ้ำได้ในทุกการเปิดตัว

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

เทมเพลตบันทึกการตั้งค่าโดเมนเรียบง่าย

เก็บไว้ในเอกสารโปรเจกต์และกรอกก่อนแตะ DNS:

• โดเมนและชื่อโฮสต์ (root, www และซับโดเมนใดๆ)
• ประเภทระเบียนและเป้าหมายที่คาด (A, CNAME, TXT) และมาจากที่ไหน
• ที่ที่แก้ DNS (ผู้ให้บริการใด) และ nameservers ที่ใช้งานอยู่
• ความคาดหวัง SSL (ใครออก, หน้าตาเมื่อ "พร้อม")
• ขั้นตอนการยืนยันที่คุณจะรัน (เครื่องมือและผลที่คาดหวัง)

ขณะเปิดตัว ให้มอบหมายคนเดียวเป็นเจ้าของ DNS. DNS มักพังเมื่อสองคนพยายามแก้ต่างกันพร้อมกัน (เช่น คนหนึ่งเปลี่ยน nameservers ขณะที่อีกคนแก้ระเบียน)

ฝั่งโฮสต์ จัดเตรียมการย้อนกลับที่ปลอดภัย หากแพลตฟอร์มรองรับ snapshot หรือ rollback ให้ถ่ายสแนปช็อตก่อนเปลี่ยน routing เพื่อย้อนกลับสู่สถานะที่ใช้งานได้เร็ว ถ้าคุณสร้างบน Koder.ai คุณสามารถใช้ Planning Mode เขียนขั้นตอนโดเมนที่ต้องทำ ใช้ทีละอย่าง และย้อนกลับถ้าการเปลี่ยนทำให้ระบบเสีย

เมื่อไหร่ควรยกระดับ (และบอกใคร)

ถ้าคุณยืนยัน DNS ถูกแล้วแต่ยังพบความล้มเหลว ให้หยุดเดาและยกระดับพร้อมหลักฐาน:

• registrar แสดง nameservers ถูกล็อกหรือคุณเปลี่ยนไม่ได้
• การแก้ DNS ไม่ปรากฏภายหลังหน้าต่าง TTL ที่คาดไว้
• SSL ยังคงล้มเหลวหลังจาก DNS แก้ชื่อถูกต้องนานแล้ว (คิดเป็นชั่วโมง ไม่ใช่นาที)
• คุณเห็นระเบียนขัดแย้งที่เอาออกไม่ได้ (บั๊ก UI หรือ split DNS)

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