SSD Nodes Learn 🎉 VPS از $5.50/ماه
راهنماها Matt Connorتوسط Matt Connor · به‌روزرسانی شده 2026-08-13

راهنمای انتخاب VPS مناسب برای سرور بازی

برای راه اندازی سرور بازی به جای GPU به سرعت بالای تک هسته CPU و رم کافی نیاز دارید. در این مطلب نکات کلیدی پورت ها، تنظیمات systemd و تاثیر موقعیت مکانی بر latency را بررسی می کنیم.

منظور شما از VPS مخصوص بازی چیست؟

یک VPS برای سرورهای بازی، خریدی مناسب برای یک هدف است: اجرای یک dedicated server که شما و دوستانتان از سیستم‌های خود به آن متصل می‌شوید. این گزینه برای هدف دیگری که افراد از این عبارت برداشت می‌کنند، یعنی اجرای بازی روی خودِ VPS از طریق remote desktop، انتخاب ضعیفی است. این دو کار به سخت‌افزارهای متفاوتی نیاز دارند. یک dedicated server به یک هسته CPU سریع و رم کافی برای بارگذاری دنیای بازی نیاز دارد. اجرای بازی به GPU (واحد پردازش گرافیکی) نیاز دارد و یک پلن استاندارد VPS فاقد آن است.

تمام مطالب زیر مربوط به هدف اول است. هدف دوم ارزش 2 دقیقه وقت گذاشتن را دارد، زیرا بسیاری از افراد سرور اشتباهی برای آن خریداری می‌کنند.

چرا نمی‌توانید روی VPS بازی کنید

یک VPS استاندارد فقط هسته‌های پردازنده مجازی در اختیار شما می‌گذارد و فاقد کارت گرافیک است. هیچ سخت‌افزاری از میزبان فیزیکی به ماشین شما منتقل (pass-through) نمی‌شود، بنابراین هیچ رندرکننده سخت‌افزاری برای استفاده بازی وجود ندارد. می‌توانید ببینید واقعاً چه چیزی در اختیار دارید:

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

پاسخ، یک آداپتور نمایشگر مجازی است، چیزی شبیه به Cirrus Logic یا دستگاه virtio GPU. این دستگاه صرفاً برای این وجود دارد که کنسول وب ارائه‌دهنده بتواند تصویری به شما نشان دهد و هیچ شتاب‌دهنده سه‌بعدی (3D acceleration) در پشت آن نیست. اگر یک محیط دسکتاپ و یک سرور VNC روی آن نصب کنید، glxinfo -B رندرکننده را به عنوان llvmpipe گزارش می‌دهد که همان رندرکننده نرم‌افزاری Mesa است که روی CPU اجرا می‌شود. یک بازی سه‌بعدی مدرن که توسط CPU ترسیم شود، با سرعت چند فریم در ثانیه اجرا می‌شود؛ بنابراین پیش از آنکه حتی از سیستم خارج شود، غیرقابل بازی است. نمونه‌های ویندوزی نیز از سمت دیگر با همین دیوار برخورد می‌کنند. بسیاری از عناوین بازی هنگام اجرا به دلیل عدم توانایی در ایجاد یک دستگاه Direct3D متوقف می‌شوند، زیرا آداپتور نمایشگری برای ایجاد آن وجود ندارد.

مشکل دوم، مسیر بازگشت تصویر به شماست. بازی روی یک سیستم از راه دور به این معناست که هر فریم به ویدیو انکود می‌شود، از طریق اینترنت ارسال شده و روی صفحه نمایش شما دیکود می‌شود. این کار زمان انکود و دیکود را به تأخیر ورودی (input lag) خودِ بازی اضافه می‌کند، و پروتکل‌های RDP و VNC برای محیط‌های دسکتاپ طراحی شده‌اند، نه برای 60 فریم در ثانیه حرکت. سرویس‌های بازی ابری (Cloud gaming) این مشکل را با سخت‌افزار GPU واقعی و یک پروتکل استریمینگ اختصاصی حل می‌کنند. یک VPS معمولی هیچ‌کدام از این‌ها را ندارد. اگر می‌خواهید بازی کنید، زمان GPU اجاره کنید. اگر می‌خواهید میزبانی کنید، به خواندن ادامه دهید.

