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

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

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

> ระบบเครดิต Cli>_ ทำงานอย่างไร?

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

บัญชี Cli>_ มีเครดิตเติมเงินร่วมหนึ่งยอด ลูกค้าใหม่ที่มีสิทธิ์สามารถขอ Starter Credit ได้หลังจากผ่านการยืนยันบัญชีและการป้องกันการใช้งานในทางที่ผิดตามที่กำหนดแล้วเท่านั้น บริการที่เข้าเงื่อนไขและกำลังทำงานจะใช้ยอดนี้ไปตามเวลา การประมาณรายเดือนใช้ 31 วัน และบริการใหม่จะเริ่มได้เมื่อยอดครอบคลุมอย่างน้อย 7 วัน คำเตือนสีแดงจะแสดงเมื่อเวลาประมาณลดต่ำกว่า 7 วัน มิฉะนั้นคำเตือนสีส้มจะแสดงเมื่อลดต่ำกว่า 14 วัน

หลังยอดหมด 7 วัน บริการจะถูกระงับ หยุดใช้เครดิต และเริ่มนับถอยหลังการเก็บรักษาและการลบเป็นเวลา 7 วัน ก่อนกำหนดที่แสดงสามารถเริ่มใหม่ได้เมื่อมีเครดิตเพียงพอ การยกเลิกบริการที่ provision แล้วจะระงับบริการและเริ่มนับถอยหลังเดียวกัน บริการที่รอดำเนินการและยังไม่ provision อาจถูกปิดทันที หลังพ้นกำหนดจะเริ่มปิดและนำบริการที่ provision แล้วออก Force delete จะปิดบริการทันที ข้ามการเก็บรักษา และเริ่มนำออกจาก runtime ที่ใช้งานอยู่ การดำเนินการเสร็จสิ้นหลังการประมวลผล deployment และ GitOps ส่วน backup และ Offsite Archive มีนโยบายเก็บรักษาแยกกัน

ตัวอย่าง OpenCode ราคา 9.90 EUR: 9.90 / 31 ≈ 0.319 EUR ต่อวัน หลังครบ 10 วันจะใช้ไปประมาณ 3.19 EUR หากยอดเริ่มต้นเท่ากับ 9.90 EUR พอดีและไม่มีบริการอื่น จะเหลือประมาณ 6.71 EUR การใช้เครดิตจะหยุดหลังปิดใช้งานบริการ

ตัวอย่างนี้ใช้เพื่ออธิบายเท่านั้น ราคาปัจจุบันที่แสดงใน Cli>_ เป็นราคาที่มีผลเสมอ

> วิธีการสร้างคีย์ SSH สาธารณะผ่านทาง Command Line

สร้างคีย์ SSH สาธารณะเพื่อการเข้าถึง VPS ที่ปลอดภัย แชร์เฉพาะคีย์สาธารณะกับ Cli>_; เก็บรักษาคีย์ส่วนตัวไว้ในอุปกรณ์ของคุณ
faq/generate-public-ssh-key-th

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

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

ขั้นตอน

  1. เปิดเทอร์มินัลบนคอมพิวเตอร์ของคุณ
  2. รันคำสั่ง: ssh-keygen -t ed25519 -C "your-email@example.com"
  3. ยืนยันตำแหน่งที่บันทึกไฟล์ หรือเลือกพาธเอง อย่าส่งคีย์ส่วนตัวให้ใคร
  4. แสดงคีย์สาธารณะโดยใช้คำสั่ง: cat ~/.ssh/id_ed25519.pub
  5. คัดลอกทั้งบรรทัดที่ขึ้นต้นด้วย ssh-ed25519 แล้ววางลงในช่อง "SSH public key" ขณะทำการสั่งซื้อหรือตั้งค่าบริการ
  6. คัดลอกทั้งบรรทัดที่มีคำว่า ssh-ed25519 และนำไปใส่ในช่อง "SSH Public Key"

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

  1. เปิดโปรแกรม PowerShell หรือ Windows Terminal.
  2. รันคำสั่ง: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. กด Enter เพื่อบันทึกคีย์ไปยัง C:\Users\your-user\.ssh\id_ed25519 หรือระบุพาธที่กำหนดเอง
  4. หาก Windows ถามรหัสผ่าน ให้ใช้รหัสผ่านที่คุณสามารถจัดเก็บได้อย่างปลอดภัย หรือกด Enter เพื่อข้ามขั้นตอนนี้สำหรับการตั้งค่าแบบง่าย
  5. แสดงคีย์สาธารณะโดยใช้คำสั่ง: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub
  6. คัดลอกเฉพาะบรรทัดที่ขึ้นต้นด้วย ssh-ed25519 เท่านั้น ห้ามคัดลอกหรืออัปโหลดไฟล์คีย์ส่วนตัว
> วิธีการสร้างคีย์ SSH แบบกราฟิกในระบบปฏิบัติการ Windows

ขั้นตอนการสร้างคู่กุญแจ SSH ในระบบปฏิบัติการ Windows โดยใช้โปรแกรมแบบมีส่วนติดต่อผู้ใช้ (GUI) เพื่อหลีกเลี่ยงการใช้ Command Line
faq/create-ssh-key-windows-gui-th

