FAQ

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

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

> สร้างคีย์ SSH สาธารณะในเทอร์มินัล

สร้างคีย์ SSH สาธารณะสำหรับการเข้าถึง และแชร์เฉพาะส่วนสาธารณะเท่านั้น
faq/generate-public-ssh-key-th

ใช้เฉพาะคีย์สาธารณะ

SSH ใช้คู่คีย์ ให้วางเฉพาะคีย์สาธารณะ ซึ่งมักเป็นไฟล์ .pub ในการตั้งค่าบริการ คีย์ส่วนตัวต้องอยู่บนอุปกรณ์ของคุณ

ขั้นตอนในเทอร์มินัล

  1. เปิด Terminal, Windows Terminal หรือ PowerShell.
  2. รัน: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. ยอมรับตำแหน่งค่าเริ่มต้นหรือเลือกพาธที่ปลอดภัย.
  4. แสดงคีย์สาธารณะด้วย: cat ~/.ssh/id_ed25519.pub.
  5. ใน Windows PowerShell ใช้: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. คัดลอกทั้งบรรทัด ssh-ed25519 ไปยังช่อง SSH public key.

ตรวจสอบก่อนวาง

อย่าคัดลอกคีย์ส่วนตัว หากตั้ง passphrase ให้เก็บไว้อย่างปลอดภัยสำหรับใช้งานภายหลัง

> สร้างคีย์ SSH ผ่านหน้าจอ Windows

ใช้ PuTTYgen บน Windows และคัดลอกเฉพาะคีย์สาธารณะ
faq/create-ssh-key-windows-gui-th

ต้องใช้เฉพาะส่วนสาธารณะ

PuTTYgen สร้างทั้งคีย์สาธารณะและคีย์ส่วนตัว เพิ่มเฉพาะคีย์สาธารณะใน Cli>_ และเก็บคีย์ส่วนตัวไว้ในเครื่อง

ขั้นตอนบน Windows

  1. เปิด PuTTYgen.
  2. เลือก EdDSA / Ed25519 หากมีให้เลือก.
  3. ใช้ RSA 4096 เฉพาะเป็นทางเลือกสำรอง.
  4. คลิก Generate แล้วขยับเมาส์จนกว่าจะสร้างคีย์เสร็จ.
  5. บันทึกคีย์ส่วนตัวไว้ในคอมพิวเตอร์ของคุณ.
  6. คัดลอกข้อความคีย์สาธารณะไปยังช่อง SSH public key.

อย่าแชร์ข้อมูลลับ

อย่าส่งไฟล์ .ppk, คีย์ส่วนตัว, passphrase, รหัสผ่าน หรือ token ให้ฝ่ายสนับสนุนหรือผ่านแบบฟอร์ม.

> เชื่อมต่อโดเมนของคุณ

ตรวจ DNS authoritative, hostname ที่แน่นอน ประเภท record, apex หรือ subdomain และ record เก่าที่ขัดกันก่อนเปลี่ยน
faq/chueamto-domain-khong-khun

Hostname ที่แน่นอนกำหนด record

Apex เช่น example.com และ subdomain เช่น app.example.com อาจต้องใช้ record ต่างชนิดกัน ตรวจว่าที่แก้ DNS คือ authoritative nameserver หรือ registrar ที่ถูกต้อง

ก่อนเปลี่ยน DNS

  1. เลือก hostname ที่จะใช้อย่างชัดเจน
  2. ลบหรือแก้ A/AAAA, CNAME, ALIAS, ANAME หรือ redirect ที่ขัดกัน
  3. ใช้ record type ที่บริการแนะนำและ DNS provider รองรับ
  4. รอ DNS propagation ก่อนทดสอบ HTTPS ขั้นสุดท้าย

Rollback อย่างปลอดภัย

อย่าปิด hosting เดิมก่อน hostname ใหม่ตอบถูกต้อง เมื่อต้องวิเคราะห์ปัญหา ให้ส่ง domain, target ที่คาดหวัง และผล DNS สาธารณะ ไม่ใช่สิทธิ์เข้า registrar

