إعداد أول سيرفر VPS من الصفر: دليل خطوة بخطوة

شراء VPS هو نصف القصة فقط. خلافًا للاستضافة المشتركة التي تأتيك جاهزة بلوحة cPanel ومحتوى مثبّت مسبقًا، يصلك الـVPS عاريًا تمامًا: نظام تشغيل خام، عنوان IP، وكلمة مرور root — ولا شيء غير ذلك. كل ما يأتي بعد ذلك مسؤوليتك أنت: التأمين، تثبيت البرمجيات، الإعداد، والصيانة. هذا ما يجعل الـVPS أقوى وأرخص بكثير، لكنه أيضًا ما يربك المبتدئين في أول ساعة. هذا الدليل مكتوب ليكون رفيقك في تلك الساعة وما بعدها: نبدأ من خادم فارغ تمامًا وننتهي بموقع حيّ يعمل خلف شهادة SSL وجدار حماية ونسخ احتياطي. إن كنت لا تزال تتساءل أصلًا عمّا إذا كان الـVPS مناسبًا لك، فابدأ بمقال ما هو الـVPS ومتى تحتاجه ثم عُد إلى هنا للتنفيذ.

مُدار أم غير مُدار: لمن هذا الدليل؟

قبل أي أمر، عليك أن تعرف أي نوع من الـVPS اشتريت، لأن ذلك يحدّد كم من هذا الدليل ينطبق عليك. هناك نموذجان رئيسيان:

VPS غير مُدار (Unmanaged): المزوّد يسلّمك خادمًا خامًا فقط — نظام تشغيل وIP وصلاحية root. كل ما بعد ذلك عليك: التأمين، التثبيت، التحديثات، حلّ المشاكل. هذا هو النوع الأرخص والأكثر مرونة، وهو بالضبط ما يستهدفه هذا الدليل خطوة بخطوة.

VPS مُدار (Managed): المزوّد يتولّى نيابةً عنك التأمين الأساسي وتحديثات النظام وأحيانًا تثبيت لوحة تحكم (مثل cPanel أو Plesk) والدعم الفنّي. أنت تدفع أكثر مقابل راحة البال. إن كان لديك VPS مُدار بلوحة، فالكثير من خطوات هذا الدليل (UFW، تثبيت الستاك يدويًا) قد تكون مُنجزة أو مُدارة عبر اللوحة — لكن فهم ما يجري تحت الغطاء يبقى نافعًا، وقسم التأمين يخصّك أنت أيضًا.

إن كنت مترددًا بين الأنواع، فمقارنة المشتركة مقابل VPS مقابل المُدارة تساعدك على الحسم. هذا الدليل يفترض أنك على VPS غير مُدار بتوزيعة Linux نظيفة، وهو السيناريو الأكثر شيوعًا للمطوّرين وأصحاب المشاريع الجادّة.

ما المتطلّبات قبل أن تبدأ؟

قبل أن تكتب أوّل أمر، تأكّد أن لديك العناصر التالية جاهزة. غياب أحدها سيوقفك في منتصف الطريق:

عند اختيار الحجم، لا تبالغ ولا تبخل. قاعدة عملية للبداية: موقع ووردبريس صغير إلى متوسط يكفيه عادةً نواتان (2 vCPU) و2–4 جيجابايت ذاكرة و40–80 جيجابايت تخزين SSD. الجمال في الـVPS أنك تستطيع الترقية لاحقًا بنقرات، فلا داعي للدفع الزائد من اليوم الأول. لمعرفة متى يصبح الانتقال إلى VPS ضرورة فعلًا، راجع متى تحتاج الترقية إلى VPS.

أمّا اختيار التوزيعة، فهو قرار ستعيش معه طويلًا. الخيارات الثلاثة الشائعة لها فلسفات مختلفة:

في هذا الدليل سنعتمد أوامر Ubuntu/Debian (apt) لأنها الأكثر شيوعًا للمبتدئين، وسنشير إلى مقابلاتها في AlmaLinux (dnf) حيث يلزم. إن كنت على AlmaLinux، استبدل apt بـ dnf، وufw بـ firewalld، واسم حزمة Apache من apache2 إلى httpd.

كيف تتصل بالـVPS عبر SSH لأول مرة؟

