إضافة وإدارة النطاقات والاستضافة (Domains & Hosting)
إضافة نطاق (Domain) جديد في Plesk هي العملية الأكثر تكراراً، ولكن الفهم العميق لخياراتها يفصل بين المبتدئ والمحترف.
الفرق المعماري بين خيارات الإضافة
عند إضافة نطاق في Plesk، ستواجه 3 أنواع:- Domain (نطاق أساسي): ينشئ مساحة عزل جديدة بالكامل (Subscription جديدة أو مجلد رئيسي جديد داخل نفس الاشتراك)، ويكون له حساب FTP مستقل و Document Root خاص.
- Subdomain (نطاق فرعي): مثل
blog.domain.com، يعيش داخل المساحة الأصلية للنطاق الأب، ويشترك معه في نفس الموارد والحدود (Limits)، لكن مسار ملفاته (Document Root) يكون منفصلاً. - Domain Alias (الاسم المستعار): مثل
domain.netالذي يوجه لـdomain.com. لا يمتلك مسار ملفات خاص، بل يعرض نفس محتوى الموقع الأصلي بالضبط ويشترك معه في نفس صندوق البريد الإلكتروني. هذا ممتاز لحماية علامتك التجارية بجميع الامتدادات.
الـ Document Root والتأمين ضد الاختراق
بشكل افتراضي، مسار الملفات لموقع جديد في Plesk يكون `httpdocs`. أي شيء تضعه في هذا المجلد يمكن للإنترنت رؤيته.
سيناريو الخبراء لتطبيقات Laravel:
مشاريع Laravel تحتوي على ملف .env حساس جداً يحوي كلمات مرور قواعد البيانات. إذا وضعته داخل httpdocs، فأنت تخاطر بتسريبه.
الحل الصحيح في Plesk:
1. قم برفع المشروع كاملاً في المجلد الأب (خارج httpdocs).
2. اذهب إلى `Hosting Settings` للنطاق، وقم بتعديل حقل الـ Document Root ليصبح httpdocs/public أو my-laravel/public.
بهذه الطريقة، سيرفر الويب يرى مجلد public فقط كجذر للموقع، وملفات المشروع وملف .env تبقى بأمان في الخلفية ولا يمكن الوصول إليها عبر المتصفح إطلاقاً.
إدارة نظام أسماء النطاقات (DNS Settings) بشكل متقدم
Plesk ليس مجرد سيرفر ويب، بل هو سيرفر DNS كامل يعتمد على BIND9 تحت الغطاء. عندما تضيف نطاقاً، يقوم Plesk أوتوماتيكياً بإنشاء "منطقة DNS" (DNS Zone) كاملة تحتوي على السجلات (A, MX, TXT).
توجيهات يجب الانتباه لها:
- إذا كنت تستخدم Cloudflare كمدير للـ DNS، فإن خادم الـ DNS المدمج في Plesk يصبح "شبحاً" (لا تأثير له على الإنترنت، لأنه ليس الـ Name Server المعتمد للنطاق). في هذه الحالة، أي تعديل على سجلات الـ DNS يجب أن تقوم به في لوحة Cloudflare وليس من داخل Plesk.
- لمنع التضارب وإراحة المعالج، يُنصح بإيقاف تشغيل خدمة الـ DNS المحلية (Disable DNS Service) للنطاقات المربوطة بـ Cloudflare عبر زر
Turn Offفي إعدادات DNS للنطاق في Plesk.
السيطرة المطلقة على النطاقات وتوجيهات DNS المعقدة
في بيئات الاستضافة المتقدمة، إدارة النطاقات تتعدى مجرد كتابة الـ IP. سنتعرف الآن على توجيهات الـ Wildcard والـ SEO Redirects.
إعداد الـ Wildcard Subdomains
لنفترض أنك تمتلك نظاماً يمنح كل مستخدم مدونة فرعية خاصة به تلقائياً (مثل ahmed.domain.com و sara.domain.com). لا يمكنك إضافة كل نطاق فرعي يدوياً في Plesk! الحل هو الـ Wildcard.
- أضف Subdomain جديد باسم
*(نجمة). - سيقوم Plesk تلقائياً بإضافة سجل
*.domain.comفي جدول الـ DNS ليوجه للـ IP. - الآن سيتم توجيه أي نطاق فرعي غير موجود (عشوائي) إلى المجلد الذي حددته، وهناك يقوم سكربت الـ PHP الخاص بك (Laravel مثلاً) بتحليل الـ URL ومعرفة اسم المستخدم المطلوب وعرض بياناته.
إعادة التوجيه الدائمة 301 (SEO Friendly Redirects)
عند نقل موقع أو تغيير النطاق من old-domain.com إلى new-domain.com، من الكارثي استخدام الـ Domain Alias القياسي دون إعداد التوجيه، فهذا يسبب مشكلة (Duplicate Content) في محركات البحث مثل جوجل.
في Plesk، قم بإضافة نطاق جديد (old-domain.com)، وغير نوع الاستضافة (Hosting Type) من Website Hosting إلى Forwarding. اختر نوع التوجيه (Permanent 301) ليخبر محركات البحث أن الموقع انتقل رسمياً للنطاق الجديد.
تأمين مسار الملفات ضد حقن الملفات الخبيثة (Web Shells)
إذا اخترق أحد الهاكرز سكربت الرفع (Upload Form) في موقعك ورفع ملف shell.php داخل مجلد الصور uploads/، فسيتمكن من تشغيله!
في Plesk، يجب عليك عزل مجلدات الرفع لمنع تنفيذ أكواد PHP بداخلها.
اذهب لـ Apache & nginx Settings للنطاق، وفي صندوق Additional nginx directives أضف:
location ~ ^/uploads/.*\.php$ {
deny all;
}
الآن، حتى لو رفع المخترق ألف ملف PHP خبيث في مجلد uploads وحاول الدخول إليه، Nginx سيعطيه الخطأ 403 Forbidden قبل أن يصل إلى محرك PHP أصلاً!
[توسعة المحترفين] سيناريوهات النطاقات المعقدة وإدارة الـ DNS (Advanced Domain Topologies)
الإنترنت الحديث لم يعد يعتمد على نطاق واحد لكل موقع. الشركات الكبيرة تمتلك عشرات النطاقات لتوجيهها لنفس التطبيق.
التعامل مع الـ CORS والـ Cross-Domain Requests
إذا كان لديك تطبيق واجهة أمامية (React) يعمل على app.domain.com، وواجهة خلفية (API) تعمل على api.domain.com، المتصفح سيحجب الطلبات بينهما لأسباب أمنية (CORS Policy).
بدلاً من محاولة حل المشكلة بـ PHP، يمكنك حلها بكفاءة مطلقة على مستوى Nginx في Plesk.
في إعدادات `Apache & nginx Settings` للنطاق `api.domain.com`، أضف التالي:
add_header 'Access-Control-Allow-Origin' 'https://app.domain.com' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE' always;
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type, X-Requested-With' always;
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' 'https://app.domain.com' always;
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain; charset=utf-8';
add_header 'Content-Length' 0;
return 204;
}
هذا الكود هو "الرصاصة الفضية" (Silver Bullet) لمشاكل الـ API، وسيجعل تطبيقاتك تتصل ببعضها بسلاسة وبأداء خارق.
استراتيجية הـ CDN وربط Cloudflare الصحيح
إذا ربطت Cloudflare بموقعك، سيرفر Plesk سيرى أن كل الزوار يمتلكون IP واحد (وهو הـ IP الخاص بسيرفرات Cloudflare). هذا يدمر الإحصائيات (AWStats) ويجعل أدوات الحماية (Fail2Ban) تحظر Cloudflare نفسه بدلاً من المخترق!
لإصلاح هذا، يجب تفعيل وحدة mod_remoteip في Apache وتكوين Nginx ليرى הـ IP الحقيقي:
في Plesk (Tools & Settings > Apache Web Server)، تأكد من تفعيل `remoteip`.
ثم عبر الـ CLI نفذ هذا السكربت لإخبار السيرفر بعناوين Cloudflare الموثوقة:
# تحميل قائمة عناوين Cloudflare وتمريرها لـ Nginx
echo "set_real_ip_from 173.245.48.0/20;" > /etc/nginx/conf.d/cloudflare.conf
echo "set_real_ip_from 103.21.244.0/22;" >> /etc/nginx/conf.d/cloudflare.conf
# (أكمل بقية قائمة הـ IP الخاصة بكلودفلير)
echo "real_ip_header CF-Connecting-IP;" >> /etc/nginx/conf.d/cloudflare.conf
service nginx reload
الآن، سيرفرك سيسجل הـ IP الحقيقي لكل زائر بدقة!
💬 التعليقات
0 تعليقات