> มอบหมายโซน DNS

A/AAAA ชี้ที่อยู่ CNAME เป็น alias MX สำหรับเมล TXT สำหรับ verification และนโยบายเมล CAA สำหรับ certificate authority
faq/mopmai-zone-dns

แต่ละ record มีหน้าที่เฉพาะ

A และ AAAA ชี้ IP, CNAME สร้าง alias ให้ subdomain, MX ส่งเมล, TXT เก็บ verification และ SPF/DKIM/DMARC, CAA จำกัดผู้ออก certificate

เมื่อคัดลอก record

  1. คัดลอก name, type และ value ตามคำสั่งเป๊ะ
  2. อย่าใส่ CNAME บน hostname ที่มี record อื่นหากกฎ DNS ห้าม
  3. วาง DKIM ใต้ selector ของ provider และ DMARC ใต้ _dmarc
  4. แก้ CAA อย่างระวังเพราะค่าผิดอาจบล็อก certificate

เมื่อ DNS ไม่ทำงาน

ส่ง hostname, record type, ค่าที่คาดหวัง และผลสาธารณะที่เห็น ห้ามส่ง login DNS หรือภาพที่มี API token

> การลงทะเบียนบัญชีและการเข้าสู่ระบบครั้งแรก

ใช้บัญชีงานหนึ่งบัญชีสำหรับคำสั่งซื้อ การชำระเงิน บริการ โดเมน และการติดต่อฝ่ายสนับสนุน
faq/account-registration-and-login

บัญชีงานที่ทีมยังเข้าถึงได้

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

ก่อนสั่งซื้อครั้งแรก

  1. สมัครด้วยอีเมลงาน
  2. ยืนยันอีเมลหากระบบร้องขอ
  3. กรอกข้อมูลชำระเงินก่อนสั่งบริการแบบเสียเงิน
  4. เปิดใช้การยืนยันสองขั้นตอนเมื่อมีให้ใช้

ให้ทีมเข้าถึงโดยไม่เปิดเผยล็อกอิน

อย่าส่งรหัสผ่านผ่านแชตหรืออีเมล หากหลายคนต้องเข้าถึง ให้ใช้ password manager ภายในหรือสอบถามขั้นตอนทีมที่ปลอดภัย ฝ่ายสนับสนุนไม่ต้องใช้รหัสผ่านหรือ token เข้าสู่ระบบ

> เครดิตเติมเงินทำงานอย่างไร

เครดิตแสดงยอดคงเหลือ ระยะเวลาที่คาดว่าจะใช้ได้ ค่าใช้จ่ายรายวัน และความเสี่ยงการระงับหรือกำหนดลบข้อมูล
faq/prepaid-credit-how-it-works

บริการที่ทำงานอยู่ใช้เครดิตต่อเนื่อง

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

ป้องกันเครดิตหมด

  1. ตรวจยอดและจำนวนวันที่คาดว่าเหลือในพื้นที่ลูกค้า
  2. ตรวจค่าใช้จ่ายรายวันก่อนยืนยันคำสั่งซื้อหรือการเปลี่ยนแปลง
  3. เติมเครดิตก่อนยอดใกล้ศูนย์
  4. หากบริการถูกระงับ ให้อ่านกำหนดลบข้อมูลที่แสดง

เมื่อต้องตรวจสอบยอดเครดิต

ส่งหมายเลขคำสั่งซื้อ ชื่อบริการ และช่วงเวลาที่ต้องการตรวจสอบ ห้ามส่งเลขบัตร รหัสผ่าน private key หรือรายการชำระเงินเต็มที่มีข้อมูลอ่อนไหว

> ประมาณการรายเดือน รายปี และการใช้เครดิตรายวัน