ใช้โปรแกรมบน Windows และใส่เฉพาะ public key เท่านั้น

คุณสามารถสร้างคู่กุญแจ SSH ได้ด้วยโปรแกรมบน Windows เช่น PuTTYgen โปรแกรม Cli>_ ต้องการเพียงแค่ public key เท่านั้น กรุณาเก็บไฟล์ private key ไว้ในเครื่องของคุณและอย่าอัปโหลดไปยังแบบฟอร์มบนเว็บไซต์

ขั้นตอน

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

ห้ามเปิดเผยข้อมูลลับ

โปรดอย่าส่งไฟล์ .ppk, คีย์ส่วนตัว, รหัสผ่าน หรือโทเค็น ไปยังฝ่ายสนับสนุนหรือผ่านแบบฟอร์ม

> นำโดเมนของคุณมาใช้

เรียนรู้วิธีการนำโดเมนหรือซับโดเมนของคุณไปเชื่อมต่อกับบริการ CLIopen ก่อนที่จะเปิดใช้งานฟีเจอร์ Bring your own domain
faq/chueamto-domain-khong-khun

การตั้งค่านี้ทำงานอย่างไร

การใช้งานโดเมนของคุณเองช่วยให้บริการของคุณตอบสนองผ่านชื่อโฮสต์ของคุณเอง เช่น app.example.com แทนที่จะใช้เฉพาะชื่อโฮสต์ที่สร้างขึ้นโดยอัตโนมัติ *.co.cliopen.cloud ก่อนที่คุณจะสามารถใช้ชื่อโฮสต์ได้อย่างปลอดภัย ระบบ DNS ของคุณต้องชี้ไปยัง CLIopen ก่อน

ก่อนเริ่มต้น

  1. เลือกชื่อโฮสต์ (hostname) ที่คุณต้องการใช้งาน เช่น app.example.com การใช้ซับโดเมนเป็นวิธีที่ง่ายที่สุด
  2. เข้าสู่ระบบการจัดการ DNS ของผู้ให้บริการจดทะเบียนโดเมนหรือผู้ให้บริการ DNS ของคุณ
  3. ลบหรือแก้ไขเรคคอร์ด A, AAAA, CNAME, ALIAS หรือ redirect ที่ขัดแย้งกันสำหรับชื่อโฮสต์นั้น
  4. ให้คงชื่อโฮสต์ CLIopen ที่สร้างขึ้นไว้จนกว่าชื่อโฮสต์ที่คุณกำหนดเองจะได้รับการตรวจสอบและใช้งานได้อย่างสมบูรณ์

การตั้งค่า DNS ที่แนะนำสำหรับโดเมนย่อย

สร้างรายการ DNS สำหรับชื่อโฮสต์ที่ถูกต้องซึ่งคุณจะป้อนใน CLIopen สำหรับ app.example.com ชื่อ DNS คือ app ชี้ไปยังที่อยู่ ingress ของ CLIopen ที่ได้รับจากฝ่ายสนับสนุนของ CLIopen หรือในเอกสารประกอบของบริการ หากผู้ให้บริการของคุณต้องการประเภทของรายการ ให้ใช้ A สำหรับ IPv4 และ AAAA สำหรับ IPv6 เมื่อมีที่อยู่เหล่านั้น

ตัวอย่าง:

app.example.com.  A     <ที่อยู่ IPv4 ของ CLIopen>
app.example.com.  AAAA  <ที่อยู่ IPv6 ของ CLIopen (ถ้ามี)>

เมื่อ CLIopen ระบุเป้าหมาย CNAME

บางบริการอาจให้ชื่อโฮสต์ที่สร้างขึ้น เช่น service.customer.co.cliopen.cloud หากคำแนะนำของบริการของคุณระบุไว้อย่างชัดเจนว่าต้องใช้ CNAME ให้สร้างรายการ เช่น app.example.com CNAME service.customer.co.cliopen.cloud ใช้ CNAME เฉพาะสำหรับโดเมนย่อย ไม่ใช่สำหรับโดเมนหลัก เว้นแต่ผู้ให้บริการ DNS ของคุณรองรับการ flattening แบบ ALIAS หรือ ANAME

การใช้งานโดเมนหลัก

สำหรับโดเมนเปล่า เช่น example.com ผู้ให้บริการ DNS ส่วนใหญ่ไม่รองรับ CNAME แบบมาตรฐาน ให้ใช้ A/AAAA records ที่ชี้ไปยังที่อยู่ ingress ของ CLIopen หรือใช้ฟังก์ชัน ALIAS/ANAME เฉพาะของผู้ให้บริการของคุณ หาก CLIopen ได้ระบุ hostname เป้าหมายให้คุณ

การมอบหมายช่วงย่อยทั้งหมด

หากคุณต้องการให้ CLIopen จัดการเรคคอร์ดภายใต้โซนย่อย เช่น apps.example.com ให้สร้าง NS records สำหรับโซนย่อยนั้น โดยชี้ไปยัง nameservers ของ CLIopen ที่คุณได้รับ อย่าเปลี่ยน nameservers สำหรับโดเมนทั้งหมด เว้นแต่ว่าคุณต้องการให้ CLIopen (หรือบริการ DNS อื่น) จัดการเรคคอร์ดทั้งหมด