نیازمندی‌های واقعی یک سرور بازی اختصاصی

یک سرور بازی در واقع یک حلقه شبیه‌سازی است. این سرور وضعیت جهان بازی را در حافظه نگه می‌دارد و آن را با تعداد دفعات مشخصی در هر ثانیه به‌روزرسانی می‌کند. سپس بخشی از جهان که برای هر بازیکن متصل قابل مشاهده است، برای او ارسال می‌شود.

این ساختار، سخت‌افزار مورد نیاز را تعیین می‌کند. حلقه شبیه‌سازی عمدتاً تک‌رشته‌ای (single-threaded) است، بنابراین سرعت هسته پردازنده اهمیت بیشتری نسبت به تعداد هسته‌ها دارد. جهان بازی در حافظه قرار می‌گیرد، بنابراین RAM معمولاً اولین محدودیتی است که با آن مواجه می‌شوید. دیسک در حین بازی کم‌کار است اما هنگام بارگذاری و ذخیره‌سازی، فعالیت بالایی دارد. مسیر شبکه شما تعیین‌کننده میزان ping است و هیچ سطح اشتراکی (plan tier) نمی‌تواند آن را تغییر دهد.

سرعت تک‌هسته‌ای بر تعداد هسته‌ها برتری دارد

بیشتر سرورهای بازی، پردازش جهان بازی را روی یک ترد (thread) اصلی انجام می‌دهند. حلقه تیک (tick loop) در Minecraft و فریم سرور در موتور Source هر دو به همین شکل کار می‌کنند. هر تیک یک مهلت زمانی مشخص دارد. نسخه Java بازی Minecraft با نرخ 20 تیک در ثانیه اجرا می‌شود که برای هر تیک، بودجه‌ای معادل 50 میلی‌ثانیه در نظر می‌گیرد. زمانی که پردازش در این بازه زمانی جای نمی‌گیرد، سرور دقیقاً این پیام را چاپ می‌کند:

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

این خط به این معناست که زمان یک ترد به پایان رسیده است. افزودن هسته‌های بیشتر، زمان بیشتری به آن ترد اختصاص نمی‌دهد. یک پلن با 2 هسته مجازی (vCPU) سریع، نرخ تیک را بهتر از پلنی با 8 هسته مجازی کند حفظ می‌کند، زیرا تنها یکی از آن 8 هسته در حال انجام پردازش اصلی است.

پیش از انتخاب هر پلن، سرعت تک‌رشته‌ای را اندازه‌گیری کنید:

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

خط events per second را بخوانید. این عدد به تنهایی معنایی ندارد و تنها در مقایسه با سایر موارد اهمیت پیدا می‌کند؛ بنابراین آن را روی دو پلن کاندید اجرا کرده و نتایج را کنار هم قرار دهید. اجرای کامل بنچمارک VPS، دیسک و شبکه را نیز به همین روش بررسی می‌کند.

هسته‌های اضافی همچنان کاربرد خود را دارند. آن‌ها سرور بازی دوم، دیتابیس، بک‌آپ‌های شبانه و پیش‌تولید چانک‌ها (chunk pre-generator) را بدون گرفتن زمان از ترد اصلی اجرا می‌کنند. نرم‌افزارهای سرور نیز یاد گرفته‌اند که پردازش‌ها را توزیع کنند؛ برای مثال Paper که یک فورک محبوب از سرور Minecraft است، بخشی از پردازش‌ها را از ترد اصلی تیک خارج می‌کند. بنابراین، انتخاب بهینه، تعداد کمی هسته سریع است، نه تعداد زیادی هسته کند.

یک عدد هرگز در صفحه مشخصات پلن‌ها دیده نمی‌شود، اما تعیین می‌کند که آیا هسته سریعی که برای آن هزینه کرده‌اید واقعاً در اختیار شماست یا خیر:

vmstat 1 5

