วิธีเลือกเช่า VPS สำหรับรัน Game Server ให้ลื่นไหล

คุณหมายถึง Gaming VPS ประเภทใด

VPS สำหรับเซิร์ฟเวอร์เกมเป็นการลงทุนที่คุ้มค่าสำหรับงานเดียว คือการรัน dedicated server เพื่อให้คุณและเพื่อนเชื่อมต่อเข้ามาจากเครื่องส่วนตัว แต่จะเป็นการลงทุนที่ไม่คุ้มค่าสำหรับอีกความหมายหนึ่งที่ผู้คนมักเข้าใจผิด ซึ่งก็คือการเล่นเกมบนตัว VPS โดยตรงผ่าน remote desktop งานทั้งสองประเภทนี้ต้องการฮาร์ดแวร์ที่แตกต่างกันอย่างสิ้นเชิง dedicated server ต้องการ CPU core ที่มีความเร็วสูงหนึ่งคอร์และ RAM ที่เพียงพอต่อการโหลดข้อมูลโลกของเกม ส่วนการเล่นเกมต้องการ GPU (graphics processing unit) ซึ่งแผนบริการ VPS มาตรฐานไม่มีให้

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

เหตุผลที่คุณไม่สามารถเล่นเกมบน VPS ได้

VPS มาตรฐานให้คุณใช้งาน virtual CPU core เท่านั้นและไม่มีการ์ดจอมาให้ ไม่มีการส่งผ่านทรัพยากรจากโฮสต์จริง ดังนั้นจึงไม่มี hardware renderer สำหรับให้เกมใช้งาน คุณสามารถตรวจสอบสิ่งที่คุณได้รับจริงได้ด้วยคำสั่งนี้:

sudo apt install -y pciutils
lspci | grep -iE "vga|3d"

คำตอบที่ได้จะเป็น virtual display adapter เช่น อุปกรณ์ประเภท Cirrus Logic หรือ virtio GPU ซึ่งมีไว้เพื่อให้ web console ของผู้ให้บริการแสดงหน้าจอให้คุณเห็นเท่านั้น และมันไม่มีระบบ 3D acceleration รองรับ หากคุณติดตั้ง desktop และ VNC server ลงไป glxinfo -B จะรายงาน renderer เป็น llvmpipe ซึ่งก็คือ Mesa software renderer ที่ทำงานบน CPU เกม 3D สมัยใหม่ที่ประมวลผลด้วย CPU จะทำงานได้เพียงไม่กี่เฟรมต่อวินาที จึงไม่สามารถเล่นได้ตั้งแต่ก่อนที่ข้อมูลจะถูกส่งออกจากเครื่องเสียอีก สำหรับ Windows instance ก็ประสบปัญหาเดียวกัน หลายเกมจะปิดตัวลงทันทีที่เปิดใช้งานโดยแจ้งเตือนว่าไม่สามารถสร้าง Direct3D device ได้ เนื่องจากไม่มี display adapter ให้ใช้งาน

ปัญหาที่สองคือการส่งข้อมูลกลับมายังคุณ การเล่นเกมบนเครื่องระยะไกลหมายความว่าทุกเฟรมจะต้องถูกเข้ารหัสเป็นวิดีโอ ส่งผ่านอินเทอร์เน็ต และถอดรหัสบนหน้าจอของคุณ ซึ่งจะเพิ่มเวลาในการเข้ารหัสและถอดรหัสเข้าไปรวมกับ input lag ของตัวเกมเอง อีกทั้ง RDP และ VNC ถูกออกแบบมาเพื่อการใช้งาน desktop ไม่ใช่สำหรับการแสดงผลภาพเคลื่อนไหวที่ 60 เฟรมต่อวินาที บริการ cloud gaming แก้ปัญหานี้ด้วยการใช้ GPU จริงและโปรโตคอลสตรีมมิ่งที่สร้างขึ้นมาโดยเฉพาะ แต่ VPS ทั่วไปไม่มีทั้งสองอย่าง หากคุณต้องการเล่นเกม ให้เช่าเวลาใช้งาน GPU หากคุณต้องการโฮสต์บริการ ให้ศึกษาเนื้อหาถัดไป

สิ่งที่เซิร์ฟเวอร์เกมแบบเฉพาะ (Dedicated Game Server) ต้องการจริงๆ

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

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

ความเร็วต่อคอร์สำคัญกว่าจำนวนคอร์