الـSSH (Secure Shell) هو القناة المشفّرة التي تتحكّم بها بخادمك عن بُعد عبر سطر الأوامر. بعد إنشاء الخادم، يمنحك المزوّد عنوان IP وكلمة مرور root. افتح Terminal (على macOS/Linux) أو PowerShell (على ويندوز 10/11 الحديث يأتي بعميل SSH مدمج) واكتب:

ssh root@203.0.113.10

استبدل 203.0.113.10 بعنوان IP الفعلي لخادمك. في أول اتصال سيعرض عليك SSH بصمة الخادم (fingerprint) ويسألك إن كنت تثق بها — اكتب yes. ثم سيُطلب منك إدخال كلمة مرور root الأولية. لن تظهر أحرف كلمة المرور أثناء الكتابة (هذا طبيعي لأسباب أمنية)، فاكتبها واضغط Enter.

The authenticity of host '203.0.113.10' can't be established.
ED25519 key fingerprint is SHA256:abc123...
Are you sure you want to continue connecting (yes/no)? yes
root@203.0.113.10's password:

إن نجح الاتصال، سترى موجّه الأوامر يتغيّر إلى شيء مثل root@your-server:~#. علامة # في النهاية تعني أنك مستخدم root — صاحب الصلاحيات الكاملة. أنت الآن داخل خادمك. أوّل ما ستفعله هو تحديثه ثم التخلّي عن استخدام root مباشرةً، كما سنرى.

إن واجهت خطأ Connection refused، فغالبًا أن الخادم لم يكتمل إقلاعه بعد (انتظر دقيقة وأعد المحاولة) أو أن خدمة SSH على منفذ غير 22. وإن رأيت Connection timed out، فالسبب عادةً جدار حماية على مستوى المزوّد (Cloud Firewall) يحجب المنفذ — راجع لوحة المزوّد وافتح المنفذ 22 من هناك. أمّا تحذير REMOTE HOST IDENTIFICATION HAS CHANGED فيظهر إن أعدت بناء الخادم على IP سبق أن اتصلت به؛ احذف السطر القديم من ملف ~/.ssh/known_hosts على جهازك ثم أعد الاتصال. هذه الأخطاء الثلاثة تغطّي الغالبية العظمى من مشاكل أول اتصال.

لماذا يجب تحديث النظام أولًا؟

النظام الذي يصلك من المزوّد قد يكون مُجهّزًا قبل أسابيع أو أشهر، وفيه حزم قديمة بثغرات معروفة. أوّل خطوة جادّة هي تحديث كل شيء إلى آخر إصدار. على Ubuntu/Debian:

apt update && apt upgrade -y

الأمر apt update يُحدّث قائمة الحزم المتاحة من المستودعات (لا يثبّت شيئًا، فقط يجلب المعلومات)، وapt upgrade -y يُثبّت فعليًا كل التحديثات المتاحة (الراية -y توافق تلقائيًا على كل المطالبات). على AlmaLinux يكون المقابل:

dnf update -y

بعد التحديث، يُستحسن إعادة تشغيل الخادم إن طُلب ذلك (خاصةً عند تحديث النواة):

reboot

سينقطع اتصال SSH عند إعادة التشغيل — هذا طبيعي. انتظر دقيقة ثم أعد الاتصال بالأمر نفسه. سنعود لاحقًا لضبط التحديثات التلقائية كي لا تكرّر هذه الخطوة يدويًا كل مرة.

كيف تُنشئ مستخدمًا عاديًا بصلاحيات sudo؟

العمل اليومي بحساب root خطر: أي خطأ مطبعي بسيط قد يدمّر النظام، وأي ثغرة في برنامج تشغّله ترث صلاحيات root الكاملة. الممارسة الصحيحة هي إنشاء مستخدم عادي (non-root) تعمل به دائمًا، وترفع صلاحياته مؤقّتًا عبر sudo فقط عند الحاجة. أنشئ المستخدم:

adduser ahmed

سيطلب منك الأمر تعيين كلمة مرور للمستخدم الجديد وبعض المعلومات الاختيارية (يمكنك تركها فارغة بالضغط على Enter). استبدل ahmed بالاسم الذي تريده. الآن أضِف هذا المستخدم إلى مجموعة sudo ليتمكّن من تنفيذ الأوامر الإدارية:

usermod -aG sudo ahmed

الراية -aG تعني «أضِف (a) إلى المجموعة (G) المذكورة» دون إزالته من مجموعاته الأخرى — لا تنسَ حرف a، لأن usermod -G وحده سيستبدل كل مجموعات المستخدم. على AlmaLinux، المجموعة المكافئة اسمها wheel:

usermod -aG wheel ahmed

تحقّق من نجاح العملية بالتبديل إلى المستخدم الجديد وتجربة أمر بصلاحية sudo:

su - ahmed
sudo whoami

إن أعاد الأمر الأخير root بعد إدخال كلمة مرور المستخدم، فالصلاحيات تعمل. من الآن فصاعدًا اعمل بهذا الحساب، واستخدم sudo قبل أي أمر يحتاج صلاحيات إدارية.

لماذا كل هذا التعقيد بدل العمل المباشر بـ root؟ لأن مبدأ أقل صلاحية ممكنة (Least Privilege) هو حجر أساس الأمان. عندما تعمل بحساب عادي، يبقى النظام محميًا حتى لو ارتكبت خطأ، لأن الأوامر الخطرة تتطلّب sudo صريحًا يجعلك تتوقّف لحظة وتفكّر. الأهمّ من ذلك: أي ثغرة في برنامج تشغّله بحسابك العادي تبقى محصورة بصلاحيات ذلك الحساب المحدودة، بينما لو شغّلته بـ root لورثت الثغرة مفاتيح المملكة كاملةً. هذا الفصل البسيط بين حساب العمل وحساب الصلاحيات الكاملة يُحبط فئة واسعة من الهجمات وأخطاء التشغيل دفعةً واحدة، وهو السبب في أن كل دليل تأمين جادّ يبدأ بهذه الخطوة بالذات.

تحتاج موارد مخصّصة وتحكّمًا كاملًا؟

خطط VPS من wpressly بموارد مضمونة وصلاحية root، مُدارة وغير مُدارة، مع دعم عربي للإعداد والتأمين من اليوم الأول.

استعرض خطط VPS

كيف تُعدّ مفاتيح SSH وتُعطّل كلمة المرور؟

كلمات المرور قابلة للتخمين والكسر بالقوة الغاشمة (brute force)، أمّا مفاتيح SSH فهي زوج تشفيري شبه مستحيل كسره: مفتاح خاص يبقى على جهازك، ومفتاح عام تضعه على الخادم. الخطوة الأقوى في تأمين أي VPS هي الاعتماد على المفاتيح وحدها وتعطيل كلمة المرور تمامًا.

على جهازك المحلّي (لا على الخادم)، أنشئ زوج المفاتيح إن لم يكن لديك واحد:

ssh-keygen -t ed25519 -C "your_email@example.com"

نوع ed25519 حديث وأكثر أمانًا وأسرع من rsa القديم. سيسألك الأمر عن مكان الحفظ (اضغط Enter للمكان الافتراضي ~/.ssh/id_ed25519) وعن عبارة مرور (passphrase) اختيارية تحمي المفتاح الخاص — يُنصح بتعيينها بشدّة. الآن انسخ مفتاحك العام إلى الخادم. أسهل طريقة:

ssh-copy-id ahmed@203.0.113.10

إن لم يتوفّر ssh-copy-id (كما على بعض أنظمة ويندوز)، يمكنك إضافة المفتاح يدويًا. على الخادم، تحت حساب المستخدم الجديد:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

الصق محتوى مفتاحك العام (محتوى ملف ~/.ssh/id_ed25519.pub من جهازك) في سطر واحد، ثم احفظ. صحّح الصلاحيات — هذه نقطة فشل شائعة جدًا:

chmod 600 ~/.ssh/authorized_keys

اختبر الآن الدخول بالمفتاح من جهازك: ssh ahmed@203.0.113.10 يجب أن يدخلك دون طلب كلمة مرور (أو يطلب عبارة مرور المفتاح فقط). لا تكمل الخطوة التالية قبل أن تتأكّد أن الدخول بالمفتاح يعمل، وإلّا قد تُغلق على نفسك الباب.

بعد التأكّد، عطّل دخول root ودخول كلمة المرور. افتح ملف إعدادات SSH على الخادم:

sudo nano /etc/ssh/sshd_config

عدّل (أو أضف) الأسطر التالية:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

احفظ، ثم أعد تشغيل خدمة SSH ليسري المفعول:

sudo systemctl restart ssh

على بعض الأنظمة اسم الخدمة sshd بدل ssh — إن فشل الأمر جرّب sudo systemctl restart sshd. مهم: أبقِ جلستك الحالية مفتوحة، وافتح نافذة طرفية جديدة لاختبار الدخول من جديد. إن نجح الدخول بالمفتاح وفشل بكلمة المرور، فقد نجحت. هكذا أغلقت أخطر بابين على الخادم دفعةً واحدة.

كيف تضبط جدار الحماية UFW؟

الخادم المتّصل بالإنترنت يتعرّض لآلاف محاولات الفحص يوميًا. جدار الحماية يُغلق كل المنافذ افتراضيًا ويفتح ما تحتاجه أنت فقط. على Ubuntu/Debian، الأداة المبسّطة هي UFW (Uncomplicated Firewall). ثبّتها إن لم تكن موجودة:

sudo apt install ufw -y

قبل تفعيل الجدار، اسمح بـ SSH أولًا — هذه أهم خطوة على الإطلاق، فنسيانها يعني قطع نفسك عن الخادم فور التفعيل:

sudo ufw allow OpenSSH

ثم افتح منفذي الويب (80 للـHTTP و443 للـHTTPS) إذا كنت ستشغّل موقعًا:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

الآن فعّل الجدار وتحقّق من حالته:

sudo ufw enable
sudo ufw status verbose

سيطلب تأكيدًا (لأن التفعيل قد يقطع الاتصالات) — اكتب y. إن رأيت OpenSSH و80 و443 في قائمة ALLOW، فأنت بأمان. على AlmaLinux، الأداة المكافئة هي firewalld:

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

القاعدة الذهبية: افتح أقل عدد ممكن من المنافذ. قاعدة البيانات مثلًا يجب أن تتصل بها التطبيقات محلّيًا عبر localhost، فلا حاجة لفتح المنفذ 3306 للخارج إطلاقًا.

تذكّر أنّ جدار UFW الذي تضبطه يعمل على مستوى نظام التشغيل داخل الخادم، وقد يضيف مزوّدك طبقة جدار حماية سحابية (Cloud Firewall) أعلى منه تُدار من لوحة التحكم. الطبقتان مستقلّتان: إن حجبت إحداهما منفذًا، يُحجب فعليًا حتى لو فتحته الأخرى. عند تشخيص مشكلة وصول، تحقّق من كليهما. للتعديل على قاعدة في UFW، أدرج القواعد المرقّمة ثم احذف بالرقم:

sudo ufw status numbered
sudo ufw delete 3

ولإزالة قاعدة بصيغتها الأصلية مباشرةً، استخدم sudo ufw delete allow 80/tcp. حافظ على قائمة قواعد نظيفة ومفهومة؛ كل قاعدة زائدة هي باب نسيت لماذا فتحته.

كيف تثبّت ستاك الويب (Nginx + PHP + قاعدة بيانات)؟

«ستاك الويب» هو مجموعة البرمجيات التي تستقبل طلبات المتصفّحات وتنفّذ الكود وتُخزّن البيانات. الستاك الأشهر اليوم هو LEMP: Linux + (E)Nginx + MariaDB/MySQL + PHP. اختصار LEMP يستخدم E لأن Nginx يُنطق «إنجن إكس». لنثبّت مكوّناته واحدًا تلو الآخر.

1) ثبّت Nginx:

sudo apt install nginx -y
sudo systemctl enable --now nginx

الأمر enable --now يُشغّل الخدمة فورًا ويجعلها تبدأ تلقائيًا مع كل إقلاع. افتح متصفّحك على http://203.0.113.10 — يجب أن ترى صفحة الترحيب الافتراضية لـ Nginx، دليلًا على أن الخادم يستقبل الطلبات.

2) ثبّت قاعدة البيانات MariaDB وأمّنها:

sudo apt install mariadb-server -y
sudo systemctl enable --now mariadb
sudo mysql_secure_installation