รายการตรวจสอบ

  1. รอให้ DNS แพร่กระจาย การเปลี่ยนแปลงเล็กน้อยมักจะปรากฏภายในไม่กี่นาที แต่ผู้ให้บริการบางรายอาจใช้เวลาในการแคชเป็นเวลานานกว่า
  2. ตรวจสอบว่าชื่อโฮสต์ชี้ไปยังปลายทาง CLIopen ไม่ใช่ไปยังผู้ให้บริการเดิม
  3. กรุณากรอกชื่อโฮสต์ที่ถูกต้องในช่อง "Bring your own domain" โดยไม่ต้องใส่ `https://` และไม่รวมพาธใดๆ
  4. หลังจากอัปเดตแล้ว โปรดทดสอบ `https://app.example.com` ในเบราว์เซอร์ของคุณ
  5. เก็บรักษาเรคอร์ด DNS เก่าไว้เฉพาะในกรณีที่ไม่ขัดแย้งกับชื่อโฮสต์ใหม่
> วิธีการย้ายโซน DNS ไปยัง CLIopen

กำหนดค่าโดเมนของคุณให้ชี้ไปยัง ns1.cliopen.com และ ns2.cliopen.com เพื่อให้ CLIopen สามารถเผยแพร่ข้อมูลสำหรับทั้งโซน
faq/mopmai-zone-dns

ความหมายของการถ่ายโอนโซนในที่นี้คืออะไร

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

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

  1. คัดลอกบันทึก DNS ที่มีอยู่ซึ่งคุณยังต้องการ เช่น เว็บไซต์, อีเมล, การตรวจสอบ, SPF, DKIM, DMARC และบันทึกบริการ
  2. เพิ่มโซนใน CLIopen DNS หากการมอบหมายยังไม่พร้อมใช้งาน CLIopen จะบันทึกไว้ แต่จะไม่เปิดใช้งานสำหรับลูกค้าจนกว่าการตรวจสอบจะเสร็จสมบูรณ์
  3. สร้างรายการที่จำเป็นใน CLIopen DNS ก่อนที่จะเปลี่ยนเซิร์ฟเวอร์ชื่อ (nameserver) ถ้าเป็นไปได้
  4. โปรดตรวจสอบการตั้งค่า CAA ให้ถูกต้อง เนื่องจากค่าที่ไม่ถูกต้องอาจทำให้ไม่สามารถออกใบรับรองได้

มอบหมายโซน

  1. เปิดการตั้งค่าโดเมนจากผู้ให้บริการรายเดิมของคุณ เช่น example.com
  2. ค้นหา Nameservers, การมอบหมาย DNS หรือการตั้งค่า DNS ที่เป็น authoritative
  3. แทนที่ nameservers ปัจจุบันด้วย ns1.cliopen.com และ ns2.cliopen.com
  4. บันทึกการเปลี่ยนแปลง และรอให้มีการเผยแพร่ไปยังรีจิสทรีและตัวแก้ไข

การตรวจสอบความถูกต้อง

กลับไปที่ CLIopen DNS แล้วคลิก "ตรวจสอบการมอบหมายใหม่อีกครั้ง" เมื่อระเบียน NS สาธารณะแสดง ns1.cliopen.com และ ns2.cliopen.com, โซนจะถูกจัดคิวสำหรับการซิงโครไนซ์ และระเบียนจะใช้งานได้จาก CLIopen

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

สร้างบัญชีสำหรับผู้ใช้งาน, กรอกรายละเอียดการออกใบแจ้งหนี้ และเก็บอีเมลไว้เพื่อให้ทีมงานสามารถเข้าถึงได้
faq/account-registration-and-login

บัญชีเดียวสำหรับจัดการคำสั่งซื้อและบริการ

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

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

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

การเข้าถึงสำหรับทีม

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

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

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

ข้อมูลเปรียบเทียบไม่ใช่ปฏิทินการเรียกเก็บเงิน

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

สิ่งที่ควรตรวจสอบเมื่อมีการเปลี่ยนแปลงราคา

  1. เปรียบเทียบปริมาณการใช้งานรายวันก่อนและหลังการเปลี่ยนแปลง
  2. หากมีการเพิ่ม CPU, RAM หรือดิสก์ หรือเลือกบริการเสริมที่ต้องชำระเงิน ค่าใช้จ่ายรายวันที่อาจสูงขึ้น
  3. การเปลี่ยนแปลงจะมีผลหลังจากได้รับการยืนยัน ชำระเงิน (ถ้ามี) และนำไปปรับใช้
  4. สำหรับฝ่ายบัญชี โปรดเก็บใบยืนยันการสั่งซื้อและประวัติเครดิตไว้

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

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

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

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

สถานะ 'กำลังดำเนินการ' ไม่ได้หมายความว่าล้มเหลวเสมอไป

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