เซิร์ฟเวอร์เกมส่วนใหญ่ประมวลผลโลกของเกมผ่านเธรดหลักเพียงเธรดเดียว ทั้งลูปการทำงานของ Minecraft และเฟรมเซิร์ฟเวอร์ของ Source engine ต่างทำงานในลักษณะนี้ ซึ่งการประมวลผลแต่ละรอบ (tick) จะมีกำหนดเวลาที่จำกัด Minecraft Java ทำงานที่ 20 ticks ต่อวินาที ซึ่งหมายความว่าแต่ละ tick จะมีงบเวลาให้ 50 มิลลิวินาที เมื่อการประมวลผลไม่เสร็จสิ้นภายในเวลาที่กำหนด เซิร์ฟเวอร์จะแสดงข้อความนี้:

[12:04:51] [Server thread/WARN]: Can't keep up! Is the server overloaded? Running 2547ms or 50 ticks behind

บรรทัดดังกล่าวหมายความว่าเธรดหลักทำงานไม่ทันเวลา การเพิ่มจำนวนคอร์ไม่ได้ช่วยให้เธรดนั้นมีเวลาทำงานมากขึ้น แผนบริการที่มี 2 vCPU ความเร็วสูงจะสามารถรักษาอัตรา tick ได้ดีกว่าแผนที่มี 8 vCPU ความเร็วต่ำ เพราะมีเพียงคอร์เดียวจาก 8 คอร์นั้นที่ทำหน้าที่ประมวลผลส่วนสำคัญ

ควรวัดความเร็วของเธรดเดี่ยว (single thread) ก่อนตัดสินใจเลือกแผนบริการ:

sudo apt install -y sysbench
sysbench cpu --cpu-max-prime=20000 --threads=1 run

ให้อ่านค่าในบรรทัด events per second ตัวเลขนี้ไม่มีความหมายในตัวเองหากไม่มีการเปรียบเทียบ ดังนั้นควรทดสอบกับแผนบริการสองแผนที่สนใจแล้วนำผลลัพธ์มาเปรียบเทียบกัน การรัน benchmark เต็มรูปแบบสำหรับ VPS จะครอบคลุมถึงการทดสอบดิสก์และเครือข่ายในลักษณะเดียวกัน

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

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

vmstat 1 5

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

เซิร์ฟเวอร์เกมต้องการ RAM เท่าใด

[
  {
    "label": "Minecraft Java, vanilla",
    "players": 10,
    "ram_gb": 2
  },
  {
    "label": "Minecraft Java, large modpack",
    "players": 10,
    "ram_gb": 8
  },
  {
    "label": "Valheim",
    "players": 10,
    "ram_gb": 4
  },
  {
    "label": "Palworld",
    "players": 32,
    "ram_gb": 16
  }
]

นี่คือการจัดสรรทรัพยากรเริ่มต้นตามที่เอกสารของตัวเกมและ modpack ระบุไว้ ณ เดือนสิงหาคม 2026 ตัวเลขเหล่านี้เป็นเพียงแนวทาง ไม่ใช่ค่าที่วัดได้จริงจากเครื่องใดเครื่องหนึ่งโดยเฉพาะ Minecraft Java รุ่น Vanilla สามารถทำงานได้อย่างราบรื่นด้วย heap ขนาด 2 GB สำหรับผู้เล่นประมาณ 10 คน หากเป็น modpack ขนาดใหญ่สำหรับผู้เล่นจำนวนเท่ากันจะต้องการ RAM 8 GB เนื่องจาก mod จะเพิ่ม entities และโครงสร้างที่ถูกสร้างขึ้น (generated structures) ซึ่งทั้งหมดต้องใช้พื้นที่ใน heap สำหรับ Valheim นั้น ขั้นต่ำที่ระบุไว้คือ 2 GB แต่ผู้ดูแลเซิร์ฟเวอร์ที่มีโลกขนาดเล็กรายงานว่ากระบวนการทำงานจริงใช้ RAM ใกล้เคียง 3 GB ดังนั้นการเริ่มต้นที่ 4 GB จึงเป็นจุดเริ่มต้นที่เหมาะสม ส่วน Palworld เป็นกรณีพิเศษที่ต้องการ RAM 16 GB สำหรับผู้เล่นสูงสุด 32 คน ตามที่ Pocketpair แนะนำ

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