ราคารายเดือนและรายปีใช้เปรียบเทียบ ส่วนเครดิตเติมเงินจริงถูกใช้รายวันหลังยืนยันและนำการเปลี่ยนแปลงไปใช้
faq/billing-periods-and-credit-burn

ตัวเลขเปรียบเทียบไม่ใช่ปฏิทินใบแจ้งหนี้

ประมาณการรายเดือนใช้ 31 วัน และรายปีใช้ 372 วัน เครดิตจริงถูกใช้ตามเวลาที่บริการทำงาน CPU, RAM, storage และตัวเลือกเสียเงินที่ถูกนำไปใช้แล้ว

เมื่อราคาเปลี่ยน

  1. เปรียบเทียบค่าใช้จ่ายรายวันก่อนและหลังเปลี่ยน
  2. รวมผลของ CPU, RAM, disk, backup และ Offsite Archive
  3. รอให้ยืนยัน ชำระเงินถ้าจำเป็น และนำไปใช้ก่อนถือว่าเปลี่ยนแล้ว
  4. เก็บใบยืนยันคำสั่งซื้อและประวัติเครดิตไว้สำหรับบัญชี

ตรวจสอบช่วงเวลาเฉพาะ

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

> สถานะคำสั่งซื้อหลังชำระเงิน

คำสั่งซื้ออาจรอการยืนยันจากผู้ให้บริการชำระเงิน อย่าสร้างคำสั่งซื้อซ้ำจนกว่ารายการแรกจะล้มเหลวหรือหมดอายุชัดเจน
faq/order-status-and-payment-confirmation

Pending ไม่ได้แปลว่าล้มเหลวเสมอ

หลังจ่ายเงิน คำสั่งซื้ออาจยังรอการแจ้งยืนยันจากผู้ให้บริการชำระเงิน การสร้างคำสั่งซื้อซ้ำเร็วเกินไปอาจทำให้การจับคู่รายการยุ่งยาก

หลังชำระเงินเสร็จ

  1. กลับมายัง Cli>_ จากหน้าผู้ให้บริการชำระเงิน
  2. ตรวจสถานะคำสั่งซื้อในบัญชี
  3. ถ้ายัง pending ให้รอการยืนยันของผู้ให้บริการ
  4. เมื่อต้องการช่วยเหลือ ให้ส่งหมายเลขคำสั่งซื้อและ reference การชำระเงินถ้ามี

หลักฐานที่ปลอดภัย

ฝ่ายสนับสนุนต้องการเพียงหมายเลขคำสั่งซื้อ เวลา สถานะที่เห็น และภาพที่ปิดข้อมูลแล้วหากมี error อย่าส่งเลขบัตร รหัสผ่าน หรือหลักฐานธนาคารเต็ม

> ข้อมูลที่ช่วยให้ตั้งค่าบริการเร็วขึ้น

เตรียมชื่อบริการ โดเมน DNS ขนาดพื้นที่ ทรัพยากร อีเมลผู้ดูแล และ public SSH key โดยไม่ส่งข้อมูลลับ
faq/service-setup-information-needed

ค่าที่ชัดเจนลดความล่าช้า

ฟอร์มสั่งซื้ออาจขอชื่อบริการ โดเมน แผน DNS storage, CPU, RAM, อีเมลผู้ดูแล หรือ public SSH key ให้กรอกเฉพาะค่าที่เป็นสาธารณะหรือไม่ลับ

ก่อน checkout

  1. เลือกชื่อบริการที่ทีมจำได้
  2. ตัดสินใจว่าจะใช้โดเมนของตัวเองหรือ hostname ชั่วคราว
  3. เตรียม public SSH key หากบริการต้องใช้
  4. ตรวจขนาด storage และทรัพยากรตามแอปที่จะใช้งาน

ข้อมูลลับไม่ควรอยู่ในฟอร์ม

private key รหัสผ่าน token dump database และไฟล์ config เต็มไม่ควรถูกส่งในคำสั่งซื้อหรือแชต หากไม่แน่ใจ ให้ถามโดยยังไม่ส่งค่านั้น