หลังจากชำระเงิน

  1. เมื่อการชำระเงินเสร็จสมบูรณ์ ให้กลับไปยังหน้า Cli>_.
  2. ตรวจสอบสถานะของคำสั่งซื้อในบัญชีของคุณ และดูข้อความที่อาจปรากฏขึ้นระหว่างการชำระเงิน
  3. หากคำสั่งซื้อยังอยู่ในขั้นตอนรอการยืนยัน โปรดให้เวลาผู้ให้บริการในการดำเนินการ
  4. หากมีปัญหา โปรดส่งหมายเลขคำสั่งซื้อและหลักฐานการชำระเงิน (ถ้ามี) ให้กับฝ่ายสนับสนุน

สิ่งที่ไม่ควรส่ง

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

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

โปรดเตรียมชื่อบริการ, โดเมน, ขนาดพื้นที่จัดเก็บ, อีเมลสำหรับเข้าถึง และคีย์ SSH สาธารณะ; กรุณาอย่าใส่ข้อมูลลับลงในแบบฟอร์ม
faq/service-setup-information-needed

ข้อมูลที่ถูกต้องช่วยประหยัดเวลา

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

เตรียมตัวก่อนคลิกเพื่อยืนยันการสั่งซื้อ

  1. เลือกชื่อบริการที่ทีมของคุณสามารถจดจำได้
  2. ตัดสินใจว่าจะใช้โดเมนส่วนตัวหรือชื่อโฮสต์ชั่วคราว
  3. เตรียมคีย์ SSH สาธารณะ หากบริการนั้นต้องการ
  4. ตรวจสอบขนาดพื้นที่จัดเก็บและทรัพยากรที่จำเป็นตามแอปพลิเคชันที่คุณต้องการใช้งาน

ข้อมูลลับห้ามส่ง

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

> เปลี่ยนแปลง CPU, RAM, ดิสก์ หรือระยะเวลาใช้งานหลังจากทำการสั่งซื้อ

แก้ไขบริการที่มีอยู่ผ่านรายละเอียดของบริการนั้น ไม่ใช่ด้วยการสร้างคำสั่งซื้อใหม่; การเปลี่ยนแปลงทรัพยากรอาจส่งผลต่อราคา ค่าบริการ การใช้เครดิตรายวัน การรีสตาร์ท และความเสี่ยงของการหยุดทำงาน
faq/change-service-resources-after-order

คุณกำลังแก้ไขบริการที่มีอยู่ ไม่ใช่สร้างบริการใหม่

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

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

  1. ดู CPU, RAM, พื้นที่จัดเก็บข้อมูล, การสำรองข้อมูล และระยะเวลาการเก็บรักษา Offsite Archive ปัจจุบัน
  2. ตรวจสอบราคาใหม่และผลกระทบต่อเครดิตรายวัน
  3. อ่านข้อความแจ้งเตือนเกี่ยวกับการรีสตาร์ท การบำรุงรักษา หรือการหยุดทำงาน
  4. ก่อนทำการเปลี่ยนแปลงใดๆ ที่อาจมีความเสี่ยง โปรดสำรองข้อมูลสำคัญของคุณเอง

เมื่อการเปลี่ยนแปลงไม่เป็นไปตามที่คาดหวัง

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

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

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

การยกเลิกไม่ได้หมายความว่าจะลบข้อมูลทันทีเสมอไป

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

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

  1. สร้างการส่งออกข้อมูลของคุณเอง เพื่อสำรองข้อมูลที่คุณต้องการเก็บไว้นานๆ
  2. โปรดอ่านวันที่และเวลาที่กำหนดไว้สำหรับการลบข้อมูล เมื่อบริการถูกระงับ
  3. โปรดทราบว่า การสำรองข้อมูลและการจัดเก็บข้อมูลภายนอก (Offsite Archive) มีระยะเวลาการเก็บรักษาที่แตกต่างจากการลบข้อมูลตามรอบเวลาของบริการ
  4. หากไม่แน่ใจ โปรดติดต่อฝ่ายสนับสนุนก่อนถึงกำหนดเวลาการลบข้อมูล

อาจไม่สามารถกู้คืนได้หลังจากหมดระยะเวลา

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

> การสำรองข้อมูลและคำขอดำเนินการกู้คืน

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

Backup ไม่ใช่ระบบสำรองข้อมูลแบบคลังข้อมูลหรือการส่งออก

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

วิธีการเตรียมคำขอรีสโตร์

  1. โปรดระบุชื่อบริการและหมายเลขคำสั่งซื้อ
  2. กรุณาระบุช่วงเวลาโดยประมาณที่คุณต้องการย้อนกลับ
  3. โปรดแจ้งว่าคุณต้องการกู้คืนทั้งบริการหรือเฉพาะบางส่วน (หากมี)
  4. แนบข้อผิดพลาดที่มองเห็นได้ หรือบริบท โดยไม่มีรหัสผ่าน, โทเค็น หรือคีย์ส่วนตัว

ประเมินผลกระทบก่อนทำการกู้คืน

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

> Offsite Archive คืออะไร