เซิร์ฟเวอร์ Java มีกฎเพิ่มเติมสองข้อ ควรตั้งค่า heap ขั้นต่ำและสูงสุดให้เท่ากัน เพื่อไม่ให้ JVM ต้องหยุดชะงักเพื่อปรับขนาดหน่วยความจำ:

java -Xms4G -Xmx4G -jar server.jar nogui

จากนั้นให้เผื่อพื้นที่หน่วยความจำไว้ด้วย JVM จะใช้หน่วยความจำนอกเหนือจาก heap ที่คุณกำหนดไว้สำหรับ thread stacks และ native buffers นอกจากนี้ kernel ยังต้องการ page cache เพื่ออ่านไฟล์โลกอย่างรวดเร็ว บนเครื่องที่มี RAM 6 GB การกำหนด heap ไว้ที่ 4 GB ถือว่าสมเหตุสมผล แต่การกำหนดไว้ที่ 6 GB นั้นไม่เหมาะสม

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

java.lang.OutOfMemoryError: Java heap space

หากกำหนด heap ใหญ่กว่าหน่วยความจำที่มีในเครื่อง กระบวนการทั้งหมดจะถูกสั่งยุติจากภายนอก คอนโซลจะแสดงเพียงข้อความ Killed และหลักฐานจะปรากฏอยู่ใน log ของ kernel:

sudo dmesg -T | grep -i "out of memory"

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

หมายเหตุเกี่ยวกับเวอร์ชัน ณ เดือนสิงหาคม 2026: Minecraft Java 1.20.5 ขึ้นไปจำเป็นต้องใช้ Java 21 หากใช้ runtime เวอร์ชันเก่า เซิร์ฟเวอร์จะเริ่มทำงานแล้วล้มเหลวพร้อมข้อความแสดงข้อผิดพลาด unsupported class file version ซึ่งมีลักษณะคล้ายข้อความจาก compiler และมักสร้างความสับสนให้กับผู้ที่พบเห็นเป็นครั้งแรก

sudo apt install -y openjdk-21-jre-headless
java -version

ความเร็วของดิสก์มีผลต่อเซิร์ฟเวอร์เกมหรือไม่

มีผลน้อยกว่าที่หลายคนคาดคิดในระหว่างการเล่น แต่มีความสำคัญอย่างมากใน 2 ช่วงเวลาหลัก ข้อมูลโลกจะถูกอ่านเข้าสู่หน่วยความจำในขณะเริ่มระบบและเขียนกลับลงดิสก์เมื่อมีการบันทึกอัตโนมัติ (autosave) ดังนั้นความเร็วของดิสก์จะส่งผลให้การบูตเครื่องช้าลงและเกิดอาการค้างชั่วขณะเมื่อระบบบันทึกข้อมูล ในระหว่างนั้นการอ่านข้อมูลส่วนใหญ่จะทำผ่าน RAM

มี 2 ปัจจัยที่ทำให้ดิสก์มีความสำคัญมากกว่าที่สรุปไว้ข้างต้น ประการแรก การสำรวจพื้นที่ใหม่จะมีการโหลด chunk หรือโซนใหม่จากดิสก์ในขณะที่ผู้เล่นกำลังเคลื่อนที่ ซึ่งการอ่านข้อมูลนี้ต้องเกิดขึ้นภายในกรอบเวลาของ tick ประการที่สอง การบันทึกอัตโนมัติในโลกขนาดใหญ่จะมีการเขียนข้อมูลจำนวนมากในคราวเดียว และบนไดรฟ์ที่ช้า การเขียนข้อมูลจะขัดจังหวะลูปการทำงานนานพอที่จะทำให้เกิดข้อความแจ้งเตือน "Can't keep up" ทั้งสองกรณีนี้เป็นปัญหาด้าน latency มากกว่าปัญหาด้าน throughput ซึ่งเป็นเหตุผลว่าทำไม ช่องว่างระหว่าง NVMe และ SATA SSD บน VPS จึงมีความสำคัญมากกว่าตัวเลขความเร็วเมกะไบต์ต่อวินาทีที่ระบุไว้ สิ่งที่คุณควรให้ความสำคัญคือระยะเวลาที่ใช้ในการดำเนินการขนาดเล็กหนึ่งรายการ

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

Tick rate, ping และความแตกต่างระหว่างค่าทั้งสอง