> เปลี่ยน CPU, RAM, disk หรือ retention หลังสั่งซื้อ

เปลี่ยนจากหน้าบริการเดิม ตรวจราคาใหม่ การใช้เครดิตรายวัน เวลานำไปใช้ restart, downtime และการ export
faq/change-service-resources-after-order

แก้บริการเดิม ไม่สร้างบริการซ้ำ

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

ก่อนยืนยันการเปลี่ยนแปลง

  1. ดู CPU, RAM, disk, backup retention และ Offsite Archive retention ปัจจุบัน
  2. ตรวจราคาใหม่และค่าใช้เครดิตรายวัน
  3. อ่านคำเตือน restart, maintenance หรือ downtime
  4. export ข้อมูลสำคัญก่อนเปลี่ยนสิ่งที่มีความเสี่ยง

เมื่อผลไม่เป็นตามคาด

ส่งชื่อบริการ เวลาที่เปลี่ยน สถานะที่เห็น และข้อความ error ห้ามส่ง private key รหัสผ่าน token หรือไฟล์ config ลับ

> ยกเลิกบริการและระยะเวลาเก็บข้อมูล

บริการที่เปิดใช้งานแล้วมักถูกระงับก่อน แสดงกำหนดลบ แล้วจึงอาจถูกลบถาวร
faq/cancel-service-and-data-retention

ยกเลิกไม่ได้แปลว่าลบทันทีเสมอ

บริการที่ใช้งานแล้วมักถูกระงับก่อนและแสดงกำหนดลบข้อมูล หลังพ้นกำหนดนั้น ข้อมูลอาจถูกลบถาวร

ก่อนยกเลิกบริการ

  1. export ข้อมูลที่ต้องเก็บระยะยาวด้วยตัวเอง
  2. อ่านวันและเวลาลบที่แสดงบนบริการที่ถูกระงับ
  3. อย่าสับสน backup หรือ Offsite Archive กับระยะเวลาเก็บข้อมูลของบริการที่ยกเลิก
  4. ติดต่อสนับสนุนก่อนถึงกำหนดหากยังไม่แน่ใจ

หลังพ้นกำหนด

เมื่อกำหนดที่เห็นผ่านไปแล้ว ไม่ควรถือว่าข้อมูลยังเรียกคืนได้ หากต้องถาม ให้ส่งหมายเลขคำสั่งซื้อและชื่อบริการ ไม่ใช่ dump database หรือ credential

> Backup และคำขอ restore

Backup ใช้สำหรับกู้คืนการทำงาน ไม่ใช่แทน export และ restore อาจเขียนทับข้อมูลใหม่กว่า
faq/backups-and-restore-requests

Backup ไม่ใช่คลังเก็บถาวร

ระยะเก็บ backup ขึ้นกับสินค้าและตัวเลือก Backup ช่วยกู้คืนหลังปัญหาการทำงาน แต่ไม่แทน export ของคุณเองหรือ Offsite Archive

เตรียมคำขอ restore

  1. ระบุชื่อบริการและหมายเลขคำสั่งซื้อ
  2. บอกเวลาประมาณที่ต้องการย้อนกลับ
  3. ระบุว่าต้องการทั้งบริการหรือบางส่วนหากรองรับ
  4. แนบ error ที่เห็นโดยไม่มีรหัสผ่าน token หรือ private key

ผลกระทบของ restore

Restore อาจแทนข้อมูลใหม่ด้วยสถานะเก่า แจ้งทีมและ export สิ่งที่ไม่ต้องการเสียก่อนยืนยันการกู้คืน

> Offsite Archive มีไว้เพื่ออะไร

Offsite Archive เก็บสำเนา archive ระยะไกล แยกจาก backup ระยะสั้นและกำหนดลบบริการ
faq/offsite-archive-purpose

Archive แยกจากการทำงานประจำวัน