Offsite Archive จัดเก็บสำเนาข้อมูลระยะยาวในศูนย์ข้อมูลอื่น ซึ่งแยกต่างหากจากระบบสำรองข้อมูลทั่วไปและการลบข้อมูลตามรอบเวลา และไม่ใช่พื้นที่จัดเก็บข้อมูลที่ใช้งานอยู่ การคิดค่าบริการอิงตามปริมาณข้อมูลที่จัดเก็บและระยะเวลา: ปริมาณข้อมูล (MB) คูณด้วยจำนวนวันที่จัดเก็บ โดยแสดงเป็นราคาต่อ GB ต่อเดือน และปัดเศษเป็นเซ็นต์
faq/offsite-archive-purpose

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

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

เมื่อใดควรใช้งาน

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

วิธีพิจารณาค่าใช้จ่าย

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

> การเลือก CPU, RAM และพื้นที่เก็บข้อมูลสำหรับ VPS

เลือกขนาด VPS ตามลักษณะงาน, ฐานข้อมูล, แคช, บันทึก และการขยายตัว; หากเกิดข้อผิดพลาด OOM หรือมีการใช้ swap แสดงว่าอาจต้องเพิ่ม RAM
faq/vps-cpu-ram-and-disk-sizing

เริ่มต้นด้วยปริมาณงานจริง ไม่ใช่แค่ความรู้สึก

เว็บไซต์แบบ static ขนาดเล็กมีความต้องการที่แตกต่างจากฐานข้อมูล, แอปพลิเคชัน Java, ระบบค้นหา หรือ container ที่ใช้ในการสร้าง (build). เมื่อวางแผนการใช้งาน ให้คำนึงถึงหน่วยความจำของแอปพลิเคชัน, cache, ฐานข้อมูล, log files, การอัปโหลด และพื้นที่สำรองสำหรับการเติบโต.

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

  1. เพิ่ม RAM เมื่อเกิดข้อผิดพลาด OOM (Out of Memory), process ถูกปิด หรือมีการใช้งาน swap อย่างต่อเนื่อง
  2. เพิ่ม CPU เมื่อมีการใช้งานการประมวลผลอย่างต่อเนื่อง, การบีบอัดข้อมูล, การสร้างโปรเจ็กต์ หรือ worker ที่ทำงานหนัก
  3. เพิ่มขนาดดิสก์ก่อนที่ระบบไฟล์, ไฟล์บันทึก หรือฐานข้อมูลจะเต็ม
  4. หลังจากทำการเปลี่ยนแปลงแต่ละครั้ง โปรดตรวจสอบว่าแอปพลิเคชันหยุดทำงานเนื่องจากข้อจำกัดเดิมหรือไม่

สิ่งที่ควรแจ้งเมื่อมีข้อสงสัยเกี่ยวกับขนาด

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

> เมื่อใดควรใช้ Public IP สำหรับ VPS

Public IP ที่กำหนดค่าเฉพาะช่วยให้การจัดการรายการอนุญาต (allowlist) การเข้าถึงจากภายนอก (inbound access) แหล่งสัญญาณขาออกที่เสถียร หรือบริการที่ผูกกับที่อยู่ทำได้ง่ายขึ้น
faq/vps-public-ip-options

ตรวจสอบทิศทางการสื่อสารก่อน

ไม่ใช่ทุกบริการที่จำเป็นต้องมี Public IP โดยทั่วไปแล้ว ความต้องการนี้มักมาจากคู่ค้า ผู้ให้บริการ หรือไฟร์วอลล์ภายนอก ซึ่งต้องการที่อยู่คงที่สำหรับการอนุญาต (allowlist) สำหรับการรับข้อมูล (inbound), การส่งข้อมูลออก (outbound source) หรือทั้งสองอย่าง

คำถามก่อนสั่งซื้อ IP

  1. สอบถามไปยังผู้ให้บริการว่าต้องการให้ใส่รายการ (allowlist) สำหรับการเชื่อมต่อขาเข้า, ขาออก หรือทั้งสองแบบหรือไม่
  2. ใช้ชื่อ DNS แทนที่หมายเลข IP ในทุกๆ ที่ที่เป็นไปได้ หากระบบภายนอกรองรับ
  3. เปิดเฉพาะพอร์ตที่แอปพลิเคชันต้องการใช้งานจริงเท่านั้น
  4. โปรดแจ้งความต้องการรายการอนุญาต (allowlist) ให้ฝ่ายสนับสนุนทราบก่อนทำการเปลี่ยนแปลงการเข้าถึงระบบจริง

สิ่งที่ไม่ควรเปิดใช้งาน

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

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

หากไม่ได้ซื้อ Public IP เพิ่มเติม, VPS จะเชื่อมต่อผ่านจุดเชื่อมต่อ SSH ที่ใช้ร่วมกันพร้อมพอร์ตสูง หากมี Public IP เฉพาะ, คุณจะสามารถเข้าถึง SSH โดยตรงที่ IP นั้นได้
faq/shared-ssh-access-for-vps

ทำไม SSH แบบแชร์ถึงต้องใช้พอร์ตสูง

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

