گیم سرور کے لیے بہترین VPS کا انتخاب کیسے کریں؟

آپ کی مراد کس قسم کے gaming VPS سے ہے؟

گیم سرورز کے لیے VPS ایک کام کے لیے بہترین سودا ہے: ایک dedicated سرور چلانا جس سے آپ اور آپ کے دوست اپنی مشینوں سے connect ہوتے ہیں۔ یہ اس دوسرے کام کے لیے ایک ناقص انتخاب ہے جس کا مطلب لوگ اس اصطلاح سے لیتے ہیں، یعنی ریموٹ ڈیسک ٹاپ کے ذریعے خود VPS پر گیم کھیلنا۔ ان دونوں کاموں کے لیے متضاد ہارڈویئر درکار ہوتا ہے۔ ایک dedicated سرور کو ایک تیز CPU کور اور دنیا (world) کو لوڈ کرنے کے لیے کافی RAM درکار ہوتی ہے۔ گیم کھیلنے کے لیے GPU (graphics processing unit) کی ضرورت ہوتی ہے، اور ایک معیاری VPS پلان میں یہ موجود نہیں ہوتا۔

ذیل میں دی گئی ہر چیز پہلے کام کے بارے میں ہے۔ دوسرے کام کے لیے آپ کے وقت کے 2 منٹ نکالنا ضروری ہے، کیونکہ بہت سے لوگ اس کے لیے غلط سرور خرید لیتے ہیں۔

آپ VPS پر گیمز کیوں نہیں کھیل سکتے

ایک معیاری VPS آپ کو ورچوئل CPU کورز دیتا ہے اور اس میں کوئی گرافکس کارڈ نہیں ہوتا۔ فزیکل ہوسٹ سے کچھ بھی پاس تھرو (pass through) نہیں کیا جاتا، لہذا گیم کے استعمال کے لیے کوئی ہارڈویئر رینڈرر موجود نہیں ہوتا۔ آپ دیکھ سکتے ہیں کہ آپ کو اصل میں کیا ملا ہے:

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

اس کا جواب ایک ورچوئل ڈسپلے اڈاپٹر ہے، جیسے کہ Cirrus Logic یا virtio GPU ڈیوائس۔ یہ اس لیے موجود ہوتا ہے تاکہ پرووائیڈر کا ویب کنسول آپ کو اسکرین دکھا سکے، اور اس کے پیچھے کوئی 3D ایکسلریشن نہیں ہوتی۔ اس کے اوپر ڈیسک ٹاپ اور VNC سرور انسٹال کریں تو glxinfo -B اپنے رینڈرر کو llvmpipe کے طور پر رپورٹ کرتا ہے، جو کہ CPU پر چلنے والا Mesa کا سافٹ ویئر رینڈرر ہے۔ CPU کی طرف سے ڈرا (draw) کی گئی ایک جدید 3D گیم چند فریم فی سیکنڈ کی رفتار سے چلتی ہے، اس لیے یہ باکس سے باہر نکلنے سے پہلے ہی ناقابلِ استعمال ہوتی ہے۔ ونڈوز انسٹینسز کو بھی دوسری طرف سے اسی رکاوٹ کا سامنا کرنا پڑتا ہے۔ بہت سے ٹائٹلز لانچ ہوتے ہی بند ہو جاتے ہیں کیونکہ وہ Direct3D ڈیوائس نہیں بنا پاتے، کیونکہ اسے بنانے کے لیے کوئی ڈسپلے اڈاپٹر موجود نہیں ہوتا۔

دوسرا مسئلہ آپ تک واپسی کا سفر ہے۔ ریموٹ باکس پر کھیلنے کا مطلب ہے کہ ہر فریم کو ویڈیو میں انکوڈ کیا جاتا ہے، انٹرنیٹ پر بھیجا جاتا ہے، اور آپ کی اسکرین پر ڈیکوڈ کیا جاتا ہے۔ یہ گیم کے اپنے ان پٹ لیگ (input lag) کے اوپر انکوڈنگ اور ڈیکوڈنگ کا وقت شامل کر دیتا ہے، اور RDP اور VNC کو 60 فریم فی سیکنڈ کی موومنٹ کے بجائے ڈیسک ٹاپس کے لیے ڈیزائن کیا گیا تھا۔ کلاؤڈ گیمنگ سروسز اسے اصلی GPU ہارڈویئر اور خاص مقصد کے لیے بنائے گئے اسٹریمنگ پروٹوکول کے ساتھ حل کرتی ہیں۔ ایک عام VPS میں ان میں سے کچھ بھی نہیں ہوتا۔ اگر آپ کھیلنا چاہتے ہیں تو GPU ٹائم کرائے پر لیں۔ اگر آپ ہوسٹ کرنا چاہتے ہیں تو پڑھنا جاری رکھیں۔