Offsite Archive ใช้สำหรับสำเนา archive ระยะไกล ไม่ใช่ disk live ของแอป ไม่แทน export ในเครื่อง และไม่เหมือน backup การทำงานระยะสั้น

เวลาที่ควรเปิดใช้

  1. ใช้กับข้อมูลที่ต้องเก็บนอกการทำงานปกติ
  2. เลือกจำนวนวัน retention ตาม recovery หรือ compliance
  3. ติดตามค่าใช้จ่ายเมื่อปริมาณและระยะเวลาเก็บเพิ่ม
  4. สำหรับข้อมูลใหญ่ ให้วางแผนคู่กับขั้นตอน export ของตัวเอง

ประเมินค่าใช้จ่าย archive

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

> เลือก CPU, RAM และ disk สำหรับ VPS

เลือกขนาด VPS ตามแอป database, cache, log, upload และการเติบโต OOM หรือ swap หนักคือสัญญาณว่า RAM ไม่พอ
faq/vps-cpu-ram-and-disk-sizing

เริ่มจาก workload จริง

เว็บ static เล็กต่างจาก database แอป Java ระบบค้นหา หรือ container build ให้คำนวณหน่วยความจำแอป cache database log upload และพื้นที่เผื่อโต

สัญญาณว่าแพ็กเล็กเกินไป

  1. เพิ่ม RAM เมื่อเจอ OOM, out of memory, process killed หรือ swap ต่อเนื่อง
  2. เพิ่ม CPU สำหรับ compression, build, worker ที่ยุ่ง หรือโหลดคำนวณต่อเนื่อง
  3. เพิ่ม disk ก่อน filesystem, log หรือ database เต็ม
  4. หลังเปลี่ยน ให้ดูว่าแอปยังชนขีดจำกัดเดิมหรือไม่

ข้อมูลสำหรับถาม sizing

ส่งชื่อบริการ ประเภทแอป error ที่เห็น เวลาเกิดปัญหา และ CPU, RAM, disk ที่เลือกอยู่ ห้ามส่งรหัสผ่าน private key หรือ config ภายใน

> เมื่อใด VPS ควรมี public IP

Dedicated public IP มีประโยชน์กับ allowlist การเข้าถึง inbound แหล่ง outbound คงที่ หรือบริการที่ผูกกับที่อยู่
faq/vps-public-ip-options

ดูทิศทางการเชื่อมต่อก่อน

ไม่ใช่ทุกบริการต้องมี public IP ความต้องการมักมาจาก partner, provider หรือ firewall ภายนอกที่ต้องการที่อยู่คงที่สำหรับ inbound, outbound source หรือทั้งสองทาง

ก่อนสั่ง IP

  1. ถาม partner ว่า allowlist ต้องการ inbound, outbound หรือทั้งสองทาง
  2. ใช้ชื่อ DNS แทนตัวเลข IP หากระบบภายนอกรองรับ
  3. เปิดเฉพาะ port ที่แอปต้องใช้จริง
  4. ส่งความต้องการ allowlist ก่อนเปลี่ยนแบบการเข้าถึง production

Public IP ไม่ได้แปลว่าเปิดทุก port

Dedicated public IP ยังต้องใช้กฎขั้นต่ำที่จำเป็น ห้ามส่งรหัสผ่าน private key หรือภาพ firewall ที่มีค่าลับ

> การเข้าถึง SSH แบบใช้ร่วมกันสำหรับ VPS

หากไม่มี public IP เพิ่ม VPS จะใช้ endpoint SSH ร่วมพร้อม port สูง เมื่อมี dedicated public IP ให้ใช้ SSH ตรงเฉพาะเมื่อบริการแสดง endpoint นั้น
faq/shared-ssh-access-for-vps

ทำไม SSH ร่วมใช้ port สูง

VPS หลายรายการอาจใช้ endpoint SSH สาธารณะเดียวกัน แต่ละบริการจึงได้ port สูงของตัวเองเพื่อให้การเชื่อมต่อถูกส่งไปยัง VPS ที่ถูกต้อง