วิธีการเชื่อมต่อตามประเภทการเข้าถึง

  1. สำหรับการเชื่อมต่อ SSH แบบร่วมกัน กรุณาคัดลอกชื่อผู้ใช้ (username), โฮสต์สาธารณะ (public host) และพอร์ต จากหน้าบริการ
  2. ใช้คำสั่ง `ssh -p <port> <username>@<public-host>` เพื่อเชื่อมต่อ
  3. หากบริการมี IP สาธารณะ โปรดตรวจสอบข้อมูลโฮสต์หรือ IP ที่แสดงสำหรับบริการนั้น
  4. ใช้คีย์ส่วนตัวเฉพาะในเครื่องของคุณผ่าน SSH client หรือ agent; ฝ่ายสนับสนุนต้องการเพียง public host, port, username และข้อผิดพลาดที่ปรากฏ

เมื่อคุณมี Public IP ที่ซื้อเพิ่ม

Dedicated public IP อาจเพิ่มช่องทางโดยตรงที่เหมาะสำหรับ allowlist, การตรวจสอบ หรือการเชื่อมต่อที่ต้องการที่อยู่คงที่ แต่ SSH ยังขึ้นอยู่กับ endpoint, พอร์ต, ไฟร์วอลล์ และวิธีการยืนยันตัวตนที่แสดงบนบริการ

> ตรวจสอบก่อนเชื่อมต่อโดเมนของคุณ

ตรวจสอบข้อมูลสำคัญก่อนเปลี่ยนโดเมน เช่น ข้อมูล DNS ที่ถูกต้อง, ชื่อโฮสต์ที่แม่นยำ, ประเภทของ Record (เช่น A record, CNAME), ว่าเป็นโดเมนหลักหรือ Subdomain และตรวจสอบว่าไม่มี Record เก่าที่ขัดแย้งกัน
faq/custom-domain-readiness-checklist

สิ่งที่ควรทราบเกี่ยวกับชื่อโฮสต์

ก่อนเริ่มต้น ตรวจสอบให้แน่ใจว่าคุณกำลังเชื่อมต่อโดเมนหลัก (เช่น example.com) หรือซับโดเมน (เช่น app.example.com) เนื่องจากแต่ละกรณีอาจต้องใช้ประเภทของเร็กคอร์ด DNS ที่แตกต่างกัน ข้อจำกัดจากผู้ให้บริการ DNS และการตรวจสอบกับผู้ลงทะเบียน

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

  1. ตรวจสอบตำแหน่งที่บันทึก DNS แบบ authoritative สำหรับโดเมนของคุณ
  2. ลบหรือแก้ไข A/AAAA, CNAME, ALIAS, ANAME หรือ redirect ที่ขัดแย้งกัน
  3. ใช้ประเภทของ record ที่แนะนำสำหรับบริการและ hostname นั้นๆ
  4. หลังจากทำการเปลี่ยนแปลงแล้ว โปรดรอให้การเผยแพร่ DNS เสร็จสมบูรณ์ก่อน จากนั้นจึงทดสอบ HTTPS ขั้นสุดท้าย

การย้อนกลับที่ปลอดภัย

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

> ประเภทของเรคอร์ด DNS สำหรับบริการ

A/AAAA ชี้ไปยังที่อยู่ IP, CNAME สร้างชื่อแทน, MX ใช้สำหรับอีเมล และ TXT ใช้สำหรับการยืนยัน เช่น SPF, DKIM หรือ DMARC
faq/dns-record-types-for-services

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

A และ AAAA ชี้ไปยังที่อยู่ IP, CNAME สร้างชื่อแทนสำหรับ subdomain, MX กำหนดเส้นทางการส่งอีเมล, TXT ใช้สำหรับการยืนยันและนโยบายอีเมล, และ CAA จำกัดหน่วยงานออกใบรับรอง

เมื่อคัดลอกรายการ

  1. คัดลอกชื่อ, ประเภท และค่าตามคำแนะนำของบริการอย่างเคร่งครัด
  2. อย่าใช้ CNAME กับ hostname ที่มี record อื่นอยู่ หากกฎ DNS ไม่อนุญาต
  3. ใส่ DKIM ไว้ใต้ส่วน selector ของผู้ให้บริการ และ DMARC โดยทั่วไปไว้ที่ _dmarc
  4. ตั้งค่า CAA อย่างระมัดระวัง เนื่องจากค่าที่ไม่ถูกต้องอาจทำให้การออกใบรับรองถูกบล็อก

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

ส่งข้อมูล hostname, ประเภทของ record, ค่าที่คาดหวัง และผลลัพธ์ที่มองเห็นได้ อย่าส่งรหัสผ่านสำหรับการเข้าสู่ระบบ DNS หรือภาพหน้าจอที่มี API token

> การแพร่กระจายของ DNS และ TTL โดยไม่มีการรับประกันเวลา

TTL (Time To Live) กำหนดระยะเวลาที่ resolver สามารถเก็บข้อมูลคำตอบเดิมไว้ได้ ในช่วงของการเปลี่ยนแปลง อาจมีทั้งข้อมูลเก่าและใหม่ปรากฏพร้อมกัน
faq/dns-propagation-and-ttl