سكربت mysql_secure_installation تفاعلي ويأخذك عبر خطوات تأمين أساسية: تعيين كلمة مرور لجذر قاعدة البيانات، إزالة المستخدمين المجهولين، منع دخول root عن بُعد، وحذف قاعدة الاختبار. أجب بـ Y على كل أسئلة التأمين.

3) ثبّت PHP وملحقاته الشائعة:

sudo apt install php-fpm php-mysql php-cli php-curl php-gd php-mbstring php-xml php-zip -y

هذه الملحقات (php-mysql للاتصال بقاعدة البيانات، php-gd لمعالجة الصور، وغيرها) ضرورية لتطبيقات مثل ووردبريس. تحقّق من تشغيل خدمة PHP-FPM:

sudo systemctl status php-fpm

(قد يحمل اسم الخدمة رقم الإصدار مثل php8.x-fpm — استخدم systemctl status php*-fpm إن لم تعرف الرقم). بهذا أصبح لديك ستاك ويب كامل: Nginx يستقبل الطلبات، يمرّر طلبات PHP إلى PHP-FPM، وقاعدة MariaDB جاهزة لتخزين البيانات.

تحتاج موارد مخصّصة وتحكّمًا كاملًا؟

خطط VPS من wpressly بموارد مضمونة وصلاحية root، مُدارة وغير مُدارة، مع دعم عربي للإعداد والتأمين من اليوم الأول.

استعرض خطط VPS

كيف تربط الدومين وتُصدر شهادة SSL؟

موقع يُوصَل عبر IP خام لا يصلح للجمهور. تحتاج دومينًا يشير إلى خادمك، ثم شهادة SSL لتشفير الاتصال (https). الربط يتم عبر سجلّ A في إعدادات DNS لدومينك:

أضِف سجلّ A يشير من دومينك إلى IP الخادم من لوحة مسجّل الدومين أو مزوّد DNS. قد يستغرق انتشار التغيير (DNS propagation) من دقائق إلى ساعات. لفهم أنواع السجلات بعمق، راجع شرح سجلّات DNS. تحقّق من أن الدومين يشير للخادم:

dig +short example.com

عندما يُرجع الأمر عنوان IP خادمك، أنت جاهز لإصدار SSL. سنستخدم Certbot مع Let's Encrypt للحصول على شهادة مجانية وتجديد تلقائي:

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d example.com -d www.example.com

سيطلب Certbot بريدك الإلكتروني وموافقتك على الشروط، ثم يتحقّق من ملكيتك للدومين، يصدر الشهادة، ويُعدّل إعدادات Nginx تلقائيًا لتحويل كل الزيارات إلى https. اختر خيار إعادة التوجيه (redirect) عند السؤال. تتجدّد الشهادة آليًا، ويمكنك اختبار التجديد بأمر:

sudo certbot renew --dry-run

للتعمّق في خيارات الشهادات وإعدادها، راجع تثبيت SSL وتفعيل HTTPS. بهذا أصبح موقعك يعمل خلف اتصال مشفّر بقفل أخضر في المتصفّح.

كيف تُجهّز النسخ الاحتياطي واللقطات؟

النسخ الاحتياطي ليس رفاهية — هو شبكة الأمان التي تنقذك من خطأ مدمّر، أو هجوم، أو فشل عتاد. لا تؤجّله أبدًا إلى ما بعد وقوع الكارثة. هناك طبقات متعدّدة للنسخ، وكلٌّ منها يحميك من نوع مختلف من الفشل:

اللقطات (Snapshots): يوفّرها معظم مزوّدي VPS من لوحة التحكم بنقرة واحدة. اللقطة هي صورة كاملة للقرص في لحظة معيّنة، تستعيد الخادم بأكمله إلى تلك اللحظة. ممتازة قبل أي تغيير كبير (ترقية، تثبيت مخاطر)، لكنها ثقيلة وتُحفظ غالبًا على البنية نفسها — فلا تكفي وحدها.

نسخ الملفات وقاعدة البيانات: نسخ منتظمة وأخفّ لمحتواك. لنسخ مجلّد الموقع:

sudo tar -czf /backups/site-$(date +%F).tar.gz /var/www/example.com

ولنسخ قاعدة البيانات:

mysqldump -u root -p mydatabase > /backups/db-$(date +%F).sql