Tick rate คือจำนวนครั้งต่อวินาทีที่เซิร์ฟเวอร์คำนวณสถานะของโลกในเกมใหม่ Minecraft Java ทำงานที่ 20 tick ต่อวินาที ส่วนเซิร์ฟเวอร์ที่ใช้ Source engine มักทำงานที่ 64 tick ต่อวินาที สำหรับ Minecraft คุณไม่สามารถซื้อ tick rate ที่สูงขึ้นได้เนื่องจากเป็นส่วนหนึ่งของการออกแบบเกม เป้าหมายจึงเป็นการรักษาค่าให้คงที่ที่ 20 แทนที่จะพยายามเพิ่มให้สูงกว่านั้น

Ping คือระยะเวลาที่ข้อมูลเดินทางไปกลับระหว่างผู้เล่นกับเซิร์ฟเวอร์ ค่าทั้งสองนี้ทำให้เกิดปัญหาที่แตกต่างกัน ดังนั้นควรแยกแยะก่อนที่จะตัดสินใจใช้จ่ายเงินเพื่อแก้ไข เมื่อเซิร์ฟเวอร์ประมวลผลไม่ทัน (missed ticks) ผู้เล่นทุกคนจะเกิดอาการกระตุก (rubber-banding) พร้อมกัน และเซิร์ฟเวอร์จะบันทึกข้อความแจ้งเตือนไว้ใน log อย่างชัดเจน ในขณะที่หากผู้เล่นคนใดคนหนึ่งมีปัญหาที่เส้นทางเครือข่าย จะมีเพียงผู้เล่นคนนั้นที่เกิดอาการแล็ก (lag) ในขณะที่ผู้เล่นคนอื่นยังใช้งานได้ตามปกติ การอัปเกรด CPU ให้แรงขึ้นจะไม่สามารถแก้ไขปัญหาในกรณีหลังได้เลย

ความหน่วงขึ้นอยู่กับตำแหน่งที่ตั้ง ไม่ใช่ระดับของแพ็กเกจบริการ

แสงที่เดินทางในสายไฟเบอร์มีความเร็วประมาณ 200 กิโลเมตรต่อมิลลิวินาที การเดินทางไป-กลับต้องใช้ระยะทางเป็นสองเท่า ดังนั้นค่าต่ำสุดทางทฤษฎีจึงอยู่ที่ประมาณ 1 ms ต่อทุกๆ 100 กม. ระหว่างผู้เล่นกับเซิร์ฟเวอร์ ไม่มีผู้ให้บริการรายใดที่ทำได้เร็วกว่านี้ และการอัปเกรดแพ็กเกจก็ไม่สามารถเปลี่ยนแปลงค่านี้ได้

[
  {
    "label": "Toronto to New York",
    "distance_km": 550,
    "rtt_floor_ms": 5.5
  },
  {
    "label": "Dallas to Chicago",
    "distance_km": 1290,
    "rtt_floor_ms": 12.9
  },
  {
    "label": "Dallas to Los Angeles",
    "distance_km": 1990,
    "rtt_floor_ms": 19.9
  },
  {
    "label": "New York to London",
    "distance_km": 5570,
    "rtt_floor_ms": 55.7
  },
  {
    "label": "Los Angeles to Sydney",
    "distance_km": 12070,
    "rtt_floor_ms": 120.7
  }
]

ค่าเหล่านี้เป็นค่าต่ำสุดที่คำนวณจากระยะทางวงกลมใหญ่ (great circle distance) ในความเป็นจริงสายไฟเบอร์ไม่ได้วางเป็นเส้นตรง และเราเตอร์ทุกตัวบนเส้นทางจะเพิ่มความหน่วงเข้าไปเล็กน้อย ดังนั้นผลลัพธ์ที่ใช้งานจริงมักจะอยู่ที่ประมาณสองเท่าของค่าต่ำสุด ผู้เล่นใน Toronto ที่เชื่อมต่อไปยังเซิร์ฟเวอร์ใน New York ซึ่งห่างออกไป 550 กม. จะมีค่าต่ำสุดอยู่ที่ 5.5 ms และโดยปกติจะเห็นค่าอยู่ที่หลักสิบต้นๆ ส่วนเส้นทางจาก Los Angeles ไปยัง Sydney มีค่าต่ำสุดอยู่ที่ 120.7 ms ซึ่งไม่ว่าคุณจะจ่ายเงินมากเท่าใดก็ไม่สามารถทำให้เร็วกว่านี้ได้

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

จงวัดค่าเส้นทางแทนการคาดเดา:

sudo apt install -y mtr-tiny
mtr -rwzc 100 203.0.113.10

ให้อ่านบรรทัดสุดท้ายก่อน บรรทัดนั้นคือเซิร์ฟเวอร์ปลายทาง ซึ่งค่า loss และ latency ของบรรทัดนี้เท่านั้นที่เป็นตัวตัดสินว่าเกมจะลื่นไหลเพียงใด หากพบค่า loss ใน hop ระหว่างทางแต่ hop สุดท้ายมีค่าปกติ มักเกิดจากการที่เราเตอร์ตัวนั้นทำ ICMP rate limiting เนื่องจากเราเตอร์จะลดลำดับความสำคัญของการตอบกลับ probe packets ในขณะที่ยังคงส่ง traffic จริงตามปกติ ควรให้ผู้เล่นแต่ละคนรันคำสั่งทดสอบไปยังเซิร์ฟเวอร์ เนื่องจากแต่ละคนใช้เส้นทางที่แตกต่างกัน

เปิดเฉพาะพอร์ตที่เกมจำเป็นต้องใช้

เซิร์ฟเวอร์เกมต้องการพอร์ตที่เปิดใช้งานเพียงหนึ่งหรือสองพอร์ตเท่านั้น ไม่จำเป็นต้องเปิดพอร์ตอื่นเพิ่มเติม ค่าเริ่มต้นที่พบบ่อยมีดังนี้:

• Minecraft Java Edition: TCP 25565
• Minecraft Bedrock Edition: UDP 19132
• Valheim: UDP 2456 และ UDP 2457
• Palworld: UDP 8211
• เกมที่ใช้ Source engine เช่น Counter-Strike 2: UDP 27015

โปรดตรวจสอบเอกสารประกอบของเกมนั้นๆ เนื่องจากหลายเกมจำเป็นต้องใช้พอร์ต query เพิ่มเติม ตัวอย่างที่ชัดเจนที่สุดคือ Valheim ซึ่งพอร์ต 2456 ใช้สำหรับรับส่งข้อมูลเกม ส่วนพอร์ต 2457 ใช้ตอบกลับ Steam server query เพื่อให้เซิร์ฟเวอร์ของคุณปรากฏในรายการค้นหา การเปิดพอร์ตเหล่านี้ด้วยโปรโตคอล TCP จะไม่เกิดผลใดๆ เนื่องจาก Valheim สื่อสารผ่าน UDP เท่านั้น

อนุญาตการเชื่อมต่อ SSH ก่อนเปิดใช้งานไฟร์วอลล์ มิฉะนั้นคุณจะถูกตัดการเชื่อมต่อจากเซิร์ฟเวอร์ของตนเอง:

sudo ufw allow 22/tcp
sudo ufw allow 25565/tcp
sudo ufw enable
sudo ufw status verbose

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

การตรวจสอบพอร์ต TCP จากเครื่องอื่นทำได้ง่าย:

sudo apt install -y netcat-openbsd
nc -vz 203.0.113.10 25565

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

sudo ss -lunp | grep 2456

ห้ามเปิดเผย RCON ซึ่งเป็นโปรโตคอลสำหรับรีโมทคอนโซลสู่สาธารณะโดยเด็ดขาด เนื่องจากเป็นการส่งรหัสผ่านผ่านการเชื่อมต่อแบบ plaintext โดยค่าเริ่มต้นจะใช้พอร์ต 25575 ให้ตั้งค่าให้ผูกกับ 127.0.0.1 และเข้าถึงผ่าน SSH tunnel เท่านั้น นอกจากนี้ควรเรียกใช้งานเซิร์ฟเวอร์เกมด้วยผู้ใช้ที่ไม่มีสิทธิ์ระดับสูง (unprivileged user) เพื่อป้องกันไม่ให้บั๊กในมอด (mod) เข้าถึงส่วนอื่นๆ ของเครื่องได้ สิบนาทีแรกบน VPS เครื่องใหม่ ครอบคลุมเรื่องการสร้างบัญชีผู้ใช้และการตั้งค่าความปลอดภัย SSH ซึ่งส่วนนี้ถือว่าคุณได้ดำเนินการเรียบร้อยแล้ว

รันเซิร์ฟเวอร์ด้วย systemd เพื่อให้ระบบเริ่มทำงานใหม่โดยอัตโนมัติ