การเผยแพร่คือแคช ไม่ใช่การรอคอยแบบมหัศจรรย์

ในระบบ DNS ไม่มีข้อสัญญาที่แน่นอนเกี่ยวกับเวลาเป็นนาที หลังจากเปลี่ยนแปลง authoritative DNS แล้ว ตัวแก้ไข (resolver) ต่างๆ อาจยังคงส่งคืนค่าเก่าและใหม่ จนกว่าแคชจะหมดอายุตาม TTL ดังนั้น ผลลัพธ์อาจแตกต่างกันไปในแต่ละเครือข่าย ประเทศ หรือตัวแก้ไข DNS

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

  1. ลดค่า TTL ล่วงหน้าหากผู้ให้บริการอนุญาต
  2. แก้ไข DNS เพียงครั้งเดียว และหลีกเลี่ยงการแก้ไขซ้ำในขณะที่แคชหมดอายุ
  3. ทดสอบจากหลายแหล่ง (resolver) หากผลลัพธ์ไม่ตรงกัน
  4. จดเวลาการเปลี่ยนแปลง, ค่าเดิม, ค่าใหม่ และค่า TTL.

ข้อมูลสำหรับการวินิจฉัย

โปรดระบุชื่อโฮสต์ (hostname), เป้าหมายที่คาดหวัง, คำตอบเดิมที่แสดงผล, คำตอบใหม่ที่แสดงผล, ค่า TTL และเวลาในการเปลี่ยนแปลง กรุณาอย่าส่งข้อมูลรหัสเข้าสู่ระบบ DNS หรือบันทึกภายในของผู้ให้บริการ

> การวางแผนพื้นที่จัดเก็บข้อมูลสำหรับ Workspace Suite

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

Workspace Suite ใช้พื้นที่มากกว่าไฟล์ที่คุณเห็น

Kapacitu míňajú používateľské súbory, zdieľané priečinky, odstránené súbory, verzovanie, náhľady, klienty synchronizácie a importy. Ak sa úložisko blíži k limitu, môžu zlyhávať nahrávania alebo synchronizácia.

ขั้นตอนก่อนทำการสั่งซื้อพื้นที่

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

เมื่อพบปัญหาเกี่ยวกับการซิงค์

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

> การย้าย repositories ไปยัง Gitea

วางแผนการย้าย Git repositories โดยคำนึงถึง Git LFS, submodules, สิทธิ์การเข้าถึง, deploy keys, webhooks และ CI/CD
faq/gitea-repository-migration

การโยกย้ายข้อมูลไม่ใช่แค่การใช้คำสั่ง git clone

นอกเหนือจากประวัติของที่เก็บ (repository) แล้ว คุณยังต้องถ่ายโอนหรือกำหนดค่าเจ้าของ, ทีม, บรันช์ที่มีการป้องกัน, แท็กที่มีการป้องกัน, Git LFS, โมดูลย่อย, คีย์สำหรับการใช้งาน, เว็บฮุค และการเชื่อมต่อ CI/CD

ตรวจสอบก่อนดำเนินการ

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

ข้อมูลสำคัญในการโยกย้าย

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

> โดเมนสำหรับส่งอีเมลของ Listmonk

สำหรับการรันแคมเปญ โปรดเตรียมโดเมนหรือซับโดเมนของผู้ส่ง รวมถึงข้อมูล From identity, SPF, DKIM, DMARC, การจัดการการตอบกลับ (bounce) และระบบยกเลิกการรับจดหมาย
faq/listmonk-sender-domain-basics

การส่งอีเมลที่มีประสิทธิภาพเริ่มต้นจากโดเมนของคุณ

Listmonk ต้องการข้อมูลประจำตัวผู้ส่งที่ชัดเจน และบันทึก DNS ที่ระบบไปรษณีย์สามารถตรวจสอบได้ SPF, DKIM และ DMARC จะต้องตรงกับโดเมนหรือซับโดเมนที่คุณต้องการใช้ในการส่งแคมเปญ

ก่อนเริ่มแคมเปญแรก

  1. เลือกโดเมนหรือซับโดเมนสำหรับผู้ส่ง และตั้งค่าชื่อ "From".
  2. เพิ่มรายการ DNS สำหรับการยืนยัน, SPF, DKIM selector และ DMARC.
  3. ทดสอบการส่งอีเมล เพื่อตรวจสอบปัญหา เช่น การถูกตีเป็นสแปม, การตอบกลับเมื่ออีเมลไม่สามารถส่งได้ (bounce), Return-Path และลิงก์ในอีเมล
  4. ตรวจสอบการยกเลิกการสมัครสมาชิกและ List-Unsubscribe ก่อนส่งอีเมลจริง

ความลับเกี่ยวกับอีเมล ไม่ควรระบุในตั๋ว

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

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

Classic Hosting สามารถทำงานได้ทั้งในโหมดอัตโนมัติและโหมด manual โดยที่ CPU, RAM, หน่วยความจำ, พื้นที่จัดเก็บข้อมูล, ระยะเวลาการเก็บสำรองข้อมูล, ระยะเวลาการเก็บ Offsite Archive, การอัปโหลด, แคช และบันทึกต่างๆ มีผลต่อราคาและความเสถียร
faq/classic-hosting-runtime-settings