ستون st نشان‌دهنده درصدی از زمان است که پردازنده مجازی شما آماده اجرا بوده، اما میزبان فیزیکی هسته را به شخص دیگری اختصاص داده است. مقدار ثابت st بالاتر از چند درصد، به این معناست که میزبان بیش از حد فروخته شده (oversold) است. بازیکنان این وضعیت را به صورت لگ (stutter) حس می‌کنند، در حالی که top روی سرور شما همچنان CPU را در حالت idle نشان می‌دهد، زیرا آن زمانِ آزاد در واقع متعلق به شما نیست که بتوانید از آن استفاده کنید.

یک سرور بازی به چه مقدار RAM نیاز دارد؟

ChartCommon starting RAM per game server (published guidance, not a measurement)
The data behind this chart
[
  {
    "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
  }
]

این‌ها مقادیر تخصیص اولیه هستند که مستندات بازی و مادپک‌ها تا اوت 2026 منتشر کرده‌اند. این اعداد صرفاً راهنما هستند و نه مقادیر اندازه‌گیری‌شده روی یک سیستم خاص. نسخه Vanilla بازی Minecraft Java با 2 گیگابایت حافظه Heap برای حدود 10 بازیکن به‌خوبی کار می‌کند. همین تعداد بازیکن در یک مادپک سنگین به 8 گیگابایت نیاز دارد، زیرا مادها موجودات (entities) و ساختارهای تولیدشده‌ای را اضافه می‌کنند که همگی در همان Heap قرار می‌گیرند. حداقل مقدار اعلام‌شده برای Valheim برابر با 2 گیگابایت است، در حالی که مدیران سرور با دنیای کوچک گزارش می‌دهند که پردازش بازی به حدود 3 گیگابایت می‌رسد؛ بنابراین 4 گیگابایت نقطه شروع معقولی است. Palworld یک استثنا است و برای حداکثر 32 بازیکن خود به 16 گیگابایت نیاز دارد که این مقدار توصیه رسمی Pocketpair است.

میزان مصرف RAM با تعداد اتصالات افزایش نمی‌یابد، بلکه با میزان دنیای بارگذاری‌شده (loaded world) تغییر می‌کند. هر بازیکن ناحیه اطراف خود را در حافظه بارگذاری نگه می‌دارد؛ بنابراین هزینه دو بازیکنی که کنار هم ایستاده‌اند بسیار کمتر از دو بازیکنی است که در دو نقطه دور از هم در حال اکتشاف هستند. به همین دلیل است که «RAM به ازای هر بازیکن» فقط یک راهنمای کلی است و «RAM به ازای هر ناحیه فعال» عامل اصلی تعیین‌کننده است؛ و به همین دلیل است که یک گروه کوچک که به اکتشاف علاقه دارند، ممکن است از پلانی که برای دو برابر تعدادشان در نظر گرفته شده، فراتر بروند.

سرورهای Java به دو قانون اضافی نیاز دارند. حداقل و حداکثر Heap را روی یک مقدار تنظیم کنید تا JVM هرگز برای تغییر اندازه آن متوقف نشود:

java -Xms4G -Xmx4G -jar server.jar nogui

سپس مقداری فضای خالی (headroom) در نظر بگیرید. JVM از حافظه‌ای خارج از Heap که به آن اختصاص داده‌اید برای پشته‌های ترد (thread stacks) و بافرهای native استفاده می‌کند و کرنل نیز برای خواندن سریع فایل‌های دنیا به page cache نیاز دارد. روی سیستمی با 6 گیگابایت RAM، اختصاص 4 گیگابایت به Heap منطقی است، اما اختصاص 6 گیگابایت منطقی نیست.

دو نوع خطای حافظه کاملاً متفاوت هستند، پس هر دو را بشناسید. Heap بسیار کوچک باعث بروز خطا در داخل Java می‌شود و سرور معمولاً به کار خود ادامه می‌دهد اما با مشکل مواجه می‌شود:

java.lang.OutOfMemoryError: Java heap space

Heap بزرگ‌تر از ظرفیت سیستم باعث می‌شود کل پردازش از بیرون کشته (kill) شود. کنسول فقط عبارت Killed را نمایش می‌دهد و شواهد آن در لاگ کرنل موجود است:

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

افزودن swap باعث جلوگیری از kill شدن می‌شود اما مشکل را حل نمی‌کند. یک حلقه پردازش (tick loop) که مجبور است داده‌های دنیا را از swap بخواند، تمام زمان‌بندی‌ها را از دست می‌دهد؛ در نتیجه بازیکنان شما به جای یک سرور کرش‌کرده، با یک سرور فریز‌شده مواجه می‌شوند.