เซิร์ฟเวอร์ที่เริ่มทำงานด้วยมือผ่าน SSH session จะหยุดทำงานทันทีเมื่อปิด session และจะไม่เริ่มทำงานใหม่หลังจากรีบูตเครื่อง systemd ช่วยแก้ปัญหาทั้งสองอย่างนี้ได้ ให้สร้างไฟล์ /etc/systemd/system/minecraft.service:

[Unit]
Description=Minecraft Java server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=minecraft
WorkingDirectory=/opt/minecraft
ExecStart=/usr/bin/java -Xms4G -Xmx4G -jar server.jar nogui
Restart=on-failure
RestartSec=15
TimeoutStopSec=180

[Install]
WantedBy=multi-user.target

Restart=on-failure จะช่วยให้เซิร์ฟเวอร์กลับมาทำงานใหม่หลังจากระบบล่ม และจะหยุดทำงานเมื่อมีการสั่ง shutdown ตามปกติ ซึ่งเป็นพฤติกรรมที่ต้องการ ส่วน Restart=always จะพยายามเริ่มเซิร์ฟเวอร์ใหม่ทุกครั้งที่คุณสั่งหยุดทำงานโดยเจตนา TimeoutStopSec=180 มีความสำคัญมากกว่าที่เห็น systemctl stop จะส่งสัญญาณ SIGTERM ซึ่งตัว vanilla Minecraft server จะดักจับสัญญาณนี้เพื่อบันทึกข้อมูลโลกก่อนปิดตัวลง และเมื่อครบกำหนดเวลา systemd จะส่ง SIGKILL เข้าไปแทน หากโลกของเกมมีขนาดใหญ่ อาจต้องใช้เวลาบันทึกข้อมูลนานกว่าค่าเริ่มต้นที่ 90 วินาที และข้อมูลใดก็ตามที่ยังบันทึกลงดิสก์ไม่เสร็จเมื่อ SIGKILL ทำงาน ข้อมูลนั้นจะสูญหาย

sudo systemctl daemon-reload
sudo systemctl enable --now minecraft
sudo journalctl -u minecraft -f

การเริ่มทำงานที่สมบูรณ์จะจบลงด้วยบรรทัดข้อความเช่น Done (12.345s)! For help, type "help" หาก unit มีสถานะสลับไปมาระหว่าง activating และ failed ให้ใช้ journalctl -u minecraft -n 50 เพื่อดูสาเหตุ ซึ่งมักเกิดจาก path ใน WorkingDirectory ไม่ถูกต้อง หรือมีการกำหนดค่า heap ไว้ใหญ่เกินกว่าที่เครื่องจะรับได้

systemd ไม่มี interactive console ให้ใช้งาน ดังนั้นควรวางแผนล่วงหน้า ให้ใช้ RCON บน localhost สำหรับการส่งคำสั่ง หรือรันเซิร์ฟเวอร์ภายใน tmux session ซึ่งเป็นวิธีเดียวกับที่ใช้ รักษา session ของ Claude Code บน VPS ให้คงอยู่ ระหว่างการล็อกอิน

เกมที่แจกจ่ายผ่าน Steam จำเป็นต้องใช้ SteamCMD ก่อนเริ่มขั้นตอนเหล่านี้ แพ็กเกจบน Ubuntu เป็น binary แบบ 32 bit ซึ่งเป็นเหตุผลว่าทำไมจึงต้องระบุบรรทัด architecture ไว้ หากข้ามบรรทัดนั้นไป apt จะแจ้งว่าไม่พบ installation candidate:

sudo add-apt-repository multiverse
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y steamcmd

เซิร์ฟเวอร์เกมบางตัวมีการใช้หน่วยความจำเพิ่มขึ้นเรื่อยๆ ตามระยะเวลาที่รัน การตั้งเวลา restart ในช่วงเวลาที่มีผู้ใช้งานน้อยเป็นวิธีแก้ปัญหาที่ยอมรับได้มากกว่าการแก้ไขที่ตัวซอฟต์แวร์ การใช้ systemd timer เพื่อเรียก systemctl restart นั้นเข้าใจง่ายกว่าการใช้ cron entry เพราะ systemctl list-timers จะแสดงให้เห็นชัดเจนว่างานจะถูกเรียกใช้ครั้งถัดไปเมื่อใด

การสำรองข้อมูลโลกของเกมตามกำหนดเวลา

