استضافة عدة مواقع باستخدام كتل خادم Nginx (المضيفات الافتراضية)

تعتبر كتل خادم Nginx طريقة لاستضافة عدة أسماء نطاقات أو مواقع ويب مع تكوينات منفصلة ضمن تثبيت واحد لـ Nginx. على سبيل المثال، يمكنك تعريف مجلدات جذر مختلفة وسجلات لوج وSSL وإعدادات PHP لمواقع مثل example.com وblog.example.com وsecond-site.com على نفس VPS. باختصار، الحل هو إنشاء مجلد منفصل لكل موقع، وتوجيه سجلات DNS الخاصة باسم النطاق إلى عنوان IP للخادم، وكتابة كتلة خادم منفصلة تحت /etc/nginx/sites-available، ثم ربطها بمجلد sites-enabled، واختبار التكوين وإعادة تحميل خدمة Nginx.

في هذا الدليل، سنعالج عملية استضافة عدة مواقع باستخدام كتل خادم Nginx بطريقة مناسبة للبيئة الإنتاجية. الهدف ليس فقط إنشاء هيكل يعمل، ولكن أيضًا بناء نظام يمكن إدارته وآمن وسريع وقابل للنسخ الاحتياطي وقابل للتوسع. سنشارك خطوات عملية خاصة بالوكالات والمطورين وأصحاب التجارة الإلكترونية والشركات التي تدير علامات تجارية متعددة، ومديري الأنظمة الذين يقومون بتشغيل مشاريع متعددة على خادم واحد. إذا لم يكن لديك خادم بعد، يمكنك الاطلاع على صفحات الخادم VPS لاختيار الموارد وتسجيل النطاق لإدارة أسماء النطاقات.

ما هي كتل خادم Nginx؟

تعتبر كتل خادم Nginx أجزاء من التكوين تحدد أي موقع ستوجه إليه طلبات HTTP أو HTTPS الواردة، وتعرف ككتلة خادم ضمن تكوين Nginx. تشبه مفهوم VirtualHost على جانب Apache. عندما يكتب زائر اسم نطاق في المتصفح، يقوم DNS بحل هذا الاسم إلى عنوان IP الخاص بالخادم. بعد ذلك، ينظر Nginx إلى رأس Host في الطلب ويقوم بتشغيل كتلة الخادم المطابقة لقيمة server_name.

بهذه الطريقة، يمكن استضافة العشرات من مواقع الويب المختلفة على نفس عنوان IP وعلى نفس الخادم المادي أو الافتراضي. من الممكن تحديد مجلد جذر منفصل وسجل وصول وسجل أخطاء وقاعدة توجيه وشهادة SSL وقاعدة أمان لكل موقع. على سبيل المثال، يمكنك الاحتفاظ بموقعك المؤسسي في /var/www/kurumsal/public، ومدونتك في /var/www/blog/public، وبيئة الاختبار الخاصة بك في /var/www/staging/public.

يعمل Nginx بكفاءة في هذا الهيكل لأنه يمكنه إدارة اتصالات متزامنة عالية باستهلاك منخفض للموارد بفضل معماريته المعتمدة على الأحداث. لذلك، يتم تفضيله في استضافة المواقع المشتركة وVPS والخوادم السحابية والبنى التحتية للتطبيقات ذات الحركة المرورية العالية. لضمان عمل استضافة عدة مواقع بشكل صحي، يجب التخطيط لكل التفاصيل بشكل صحيح، من أذونات الملفات إلى توجيه DNS، ومن إعداد SSL إلى تقسيم السجلات.

متى تستخدم كتل خادم Nginx؟

تستخدم كتل خادم Nginx بشكل خاص عندما تحتاج إلى إدارة وجودات ويب متعددة على نفس الخادم. قد تكون هذه أحيانًا موقعين مؤسسيين صغيرين، أو عشرات مشاريع العملاء أو نطاقات فرعية أو خدمات ميكروسيرفس. النقطة الحرجة هنا هي الفصل المنطقي بين كل مشروع وآخر.