النسخ خارج الخادم (Off-site): القاعدة الذهبية «3-2-1»: ثلاث نسخ، على وسيطين مختلفين، واحدة منها خارج الموقع. انسخ ملفاتك إلى تخزين بعيد (S3 أو R2 أو خادم آخر) عبر أدوات مثل rsync أو rclone:

rsync -avz /backups/ user@backup-server:/remote-backups/

أتمتة النسخ عبر cron هي الخطوة التي تحوّل النسخ من نيّة إلى عادة. لتشغيل نسخة يومية الساعة 3 فجرًا، عدّل جدول cron:

crontab -e

وأضف سطرًا مثل:

0 3 * * * /home/ahmed/backup.sh

حيث backup.sh سكربت يجمع أوامر النسخ السابقة. لا تنسَ اختبار الاستعادة فعليًا بين الحين والآخر — نسخة احتياطية لم تختبر استعادتها ليست نسخة، بل وهم.

كيف تراقب الخادم وتقرأ سجلّاته؟

بعد أن يعمل الخادم، تحتاج لرؤية ما يجري داخله: استهلاك الموارد، والأخطاء، والسلوك غير المعتاد. أبسط أداة لمراقبة الموارد لحظيًا هي htop:

sudo apt install htop -y
htop

تعرض htop واجهة حيّة باستهلاك المعالج والذاكرة وقائمة العمليات النشطة، فترى فورًا أي عملية تلتهم الموارد. اضغط q للخروج. لمراقبة مساحة القرص:

df -h

أمّا السجلّات (Logs) فهي عين الخادم على المشاكل. أهمها:

لمتابعة سجل حيًّا أثناء حدوث المشكلة:

sudo tail -f /var/log/nginx/error.log

ولمراجعة سجلّات خدمة معيّنة عبر systemd:

sudo journalctl -u nginx --since "1 hour ago"

مراقبة auth.log بانتظام تكشف لك حجم محاولات الاختراق الآلية — وهو ما يقودنا إلى طبقة التأمين الإضافية.

ما التأمين الإضافي الذي يستحق العناء؟

أمّنت SSH والجدار، لكن هناك طبقتان إضافيتان ترفعان أمانك بفارق كبير مقابل جهد بسيط:

1) Fail2ban — الحارس ضد القوة الغاشمة: يراقب السجلّات ويحظر تلقائيًا أي IP يكرّر محاولات دخول فاشلة. ثبّته وفعّله:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

يأتي بإعداد افتراضي معقول يحمي SSH فورًا. لمراجعة حالته:

sudo fail2ban-client status sshd

2) التحديثات الأمنية التلقائية: كي لا تعتمد على ذاكرتك لتحديث النظام، فعّل التحديثات الأمنية غير المراقَبة:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

هذا يثبّت تلقائيًا التحديثات الأمنية الحرجة فور صدورها، فيُغلق الثغرات قبل أن تُستغلّ.

إن كنت ستشغّل لوحة تحكم مثل cPanel فوق الخادم، فلها اعتباراتها الأمنية الخاصّة المشروحة في تأمين cPanel. هذه الطبقات مجتمعةً تنقل خادمك من «مكشوف» إلى «صلب» دون ساعات من العمل.

أخطاء شائعة في إعداد أول VPS

كثير من المبتدئين يقعون في الأخطاء نفسها. معرفتها مسبقًا توفّر عليك ساعات من الإحباط:

• العمل الدائم بحساب root: أخطر عادة. خطأ مطبعي واحد (مثل rm -rf / بدل مسار محدّد) قد يمسح النظام. اعمل دائمًا بمستخدم non-root وارفع الصلاحية بـ sudo عند الحاجة فقط.
• تفعيل UFW قبل السماح بـ SSH: يقطعك عن الخادم فورًا. اسمح بـ OpenSSH قبل ufw enable دائمًا.
• تعطيل كلمة المرور قبل اختبار المفتاح: إن أوقفت PasswordAuthentication ولم يكن مفتاحك يعمل، تُغلق على نفسك. اختبر دخول المفتاح في نافذة جديدة قبل تعطيل كلمة المرور.
• صلاحيات خاطئة لملفات SSH: مجلّد ~/.ssh يجب أن يكون 700 وملف authorized_keys يجب أن يكون 600، وإلّا يرفض SSH المفتاح بصمت.
• فتح منافذ غير ضرورية: فتح منفذ قاعدة البيانات 3306 للخارج خطأ أمني كبير. أبقِ كل ما لا تحتاجه مغلقًا.
• إهمال النسخ الاحتياطي حتى الكارثة: «سأجهّزه لاحقًا» يتحوّل إلى «فقدت كل شيء». جهّزه من اليوم الأول.
• نسيان فتح المنفذ 80 قبل Certbot: يفشل التحقّق من الدومين. تأكّد أن 80 و443 مفتوحان قبل إصدار SSL.