یک نکته در مورد نسخه‌ها، معتبر تا اوت 2026: بازی Minecraft Java نسخه 1.20.5 و بالاتر به Java 21 نیاز دارد. یک runtime قدیمی‌تر اجرا می‌شود و سپس با خطای unsupported class file version متوقف می‌گردد؛ این خطا شبیه پیام کامپایلر است و اولین باری که با آن مواجه می‌شوید، ممکن است گمراه‌کننده باشد.

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

آیا سرعت دیسک برای سرور بازی اهمیت دارد؟

در حین بازی، اهمیت آن کمتر از حد انتظار است، اما در دو لحظه خاص بسیار حیاتی است. دنیای بازی هنگام راه‌اندازی در حافظه بارگذاری شده و در زمان ذخیره خودکار (autosave) روی دیسک نوشته می‌شود؛ بنابراین سرعت دیسک پایین باعث کندی در بالا آمدن سرور و ایجاد وقفه هنگام ذخیره‌سازی می‌شود. در فواصل بین این دو، اکثر عملیات خواندن از طریق RAM انجام می‌گیرد.

دو عامل باعث می‌شود اهمیت دیسک بیش از این خلاصه باشد. اکتشاف در بازی باعث بارگذاری بخش‌ها (chunks) یا مناطق جدید از دیسک در حین حرکت بازیکنان می‌شود و این عملیات خواندن باید در محدوده زمانی هر تیک (tick budget) انجام شود. ذخیره خودکار در یک دنیای بزرگ، حجم زیادی از داده را یک‌باره می‌نویسد و روی یک درایو کند، این عملیات نوشتن باعث مسدود شدن حلقه پردازش (loop) به مدت طولانی می‌شود که منجر به نمایش هشدار "Can't keep up" می‌گردد. هر دوی این موارد، مشکلات تأخیر (latency) هستند نه مشکلات پهنای باند (throughput)؛ به همین دلیل است که تفاوت بین NVMe و SATA SSD در یک VPS در اینجا اهمیت بیشتری نسبت به اعداد اسمی مگابایت بر ثانیه دارد. آنچه اهمیت دارد، مدت زمانی است که یک عملیات کوچک طول می‌کشد.

حجم دیسک را برای رشد آینده در نظر بگیرید. دنیای بازی با هر بار حرکت بازیکنان به مناطق جدید بزرگ‌تر می‌شود و نسخه‌های پشتیبان نیز حجم کلی را چند برابر می‌کنند. دستور du -sh world را به مدت یک ماه، هفته‌ای یک‌بار اجرا کنید تا نرخ رشد واقعی دیسک خود را به دست آورید.

نرخ تیک (Tick rate)، پینگ و تفاوت میان آن‌ها

نرخ تیک نشان‌دهنده تعداد دفعاتی است که سرور در هر ثانیه وضعیت جهان بازی را بازمحاسبه می‌کند. Minecraft Java با نرخ 20 اجرا می‌شود. سرورهای مبتنی بر Source engine معمولاً با نرخ 64 کار می‌کنند. در Minecraft، امکان خرید نرخ بالاتر وجود ندارد، زیرا این نرخ بخشی از طراحی بازی است؛ بنابراین هدف، حفظ عدد 20 است، نه فراتر رفتن از آن.

پینگ به معنای زمان رفت و برگشت داده‌ها بین یک بازیکن و سرور است. این دو مورد باعث بروز شکایات متفاوتی می‌شوند، بنابراین پیش از صرف هزینه، آن‌ها را از هم تفکیک کنید. هنگامی که سرور تیک‌ها را از دست می‌دهد (missed ticks)، همه بازیکنان در یک لحظه دچار پرش (rubber-banding) می‌شوند و لاگ سرور نیز این موضوع را به‌صراحت اعلام می‌کند. هنگامی که یک بازیکن مسیر شبکه طولانی دارد، فقط همان بازیکن دچار لگ می‌شود و بقیه گروه مشکلی ندارند. ارتقای CPU هرگز مشکل دوم را حل نخواهد کرد.

