المعيار الحقيقي: من يطبّق التصحيحات
سؤال «أيّهما أقوى؟» يقود في الغالب إلى الـ VPS. أما السؤال المفيد للوكالة فهو آخر: حين يُعلن عن ثغرة حرجة مساء الثلاثاء، من يطبّق التصحيح على خادم هذا العميل؟ في استضافة cPanel المشتركة يتولى المستضيف ذلك. فالنواة ومفسّر PHP وجدار حماية الخادم ومراقبة الجهاز ليست من مسؤوليتك، وتحتفظ أنت بعلاقتك بالعميل. أما على VPS فيصبح كل ذلك ضمن نطاقك منذ الدقيقة الأولى، بما في ذلك عطلات نهاية الأسبوع. وهذا ليس عيبًا في الـ VPS، بل ثمن الحرية التي يمنحها: صلاحيات root وخدمات دائمة وبنية مخصصة. يقابل الجدول التالي كل معيار بالجهة التي تتولاه، لأن هذا السطر، أكثر بكثير من أرقام الذاكرة، هو ما يغيّر حجم عملك. نحن هنا نفكر بالمسؤوليات لا بالأداء الخام.
المشتركة وVPS، معيارًا بمعيار
مرّر الجدول أفقيًا
| المعيار | الاستضافة المشتركة (من يتولى الأمر) | VPS (من يتولى الأمر) |
|---|---|---|
| صلاحيات root | لا، حسابات cPanel محدودة: المستضيف | نعم، كاملة: الوكالة |
| العزل بين المواقع | حسابات cPanel معزولة عن بعضها: المستضيف | VPS لكل عميل، أو نطاق تأثير مشترك إذا تعايشت عدة مواقع: الوكالة |
| تحديثات النواة | تُطبَّق على الجهاز المشترك: المستضيف | تحديث ثم إعادة تشغيل مخططان: الوكالة |
| تحديثات PHP | تصحيحات تُطبَّق على الخادم: المستضيف | حزم تُحدَّث وتُختبر: الوكالة |
| جدار الحماية | جدار حماية الخادم: المستضيف | يُضبط ويُبقى محدَّثًا: الوكالة |
| النسخ الاحتياطية | حسب الخطة، أسبوعية في الفئة الدنيا ويومية في Pro وAgency: المستضيف | استراتيجية تُحدَّد وتُختبر: الوكالة |
| المراقبة | الجهاز يراقبه المستضيف والموقع تراقبه أنت: مشتركة | التوافر والقرص والشهادات والخدمات: الوكالة |
| التوسّع | حدود لكل حساب ثم خطة أعلى أو VPS: المستضيف والوكالة | موارد تُعدَّل عند الطلب وبنية بيدك: الوكالة |
PHP2Shell: تصحيح PHP في الاستضافة المشتركة وعلى VPS
في 21 أكتوبر 2026 نشر مشروع PHP نشرة الثغرة CVE-2026-109619 المعروفة باسم PHP2Shell، وهي تنفيذ شيفرة عن بُعد مصنَّف حرجًا، صُحّح في إصدارات PHP 8.2.35 و8.3.36 و8.4.27 و8.5.12. في الاستضافة المشتركة يطبّق المستضيف التصحيح؛ أما على VPS فعليك تحديث PHP على كل جهاز ثم إعادة تحميل PHP-FPM. ويفصّل المقال المخصص لـ PHP2Shell الجرد وسبل التخفيف.
Fragnesia: حين تكون النواة نواة الوكالة
Fragnesia (CVE-2026-46300) ثغرة في نواة Linux تتيح رفعًا محليًا للصلاحيات حتى root. في الاستضافة المشتركة يخطط المستضيف لتحديث النواة؛ أما على VPS فالنواة نواة الوكالة، وبالتالي نافذة صيانتها وإعادة تشغيلها، لأن الـ VPS الذي لا يُعاد تشغيله يحتفظ بالنواة القديمة في الذاكرة. تحقق من النواة العاملة بالأمر uname -r. ويفصّل المقال المخصص لـ Fragnesia الثغرة وسبل التخفيف.
العزل والنسخ الاحتياطية: ما يحمي عميلًا من الآخرين
في الاستضافة المشتركة يعيش كل موقع في حساب cPanel معزول: الموقع المخترَق لا يمنح، من حيث المبدأ، وصولًا إلى ملفات الجار. أما على VPS فالعزل يتوقف على طريقة تقسيمك. VPS لكل عميل يرسم حدًا واضحًا، لكنه يضاعف عدد الأجهزة الواجب تحديثها. وعدة مواقع مختلطة على VPS واحد تخفّض الفاتورة، لكنها تتشارك نطاق تأثير واحدًا: إضافة ضعيفة في موقع تكشف بقية المواقع، وسرقة صلاحيات root تأخذها جميعًا. وبالنسبة إلى النسخ الاحتياطية، لا تعمّم. في الاستضافة المشتركة تتوقف الوتيرة على الخطة: أسبوعية في الفئة الدنيا ويومية في خطتي Pro وAgency. راجع بطاقة الخطة قبل أن تَعِد عميلًا بوتيرة استعادة. أما على VPS فلا شيء يُقرَّر نيابة عنك: استراتيجية النسخ ووجهتها خارج الجهاز وخصوصًا اختبار الاستعادة، كلها تحددها الوكالة وتتحقق منها. نسخة لم تُستعَد قط تبقى مجرد فرضية.
كم ساعة صيانة شهريًا لكل موقع
أرقام الجدول التالي ليست معيارًا مرجعيًا: إنها فرضيات هذا المقال، فاستبدلها بقياساتك الخاصة. وهي تفترض VPS Linux قياسيًا لكل عميل، يديره شخص كفء، مقابل موقع على حساب مشترك يدير المستضيف جهازه. يعطي المجموع رتبة الحجم: نحو 0.75 ساعة شهريًا لكل موقع في الاستضافة المشتركة، مقابل نحو 4.5 ساعات شهريًا لكل VPS. ولاثني عشر عميلًا يعني ذلك 9 ساعات مقابل 54 ساعة شهريًا. قارن بأجرتك الساعية الداخلية: إذا تجاوز فارق الساعات، مقدَّرًا بهذه الأجرة، فارق السعر الشهري، لفترة فوترة متماثلة، بين 799 درهم/سنة و99 درهم/شهر، فإن الـ VPS يكلف أكثر من سعره المعلن. وتجميع عدة مواقع على VPS واحد يقسّم الساعات على المواقع، لكنه يوسّع نطاق التأثير. ويمكن لخيار إدارة VPS أن ينقل جزءًا من هذه الساعات إلى ServOrbit؛ تحقق من نطاقه في صفحة VPS. أما أدلة المدونة فتُقدَّم دون دعم.
فرضية المقال: ساعات الصيانة الشهرية
مرّر الجدول أفقيًا
| المهمة | مشتركة (لكل موقع) | VPS (لكل خادم) |
|---|---|---|
| النواة وإعادات التشغيل | 0 ساعة | 0.5 ساعة |
| PHP وحزم النظام | 0 ساعة | 1 ساعة |
| جدار الحماية والتحصين | 0 ساعة | 0.5 ساعة |
| النسخ الاحتياطية واختبار الاستعادة | 0.25 ساعة | 1 ساعة |
| المراقبة والتنبيهات | 0.25 ساعة | 0.75 ساعة |
| الحوادث والمناوبة | 0.25 ساعة | 0.75 ساعة |
| المجموع | 0.75 ساعة | 4.5 ساعات |
شبكة القرار: خمسة أسئلة بنعم أو لا
هل تتجاوز الزيارات حدود الخطة بشكل دائم؟
لا: تكفي الاستضافة المشتركة. نعم، بشكل مستمر وليس عند ذروة معزولة: انتقل إلى السؤال 2. الذروة العابرة تُعالج أولًا بالتخزين المؤقت وبخطة أعلى.
هل لدى العميل عدة مواقع أو خدمات ثقيلة؟
لا: ابقَ على الاستضافة المشتركة ما دامت حدود العمليات تكفي. نعم: يصبح الـ VPS مقبولًا، انتقل إلى السؤال 3.
هل تحتاج إلى root أو خدمات دائمة؟
لا: تبقى الاستضافة المشتركة الخيار الافتراضي. نعم، لخدمة خلفية أو طابور مهام أو محرك قاعدة بيانات محدد أو بنية غير قياسية: الـ VPS مبرَّر، انتقل إلى السؤال 4.
هل يجب عزل هذا العميل عن الآخرين؟
نعم، لبيانات حساسة أو متطلب تعاقدي: خطّط لـ VPS مخصص لهذا العميل. لا: عزل حسابات cPanel في الاستضافة المشتركة يكفي أصلًا.
هل تملك كفاءة الإدارة والمناوبة؟
لا: لا تفتح VPS دون إدارة مخططة، وابقَ على الاستضافة المشتركة أو ادرس خيار إدارة VPS. نعم: يُعتمد الـ VPS وتُدرج في ميزانيتك ساعات الجدول السابق.
الإشارات التي تبرّر تغيير النموذج
لا يُختار نموذج الاستضافة مرة واحدة وإلى الأبد. تُطلق عائلتان من الإشارات عملية الانتقال، في أي اتجاه. نحو الـ VPS تكون قيودًا تقنية متكررة: السقف نفسه يُبلغ كل شهر، وخدمة لا تسمح بها الاستضافة المشتركة. ونحو الاستضافة المشتركة يحدث العكس: الجهاز يستهلك وقتًا أكثر مما يعود به. دوّن تاريخ كل حادث مرتبط بالحدود أو بالإدارة وسببه. قاعدة عملية في هذا المقال: حادث واحد معزول عارض، وثلاثة حوادث في ربع سنة إشارة.
سبع إشارات للانتقال
- نحو VPS: عمليات أو ذاكرة محدودة — تعود أخطاء الحدود رغم تحسين الموقع، ويُبلغ سقف الخطة.
- نحو VPS: root أو خدمات دائمة — يتطلب المشروع خدمة خلفية أو عاملًا أو محرك بحث أو إصدارًا من النظام لا توفره الاستضافة المشتركة.
- نحو VPS: حمل مستمر — يبقى الحمل مرتفعًا عدة أسابيع، وليس فقط أثناء حملة عابرة.
- نحو VPS: جدار حماية أو بنية محددة — قاعدة شبكية أو وكيل عكسي أو بيئة تشغيل بعينها تصبح مطلبًا للعميل.
- نحو الاستضافة المشتركة: زيارات قليلة — يتسع الموقع بسهولة لخطة مشتركة ويبقى الـ VPS خاملًا معظم الوقت.
- نحو الاستضافة المشتركة: لا كفاءة إدارة متاحة — لا أحد في الفريق يستطيع تطبيق تصحيح للنواة أو لـ PHP خلال اليوم.
- نحو الاستضافة المشتركة: مناوبة تفوق القيمة — تتجاوز ساعات الصيانة ما يدفعه العميل مقابل الموقع.
الانتقال مع تقليل الانقطاع: ست خطوات
انسخ المصدر احتياطيًا
خذ نسخة كاملة من الملفات وقاعدة البيانات، ثم تحقق من استعادتها على جهاز اختبار قبل أن تلمس أي شيء.
خفّض TTL في DNS
قبل التحويل بـ 24 إلى 48 ساعة على الأقل، اخفض TTL للسجلات إلى 300 ثانية، ثم تحقق بالأمر
dig +short your-domain.com.جهّز الوجهة
ثبّت البنية على الـ VPS، أو أنشئ حساب cPanel، وانسخ الملفات وقاعدة البيانات، ثم أعد ضبط PHP والمهام المجدولة.
اختبر قبل التحويل
اختبر الوجهة دون المساس بـ DNS بالأمر
curl -I --resolve your-domain.com:443:IP_CIBLE https://your-domain.com/، ثم جرّب النماذج والدفع وإرسال البريد.حوّل
أوقف الكتابة على المصدر إن كان الموقع يستقبلها، وأعد نسخة نهائية من قاعدة البيانات، ثم غيّر سجل A. أبقِ TTL قصيرًا أثناء التحويل.
راقب وأغلق
راقب السجلات 48 ساعة، وأبقِ المصدر سليمًا بضعة أيام، ثم ارفع TTL مجددًا واحذف البيئة القديمة.
قاعدة ترجيح لمحفظة العملاء
ابدأ من الاستضافة المشتركة لكل موقع جديد لعميل، ولا تنتقل إلى VPS إلا عند إشارة مكتوبة: حد بُلغ أو حاجة إلى root أو متطلب عزل. احتفظ بجدول لكل عميل يضم النموذج وتاريخ آخر تحديث للنواة ولـ PHP وآخر استعادة مختبَرة. الـ VPS الذي لا يكون سطره محدَّثًا دَين تحمله بدلًا من العميل.
الوثائق الرسمية
نشرة أمان PHP2Shell (GitHub، مشروع PHP) : https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
صفحة Debian عن Fragnesia : https://security-tracker.debian.org/tracker/CVE-2026-46300
تغطية Security Affairs لثغرة Fragnesia : https://securityaffairs.com/192145/security/linux-kernel-bug-fragnesia-allows-local-root-access-attacks.html
إصدارات PHP المدعومة : https://www.php.net/supported-versions.php