• إذا كنت ترغب في نشر عدة أسماء نطاقات على نفس VPS.
• إذا كنت ترغب في توجيه النطاقات التي تحتوي على www وتلك التي لا تحتوي على www إلى عنوان واحد قنوني.
• إذا كنت ترغب في ربط النطاقات الفرعية بمجلدات أو تطبيقات مختلفة.
• إذا كنت ترغب في تحديد شهادة SSL وقاعدة أمان منفصلة لكل موقع.
• إذا كنت ترغب في متابعة مشاريع العملاء من خلال سجلات منفصلة.
• إذا كنت ترغب في تشغيل تطبيقات مختلفة مثل Laravel وWordPress وHTML الثابت وNode.js على نفس الخادم.

على سبيل المثال، من الممكن تقنيًا أن تقوم وكالة رقمية بنشر 8 مواقع مؤسسية ذات حركة مرور منخفضة على VPS واحد بسعة 4 جيجابايت RAM. ومع ذلك، يجب حساب حركة المرور واستهلاك القرص وعدد عمليات PHP وحمل قاعدة البيانات وتكرار النسخ الاحتياطي لكل موقع. إذا كانت المشاريع تتلقى حركة مرور كثيفة أو كانت عزل الموارد أمرًا حاسمًا، فإنه يجب اختيار VPS أقوى أو خادم سحابي أو حلول استضافة مُدارة. في هذه النقطة، يمكن مقارنة خيارات استضافة الويب واستضافة مؤسسية.

المتطلبات قبل البدء

سنفترض في هذا الدليل وجود خادم Linux مبني على Ubuntu أو Debian. قد تختلف الأوامر قليلاً حسب التوزيعة، ولكن المنطق هو نفسه. قبل إجراء أي عمليات في بيئة الإنتاج، تأكد دائمًا من أخذ نسخة احتياطية. قد تؤدي تكوينات Nginx الخاطئة إلى جعل جميع المواقع غير قابلة للوصول مؤقتًا.

التحضيرات الفنية اللازمة

• حساب مستخدم Linux بصلاحيات root أو sudo.
• خدمة Nginx مثبتة وتعمل.
• اسم نطاق واحد على الأقل موجه إلى عنوان IP للخادم.
• فتح المنافذ 80 و443 في جدار الحماية.
• هيكل مجلد منظم لملفات الموقع.
• شهادة صالحة لـ SSL أو استخدام Let's Encrypt المجاني.
• تثبيت PHP-FPM لتطبيقات PHP.

على جانب DNS، يقوم سجل A بتوجيه اسم النطاق الرئيسي إلى عنوان IPv4، وإذا كان هناك سجل AAAA، فإنه يوجه إلى عنوان IPv6. يمكن استخدام سجل CNAME أو A للنطاقات الفرعية مثل www. عادةً ما تكتمل فترة انتشار DNS في غضون دقائق قليلة إلى 24 ساعة. عند إجراء إعداد جديد، سيكون من الأسرع إعداد سجلات DNS أولاً، ثم الانتقال إلى تكوين كتل خادم Nginx.

هيكل المجلد المقترح

واحدة من الأخطاء الأكثر شيوعًا في استضافة عدة مواقع هي الاحتفاظ بجميع الملفات في مجلد واحد بشكل مختلط. على الرغم من أن هذه الطريقة قد تبدو سهلة على المدى القصير، إلا أنها تضيع وقتًا كبيرًا في عمليات الصيانة والنسخ الاحتياطي وإصلاح الأخطاء. طريقة أفضل هي استخدام مجلد رئيسي منفصل لكل اسم نطاق، مع استخدام مجلدات فرعية مثل public وlogs وbackups بداخله.

يمكن تخطيط هيكل نموذجي على النحو التالي: /var/www/site1.com/public و/var/www/site1.com/logs و/var/www/site2.com/public و/var/www/site2.com/logs. يجب أن تشير قيمة root في Nginx مباشرة إلى مجلد public. وبهذه الطريقة، لن تكون ملفات التطبيق والملفات الحساسة مثل .env والنسخ الاحتياطية متاحة للوصول عبر الويب مباشرة.

يمكنك وضع ملف index.html بسيط في كل مجلد موقع كصفحة اختبار ثابتة. من خلال كتابة اسم الموقع في محتواه، يمكنك بسرعة التحقق من أي كتلة خادم تعمل. في بيئات الإنتاج، عادةً ما يتم تنظيم ملكية هذه المجلدات بواسطة مستخدم www-data أو مستخدم خاص يقوم بالتوزيع. في أذونات الملفات، يكفي أن تكون 755 للمجلدات و644 للملفات في معظم السيناريوهات الثابتة. يجب تقييم مجلدات معينة مثل uploads في التطبيقات التي تتطلب الكتابة مثل WordPress.