ایک dedicated گیم سرور کو درحقیقت کن چیزوں کی ضرورت ہوتی ہے

گیم سرور دراصل ایک simulation loop ہے۔ یہ دنیا کو memory میں رکھتا ہے اور اسے فی سیکنڈ ایک مقررہ تعداد میں آگے بڑھاتا ہے۔ اس کے بعد ہر منسلک کھلاڑی کو دنیا کا وہ حصہ بھیجا جاتا ہے جسے وہ دیکھ سکتا ہے۔

یہ ساخت ہارڈویئر کا تعین کرتی ہے۔ یہ loop زیادہ تر ایک thread پر مشتمل ہوتی ہے، اس لیے core count کے مقابلے میں core speed زیادہ اہمیت رکھتی ہے۔ دنیا memory میں رہتی ہے، اس لیے RAM عام طور پر وہ پہلی حد ہے جس کا آپ کو سامنا ہوتا ہے۔ کھیل کے دوران disk خاموش رہتی ہے لیکن load اور save کے وقت مصروف ہو جاتی ہے۔ آپ کا network path ping کا تعین کرتا ہے، اور کوئی بھی plan tier اسے تبدیل نہیں کر سکتا۔

سنگل کور کی رفتار کور کی تعداد سے زیادہ اہم ہے

زیادہ تر گیم سرورز دنیا کی پیش رفت کو ایک مرکزی تھریڈ پر چلاتے ہیں۔ Minecraft کا ٹک لوپ اور Source انجن کا سرور فریم دونوں اسی طرح کام کرتے ہیں۔ اس ٹک کے لیے ایک ڈیڈ لائن ہوتی ہے۔ Minecraft Java فی سیکنڈ 20 ٹک پر چلتا ہے، جس کا مطلب ہے کہ ہر ٹک کے لیے 50 ملی سیکنڈ کا بجٹ ہوتا ہے۔ جب کام اس وقت میں مکمل نہیں ہوتا، تو سرور بالکل یہ پیغام پرنٹ کرتا ہے:

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

اس لائن کا مطلب ہے کہ ایک تھریڈ کا وقت ختم ہو گیا ہے۔ مزید کورز شامل کرنے سے اس تھریڈ کو زیادہ وقت نہیں ملتا۔ 2 تیز vCPUs والا پلان اس ٹک ریٹ کو برقرار رکھے گا جسے 8 سست vCPUs والا پلان گرا دے گا، کیونکہ ان 8 میں سے صرف ایک ہی وہ کام کر رہا ہے جو اہمیت رکھتا ہے۔

کسی بھی پلان کو منتخب کرنے سے پہلے سنگل تھریڈ کی رفتار کی پیمائش کریں:

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

events per second لائن کو پڑھیں۔ یہ نمبر اپنے آپ میں کوئی معنی نہیں رکھتا لیکن موازنہ کے لیے بہت اہم ہے، لہذا اسے دو امیدوار پلانز پر چلائیں اور نتائج کا ساتھ ساتھ موازنہ کریں۔ ایک مکمل VPS بینچ مارک رن میں ڈسک اور نیٹ ورک کی پیمائش بھی اسی طرح کی جاتی ہے۔

اضافی کورز پھر بھی اپنی جگہ اہم ہیں۔ وہ دوسرے گیم سرور، ڈیٹا بیس، رات کے بیک اپ اور چنک پری جنریٹر کو ٹک تھریڈ کا وقت چرائے بغیر چلا سکتے ہیں۔ سرور سافٹ ویئر نے بھی اب کام کو تقسیم کرنا سیکھ لیا ہے، اور Paper، جو کہ ایک مقبول Minecraft سرور فورک ہے، کچھ کام کو مرکزی ٹک تھریڈ سے ہٹا دیتا ہے۔ لہذا، خریدنے کے لیے بہترین انتخاب چند تیز کورز ہیں، نہ کہ بہت سارے سست کورز۔

ایک نمبر کبھی بھی پلان کے صفحے پر نظر نہیں آتا، اور وہی فیصلہ کرتا ہے کہ جس تیز کور کے لیے آپ نے ادائیگی کی ہے وہ واقعی آپ کا ہے یا نہیں:

vmstat 1 5

st کالم اس وقت کا فیصد ہے جب آپ کا ورچوئل CPU چلنے کے لیے تیار تھا لیکن فزیکل ہوسٹ نے وہ کور کسی اور کو دے دیا تھا۔ 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
  }
]