ทุกอย่างบนเซิร์ฟเวอร์เกมสามารถหามาทดแทนได้ ยกเว้นไดเรกทอรีของโลก (world directory) และข้อมูลผู้เล่น การติดตั้งเกมใหม่ใช้เวลาเพียงไม่กี่นาที แต่การสร้างสิ่งที่กลุ่มของคุณสร้างขึ้นมาใหม่นั้นต้องใช้เวลาหลายเดือน

การสำรองข้อมูลที่ปลอดภัยคือการสำรองข้อมูลในขณะที่ไม่มีการเขียนข้อมูลใดๆ ลงดิสก์ การหยุดเซิร์ฟเวอร์เป็นเวลาหนึ่งนาทีเป็นวิธีที่ง่ายที่สุดในการรับประกันความปลอดภัยนี้:

sudo systemctl stop minecraft
sudo tar czf /var/backups/mc-$(date +%F).tgz -C /opt/minecraft world world_nether world_the_end
sudo systemctl start minecraft

หากการหยุดเซิร์ฟเวอร์ทุกคืนเป็นสิ่งที่ยอมรับไม่ได้ ให้ใช้วิธีสั่ง flush ข้อมูลโลกแทน ในคอนโซลของ Minecraft คำสั่ง save-off จะหยุดการบันทึกอัตโนมัติ (autosave), save-all flush จะเขียนข้อมูลที่ค้างอยู่ทั้งหมดลงดิสก์ และ save-on จะเปิดการบันทึกอัตโนมัติอีกครั้งหลังจากคัดลอกเสร็จสิ้น การคัดลอกโลกในขณะที่เซิร์ฟเวอร์กำลังเขียนข้อมูลอยู่อาจทำให้ได้ไฟล์ region ที่เขียนไม่สมบูรณ์ ซึ่งคุณจะไม่ทราบจนกว่าจะถึงวันที่คุณต้องการกู้คืนข้อมูลนั้น

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

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

ตรวจสอบให้แน่ใจก่อนตัดสินใจเลือกใช้

ให้เลือกซื้อแบบรายเดือนแทนรายปี และทดสอบกับผู้เล่นจริงเป็นเวลาหนึ่งช่วงเย็น ให้รันตัวเลข sysbench แบบ single thread จากนั้นให้ผู้เล่นทุกคนรัน mtr ไปยังเซิร์ฟเวอร์ ขั้นตอนการทำ benchmark VPS ฉบับเต็ม จะอธิบายการใช้เครื่องมือเหล่านี้และแสดงให้เห็นว่าผลลัพธ์ที่ไม่ดีเป็นอย่างไร ส่วน ต้นทุนที่แท้จริงของ VPS ต่อเดือน จะช่วยให้คุณตรวจสอบได้ว่าคุณกำลังจ่ายเงินเพื่อทรัพยากรที่เป็นคอขวดของเซิร์ฟเวอร์จริงๆ ไม่ใช่จ่ายตามตัวเลขที่พิมพ์ไว้ตัวใหญ่ที่สุดบนหน้าแผนบริการ

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

FAQ

ฉันสามารถเล่นเกมบน VPS แทนการซื้อคอมพิวเตอร์สำหรับเล่นเกมได้หรือไม่?

ไม่ได้ VPS มาตรฐานไม่มี GPU มีเพียง virtual display adapter สำหรับคอนโซลของผู้ให้บริการเท่านั้น ดังนั้นเมื่อติดตั้งเดสก์ท็อปแล้ว glxinfo -B จะรายงานว่าเป็น software renderer llvmpipe และเกม 3D จะทำงานได้เพียงไม่กี่เฟรมต่อวินาที แม้จะมีการติดตั้ง GPU เพิ่มเติม การเล่นผ่านรีโมทจะเพิ่มภาระการเข้ารหัสและถอดรหัสวิดีโอในทุกเฟรมที่รับส่ง ซึ่งโปรโตคอล RDP และ VNC ไม่ได้ถูกออกแบบมาเพื่อการนี้ VPS มีไว้สำหรับโฮสต์เซิร์ฟเวอร์เฉพาะที่กลุ่มของคุณเชื่อมต่อเข้าไปเท่านั้น หากต้องการเล่นเกม ให้เช่าเวลาใช้งาน GPU หรือใช้บริการ cloud gaming จะเหมาะสมกว่า

เซิร์ฟเวอร์เกมต้องการ CPU กี่คอร์?