استكشاف الأخطاء وإصلاحها

حتى مع الحذر، ستواجه مشاكل. إليك الأكثر شيوعًا وحلولها:

أُغلقت على نفسي عن SSH (لا أستطيع الدخول): إن عطّلت كلمة المرور ولم يعمل المفتاح، أو غيّرت المنفذ ونسيت فتحه، فالحلّ هو الكونسول الطارئ (Console / VNC) من لوحة المزوّد. كل مزوّد VPS جادّ يوفّر وصولًا مباشرًا للخادم عبر المتصفّح يتجاوز SSH تمامًا. ادخل منه كـ root، وأصلح الإعداد (أعد تفعيل كلمة المرور مؤقّتًا، أو أصلح صلاحيات authorized_keys، أو افتح المنفذ في UFW).

جدار الحماية حظرني: إن نفّذت ufw enable دون السماح بـ SSH، استخدم الكونسول الطارئ، ثم نفّذ sudo ufw allow OpenSSH ثم sudo ufw reload. أو عطّل الجدار مؤقّتًا بـ sudo ufw disable لاستعادة الوصول ثم أعد ضبطه بشكل صحيح.

مشاكل الصلاحيات (Permission denied): عند ظهور Permission denied (publickey) تحقّق من صلاحيات ~/.ssh (700) وauthorized_keys (600)، ومن أن الملف يحتوي مفتاحك العام الصحيح. لمشاكل ملفات الموقع، تأكّد أن المالك هو مستخدم خادم الويب (غالبًا www-data على Ubuntu): sudo chown -R www-data:www-data /var/www/example.com.