یہ وہ ابتدائی ایلوکیشنز ہیں جو گیم اور موڈ پیک کی دستاویزات میں اگست 2026 تک شائع کی گئی ہیں۔ یہ محض رہنمائی ہے، نہ کہ کسی ایک مشین پر ماپی گئی حتمی اقدار۔ Vanilla Minecraft Java تقریباً 10 کھلاڑیوں کے لیے 2 GB ہیپ (heap) کے ساتھ آرام سے چلتا ہے۔ اتنے ہی کھلاڑیوں کے لیے ایک بڑے موڈ پیک کو 8 GB درکار ہوتے ہیں، کیونکہ موڈز ایسی اینٹیٹیز اور جنریٹڈ اسٹرکچرز کا اضافہ کرتے ہیں جو سب اسی ہیپ میں رہتے ہیں۔ Valheim کی اپنی درج کردہ کم از کم ضرورت 2 GB ہے، جبکہ چھوٹے ورلڈ والے آپریٹرز کے مطابق یہ پروسیس 3 GB کے قریب سیٹل ہوتا ہے، لہذا 4 GB سے شروعات کرنا ایک معقول فیصلہ ہے۔ Palworld اس معاملے میں سب سے الگ ہے، جس کے 32 کھلاڑیوں کی زیادہ سے زیادہ تعداد کے لیے 16 GB درکار ہوتے ہیں، جو کہ Pocketpair کی تجویز کردہ مقدار ہے۔

RAM کا تعلق کنکشنز سے نہیں، بلکہ لوڈ ہونے والے ورلڈ سے ہوتا ہے۔ ہر کھلاڑی اپنے ارد گرد کے ریجن کو لوڈ رکھتا ہے، اس لیے ایک ساتھ کھڑے دو کھلاڑیوں کی لاگت، نقشے کے مخالف کونوں کو ایکسپلور کرنے والے دو کھلاڑیوں سے بہت کم ہوتی ہے۔ یہی وجہ ہے کہ "فی کھلاڑی RAM" صرف ایک اندازہ ہے جبکہ "فی فعال علاقہ RAM" اصل محرک ہے، اور اسی لیے ایک چھوٹا گروپ جو ایکسپلورنگ کا شوقین ہو، وہ اپنی تعداد سے دگنے سائز کے پلان سے بھی آگے نکل سکتا ہے۔

Java سرورز کے لیے دو اضافی اصول درکار ہیں۔ کم از کم اور زیادہ سے زیادہ ہیپ کو ایک ہی ویلیو پر سیٹ کریں تاکہ JVM اسے ری سائز کرنے کے لیے کبھی نہ رکے:

java -Xms4G -Xmx4G -jar server.jar nogui

اس کے بعد کچھ گنجائش (headroom) چھوڑیں۔ JVM آپ کے دیے گئے ہیپ کے باہر بھی میموری استعمال کرتا ہے، جیسے تھریڈ اسٹیکس اور نیٹو بفرز کے لیے، اور کرنل کو ورلڈ فائلز کو تیزی سے پڑھنے کے لیے پیج کیشے کی ضرورت ہوتی ہے۔ 6 GB والی مشین پر 4 GB ہیپ رکھنا سمجھداری ہے، جبکہ 6 GB ہیپ رکھنا درست نہیں۔

میموری کی دو ناکامیاں بالکل مختلف نظر آتی ہیں، لہذا دونوں اسٹرنگز کو پہچاننا سیکھیں۔ بہت چھوٹا ہیپ Java کے اندر ایرر پھینکتا ہے، اور سرور عام طور پر لنگڑا کر چلتا رہتا ہے:

java.lang.OutOfMemoryError: Java heap space

مشین سے بڑا ہیپ ہونے پر پورا پروسیس باہر سے کل (kill) کر دیا جاتا ہے۔ کنسول پر صرف Killed نظر آتا ہے، اور اس کا ثبوت کرنل لاگ میں موجود ہوتا ہے:

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

Swap شامل کرنے سے کل (kill) تو رک جاتا ہے لیکن مسئلہ حل نہیں ہوتا۔ ایک ٹک لوپ (tick loop) جسے اپنا ورلڈ Swap سے واپس پڑھنا پڑے، وہ ہر ڈیڈ لائن مس کر دیتا ہے، جس کے نتیجے میں آپ کے کھلاڑیوں کو کریش ہونے کے بجائے ایک منجمد (frozen) سرور ملتا ہے۔