สำหรับเกมส่วนใหญ่ CPU ที่มี 2 คอร์ความเร็วสูงจะทำงานได้ดีกว่า 8 คอร์ความเร็วต่ำ เนื่องจากระบบจำลองโลกของเกมทำงานบนเธรดหลักเพียงเธรดเดียว และคอร์ที่เพิ่มเข้ามาไม่สามารถช่วยให้เธรดนั้นประมวลผลให้ทันภายในกรอบเวลา 50 ms ได้ ให้เปรียบเทียบแผนบริการต่างๆ ด้วย sysbench cpu --cpu-max-prime=20000 --threads=1 run และอ่านค่าเหตุการณ์ต่อวินาที (events per second) คอร์ที่เพิ่มเข้ามาจะคุ้มค่าก็ต่อเมื่อคุณรันเซิร์ฟเวอร์ตัวที่สองหรือฐานข้อมูลบนเครื่องเดียวกัน เนื่องจากภาระงานเหล่านั้นจะสามารถทำงานได้โดยไม่แย่งเวลาประมวลผลจาก tick thread หลัก

เซิร์ฟเวอร์ Minecraft ต้องการ RAM เท่าใด?

สำหรับโลกแบบ vanilla ที่มีผู้เล่นประมาณ 10 คน จะต้องการ heap ประมาณ 2 GB และสำหรับ modpack ขนาดใหญ่ที่มีจำนวนผู้เล่นเท่ากันจะต้องการ 8 GB ให้ตั้งค่า -Xms และ -Xmx ให้มีค่าเท่ากัน และควรเหลือ RAM ไว้ให้ระบบปฏิบัติการประมาณ 1 GB ถึง 2 GB เนื่องจาก JVM มีการใช้หน่วยความจำนอกเหนือจาก heap และ kernel จำเป็นต้องใช้ page cache หากตั้งค่า heap ใหญ่กว่าหน่วยความจำที่มีในเครื่อง กระบวนการจะถูก kernel สั่งยุติการทำงาน ซึ่งจะปรากฏใน dmesg ว่าเป็นข้อความ out of memory แทนที่จะเป็นข้อผิดพลาดของ Java

ทำไมผู้เล่นถึงพบอาการแล็กทั้งที่เซิร์ฟเวอร์ยังมี CPU และ RAM เหลือ?

มีสาเหตุหลัก 2 ประการสำหรับกรณีนี้ ให้ตรวจสอบ log ของเซิร์ฟเวอร์เพื่อหา Can't keep up! Is the server overloaded? ซึ่งหมายความว่าเธรดหลักไม่สามารถประมวลผล tick ให้ทันภายในงบเวลา 50 ms ในขณะที่คอร์อื่นยังว่างอยู่ หากไม่พบข้อความดังกล่าว ปัญหาจะอยู่ที่เส้นทางเครือข่าย ให้ผู้เล่นแต่ละคนรัน mtr -rwzc 100 203.0.113.10 ไปยังที่อยู่เซิร์ฟเวอร์ของคุณแล้วดูบรรทัดสุดท้าย นอกจากนี้ให้ตรวจสอบคอลัมน์ st ใน vmstat 1 หากค่า steal time สูงกว่าไม่กี่เปอร์เซ็นต์ แสดงว่าโฮสต์มีการใช้งานเกินขีดจำกัด (oversold) ทำให้ CPU ที่คุณเห็นว่าว่างอยู่นั้นไม่สามารถใช้งานได้จริง

ฉันต้องเปิดพอร์ตใดบ้างสำหรับเซิร์ฟเวอร์เกม?

ให้เปิดเฉพาะพอร์ตของเกมนั้นๆ และพอร์ต SSH เท่านั้น Minecraft Java ใช้ TCP 25565, Minecraft Bedrock ใช้ UDP 19132, Valheim ใช้ UDP 2456 และ 2457 และ Palworld ใช้ UDP 8211 ให้เพิ่มกฎสำหรับ SSH ก่อนรัน ufw enable มิฉะนั้นคุณจะสูญเสียการเข้าถึงเครื่อง โปรดจำไว้ว่าผู้ให้บริการหลายรายมี firewall ชั้นที่สองในแผงควบคุม (control panel) ซึ่งคุณต้องเปิดพอร์ตในนั้นด้วยเช่นกัน ห้ามเปิด RCON บนพอร์ต 25575 สู่สาธารณะเด็ดขาด เนื่องจากเป็นการส่งรหัสผ่านแบบ plaintext