เลือก endpoint SSH ที่แสดง

  1. สำหรับ SSH ร่วม ให้คัดลอก SSH username, public host และ port สูงจากหน้าบริการ
  2. ใช้คำสั่ง ssh -p <port> <username>@<public-host>
  3. ถ้าบริการมี dedicated public IP ให้ใช้ host หรือ IP ตรงและ port SSH ที่แสดงสำหรับบริการนั้น
  4. ใช้ private key เฉพาะในเครื่องผ่าน SSH client หรือ agent; ฝ่ายสนับสนุนต้องการเพียง public host, port, username และ error ที่เห็น

Public IP ไม่ได้เปิด SSH เอง

Dedicated public IP อาจเพิ่มทางเข้าตรงที่เหมาะกับ allowlist, monitoring หรือ integration ที่ต้องการที่อยู่คงที่ แต่ SSH ยังขึ้นกับ endpoint, port, firewall และวิธียืนยันตัวตนที่แสดงบนบริการ

> Checklist ก่อนเชื่อมโดเมนของคุณ

ตรวจ DNS authoritative, hostname ที่แน่นอน ประเภท record, apex หรือ subdomain และ record เก่าที่ขัดกันก่อนเปลี่ยน
faq/custom-domain-readiness-checklist

Hostname ที่แน่นอนกำหนด record

Apex เช่น example.com และ subdomain เช่น app.example.com อาจต้องใช้ record ต่างชนิดกัน ตรวจว่าที่แก้ DNS คือ authoritative nameserver หรือ registrar ที่ถูกต้อง

ก่อนเปลี่ยน DNS

  1. เลือก hostname ที่จะใช้อย่างชัดเจน
  2. ลบหรือแก้ A/AAAA, CNAME, ALIAS, ANAME หรือ redirect ที่ขัดกัน
  3. ใช้ record type ที่บริการแนะนำและ DNS provider รองรับ
  4. รอ DNS propagation ก่อนทดสอบ HTTPS ขั้นสุดท้าย

Rollback อย่างปลอดภัย

อย่าปิด hosting เดิมก่อน hostname ใหม่ตอบถูกต้อง เมื่อต้องวิเคราะห์ปัญหา ให้ส่ง domain, target ที่คาดหวัง และผล DNS สาธารณะ ไม่ใช่สิทธิ์เข้า registrar

> ชนิด DNS record สำหรับบริการ

A/AAAA ชี้ที่อยู่ CNAME เป็น alias MX สำหรับเมล TXT สำหรับ verification และนโยบายเมล CAA สำหรับ certificate authority
faq/dns-record-types-for-services

แต่ละ record มีหน้าที่เฉพาะ

A และ AAAA ชี้ IP, CNAME สร้าง alias ให้ subdomain, MX ส่งเมล, TXT เก็บ verification และ SPF/DKIM/DMARC, CAA จำกัดผู้ออก certificate

เมื่อคัดลอก record

  1. คัดลอก name, type และ value ตามคำสั่งเป๊ะ
  2. อย่าใส่ CNAME บน hostname ที่มี record อื่นหากกฎ DNS ห้าม
  3. วาง DKIM ใต้ selector ของ provider และ DMARC ใต้ _dmarc
  4. แก้ CAA อย่างระวังเพราะค่าผิดอาจบล็อก certificate

เมื่อ DNS ไม่ทำงาน

ส่ง hostname, record type, ค่าที่คาดหวัง และผลสาธารณะที่เห็น ห้ามส่ง login DNS หรือภาพที่มี API token

> DNS propagation และ TTL โดยไม่มีคำมั่นเป็นนาที

TTL กำหนดว่า resolver เก็บคำตอบเก่าได้นานเท่าไร คำตอบเก่าและใหม่อาจอยู่ร่วมกันชั่วคราว
faq/dns-propagation-and-ttl

Propagation คือ cache ของ resolver