ایک ورژن نوٹ، جو اگست 2026 تک درست ہے: Minecraft Java 1.20.5 اور اس کے بعد کے ورژنز کے لیے Java 21 درکار ہے۔ پرانا رن ٹائم شروع تو ہوتا ہے لیکن unsupported class file version ایرر کے ساتھ فیل ہو جاتا ہے، جو کمپائلر کے پیغام جیسا لگتا ہے اور پہلی بار دیکھنے والے ہر شخص کو الجھا دیتا ہے۔

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

کیا گیم سرور کے لیے ڈسک کی رفتار اہمیت رکھتی ہے؟

کھیل کے دوران لوگوں کی توقع سے کم، لیکن دو مخصوص مواقع پر بہت زیادہ۔ دنیا کو سٹارٹ اپ کے وقت میموری میں لوڈ کیا جاتا ہے اور آٹو سیو کے دوران واپس لکھا جاتا ہے، اس لیے ڈسک کی رفتار سست بوٹ اور سیو کے دوران وقفے کی صورت میں ظاہر ہوتی ہے۔ اس کے درمیان، زیادہ تر ریڈ آپریشنز RAM سے پورے کیے جاتے ہیں۔

دو چیزیں ڈسک کو اس خلاصے سے زیادہ اہم بناتی ہیں۔ ایکسپلوریشن کے دوران کھلاڑیوں کی نقل و حرکت کے ساتھ نئے چنکس یا زونز ڈسک سے لوڈ ہوتے ہیں، اور یہ ریڈ آپریشن ٹک بجٹ کے اندر ہوتا ہے۔ ایک بڑی دنیا پر آٹو سیو ایک ساتھ بہت زیادہ ڈیٹا لکھتا ہے، اور سست والیوم پر یہ رائٹ آپریشن لوپ کو اتنی دیر کے لیے بلاک کر دیتا ہے کہ اوپر دی گئی "Can't keep up" وارننگ ظاہر ہو جاتی ہے۔ یہ دونوں مسائل تھرو پٹ کے بجائے لیٹنسی کے ہیں، اسی لیے VPS پر NVMe اور SATA SSD کے درمیان فرق یہاں ہیڈلائن میں دی گئی میگا بائٹس فی سیکنڈ سے زیادہ اہمیت رکھتا ہے۔ آپ کے لیے اہم یہ ہے کہ ایک چھوٹا آپریشن کتنا وقت لیتا ہے۔

والیوم کا سائز بڑھوتری کے مطابق رکھیں۔ جب بھی کوئی نئی جگہ جاتا ہے تو دنیا کا سائز بڑھتا ہے، اور آپ کے بیک اپس اس کے وزن کو کئی گنا کر دیتے ہیں۔ ایک مہینے تک ہفتے میں ایک بار du -sh world چلائیں، آپ کو اپنی اصل گروتھ ریٹ معلوم ہو جائے گی۔

Tick rate، ping، اور ان کے درمیان فرق

Tick rate اس بات کا پیمانہ ہے کہ سرور ایک سیکنڈ میں کتنی بار دنیا (world) کو دوبارہ calculate کرتا ہے۔ Minecraft Java میں یہ شرح 20 ہے۔ Source engine کے سرورز عام طور پر 64 پر چلتے ہیں۔ Minecraft میں آپ زیادہ شرح نہیں خرید سکتے، کیونکہ یہ شرح گیم کے ڈیزائن کا حصہ ہے، لہذا مقصد اسے 20 پر برقرار رکھنا ہے نہ کہ اس سے تجاوز کرنا۔

Ping ایک کھلاڑی اور سرور کے درمیان ڈیٹا کے آنے اور جانے کا دورانیہ ہے۔ یہ دونوں چیزیں مختلف شکایات پیدا کرتی ہیں، اس لیے پیسے خرچ کرنے سے پہلے ان میں فرق کرنا سیکھیں۔ جب سرور ticks مس کرتا ہے، تو ہر کھلاڑی کو ایک ہی لمحے میں rubber-banding کا سامنا ہوتا ہے اور سرور لاگ میں یہ بات واضح طور پر لکھی جاتی ہے۔ جب کسی ایک کھلاڑی کا نیٹ ورک پاتھ طویل ہوتا ہے، تو صرف وہی کھلاڑی لیگ (lag) محسوس کرتا ہے اور باقی گروپ ٹھیک رہتا ہے۔ ایک طاقتور CPU دوسرے کیس کو کبھی ٹھیک نہیں کر سکتا۔

Latency کا تعلق مقام سے ہے، نہ کہ پلان کے درجے سے