خدمة لا تبدأ (service won't start): عند فشل بدء خدمة (Nginx مثلًا)، اقرأ السبب الدقيق:

sudo systemctl status nginx
sudo journalctl -u nginx --no-pager -n 50

أكثر سبب شائع لفشل Nginx هو خطأ في ملف الإعداد أو تعارض على المنفذ 80. اختبر صحّة إعداد Nginx قبل إعادة التشغيل:

sudo nginx -t

إن أبلغ عن خطأ، سيشير إلى الملف والسطر بالضبط، فأصلحه ثم sudo systemctl restart nginx. إن كان المنفذ مشغولًا، اكتشف العملية التي تحتلّه عبر sudo ss -tlnp | grep :80.

نصائح خبير: اضبط منفذ SSH مخصّصًا (غير 22) لتقليل الضوضاء؛ احتفظ دائمًا بنافذة SSH ثانية مفتوحة عند تعديل إعدادات SSH أو الجدار؛ خذ لقطة (snapshot) قبل أي تغيير كبير؛ وثّق كل ما تغيّره في ملف ملاحظات على جهازك؛ ولا تثبّت إلّا ما تحتاجه فعلًا — كل خدمة إضافية سطح هجوم جديد.

تحتاج موارد مخصّصة وتحكّمًا كاملًا؟

خطط VPS من wpressly بموارد مضمونة وصلاحية root، مُدارة وغير مُدارة، مع دعم عربي للإعداد والتأمين من اليوم الأول.

استعرض خطط VPS

الخلاصة

إعداد أول VPS يبدو مهيبًا، لكنه في جوهره سلسلة خطوات منطقية متتابعة: اتصل عبر SSH، حدّث النظام، أنشئ مستخدمًا non-root، أمّن الدخول بالمفاتيح، أغلق الأبواب الخطرة، فعّل جدار الحماية، ثبّت الستاك، اربط الدومين، أصدر SSL، ثم جهّز النسخ الاحتياطي والمراقبة والتأمين الإضافي. كل خطوة تبني على ما قبلها، وحالما تنفّذها مرة تصبح طبيعةً ثانية. القاعدة الجامعة التي تنقذك دائمًا: أمّن أوّلًا، انسخ احتياطيًا دائمًا، وافتح أقل قدر ممكن. بهذا تملك خادمًا سريعًا وآمنًا تحت سيطرتك الكاملة — وهذا بالضبط جوهر قوّة الـVPS.

الأسئلة الشائعة

هل أحتاج خبرة برمجية لإعداد VPS؟ لا تحتاج أن تكون مبرمجًا، لكنك تحتاج ارتياحًا مع سطر الأوامر واتّباع الخطوات بدقّة. هذا الدليل يوفّر الأوامر جاهزة. إن كنت تفضّل تجنّب سطر الأوامر تمامًا، ففكّر في VPS مُدار بلوحة تحكم، أو في الاستضافة المُدارة.

كم يستغرق إعداد أول VPS؟ لأول مرة، توقّع ساعة إلى ساعتين بتأنٍّ. مع التكرار، ينخفض الوقت إلى 20–30 دقيقة. أتمتة الإعداد بسكربت لاحقًا تختصره إلى دقائق.

هل يجب فعلًا تعطيل دخول كلمة المرور؟ نعم بشدّة. كلمات المرور عرضة للكسر بالقوة الغاشمة، ومحاولات الاختراق الآلية على المنفذ 22 لا تتوقّف. مفاتيح SSH أقوى بمراحل، وتعطيل كلمة المرور يُغلق أوسع باب هجوم على الخادم.

ما الفرق بين Nginx وApache؟ كلاهما خادم ويب. Nginx أخفّ وأسرع في خدمة الملفات الثابتة والتعامل مع آلاف الاتصالات المتزامنة، ولهذا صار الأشهر للمواقع الحديثة. Apache أكثر مرونة في الإعداد لكل مجلّد (.htaccess). لمعظم المشاريع الجديدة، Nginx خيار ممتاز.

هل النسخ الاحتياطي عبر اللقطات يكفي؟ لا وحده. اللقطات سريعة للاستعادة لكنها تُحفظ غالبًا على بنية المزوّد نفسها، فتفشل إن فشلت البنية أو اختُرق حسابك. اتبع قاعدة 3-2-1: نسخ متعددة، على وسائط مختلفة، واحدة خارج الموقع.

ماذا أفعل إن أُغلقت على نفسي عن SSH؟ استخدم الكونسول الطارئ (Console/VNC) من لوحة المزوّد. يتجاوز SSH تمامًا ويمنحك وصولًا مباشرًا لإصلاح ما عطّلته — سواء إعداد SSH أو قاعدة جدار الحماية أو الصلاحيات.

هل أحتاج دومينًا قبل إعداد الخادم؟ لا للبدء — تستطيع إعداد الخادم وتثبيت الستاك والوصول إليه عبر IP. لكنك تحتاج دومينًا يشير للخادم عبر سجلّ A قبل إصدار شهادة SSL وإطلاق الموقع للجمهور.

ما الفرق بين VPS مُدار وغير مُدار في الإعداد؟ في غير المُدار، كل خطوات هذا الدليل عليك أنت. في المُدار، يتولّى المزوّد التأمين والتحديثات وغالبًا يرفق لوحة تحكم تختصر الإعداد اليدوي. غير المُدار أرخص وأكثر مرونة، والمُدار أسهل وأغلى.

كيف أعرف أن خادمي مؤمّن بما يكفي؟ المؤشّرات الأساسية: لا دخول root مباشر، لا دخول بكلمة مرور (مفاتيح فقط)، جدار حماية يفتح المنافذ الضرورية فقط، Fail2ban يعمل، تحديثات أمنية تلقائية مفعّلة، ونسخ احتياطي خارجي منتظم. متى توفّرت هذه، تكون قد تجاوزت معظم المخاطر الشائعة.

هل يمكنني ترقية حجم الخادم لاحقًا؟ نعم، وهذه إحدى أكبر مزايا الـVPS. معظم المزوّدين يتيحون ترقية المعالج والذاكرة والتخزين بنقرات قليلة وبأقل توقّف ممكن، فابدأ بحجم متواضع وارتقِ مع نمو حاجتك بدل الدفع الزائد مبكرًا.