خطوات إنشاء كتلة خادم Nginx خطوة بخطوة

تتم شرح الخطوات التالية باستخدام اسم النطاق site1.com كمثال. يمكنك تكرار نفس الطريقة لمواقع ثانية أو ثالثة أو أكثر. النقطة الحاسمة هي استخدام server_name وroot وملف السجل الفريد لكل موقع.

1. إنشاء مجلد الموقع

الخطوة الأولى هي إنشاء المجلد الذي ستحتفظ فيه بملفات الويب. على سبيل المثال: sudo mkdir -p /var/www/site1.com/public. ثم يمكنك إنشاء ملف /var/www/site1.com/public/index.html للاختبار وكتابة نص مميز مثل "هذه صفحة اختبار site1.com".

لضبط ملكية الملف بشكل صحيح، يمكن استخدام الأمر sudo chown -R www-data:www-data /var/www/site1.com. إذا كنت تقوم بعمليات النشر بواسطة مستخدم مختلف، فقم بتنظيم أذونات المجموعة وفقًا لذلك. في بيئة الإنتاج، تجنب الأذونات 777 التي تمنح الجميع حق الكتابة. يمكن أن تؤدي هذه الأذونات إلى استغلال المهاجمين لمجلدات التحميل.

2. إنشاء ملف كتلة الخادم

الممارسة الشائعة في Nginx هي الاحتفاظ بالتكوينات غير النشطة تحت /etc/nginx/sites-available، ورابطها إلى /etc/nginx/sites-enabled باستخدام ارتباط رمزي. ملف المثال: /etc/nginx/sites-available/site1.com.

تكتب كتلة خادم HTTP بسيطة على هذا النحو: server { listen 80; server_name site1.com www.site1.com; root /var/www/site1.com/public; index index.html index.htm; access_log /var/log/nginx/site1.com.access.log; error_log /var/log/nginx/site1.com.error.log; location / { try_files $uri $uri/ =404; } }

في هذا التكوين، listen 80 يستمع لحركة مرور HTTP، وserver_name يحدد أي أسماء نطاقات تنتمي إلى هذه الكتلة، وroot يشير إلى المجلد الذي توجد فيه ملفات الويب، وindex يحدد الملف الافتراضي. إذا لم يتم العثور على الملف أو المجلد المطلوب، فإن try_files ترجع 404. هذه البنية كافية جدًا للمواقع الثابتة.

3. تفعيل الموقع

لتفعيل التكوين، يتم إنشاء رابط رمزي: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. هذه الطريقة أكثر صحة من نسخ الملفات، لأنك تعمل على ملف تكوين رئيسي واحد. عندما تجري تغييرات، يبقى الملف المرتبط محدثًا.

إذا كنت لا ترغب في أن تتجاوز الصفحة الافتراضية لـ Nginx موقعك، يمكنك تعطيل تكوين default. يمكن إزالة الرابط /etc/nginx/sites-enabled/default. ولكن تأكد من أن كتلة الخادم الخاصة بك تعمل بشكل صحيح قبل القيام بذلك.

4. اختبار التكوين وإعادة تحميل Nginx

بعد كل تغيير، يجب إجراء اختبار بناء الجملة باستخدام الأمر sudo nginx -t. إذا كانت الاختبارات ناجحة، يتم إعادة تحميل الخدمة دون انقطاع باستخدام الأمر sudo systemctl reload nginx. عادةً ما يكون الأمر reload أكثر أمانًا من الأمر restart لأنه يدير الاتصالات النشطة بشكل أكثر سلاسة.

إذا فشلت الاختبارات، فإن رسالة الخطأ عادةً ما تشير إلى اسم الملف ورقم السطر. تشمل المشاكل الشائعة الفاصلة المنقوطة المفقودة، أو الأقواس المعوجة الخاطئة، أو مسارات المجلدات غير الصحيحة، أو قيم server_name المتضاربة. يجب عدم إعادة تحميل Nginx حتى يتم إصلاح الخطأ.

إضافة الموقع الثاني والثالث