DNS ไม่มีคำมั่นเรื่องเวลาที่แน่นอนเป็นนาที หลังแก้ authoritative record แล้ว resolver ต่าง ๆ อาจยังคืนค่าเก่าจนกว่า cache ตาม TTL จะหมดอายุ

สำหรับการเปลี่ยนที่วางแผนไว้

  1. ลด TTL ล่วงหน้าหาก provider อนุญาต
  2. แก้ DNS ครั้งเดียวและหลีกเลี่ยงการแก้ซ้ำระหว่าง cache หมดอายุ
  3. ทดสอบจากหลาย resolver หากผลไม่ตรงกัน
  4. จดเวลาเปลี่ยน ค่าเดิม ค่าใหม่ และ TTL

ข้อมูลสำหรับวิเคราะห์ DNS

ระบุ hostname, target ที่คาดหวัง คำตอบเก่า คำตอบใหม่ TTL และเวลาเปลี่ยน ห้ามส่งสิทธิ์เข้า DNS หรือบันทึกภายในของ provider

> วางแผนพื้นที่เก็บข้อมูล Nextcloud

คิดรวมไฟล์ผู้ใช้ โฟลเดอร์แชร์ version ถังขยะ previews, thumbnails, sync overhead และการเติบโตของทีม
faq/nextcloud-storage-planning

Nextcloud ใช้พื้นที่นอกเหนือจากไฟล์หลัก

พื้นที่ถูกใช้โดยไฟล์ผู้ใช้ โฟลเดอร์แชร์ ไฟล์ที่ลบ version history, previews, thumbnails, sync client และ import ใหญ่ หากใกล้เต็ม upload หรือ sync อาจล้มเหลว

ก่อนสั่งพื้นที่

  1. ประเมินข้อมูลผู้ใช้และโฟลเดอร์ร่วมปัจจุบัน
  2. เผื่อพื้นที่สำหรับถังขยะ version, previews และ sync overhead
  3. คิดรวม import ใหญ่ ทีมใหม่ และการเติบโตที่คาดไว้
  4. เพิ่ม storage ก่อนผู้ใช้ชน limit

เมื่อ sync มีปัญหา

ส่งขนาดบริการ การใช้งานโดยประมาณ เวลาเกิดปัญหา และ error จาก client ห้ามส่งไฟล์ส่วนตัวหรือ export ข้อมูลผู้ใช้ เว้นแต่มีช่องทางปลอดภัยที่ร้องขอ

> ย้าย repository ไปยัง Gitea

วางแผนย้าย Git พร้อม Git LFS, submodules, protected branches, deploy keys, webhook และ CI/CD
faq/gitea-repository-migration

Migration ไม่ใช่แค่ git clone

นอกจากประวัติ Git ต้องย้ายหรือกำหนด owner, team, protected branches, protected tags, Git LFS, submodules, deploy keys, webhooks และ CI/CD ใหม่

ก่อน cutover

  1. ลิสต์ repository, owner, กลุ่มสิทธิ์ และบัญชี automation
  2. ตรวจ Git LFS, submodules, branch protection และ tag protection
  3. หลังย้ายให้ทดสอบ clone, push, Git LFS, submodules และ CI
  4. หมุนหรือยกเลิก token เก่าโดยไม่แชร์ค่าของ token

ข้อมูลลับระหว่าง migration

อย่าส่ง token, private key, ส่วน private ของ deploy key หรือ CI secrets ให้ส่งเฉพาะชื่อ repository ชนิด integration, error ที่เห็น และสิ่งที่เคยทำงานก่อนย้าย

> Sender domain สำหรับ Listmonk

เตรียม domain หรือ subdomain ผู้ส่ง From identity, SPF, DKIM, DMARC, bounce และ unsubscribe ก่อน campaign
faq/listmonk-sender-domain-basics

Deliverability เริ่มจาก domain

Listmonk ต้องมี From identity ชัดเจนและ DNS record ที่ระบบเมลตรวจสอบได้ SPF, DKIM และ DMARC ต้องสอดคล้องกับ domain หรือ subdomain ที่ใช้ส่ง