فائبر میں روشنی تقریباً 200 کلومیٹر فی ملی سیکنڈ کی رفتار سے سفر کرتی ہے۔ ایک round trip میں فاصلہ دو بار طے ہوتا ہے، لہذا کھلاڑی اور سرور کے درمیان ہر 100 کلومیٹر کے لیے کم از کم وقت (floor) تقریباً 1 ms ہے۔ کوئی بھی فراہم کنندہ اس سے بہتر کارکردگی نہیں دے سکتا، اور نہ ہی پلان کو اپ گریڈ کرنے سے اس میں کوئی تبدیلی آتی ہے۔

[
  {
    "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 سے شمار کیا گیا ہے۔ حقیقی فائبر سیدھی نہیں ہوتی، اور راستے میں آنے والا ہر router تھوڑی تاخیر کا اضافہ کرتا ہے، اس لیے حقیقی دنیا کا اچھا نتیجہ اس کم از کم وقت سے تقریباً دوگنا ہوتا ہے۔ ٹورنٹو میں موجود ایک کھلاڑی جو نیویارک میں 550 کلومیٹر دور سرور تک رسائی حاصل کرتا ہے، اس کا کم از کم وقت 5.5 ms ہے اور اسے عام طور پر 10 سے 20 ms کے درمیان latency ملے گی۔ لاس اینجلس سے سڈنی کے راستے کا کم از کم وقت 120.7 ms ہے، اور اسے پیسوں سے تبدیل نہیں کیا جا سکتا۔

لہذا سرور کو ان لوگوں کے قریب رکھیں جو اس پر کھیلتے ہیں۔ اگر آپ کا گروپ سمندر کے پار بٹا ہوا ہے، تو کسی نہ کسی کو طویل راستہ طے کرنا پڑے گا، اور منصفانہ حل عام طور پر وہ خطہ ہے جہاں زیادہ تر کھلاڑی موجود ہوں۔

اندازہ لگانے کے بجائے راستے کی پیمائش کریں:

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

پہلے آخری لائن پڑھیں۔ وہ لائن سرور ہے، اور اس کا loss اور latency ہی یہ طے کرتے ہیں کہ گیم کی کارکردگی کیسی ہے۔ درمیانی hop پر دکھایا گیا loss اگر آخری hop پر صاف ہو تو یہ تقریباً ہمیشہ اس router پر ICMP rate limiting کی وجہ سے ہوتا ہے، کیونکہ routers اصل ٹریفک کو معمول کے مطابق آگے بھیجتے ہوئے probe packets کے جوابات کو کم ترجیح دیتے ہیں۔ ہر کھلاڑی سے کہیں کہ وہ سرور کی طرف اس کی پیمائش کرے، کیونکہ ان میں سے ہر ایک کا راستہ مختلف ہوتا ہے۔

صرف وہی ports کھولیں جن کی گیم کو ضرورت ہے

گیم سرور کو صرف ایک یا دو ports کھلی رکھنے کی ضرورت ہوتی ہے، اس کے علاوہ کچھ نہیں۔ عام defaults یہ ہیں:

• 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

گیم کی اپنی documentation چیک کریں، کیونکہ کئی titles ایک اضافی query port استعمال کرتے ہیں۔ Valheim اس کی واضح مثال ہے: 2456 گیم ٹریفک لے جاتا ہے اور 2457 اس Steam سرور query کا جواب دیتا ہے جس کی وجہ سے آپ کا سرور براؤزر لسٹ میں نظر آتا ہے۔ ان نمبرز کو TCP پر کھولنے سے کچھ حاصل نہیں ہوگا، کیونکہ Valheim صرف UDP استعمال کرتا ہے۔

فائر وال فعال کرنے سے پہلے SSH کو اجازت دیں، ورنہ آپ اپنے ہی سرور سے باہر ہو جائیں گے:

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

بہت سے پرووائیڈرز اپنے کنٹرول پینل میں بھی ایک نیٹ ورک فائر وال چلاتے ہیں، جو سرور کے اندر موجود فائر وال سے الگ ہوتی ہے۔ ایک port جو ufw میں کھلی ہو لیکن وہاں بند ہو، وہ پھر بھی کنکشنز کو مسترد کر دے گی، اور باہر سے اس کی علامت بالکل ایک جیسی ہوتی ہے، لہذا کنفیگریشن فائلز میں ترمیم شروع کرنے سے پہلے دونوں جگہ چیک کریں۔

کسی دوسری مشین سے TCP port چیک کرنا آسان ہے:

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

UDP کو اس طرح ٹیسٹ نہیں کیا جا سکتا۔ ایک بند UDP port عام طور پر خاموش رہتی ہے، لہذا ایسی جانچ جس کا کوئی جواب نہ ملے، وہ آپ کو کچھ نہیں بتاتی۔ اس کے بجائے سرور کی طرف سے تصدیق کریں، اور دیکھیں کہ گیم کا عمل آپ کی متوقع port پر bind ہے یا نہیں:

sudo ss -lunp | grep 2456

RCON، یعنی ریموٹ کنسول پروٹوکول، کو کبھی بھی انٹرنیٹ پر ظاہر نہ کریں۔ یہ ایک سادہ پاس ورڈ ہے جو plaintext کنکشن پر بھیجا جاتا ہے، جو بائی ڈیفالٹ port 25575 پر ہوتا ہے۔ اسے 127.0.0.1 پر bind کریں اور SSH ٹنل کے ذریعے اس تک رسائی حاصل کریں۔ گیم سرور کو بھی اپنے ایک غیر مراعات یافتہ (unprivileged) صارف کے طور پر چلائیں، تاکہ کسی mod میں موجود خرابی مشین کے باقی حصوں تک نہ پہنچ سکے۔ نئے VPS پر پہلے دس منٹ میں وہ یوزر اکاؤنٹ اور SSH ہارڈننگ شامل ہے جس کے بارے میں یہ سیکشن فرض کرتا ہے کہ آپ پہلے ہی کر چکے ہیں۔

سرور کو systemd کے تحت چلائیں تاکہ یہ خودکار طور پر restart ہو

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 کریش کے بعد سرور کو دوبارہ بحال کرتا ہے اور کلین شٹ ڈاؤن کے بعد اسے بند ہی رکھتا ہے، جو کہ آپ کی ضرورت ہے۔ 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" جیسی لائن پر ختم ہوتا ہے۔ اگر یونٹ activating اور failed کے درمیان سوئچ کرتا رہے، تو journalctl -u minecraft -n 50 میں اس کی وجہ موجود ہوتی ہے، اور یہ عام طور پر WorkingDirectory میں غلط پاتھ یا سرور کی صلاحیت سے بڑا heap سائز ہوتا ہے۔

systemd آپ کو کوئی انٹرایکٹو کنسول فراہم نہیں کرتا، لہذا پہلے سے منصوبہ بندی کریں۔ کمانڈز کے لیے localhost پر RCON استعمال کریں، یا سرور کو tmux سیشن کے اندر چلائیں، یہ وہی عادت ہے جو VPS پر طویل عرصے تک چلنے والے Claude Code سیشن کو لاگ ان کے درمیان زندہ رکھتی ہے۔

Steam کے ذریعے تقسیم ہونے والی گیمز کو اس سب سے پہلے SteamCMD کی ضرورت ہوتی ہے۔ Ubuntu پیکیج ایک 32 بٹ بائنری ہے، اسی لیے وہاں آرکیٹیکچر لائن موجود ہے۔ اس لائن کو چھوڑ دیں تو apt رپورٹ کرے گا کہ اس کے پاس کوئی انسٹالیشن کینڈیڈیٹ نہیں ہے:

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

کچھ گیم سرورز جتنا زیادہ چلتے ہیں، ان کا میموری کا استعمال اتنا ہی بڑھتا جاتا ہے، اور اس کا حل یہ ہے کہ کسی پرسکون وقت پر شیڈول کے مطابق restart کیا جائے۔ ایک systemd ٹائمر جو systemctl restart کو کال کرے، cron انٹری سے زیادہ سمجھ میں آتا ہے، کیونکہ systemctl list-timers آپ کو بالکل دکھاتا ہے کہ یہ اگلی بار کب چلے گا۔

دنیا کا شیڈول کے مطابق بیک اپ لیں

گیم سرور پر موجود ہر چیز کو دوبارہ حاصل کیا جا سکتا ہے، سوائے world ڈائریکٹری اور کھلاڑیوں کے ڈیٹا کے۔ گیم کو دوبارہ انسٹال کرنے میں چند منٹ لگتے ہیں۔ آپ کے گروپ کی بنائی ہوئی چیزوں کو دوبارہ تعمیر کرنے میں مہینوں لگ سکتے ہیں۔

ایک محفوظ بیک اپ وہ ہے جو اس وقت لیا جائے جب کوئی بھی چیز لکھی (write) نہ جا رہی ہو۔ سرور کو ایک منٹ کے لیے روکنا اس بات کی ضمانت دینے کا سب سے آسان طریقہ ہے:

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 کاپی مکمل ہونے کے بعد آٹو سیو کو دوبارہ آن کر دیتا ہے۔ سرور کے لکھتے وقت دنیا کی کاپی کرنے سے ایسی region فائل کیپچر ہو سکتی ہے جو صرف آدھی لکھی گئی ہو، اور آپ کو اس کا پتہ تب تک نہیں چلے گا جب تک آپ کو اسے بحال (restore) کرنے کی ضرورت نہ پڑے۔

کم از کم ایک کاپی مشین سے باہر رکھیں۔ ایک ہی ڈسک پر موجود بیک اپ ڈسک کے خراب ہونے کی صورت میں محفوظ نہیں رہتا، اور پرووائیڈر کا اسنیپ شاٹ ایک سہولت ہے نہ کہ بیک اپ، کیونکہ یہ اسی اکاؤنٹ میں ہوتا ہے جسے آپ کھو سکتے ہیں۔ آف سائٹ اسٹوریج پر شیڈولڈ restic بیک اپ ریٹینشن اور ڈیڈپلیکیشن کو سنبھالتے ہیں، لہذا رات بھر کی دنیا کی کاپیوں کا ایک مہینہ آپ کے والیم کو نہیں بھرتا۔

پھر ایک بیک اپ کو بحال کر کے دیکھیں۔ جس بیک اپ کو آپ نے کبھی بحال نہیں کیا، وہ صرف ایک اندازہ ہے۔ کل رات کا آرکائیو ایک اضافی ڈائریکٹری میں نکالیں، ایک ٹیسٹ سرور کو اس کی طرف پوائنٹ کریں، اور تصدیق کریں کہ دنیا لوڈ ہو رہی ہے اور عمارتیں وہیں موجود ہیں جہاں آپ نے انہیں چھوڑا تھا۔

فیصلہ کرنے سے پہلے جانچ پڑتال کریں

ایک سال کے بجائے ایک ماہ کا پلان خریدیں، اور ایک شام حقیقی کھلاڑیوں کے ساتھ ٹیسٹ کریں۔ سنگل تھریڈ sysbench فگر چلائیں، پھر ہر کھلاڑی سے سرور کی جانب mtr چلوا کر دیکھیں۔ VPS بینچ مارکنگ کا مکمل طریقہ کار ان ٹولز کے استعمال کی وضاحت کرتا ہے اور دکھاتا ہے کہ خراب نتائج کیسے نظر آتے ہیں، اور ایک VPS کی ماہانہ اصل قیمت آپ کو یہ جانچنے میں مدد دیتی ہے کہ آپ ان وسائل کے پیسے دے رہے ہیں جو آپ کے سرور کو محدود کر رہے ہیں، نہ کہ ان کے جو پلان کے صفحے پر بڑے حروف میں لکھے گئے ہیں۔

دو تحریریں وہاں سے شروع ہوتی ہیں جہاں یہ ختم ہوتی ہے۔ VPS پر Minecraft سرور بنانا اوپر بیان کردہ ہر چیز کا مرحلہ وار ورژن ہے، جو اس گیم پر مبنی ہے جس سے زیادہ تر لوگ شروعات کرتے ہیں۔ VPS پر چلائی جا سکنے والی دیگر چیزوں کی وسیع فہرست پڑھنا اس وقت مفید ہے اگر آپ چاہتے ہیں کہ آپ کا سرور گیم نائٹس کے درمیان کچھ اور کارآمد کام بھی کر سکے۔

FAQ

کیا میں گیمنگ پی سی خریدنے کے بجائے VPS پر گیمز کھیل سکتا ہوں؟

نہیں۔ ایک معیاری VPS میں GPU نہیں ہوتا، صرف پرووائیڈر کے کنسول کے لیے ایک ورچوئل ڈسپلے اڈاپٹر ہوتا ہے۔ لہذا جب آپ ڈیسک ٹاپ انسٹال کرتے ہیں تو glxinfo -B سافٹ ویئر رینڈرر llvmpipe کی اطلاع دیتا ہے اور کوئی بھی 3D گیم چند فریم فی سیکنڈ پر چلتی ہے۔ اگر GPU منسلک بھی ہو، تب بھی ریموٹ پلے ہر فریم کے راؤنڈ ٹرپ میں ویڈیو انکوڈنگ اور ڈیکوڈنگ کا اضافہ کر دیتا ہے، اور RDP یا VNC اس مقصد کے لیے نہیں بنائے گئے تھے۔ VPS کا مقصد وہ ڈیڈیکیٹڈ سرور ہوسٹ کرنا ہے جس سے آپ کا گروپ منسلک ہوتا ہے۔ اگر آپ گیم کھیلنا چاہتے ہیں تو GPU ٹائم کرائے پر لیں یا کلاؤڈ گیمنگ سروس استعمال کریں۔

گیم سرور کو کتنے CPU کورز کی ضرورت ہوتی ہے؟

زیادہ تر گیمز کے لیے دو تیز رفتار کورز آٹھ سست رفتار کورز سے بہتر ہیں، کیونکہ ورلڈ سیمولیشن ایک مین تھریڈ پر چلتی ہے اور اضافی کورز اس تھریڈ کو 50 ms کی ڈیڈ لائن پورا کرنے میں مدد نہیں کر سکتے۔ امیدوار پلانز کا موازنہ sysbench cpu --cpu-max-prime=20000 --threads=1 run کے ساتھ کریں اور ایونٹس فی سیکنڈ کا اعداد و شمار پڑھیں۔ اضافی کورز اس وقت فائدہ مند ہوتے ہیں جب آپ اسی مشین پر دوسرا سرور یا ڈیٹا بیس بھی چلا رہے ہوں، کیونکہ تب وہ ورک لوڈز ٹک تھریڈ کا وقت ضائع کیے بغیر چل سکتے ہیں۔

مائن کرافٹ (Minecraft) سرور کو کتنی RAM درکار ہوتی ہے؟

تقریباً 10 کھلاڑیوں کے ساتھ ایک ونیلا ورلڈ کے لیے 2 GB ہیپ، اور اتنے ہی کھلاڑیوں کے ساتھ بڑے موڈ پیک کے لیے 8 GB درکار ہوتی ہے۔ -Xms اور -Xmx کو ایک ہی ویلیو پر سیٹ کریں، اور مشین کی 1 GB سے 2 GB RAM آپریٹنگ سسٹم کے لیے خالی چھوڑ دیں، کیونکہ JVM ہیپ کے باہر بھی میموری استعمال کرتا ہے اور کرنل کو پیج کیشے کی ضرورت ہوتی ہے۔ اگر ہیپ مشین کی کل میموری سے زیادہ ہو تو کرنل پروسیس کو ختم کر دیتا ہے، جو dmesg میں جاوا ایرر کے بجائے آؤٹ آف میموری لائن کے طور پر ظاہر ہوتا ہے۔

جب سرور پر CPU اور RAM خالی ہو تو میرے کھلاڑیوں کو لیگ (lag) کا سامنا کیوں ہوتا ہے؟

اس صورتحال کی دو وجوہات ہو سکتی ہیں۔ سرور لاگ میں Can't keep up! Is the server overloaded? چیک کریں، جس کا مطلب ہے کہ سنگل مین تھریڈ اپنا 50 ms کا ٹک بجٹ پورا نہیں کر سکا جبکہ باقی کورز فارغ بیٹھے تھے۔ اگر یہ لائن موجود نہیں ہے تو مسئلہ نیٹ ورک پاتھ کا ہے، لہذا ہر کھلاڑی سے اپنے سرور ایڈریس کے خلاف mtr -rwzc 100 203.0.113.10 چلوا کر آخری لائن پڑھیں۔ اس کے علاوہ vmstat 1 میں st کالم چیک کریں: اگر اسٹیل ٹائم چند فیصد سے زیادہ ہے تو اس کا مطلب ہے کہ ہوسٹ اوور سولڈ (oversold) ہے، یعنی جو فارغ CPU آپ کو نظر آ رہا ہے وہ درحقیقت آپ کے لیے دستیاب نہیں ہے۔

گیم سرور کے لیے مجھے کون سے پورٹس کھولنے کی ضرورت ہے؟

صرف گیم کا اپنا پورٹ اور SSH۔ Minecraft Java کے لیے TCP 25565، Minecraft Bedrock کے لیے UDP 19132، Valheim کے لیے UDP 2456 اور 2457، اور Palworld کے لیے UDP 8211 استعمال ہوتا ہے۔ ufw enable چلانے سے پہلے SSH رول شامل کریں، ورنہ آپ مشین تک رسائی کھو دیں گے۔ یاد رکھیں کہ بہت سے پرووائیڈرز اپنے کنٹرول پینل میں ایک دوسرا فائر وال بھی چلاتے ہیں، اور پورٹ کا دونوں جگہ کھلا ہونا ضروری ہے۔ RCON کو پورٹ 25575 پر کبھی بھی انٹرنیٹ کے لیے نہ کھولیں، کیونکہ یہ ایک پاس ورڈ ہے جو پلین ٹیکسٹ میں بھیجا جاتا ہے۔