تكمن جماليات استضافة عدة مواقع في إمكانية تكرار العملية بعد الإعداد الصحيح الأول. يمكنك إنشاء مجلد /var/www/site2.com/public، وكتابة ملف /etc/nginx/sites-available/site2.com، وتغيير قيم root والسجل إلى site2.com، ثم إنشاء رابط رمزي وإجراء اختبار Nginx.

تتميز البنية البسيطة للموقع الثاني بالمنطق التالي: server { listen 80; server_name site2.com www.site2.com; root /var/www/site2.com/public; index index.html; access_log /var/log/nginx/site2.com.access.log; error_log /var/log/nginx/site2.com.error.log; location / { try_files $uri $uri/ =404; } }

استخدام سجلات منفصلة لكل موقع ذو قيمة كبيرة في العالم الواقعي. على سبيل المثال، قد ترتفع أخطاء 404 في موقع واحد بينما لا توجد مشاكل في موقع آخر. بفضل هيكل السجلات المنفصل، يمكنك تحديد مصدر الخطأ في ثوانٍ. وبالمثل، يمكن تتبع تحليل حركة المرور وهجمات البوت والروابط المعطلة ومشاكل الأداء على مستوى كل موقع.

إعداد SSL وHTTPS

وفقًا لمعايير SEO لعام 2026، لم يعد HTTPS مجرد ميزة أمان، بل أصبح أيضًا مؤشرًا على ثقة المستخدم وجودة التقنية. تقوم المتصفحات بالإشارة إلى مواقع HTTP على أنها غير آمنة؛ لذا فإن SSL ضروري في المشاريع التي تتضمن الدفع أو التسجيل أو النماذج أو لوحات التحكم. يجب تحديد الشهادة الصحيحة لكل اسم نطاق أثناء استضافة عدة مواقع. يمكنك زيارة صفحة شهادات SSL على Hostragons لاحتياجات SSL الخاصة بك.

إذا كنت تستخدم Let's Encrypt، يمكنك الحصول على الشهادة لكل اسم نطاق باستخدام Certbot. في العملية النموذجية، يمكن أن يكون الأمر certbot --nginx -d site1.com -d www.site1.com لاكتشاف تكوين Nginx وإضافة كتلة HTTPS تلقائيًا. ومع ذلك، من الجيد فحص الملف بعد التعديل التلقائي. قد تحدث مشاكل في التوجيه الخاطئ أو تكرار كتل الخادم.

في إعداد HTTPS، يتم عادةً توجيه حركة المرور على المنفذ 80 بشكل دائم إلى المنفذ 443. يوفر التوجيه 301 إشارة دائمة للتفضيل من منظور SEO. حدد ما إذا كنت ستستخدم www أم لا، واجمع جميع المتغيرات في عنوان قنوني واحد. على سبيل المثال، إذا كنت ستستخدم https://site1.com بدلاً من https://www.site1.com، فتأكد من توجيه كل من حركة مرور HTTP وHTTPS www إلى عنوان بدون www. هذا يقلل من خطر المحتوى المكرر.

كتل خادم Nginx لمواقع PHP وWordPress

تكون الإعدادات بسيطة في مواقع HTML الثابتة؛ ومع ذلك، تتطلب WordPress وLaravel أو التطبيقات المخصصة تكاملًا مع PHP-FPM. في هذه الحالة، يتم تعريف ملف index.php وتوجيه طلبات PHP إلى المقبس المعني. على سبيل المثال، قد يكون مسار المقبس لـ PHP 8.3 في Ubuntu هو /run/php/php8.3-fpm.sock. يختلف الإصدار حسب الخادم.

منطق مثال PHP: server { listen 80; server_name wordpress-site.com www.wordpress-site.com; root /var/www/wordpress-site.com/public; index index.php index.html; location / { try_files $uri $uri/ /index.php?$args; } location ~ php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.3-fpm.sock; } }

لبقاء الروابط الدائمة لـ WordPress تعمل، تعتبر بنية try_files $uri $uri/ /index.php?$args مهمة. يجب أيضًا مراعاة تدابير الأمان مثل الوصول إلى xmlrpc.php، وحدود معدل wp-login.php، ومنع تشغيل PHP في مجلد uploads. إذا كنت تستضيف العديد من مواقع WordPress على نفس VPS، استخدم قاعدة بيانات منفصلة لكل موقع، ومستخدم منفصل، وسياسة تحديث منتظمة. بالنسبة لأولئك الذين يبحثون عن بديل لاستضافة WordPress، قد تكون استضافة WordPress خيارًا أكثر قابلية للإدارة.