تأخیر به موقعیت جغرافیایی بستگی دارد، نه به سطح پلن

سرعت نور در فیبر نوری حدود 200 کیلومتر در هر میلی‌ثانیه است. یک رفت‌وبرگشت، این مسافت را دو بار طی می‌کند؛ بنابراین حداقل تأخیر (floor) تقریباً 1 میلی‌ثانیه به ازای هر 100 کیلومتر فاصله بین بازیکن و سرور است. هیچ ارائه‌دهنده‌ای نمی‌تواند از این حد فراتر رود و ارتقای پلن نیز تغییری در آن ایجاد نمی‌کند.

ChartRound trip floor by distance, fibre physics only
The data behind this chart
[
  {
    "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) هستند. فیبرهای واقعی در مسیر مستقیم قرار ندارند و هر روتر در مسیر، مقدار کمی به تأخیر اضافه می‌کند؛ بنابراین یک نتیجه واقعی و مناسب، معمولاً نزدیک به دو برابر این حداقل است. بازیکنی در تورنتو که به سروری در نیویورک با فاصله 550 کیلومتر متصل می‌شود، حداقل تأخیر 5.5 میلی‌ثانیه دارد و معمولاً عددی در محدوده 10 تا 20 میلی‌ثانیه را مشاهده می‌کند. مسیر لس‌آنجلس به سیدنی حداقل تأخیر 120.7 میلی‌ثانیه دارد و هیچ مبلغی نمی‌تواند این مقدار را کاهش دهد.

بنابراین سرور را نزدیک به افرادی قرار دهید که از آن استفاده می‌کنند. اگر گروه شما در دو سوی اقیانوس پراکنده است، یک نفر ناچار به تحمل مسیر طولانی خواهد بود و راه‌حل منصفانه معمولاً انتخاب منطقه‌ای است که بیشترین تعداد بازیکن در آن حضور دارند.

به‌جای حدس زدن، مسیر را اندازه‌گیری کنید:

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

ابتدا خط آخر را بخوانید. آن خط نشان‌دهنده سرور است و میزان Packet Loss و تأخیر آن، تنها عواملی هستند که تجربه بازی را تعیین می‌کنند. Packet Loss نمایش‌داده‌شده در یک گره میانی (hop) در حالی که گره نهایی وضعیت سالمی دارد، تقریباً همیشه به دلیل محدودیت نرخ ICMP در آن روتر است؛ زیرا روترها اولویت پاسخ‌دهی به بسته‌های کاوشگر (probe packets) را کاهش می‌دهند، در حالی که ترافیک واقعی را به‌طور عادی هدایت می‌کنند. از هر بازیکن بخواهید این تست را به سمت سرور انجام دهد، زیرا مسیر هر یک از آن‌ها متفاوت است.

نحوه محاسبه حداقل تأخیر رفت‌وبرگشت

سرعت نور در شیشه تقریباً دو‌سوم سرعت آن در خلأ است که به حدود 200 کیلومتر در هر میلی‌ثانیه می‌رسد. یک رفت‌وبرگشت، مسافت را دو بار طی می‌کند؛ بنابراین حداقل تأخیر به میلی‌ثانیه، برابر است با فاصله یک‌طرفه به کیلومتر تقسیم بر 100. فاصله نیویورک تا لندن 5,570 کیلومتر است و 5570 تقسیم بر 100 برابر با 55.7 میلی‌ثانیه می‌شود. هر عدد اندازه‌گیری‌شده‌ای بالاتر از این مقدار خواهد بود، زیرا کابل‌ها از خطوط ساحلی پیروی می‌کنند و روترها برای پردازش بسته‌ها به زمان نیاز دارند.

فقط پورت‌های مورد نیاز بازی را باز کنید

یک سرور بازی تنها به یک یا دو پورت باز نیاز دارد و نه بیشتر. مقادیر پیش‌فرض رایج عبارتند از:

  • 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 port) اضافی استفاده می‌کنند. Valheim واضح‌ترین مثال است: پورت 2456 ترافیک بازی را منتقل می‌کند و پورت 2457 به پرس‌وجوی سرور Steam پاسخ می‌دهد که باعث می‌شود سرور شما در لیست مرورگر بازی نمایش داده شود. باز کردن این شماره‌ها روی TCP هیچ نتیجه‌ای ندارد، زیرا Valheim فقط از پروتکل UDP استفاده می‌کند.

پیش از فعال‌سازی فایروال، دسترسی SSH را مجاز کنید، در غیر این صورت دسترسی خودتان به سرور قطع خواهد شد:

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

بسیاری از ارائه‌دهندگان خدمات، یک فایروال شبکه در پنل مدیریتی خود دارند که از فایروال داخل سیستم‌عامل جداست. پورتی که در ufw باز است اما در آن پنل بسته باشد، همچنان اتصالات را رد می‌کند و علائم آن از بیرون دقیقاً مشابه است؛ بنابراین پیش از ویرایش فایل‌های پیکربندی، هر دو محل را بررسی کنید.

بررسی یک پورت TCP از ماشینی دیگر ساده است:

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

پروتکل UDP را نمی‌توان به این روش تست کرد. یک پورت UDP بسته معمولاً هیچ پاسخی نمی‌دهد، بنابراین کاوشی که پاسخی دریافت نمی‌کند، عملاً هیچ اطلاعاتی به شما نمی‌دهد. در عوض، از سمت سرور تأیید کنید و بررسی کنید که آیا پردازش بازی به پورتی که انتظار دارید متصل (bind) شده است یا خیر:

sudo ss -lunp | grep 2456

هرگز RCON، پروتکل کنسول از راه دور، را در معرض اینترنت قرار ندهید. این پروتکل تنها از یک رمز عبور استفاده می‌کند که به‌صورت متن ساده (plaintext) و به‌طور پیش‌فرض روی پورت 25575 ارسال می‌شود. آن را به 127.0.0.1 محدود کنید و از طریق یک تونل SSH به آن دسترسی داشته باشید. همچنین سرور بازی را با یک کاربر بدون امتیاز (unprivileged) اجرا کنید تا باگ‌های احتمالی در مادها نتوانند به سایر بخش‌های سیستم دسترسی پیدا کنند. ده دقیقه اول در یک VPS جدید به مباحث مربوط به حساب کاربری و ایمن‌سازی SSH می‌پردازد که این بخش فرض را بر انجام آن‌ها توسط شما گذاشته است.

اجرای سرور تحت systemd برای راه‌اندازی مجدد خودکار

سروری که به‌صورت دستی در یک نشست SSH اجرا شود، با بسته شدن نشست متوقف می‌شود و پس از reboot نیز بالا نمی‌آید. 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 این سیگنال را دریافت کرده و پیش از خروج، وضعیت جهان (world) را ذخیره می‌کند. اگر زمان تعیین‌شده به پایان برسد، 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 دلیل آن را نشان می‌دهد؛ این مشکل معمولاً ناشی از مسیر اشتباه در WorkingDirectory یا اختصاص حافظه heap بیش از ظرفیت سرور است.

systemd کنسول تعاملی در اختیار شما نمی‌گذارد، پس از قبل برای آن برنامه‌ریزی کنید. برای ارسال دستورات از RCON روی localhost استفاده کنید، یا سرور را درون یک نشست tmux اجرا کنید؛ همان عادتی که باعث می‌شود یک نشست طولانی‌مدت Claude Code روی VPS بین ورودهای مختلف زنده بماند.

بازی‌هایی که از طریق Steam توزیع می‌شوند، پیش از هر کاری به SteamCMD نیاز دارند. بسته Ubuntu یک باینری 32 بیتی است و به همین دلیل خط مربوط به معماری در آن قرار دارد. اگر آن خط را حذف کنید، apt گزارش می‌دهد که هیچ کاندیدایی برای نصب پیدا نکرده است:

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

برخی از سرورهای بازی با گذشت زمان مصرف حافظه خود را افزایش می‌دهند و راه‌اندازی مجدد زمان‌بندی‌شده در ساعات خلوت، راهکار پذیرفته‌شده‌ای به‌جای رفع اصلی مشکل است. استفاده از یک systemd timer برای فراخوانی systemctl restart منطقی‌تر از یک ورودی cron است، زیرا systemctl list-timers دقیقاً به شما نشان می‌دهد که اجرای بعدی چه زمانی خواهد بود.

پشتیبان‌گیری زمان‌بندی‌شده از دنیای بازی

همه چیز در یک سرور بازی به‌جز دایرکتوری world و داده‌های بازیکنان قابل جایگزینی است. نصب مجدد بازی چند دقیقه زمان می‌برد، اما بازسازی آنچه گروه شما ساخته است، ماه‌ها طول می‌کشد.

پشتیبان ایمن، نسخه‌ای است که در زمان عدم نوشتن داده‌ها تهیه شود. متوقف کردن سرور برای یک دقیقه، ساده‌ترین راه برای تضمین این موضوع است:

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

اگر وقفهٔ شبانه برای شما قابل‌قبول نیست، ابتدا world را flush کنید. در کنسول Minecraft، دستور save-off ذخیره خودکار را متوقف می‌کند، save-all flush تمام داده‌های معلق را می‌نویسد و save-on پس از پایان کپی، ذخیره خودکار را دوباره فعال می‌کند. کپی کردن world در حین نوشتن داده‌ها توسط سرور ممکن است منجر به ثبت یک فایل region شود که تنها نیمی از آن نوشته شده است؛ این مشکل را تا روزی که به بازیابی نیاز دارید، متوجه نخواهید شد.

حداقل یک نسخه را خارج از دستگاه نگه دارید. پشتیبان روی همان دیسک، در صورت خرابی دیسک از بین می‌رود و snapshot ارائه‌دهنده سرویس، بیشتر یک ابزار راحتی است تا پشتیبان، زیرا در همان حسابی قرار دارد که ممکن است دسترسی به آن را از دست بدهید. پشتیبان‌گیری زمان‌بندی‌شده با restic به فضای ذخیره‌سازی خارج از سایت، مدیریت نگهداری و حذف داده‌های تکراری (deduplication) را انجام می‌دهد تا یک ماه نسخه پشتیبان شبانه، فضای دیسک شما را پر نکند.

سپس یکی از آن‌ها را بازیابی کنید. پشتیبانی که هرگز بازیابی نکرده‌اید، فقط یک حدس است. آرشیو دیشب را در یک دایرکتوری جداگانه استخراج کنید، یک سرور آزمایشی را به آن متصل کنید و تأیید کنید که world بارگذاری می‌شود و ساختمان‌ها در همان جایی هستند که رهایشان کرده بودید.

پیش از تعهد، بررسی نهایی را انجام دهید

به‌جای خرید اشتراک یک‌ساله، یک ماه تهیه کنید و آن را برای یک شب با بازیکنان واقعی تست کنید. عدد تک‌رشته‌ای (single thread) sysbench را اجرا کنید و سپس از همه بازیکنان بخواهید mtr را به سمت سرور انجام دهند. روش کامل بنچمارک VPS شما را با این ابزارها آشنا می‌کند و نشان می‌دهد که نتیجه نامطلوب چگونه است، و هزینه واقعی ماهانه یک VPS به شما کمک می‌کند مطمئن شوید که هزینه را برای منبعی می‌پردازید که سرور شما را محدود می‌کند، نه آن عددی که با فونت بزرگ‌تر در صفحه پلن‌ها درج شده است.

دو مطلب دیگر، ادامه مباحث این بخش را پوشش می‌دهند. راه‌اندازی سرور Minecraft روی VPS نسخه گام‌به‌گام تمام موارد فوق برای بازی‌ای است که اکثر افراد با آن شروع می‌کنند. لیست گسترده‌تری از کارهایی که یک VPS می‌تواند انجام دهد نیز ارزش خواندن دارد، اگر ترجیح می‌دهید سرور شما در فواصل بین شب‌های بازی، کاربرد مفید دیگری هم داشته باشد.

FAQ

آیا می‌توانم به‌جای خرید کامپیوتر گیمینگ، روی VPS بازی کنم؟

خیر. یک VPS استاندارد فاقد GPU است و تنها یک آداپتور نمایش مجازی برای کنسول ارائه‌دهنده دارد. بنابراین پس از نصب دسکتاپ، glxinfo -B رندر نرم‌افزاری را گزارش می‌کند llvmpipe و بازی‌های سه‌بعدی با نرخ چند فریم در ثانیه اجرا می‌شوند. حتی با اتصال GPU، پخش از راه دور (remote play) باعث اضافه شدن انکود و دیکود ویدیو به هر رفت‌وبرگشت فریم می‌شود و پروتکل‌های RDP و VNC هرگز برای این کار طراحی نشده‌اند. VPS برای میزبانی سرور اختصاصی است که گروه شما به آن متصل می‌شود. اگر قصد بازی دارید، زمان GPU اجاره کنید یا از سرویس‌های ابری مخصوص بازی استفاده کنید.

یک سرور بازی به چند هسته CPU نیاز دارد؟

برای اکثر بازی‌ها، دو هسته سریع بهتر از هشت هسته کند عمل می‌کنند، زیرا شبیه‌سازی دنیای بازی روی یک ترد اصلی اجرا می‌شود و هسته‌های اضافی نمی‌توانند به آن ترد در رعایت مهلت زمانی 50 میلی‌ثانیه‌ای کمک کنند. پلن‌های پیشنهادی را با sysbench cpu --cpu-max-prime=20000 --threads=1 run مقایسه کنید و عدد رویداد در ثانیه (events per second) را بخوانید. هسته‌های اضافی زمانی ارزش هزینه کردن دارند که بخواهید سرور دوم یا دیتابیس را روی همان ماشین اجرا کنید، زیرا در این صورت آن بار کاری می‌تواند بدون گرفتن زمان از ترد اصلی (tick thread) اجرا شود.

سرور Minecraft به چه مقدار RAM نیاز دارد؟

برای یک دنیای وانیلا با حدود 10 بازیکن، به حدود 2 گیگابایت Heap نیاز دارید و برای یک مادپک بزرگ با همان تعداد بازیکن، 8 گیگابایت. مقادیر -Xms و -Xmx را روی یک عدد تنظیم کنید و 1 تا 2 گیگابایت از رم ماشین را برای سیستم‌عامل آزاد بگذارید، زیرا JVM از حافظه‌ای خارج از Heap استفاده می‌کند و کرنل به page cache نیاز دارد. اگر Heap بزرگ‌تر از رم موجود باشد، پردازش توسط کرنل کشته می‌شود که در dmesg به‌جای خطای جاوا، به‌عنوان خطای کمبود حافظه (out of memory) ظاهر می‌شود.

چرا با وجود خالی بودن CPU و RAM، بازیکنان من لگ دارند؟

دو دلیل برای این وضعیت وجود دارد. لاگ سرور را برای Can't keep up! Is the server overloaded? بررسی کنید؛ این یعنی ترد اصلی نتوانسته بودجه زمانی 50 میلی‌ثانیه‌ای خود را رعایت کند، در حالی که سایر هسته‌ها بیکار بوده‌اند. اگر این خط وجود ندارد، مشکل از مسیر شبکه است؛ از هر بازیکن بخواهید mtr -rwzc 100 203.0.113.10 را روی آدرس سرور شما اجرا کند و خط آخر را بخواند. همچنین ستون st را در vmstat 1 بررسی کنید: اگر مقدار steal time بیش از چند درصد باشد، یعنی منابع هاست بیش از حد فروخته شده (oversold) و CPU بیکاری که می‌بینید، در واقع در دسترس شما نیست.

برای سرور بازی باید چه پورت‌هایی را باز کنم؟

فقط پورت اختصاصی همان بازی و پورت SSH. نسخه Java بازی Minecraft از TCP 25565، نسخه Bedrock از UDP 19132، بازی Valheim از UDP 2456 و 2457، و Palworld از UDP 8211 استفاده می‌کنند. قانون SSH را پیش از اجرای ufw enable اضافه کنید، وگرنه دسترسی شما به ماشین قطع می‌شود. به یاد داشته باشید که بسیاری از ارائه‌دهندگان یک فایروال دوم در پنل مدیریتی خود دارند و پورت باید در هر دو باز باشد. هرگز پورت RCON 25575 را روی اینترنت باز نکنید، زیرا رمز عبور آن به‌صورت متن ساده (plaintext) ارسال می‌شود.