โหมดอัตโนมัติไม่ใช่ตัวเลือกที่ดีที่สุดเสมอไป

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

การตั้งค่าก่อนใช้งาน

  1. เลือกโหมดอัตโนมัติสำหรับการสร้างแบบตรวจจับ หรือโหมดด้วยตนเองสำหรับ Nginx, Apache หรือ FrankenPHP runtime control
  2. เลือก PHP 8.2/8.3/8.4 เฉพาะเมื่อ runtime ที่เลือกนั้นรองรับตัวเลือกนี้
  3. กำหนดขนาด CPU, RAM, หน่วยความจำ, พื้นที่จัดเก็บข้อมูล, ระยะเวลาการสำรองข้อมูล และระยะเวลาการเก็บรักษา Offsite Archive ตามปริมาณข้อมูลและจำนวนผู้เข้าชม
  4. หลังจากติดตั้ง ให้ทดสอบการอัปโหลด, แคช, บันทึก และข้อผิดพลาดที่มองเห็นได้ของแอปพลิเคชัน

เมื่อแอปพลิเคชันไม่เริ่มต้นทำงาน

ส่งข้อมูลเกี่ยวกับโหมดการทำงาน, ภาษา หรือเวอร์ชัน PHP, ข้อผิดพลาดที่ปรากฏ สิ่งที่เปลี่ยนแปลงล่าสุด และเวลาในการติดตั้ง โปรดอย่าส่งไฟล์ .env รหัสผ่าน โทเค็น หรือบันทึกทั้งหมดที่มีข้อมูลที่เป็นความลับ

> ข้อมูลใดบ้างที่สามารถส่งให้ทีมสนับสนุนได้อย่างปลอดภัย

ข้อมูลที่สำคัญที่สุด ได้แก่ หมายเลขคำสั่งซื้อ ชื่อบริการ โดเมน เวลา เซิร์ฟเวอร์สาธารณะ พอร์ต ระยะเวลาการเก็บสำรองข้อมูล Offsite Archive การอัปโหลด แคช บันทึกภาพหน้าจอ และข้อผิดพลาดที่มองเห็นได้ โดยไม่เปิดเผยข้อมูลที่เป็นความลับ
faq/support-safe-information-to-share

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

ฝ่ายสนับสนุนสามารถช่วยเหลือได้เร็วขึ้นเมื่อได้รับข้อมูลบริบทที่เกี่ยวข้องกับลูกค้า โดยไม่เปิดเผยข้อมูลที่เป็นความลับ ข้อมูลที่ปลอดภัยในการให้ ได้แก่ หมายเลขคำสั่งซื้อ ชื่อบริการที่แสดงต่อผู้ใช้ โดเมน เซิร์ฟเวอร์สาธารณะและพอร์ต เวอร์ชั่น PHP CPU RAM พื้นที่จัดเก็บ การสำรองข้อมูล ระยะเวลาการเก็บรักษาไฟล์สำรอง อัปโหลด แคช บันทึกโดยประมาณ ภาพหน้าจอที่ปิดบังข้อความ และข้อผิดพลาดที่ปรากฏ อย่าส่งรหัสผ่าน คีย์ส่วนตัว โทเค็นวลีเริ่มต้น ไฟล์บันทึกที่มีข้อมูลที่เป็นความลับ การสำรองข้อมูลฐานข้อมูล หรือรายละเอียดโครงสร้างพื้นฐานภายใน

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

  1. โปรดระบุหมายเลขคำสั่งซื้อ ชื่อบริการที่แสดง ประเภทโดเมน เวลาโดยประมาณ และโฮสต์หรือพอร์ตสาธารณะ (ถ้าเกี่ยวข้อง) เมื่อเกิดปัญหา
  2. สำหรับปัญหาเกี่ยวกับ hosting โปรดระบุ runtime, ภาษา หรือเวอร์ชัน PHP, CPU, RAM, พื้นที่จัดเก็บข้อมูล, ระยะเวลาการสำรองข้อมูล, ระยะเวลาการเก็บรักษา Offsite Archive, การอัปโหลด, แคช และบันทึก (logs) โดยไม่รวมข้อมูลที่เป็นความลับ
  3. โปรดปิดบังรหัสผ่าน โทเค็น คีย์ส่วนตัว เซสชัน และข้อมูลส่วนบุคคลในภาพหน้าจอ ก่อนที่จะส่ง
  4. หากไม่แน่ใจว่าข้อมูลนั้นควรอยู่ในรายการแจ้งปัญหาหรือไม่ ให้สอบถามก่อนที่จะส่งข้อมูลใดๆ

สิ่งที่ต้องหลีกเลี่ยงในการส่งข้อมูล

ห้ามส่งรหัสผ่าน, private keys, recovery seed, API token, session cookies, ข้อมูลการสำรองฐานข้อมูล, ไฟล์ .env ทั้งหมด, บันทึก (log) ที่มีข้อมูลสำคัญ หรือรายละเอียดโครงสร้างพื้นฐานภายใน