مقارنة كتل خادم Nginx مع Apache VirtualHost

يصل كل من Nginx وApache إلى نفس الهدف باستخدام معماريات مختلفة. يمكن لكل منهما استضافة عدة مواقع على خادم واحد. تعتمد الاختيار على احتياجات التطبيق وعادات الإدارة وتوقعات الأداء.

إذا كان تطبيقك يعتمد بشكل كبير على قواعد .htaccess، فقد يكون Apache أكثر سهولة. ومع ذلك، بالنسبة للحركة المرورية العالية، والوكيل العكسي، والتخزين المؤقت، وتدفقات النشر الحديثة، يعتبر Nginx اختيارًا قويًا في معظم المشاريع. في بعض البنى التحتية، يمكن استخدام Nginx كوكيل عكسي بينما يكون Apache هو خادم تطبيقات الخلفية.

أفضل الممارسات للأمان

توفر استضافة عدة مواقع على نفس الخادم ميزة من حيث التكلفة، لكنها تزيد من المسؤولية الأمنية. يجب تطبيق مبدأ العزل والحد الأدنى من الصلاحيات لضمان عدم تأثير الثغرات في موقع واحد على الآخرين.

• أنشئ قاعدة بيانات منفصلة ومستخدم قاعدة بيانات منفصل لكل موقع.
• حدد جذر الويب ليقتصر فقط على مجلد public.
• احتفظ بالنسخ الاحتياطية وملفات .env و.git وconfig وSQL خارج الوصول عبر الويب.
• قم بتجديد شهادات SSL بانتظام واجعل توجيه HTTPS إلزاميًا.
• استخدم جدار حماية مثل UFW على الخادم؛ افتح فقط المنافذ الضرورية.
• تأكد من تحديث Nginx ونظام التشغيل بانتظام.
• احتفظ بسجلات access_log وerror_log منفصلة لكل موقع.
• أضف قيود IP أو مصادقة إضافية إلى لوحات الإدارة.
• تجنب الأذونات الواسعة مثل 777 في أذونات الملفات.

من المفيد أيضًا إضافة رؤوس الأمان الأساسية. يمكن تقييم رؤوس مثل X-Frame-Options وX-Content-Type-Options وReferrer-Policy وContent-Security-Policy في المشاريع المناسبة. ولكن يجب اختبار Content-Security-Policy في بيئات الاختبار أولاً، حيث إن تطبيقها بشكل خاطئ يمكن أن يمنع تحميل ملفات السكربتات والأنماط. يمكن ربط المحتوى الإضافي حول الأمان بمقالات أمان الموقع.

النقاط التي يجب مراعاتها للأداء وSEO

تؤثر كتل خادم Nginx ليس فقط على النشر ولكن أيضًا على جودة الأداء وSEO. يمكن أن تؤدي سلاسل إعادة التوجيه الخاطئة، والتفضيلات الكانونية المعيبة، وغياب ضغط gzip أو brotli، وسجلات اللوج الكبيرة، وإعدادات التخزين المؤقت غير الكافية إلى إبطاء سرعة الموقع. تعتبر إشارات تجربة الصفحة من Google موجهة نحو المستخدم؛ تميل المواقع السريعة والآمنة والمستقرة إلى تحقيق أداء أفضل.

حدد أولاً إصدارًا قنونيًا واحدًا لكل اسم نطاق. قم بتوجيه حركة المرور من HTTP إلى HTTPS، ومن www إلى غير www، أو العكس، في خطوة واحدة. لا ينبغي أن تكون السلسلة على النحو التالي: http://site.com ثم http://www.site.com، ثم https://www.site.com، ثم https://site.com. بدلاً من ذلك، من الأفضل الوصول مباشرة إلى الهدف باستخدام توجيه 301.

يمكن استخدام رؤوس cache-control للملفات الثابتة. يمكن تخزين الصور وملفات CSS وJS لفترة معينة في المتصفح. ومع ذلك، يجب استخدام تقنيات ترقيم الملفات أو استراتيجيات سلسلة الاستعلام للملفات المتغيرة بشكل متكرر. يقلل ضغط gzip عرض النطاق الترددي للملفات النصية مثل HTML وCSS وJS وJSON. بالنسبة للمواقع ذات الحركة المرورية العالية، يمكن تقييم استخدام microcache وFastCGI cache أو CDN في Nginx. يمكن ربط المحتوى المتعلق بـ CDN واحتياجات الوصول العالمي بمقال مثل ما هو CDN.