ก่อน campaign แรก

  1. เลือก sender domain หรือ subdomain และชื่อ From
  2. เพิ่ม verification record, SPF, DKIM selector และ DMARC
  3. ทดสอบการส่ง bounce หรือ Return-Path และลิงก์ในอีเมล
  4. ตรวจ unsubscribe และ List-Unsubscribe ก่อนส่งจริง

ความลับของระบบเมล

เมื่อต้องวิเคราะห์ ให้ส่ง domain, record type, ค่า DNS สาธารณะ และข้อความ error ห้ามส่ง SMTP password, API token, private DKIM key หรือรายชื่อผู้รับที่มีข้อมูลส่วนตัว

> การตั้งค่า Runtime สำหรับ Classic Hosting

Classic Hosting ใช้ Runtime อัตโนมัติหรือ manual ได้ CPU, RAM, storage, backup, Offsite Archive, upload, cache และ log ส่งผลต่อราคาและเสถียรภาพ
faq/classic-hosting-runtime-settings

Auto ไม่ใช่ตัวเลือกเดียว

Auto Runtime ช่วยกับโปรเจกต์ที่ตรวจจับได้ ส่วน Manual Runtime เหมาะเมื่อต้องเลือก Nginx, Apache, FrankenPHP หรือ runtime ภาษาเฉพาะ PHP selector ใช้เฉพาะกรณีที่รองรับ

ตั้งค่าก่อน deploy

  1. เลือก auto หรือ manual Runtime ตาม framework และขั้นตอน build
  2. เลือก PHP 8.2, 8.3 หรือ 8.4 เฉพาะ scenario PHP ที่รองรับ
  3. ตั้ง CPU, RAM, disk, backup retention และ Offsite Archive ตามข้อมูลและ traffic
  4. หลัง deploy ให้ทดสอบ upload, cache, log และ error ของแอปที่มองเห็น

เมื่อแอปไม่เริ่มทำงาน

ส่ง runtime mode, ภาษา หรือ PHP version, error ที่เห็น สิ่งที่เปลี่ยนล่าสุด และเวลา deploy ห้ามส่งไฟล์ .env รหัสผ่าน token หรือ log เต็มที่มีความลับ

> ข้อมูลที่แชร์กับฝ่ายสนับสนุนได้อย่างปลอดภัย

หมายเลขคำสั่งซื้อ ชื่อบริการ โดเมน เวลา public host, port การตั้งค่า hosting ภาพที่ปิดข้อมูล และ error ที่เห็นช่วยได้โดยไม่เปิดเผยความลับ
faq/support-safe-information-to-share

Ticket ที่ดีมีบริบท

ฝ่ายสนับสนุนช่วยได้เร็วขึ้นเมื่อมีหมายเลขคำสั่งซื้อ ชื่อบริการ โดเมน public host หรือ port เวลาเกิดปัญหา สิ่งที่เปลี่ยนล่าสุด และข้อความ error ที่เห็น

เนื้อหาที่ส่งได้ปลอดภัย

  1. ระบุคำสั่งซื้อ บริการ โดเมน เวลา และขั้นตอนที่เกิดปัญหา
  2. สำหรับ hosting ให้เพิ่ม runtime, PHP หรือภาษา CPU, RAM, disk, backup retention, Offsite Archive retention, upload, cache และ log ที่ไม่มีความลับ
  3. ปิดข้อมูลอ่อนไหวในภาพก่อนส่ง
  4. หากไม่แน่ใจว่าข้อมูลปลอดภัยหรือไม่ ให้ถามก่อนโดยยังไม่ส่งค่า

สิ่งที่ห้ามส่ง

ห้ามส่งรหัสผ่าน private keys, recovery seed, API token, session cookies, database dump, ไฟล์ .env เต็ม, log เต็มที่มีความลับ หรือรายละเอียดโครงสร้างพื้นฐานภายใน