إدارة السجلات والمراقبة

تعتبر إدارة السجلات نقطة أساسية لحل المشكلات في استضافة عدة مواقع. تُظهر سجلات اللوج المنفصلة بوضوح الأخطاء التي تحدث في أي موقع. تسجل access_log طلبات الزوار، بينما تسجل error_log الأخطاء المتعلقة بالتكوين والأذونات وعدم العثور على الملفات والأخطاء upstream. غالبًا ما تتعلق أخطاء 502 Bad Gateway بموصل PHP-FPM أو اتصال خدمة الخلفية. يمكن أن تشير 403 Forbidden إلى مشكلة في الأذونات أو وجود ملف index. تشير 404 Not Found إلى مشكلة في مسار الملف أو إعادة الكتابة أو مشكلة في الجذر بعد تسجيل DNS.

يجب فحص تكوين logrotate لمنع سجلات اللوج من النمو بلا حدود. في المشاريع الصغيرة، قد تكون عملية التدوير اليومية أو الأسبوعية كافية. بالنسبة للمواقع ذات الحركة المرورية العالية، يجب استخدام جمع سجلات مركزي ونظام متابعة المقاييس وتحذيرات. قد يؤدي امتلاء القرص إلى عدم قدرة Nginx على كتابة السجلات، مما يؤدي إلى توقف قاعدة البيانات وعدم إمكانية الوصول إلى المواقع. لذلك، من المفيد تحديد عتبات لاستخدام القرص كإجراء عملي.

الأخطاء الشائعة والحلول السريعة

عند العمل مع كتل خادم Nginx، قد تواجه بعض الأخطاء بشكل متكرر في كل مشروع. معرفة هذه الأخطاء يمكن أن تقلل بشكل كبير من وقت الإعداد.

• يفتح اسم النطاق الموقع الخاطئ: تحقق من تضارب server_name وكتلة الخادم الافتراضية.
• خطأ 403 Forbidden: تحقق من مجلد الجذر وأذونات الملفات ووجود ملف index.
• خطأ 404 Not Found: تحقق من المسار الجذري وقاعدة try_files.
• خطأ 502 Bad Gateway: تحقق مما إذا كانت خدمة PHP-FPM تعمل وما إذا كان مسار المقبس صحيحًا.
• تشير شهادة SSL إلى موقع خاطئ: تحقق من server_name في المنفذ 443 وملفات الشهادة.
• تحدث حلقة توجيه: قم بتبسيط قواعد توجيه HTTP-HTTPS وwww.
• لا يتم إعادة تحميل Nginx: قم بتصحيح خطأ بناء الجملة وفقًا لرقم السطر في مخرجات sudo nginx -t.

يوجد لدى المديرين ذوي الخبرة قائمة فحص بسيطة يتبعونها: هل DNS صحيح؟ هل تكوين Nginx نشط؟ هل يوجد مجلد الجذر؟ هل الأذونات صحيحة؟ هل اجتاز الخدمة الاختبار؟ ماذا تقول السجلات؟ سيساعدك اتباع هذه الخطوات على إيجاد حلول سريعة دون الذعر.

قائمة التحقق العملية للبيئات الإنتاجية

قبل الانتقال إلى الإنتاج، تحقق من كل موقع باستخدام قائمة التحقق التالية. خاصة في مشاريع العملاء، يعد توثيق هذه النقاط قبل التسليم معيارًا احترافيًا للعمل.

• يتم توجيه سجل A أو AAAA لاسم النطاق إلى عنوان IP الصحيح.
• تم اختيار أحد الإصدارات بإصدار www أو بدون www بشكل قنوني.
• يتم توجيه حركة مرور HTTP إلى HTTPS باستخدام 301.
• شهادة SSL صالحة وتجديدها تلقائيًا نشط.
• تم تحديد جذر وسجل منفصل لكل موقع.
• تم التحقق من تكوين Nginx باستخدام sudo nginx -t.
• تم تحديد خطة النسخ الاحتياطي وإجراء اختبار الاستعادة.
• تتوافق أذونات الملفات مع مبدأ الحد الأدنى من الصلاحيات.
• جدار الحماية مفتوح فقط للمنافذ الضرورية.
• تم مراقبة سجلات الأخطاء لمدة 15 دقيقة على الأقل بعد الانتقال إلى الإنتاج.

قد تبدو هذه القائمة صغيرة، لكنها تقلل بشكل كبير من مخاطر التوقف في المشاريع الحقيقية. خاصة أن خطوات تجديد SSL والتحقق من DNS ومراقبة السجلات تلتقط معظم الأخطاء المخفية مبكرًا.

الختام

تعتبر كتل خادم Nginx واحدة من الطرق الأساسية لاستضافة عدة مواقع بشكل منظم وآمن وأداء عالٍ على خادم واحد. يمكن أن تجعل الإدارة الفعالة للمواقع المتعددة من خلال هيكل المجلد الصحيح وملفات التكوين المنفصلة وقواعد التوجيه الواضحة واستخدام HTTPS والفصل بين السجلات وعملية الاختبار المنتظمة من إدارة المواقع المتعددة فعالة للغاية. يمكن تطبيق نفس المبادئ على موقع محفظة صغيرة أو مشاريع عملاء متعددة.

إذا كنت تخطط لنشر مشروع جديد، فتأكد من تحديد اسم النطاق ومصدر الخادم واحتياجات SSL الخاصة بك؛ ثم قم بإنشاء تكوين Nginx الخاص بك خطوة بخطوة باستخدام قائمة التحقق أعلاه. إذا كنت تبحث عن بنية تحتية أكثر قابلية للإدارة، يمكنك اختيار نقطة انطلاق مناسبة لمشروعك من خلال استكشاف حلول Hostragons حزم الاستضافة والخادم VPS وشهادات SSL.

أسئلة شائعة

كم عدد المواقع التي يمكن استضافتها باستخدام كتل خادم Nginx؟

تقنيًا، يمكنك استضافة عدد كبير من المواقع على نفس الخادم باستخدام Nginx؛ حيث يعتمد الحد عادةً على CPU وRAM واستخدام القرص وحركة المرور وحمل قاعدة البيانات وقدرات PHP-FPM. في المواقع الثابتة ذات الحركة المرورية المنخفضة، قد يكون من الممكن استضافة العشرات، بينما في مشاريع WordPress أو التجارة الإلكترونية ذات الحركة الكثيفة، يكون من الأكثر صحة استضافة عدد أقل من المواقع.

هل تحتاج كل موقع إلى شهادة SSL منفصلة؟

نعم، يجب تضمين الشهادة ضمن نطاق HTTPS لكل اسم نطاق أو نطاق فرعي. يمكن استخدام شهادات فردية أو شهادات SAN أو wildcard. المهم هو ربط ملفات الشهادة الصحيحة بأسماء النطاق الصحيحة في كتلة Nginx على المنفذ 443.

هل يمكن نشر نطاق فرعي باستخدام كتلة خادم Nginx؟

نعم. يمكنك تحديد server_name منفصل للنطاقات الفرعية مثل blog.site.com أو panel.site.com وتوجيهها إلى مجلد جذر مختلف أو تطبيق خلفي مختلف. ستحتاج إلى إنشاء سجل A أو CNAME للنطاق الفرعي على جانب DNS.

ما الفرق بين sites-available وsites-enabled؟

تحتوي sites-available على ملفات التكوين التي يمكن استخدامها؛ بينما تحتوي sites-enabled على التكوينات النشطة. عادةً ما يتم إنشاء ارتباط رمزي في sites-enabled إلى ملف في sites-available. تجعل هذه الطريقة تنشيط وتعطيل المواقع أكثر تنظيمًا.

إذا كان يفتح الموقع الخاطئ، من أين تأتي المشكلة؟

تشمل الأسباب الأكثر شيوعًا توجيه DNS إلى IP خاطئ، أو وجود خطأ في قيمة server_name، أو التقاط الكتلة الافتراضية لـ Nginx الطلب، أو تشغيل كتلة SSL خاطئة على المنفذ 443. تحقق أولاً من سجلات DNS، ثم قم بمراجعة مخرجات nginx -t، والارتباطات النشطة في sites-enabled، وملفات access_log ذات الصلة.