میزبانی چند سایت با بلوک‌های سرور Nginx (میزبان‌های مجازی) به صورت حرفه‌ای

بلوک‌های سرور Nginx، مفهومی مشابه میزبان‌های مجازی هستند که به شما امکان می‌دهند چندین دامنه یا وب‌سایت را روی یک نصب واحد Nginx با تنظیمات مستقل میزبانی کنید. برای مثال، می‌توانید در یک سرور مجازی خصوصی (VPS) به صورت همزمان سایت‌های example.com، blog.example.com و site2.com را با پوشه‌های ریشه متفاوت، فایل‌های لاگ جداگانه، گواهی‌های SSL اختصاصی و تنظیمات PHP مجزا اجرا کنید. راه‌حل کلی شامل ایجاد دایرکتوری‌های جداگانه برای هر سایت، تنظیم رکوردهای DNS دامنه‌ها به سمت IP سرور، ایجاد بلوک‌های سرور جداگانه در مسیر /etc/nginx/sites-available، فعال‌سازی آن‌ها در sites-enabled، تست پیکربندی و بارگذاری مجدد سرویس Nginx است.

در این راهنما، فرایند میزبانی چند سایت با بلوک‌های سرور Nginx را به شکلی مناسب محیط‌های تولید بررسی می‌کنیم. هدف صرفاً راه‌اندازی یک ساختار عملی نیست؛ بلکه ایجاد ساختاری امن، قابل مدیریت، سریع، قابل پشتیبان‌گیری و مقیاس‌پذیر است. این روش به‌ویژه برای آژانس‌ها، توسعه‌دهندگان، صاحبان فروشگاه‌های اینترنتی، کسب‌وکارهای چندبرندی و مدیران سیستم که چند پروژه را روی یک سرور اجرا می‌کنند، کاربردی است. اگر هنوز سروری ندارید، برای انتخاب منابع می‌توانید صفحات سرور VPS و ثبت دامنه را مطالعه کنید.

بلوک‌های سرور Nginx چیست؟

بلوک‌های سرور Nginx بخش‌هایی از پیکربندی Nginx هستند که با دستور server تعریف می‌شوند و مشخص می‌کنند درخواست‌های HTTP یا HTTPS به کدام سایت هدایت شوند. این مفهوم معادل VirtualHost در Apache است. وقتی کاربر دامنه‌ای را در مرورگر وارد می‌کند، DNS آن را به IP سرور تبدیل می‌کند و سپس Nginx با بررسی هدر Host درخواست، بلوک سروری را اجرا می‌کند که نام دامنه در server_name آن تعریف شده است.

بدین ترتیب، امکان میزبانی ده‌ها سایت مختلف روی یک IP و یک سرور فیزیکی یا مجازی وجود دارد. برای هر سایت می‌توان دایرکتوری ریشه (root)، فایل لاگ دسترسی و خطا، قواعد ریدایرکت، گواهی SSL، سیاست کش و تنظیمات امنیتی اختصاصی تعریف کرد. به عنوان مثال، سایت شرکتی را در /var/www/corporate/public، وبلاگ در /var/www/blog/public و محیط تست در /var/www/staging/public نگه‌داری کنید.

از آنجا که Nginx از معماری رویدادمحور استفاده می‌کند، مصرف منابع آن بهینه بوده و می‌تواند تعداد زیادی اتصال همزمان را با کارایی بالا مدیریت کند. به همین دلیل در هاستینگ اشتراکی، VPS، سرورهای ابری و برنامه‌های پر ترافیک بسیار محبوب است. برای عملکرد صحیح میزبانی چند سایت، باید همه جزئیات از مجوزهای فایل گرفته تا تنظیم DNS، نصب SSL و تفکیک لاگ‌ها به دقت برنامه‌ریزی شود.

چه زمانی از بلوک‌های سرور Nginx استفاده می‌کنیم؟

بلوک‌های سرور Nginx زمانی کاربرد دارند که بخواهید چندین وب‌سایت یا پروژه را روی یک سرور مدیریت کنید. این ممکن است دو سایت کوچک شرکتی باشد یا ده‌ها پروژه مشتری، زیر دامنه یا میکروسرویس. نکته مهم جداسازی منطقی هر پروژه از دیگری است.

• اگر می‌خواهید چند دامنه مختلف را روی یک VPS منتشر کنید.
• اگر قصد دارید نسخه‌های www و بدون www دامنه را به یک آدرس اصلی هدایت کنید.
• اگر می‌خواهید زیر دامنه‌ها را به فولدرها یا برنامه‌های متفاوت متصل کنید.
• اگر برای هر سایت نیاز به گواهی SSL و سیاست امنیتی جداگانه دارید.
• اگر می‌خواهید پروژه‌های مشتری را با فایل‌های لاگ جداگانه رصد کنید.
• اگر قصد اجرای همزمان برنامه‌هایی مثل Laravel، WordPress، HTML ایستا و Node.js روی یک سرور را دارید.

برای نمونه، یک آژانس دیجیتال می‌تواند روی یک VPS با 4 گیگابایت رم، هشت سایت شرکتی با ترافیک کم را میزبانی کند. اما باید مصرف ترافیک، فضای دیسک، تعداد پردازش‌های PHP، بار دیتابیس و دفعات پشتیبان‌گیری برای هر سایت محاسبه شود. در صورت ترافیک بالا یا نیاز به ایزولاسیون منابع، استفاده از VPS قوی‌تر، سرور ابری یا هاستینگ مدیریت‌شده توصیه می‌شود. در این زمینه می‌توانید گزینه‌های هاستینگ وب و هاستینگ شرکتی را مقایسه کنید.

پیش‌نیازها قبل از شروع

این آموزش بر پایه سرورهای لینوکس Ubuntu یا Debian نوشته شده است. دستورات ممکن است بسته به توزیع کمی متفاوت باشند ولی کلیت کار یکسان است. قبل از اعمال هر تغییر در محیط تولید حتماً از داده‌ها پشتیبان تهیه کنید. پیکربندی نادرست Nginx ممکن است باعث قطع دسترسی موقت به همه سایت‌ها شود.

آماده‌سازی‌های فنی ضروری

• حساب کاربری لینوکس با دسترسی root یا sudo.
• نصب و اجرای سرویس Nginx.
• حداقل یک دامنه که به IP سرور اشاره می‌کند.
• باز بودن پورت‌های 80 و 443 در فایروال.
• ساختار دایرکتوری منظم برای فایل‌های سایت.
• داشتن گواهی SSL معتبر یا استفاده رایگان از Let’s Encrypt.
• نصب PHP-FPM برای سایت‌های مبتنی بر PHP.

در DNS، رکورد A دامنه اصلی را به IP نسخه 4 و رکورد AAAA در صورت وجود به IP نسخه 6 هدایت می‌کند. برای زیر دامنه‌ها می‌توان از رکورد CNAME یا A استفاده کرد. انتشار DNS معمولاً بین چند دقیقه تا ۲۴ ساعت طول می‌کشد. بهتر است ابتدا رکوردهای 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 اشاره کند تا فایل‌های حساس مانند فایل‌های پیکربندی یا نسخه‌های پشتیبان از دسترس وب خارج باشند.

برای تست می‌توانید در هر پوشه سایت یک فایل index.html ساده با نام سایت قرار دهید تا به سرعت مطمئن شوید بلوک سرور درست عمل می‌کند. در محیط‌های تولید، مالکیت پوشه‌ها معمولاً روی کاربر www-data یا کاربر مخصوص دیپلویمنت تنظیم می‌شود. مجوزهای ۷۵۵ برای پوشه‌ها و ۶۴۴ برای فایل‌ها معمولاً کافی است. در برنامه‌هایی مثل وردپرس که پوشه‌هایی نیاز به نوشتن دارند (مثلاً uploads)، مجوزها باید جداگانه تنظیم شوند.

مراحل ساخت بلوک سرور 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 را اجرا کنید. اگر دیپلویمنت را با کاربر دیگری انجام می‌دهید، مجوز گروه را متناسب با آن تغییر دهید. هرگز مجوز ۷۷۷ ندهید چون این موضوع می‌تواند باعث سوء استفاده مهاجمان شود.

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 بررسی می‌کند که فایل یا پوشه درخواست شده وجود داشته باشد و در غیر این صورت خطای ۴۰۴ نمایش داده شود. این ساختار برای سایت‌های ایستا کاملاً مناسب است.

3. فعال‌سازی سایت

برای فعال کردن پیکربندی، لینک سمبولیکی ایجاد کنید: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. این روش بهتر از کپی کردن فایل است چون تغییرات به صورت متمرکز اعمال می‌شود و همواره به‌روز باقی می‌ماند.

اگر نمی‌خواهید صفحه پیش‌فرض Nginx جای سایت شما را بگیرد، می‌توانید لینک /etc/nginx/sites-enabled/default را حذف کنید. البته قبل از این کار مطمئن شوید سایت شما به درستی کار می‌کند.

4. تست پیکربندی و بارگذاری مجدد Nginx

بعد از هر تغییر، با دستور sudo nginx -t صحت نحو پیکربندی را بررسی کنید. اگر موفق بود، با sudo systemctl reload nginx سرویس را بدون قطعی مجدد بارگذاری نمایید. دستور reload نسبت به restart ایمن‌تر است چون اتصالات جاری را نادیده نمی‌گیرد.

اگر خطایی وجود داشته باشد، پیام خطا معمولاً فایل و شماره خط را نشان می‌دهد. خطاهای رایج شامل نبودن نقطه ویرگول، پرانتزهای ناهماهنگ، مسیرهای نادرست و تکرار server_name است. بدون رفع خطا نباید Nginx را بارگذاری مجدد کرد.

افزودن سایت دوم و سوم

مزیت میزبانی چند سایت این است که پس از تنظیم اولیه، فرآیند برای سایت‌های بعدی تکرارپذیر است. برای site2.com پوشه /var/www/site2.com/public را بسازید، فایل پیکربندی /etc/nginx/sites-available/site2.com را ایجاد کنید، root و مسیرهای لاگ را متناسب تغییر دهید، لینک سمبولیک بسازید و تست 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;   } }

داشتن لاگ‌های مجزا برای هر سایت اهمیت زیادی دارد. مثلاً ممکن است در سایت اول خطاهای ۴۰۴ افزایش یابد ولی سایت دوم کاملاً بدون مشکل باشد. این تفکیک اجازه می‌دهد منبع خطا یا مشکل را در چند ثانیه پیدا کنید. همچنین تحلیل ترافیک، حملات ربات‌ها، لینک‌های خراب و مشکلات عملکرد به صورت سایت به سایت قابل پیگیری است.

پیکربندی SSL و HTTPS

در استانداردهای سئو ۲۰۲۶، HTTPS فقط یک ویژگی امنیتی نیست بلکه نشان‌دهنده اعتماد کاربران و کیفیت فنی سایت است. مرورگرها سایت‌های HTTP را ناامن علامت می‌زنند؛ به‌خصوص در پروژه‌هایی که پرداخت، ورود کاربر، فرم یا پنل مدیریت دارند، استفاده از SSL الزامی است. در میزبانی چند سایت باید برای هر دامنه گواهی مناسب نصب شود. برای نیازهای SSL می‌توانید صفحه گواهی‌نامه‌های SSL را در Hostragons مشاهده کنید.

اگر از Let’s Encrypt استفاده می‌کنید، با Certbot می‌توان برای هر دامنه گواهی گرفت. دستور نمونه: certbot --nginx -d site1.com -d www.site1.com که تنظیمات Nginx را تشخیص داده و بلوک HTTPS را به صورت خودکار اضافه می‌کند. ولی پس از آن بهتر است فایل پیکربندی را بررسی کنید تا خطاهای ریدایرکت یا تکرار بلوک پیش نیاید.

معمولاً ترافیک پورت ۸۰ به صورت دائمی به پورت ۴۴۳ ارجاع داده می‌شود (ریدایرکت ۳۰۱). این موضوع از نظر سئو به معنی تغییر دائمی است و بهتر است نسخه اصلی دامنه (مثلاً www یا بدون www) را مشخص و همه نسخه‌های دیگر را به آن هدایت کنید. مثلاً اگر می‌خواهید https://site1.com نسخه اصلی باشد، همه درخواست‌های http و https با www را به آن هدایت نمایید تا خطر محتوای تکراری کاهش یابد.

بلوک‌های سرور Nginx برای سایت‌های PHP و وردپرس

سایت‌های HTML ایستا ساده هستند، اما سایت‌های وردپرس، لاراول یا برنامه‌های اختصاصی PHP نیاز به اتصال به PHP-FPM دارند. در این حالت باید index.php را به عنوان فایل اصلی تعریف و درخواست‌های PHP را به سوکت مربوطه ارسال کنید. مثلاً مسیر سوکت PHP 8.3 روی اوبونتو معمولاً /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;   } }

برای عملکرد درست پیوندهای یکتا در وردپرس، ساختار try_files اهمیت زیادی دارد. همچنین باید به مسائل امنیتی مانند محدود کردن دسترسی به xmlrpc.php، محافظت از wp-login.php و جلوگیری از اجرای PHP در پوشه uploads توجه کنید. اگر چند سایت وردپرس روی یک VPS دارید، هر کدام را با دیتابیس، کاربر و سیاست به‌روزرسانی جداگانه مدیریت کنید. برای گزینه‌های مدیریت‌شده وردپرس می‌توانید به هاستینگ وردپرس مراجعه کنید.

مقایسه بلوک‌های سرور Nginx و VirtualHost های Apache

Nginx و Apache هر دو به هدف میزبانی چند سایت روی یک سرور می‌رسند اما معماری متفاوتی دارند. انتخاب بین آن‌ها بستگی به نیازهای برنامه، عادت‌های مدیریت و انتظارات عملکردی شما دارد.

اگر برنامه‌تان به شدت به قوانین .htaccess وابسته است، Apache انتخاب راحت‌تری است. ولی برای ترافیک بالا، پروکسی معکوس، کشینگ و جریان‌های توزیع مدرن، Nginx گزینه قدرتمندتری است. در برخی ساختارها، Nginx به عنوان پروکسی معکوس و Apache به عنوان سرور بک‌اند با هم کار می‌کنند.

بهترین روش‌های امنیتی

میزبانی چند سایت روی یک سرور هزینه را کاهش می‌دهد اما مسئولیت امنیتی را افزایش می‌دهد. برای جلوگیری از تأثیر آسیب‌پذیری یک سایت روی بقیه، باید جداسازی و اصل حداقل دسترسی رعایت شود.

• برای هر سایت دیتابیس و کاربر دیتابیس جداگانه بسازید.
• دایرکتوری ریشه را فقط به پوشه public محدود کنید.
• فایل‌های بکاپ، .env، .git، config و SQL را از دسترس وب خارج نگه دارید.
• گواهی‌های SSL را مرتب به‌روزرسانی و ریدایرکت HTTPS را اجباری کنید.
• از فایروال (مثل UFW) استفاده کرده و فقط پورت‌های ضروری را باز کنید.
• به‌روزرسانی‌های Nginx و سیستم عامل را منظم انجام دهید.
• برای هر سایت فایل‌های access_log و error_log جداگانه داشته باشید.
• پنل‌های مدیریت را با محدودیت IP یا احراز هویت اضافی محافظت کنید.
• از مجوزهای گسترده مثل ۷۷۷ پرهیز کنید.

علاوه بر این، افزودن هدرهای امنیتی مانند X-Frame-Options، X-Content-Type-Options، Referrer-Policy و Content-Security-Policy توصیه می‌شود. البته اجرای نادرست Content-Security-Policy ممکن است بارگذاری اسکریپت و استایل‌ها را مختل کند؛ بنابراین ابتدا در محیط تست بررسی شود. برای مطالعه بیشتر درباره امنیت وب‌سایت می‌توانید به امنیت وب‌سایت مراجعه کنید.

نکات مهم در عملکرد و سئو

بلوک‌های سرور Nginx تنها برای انتشار سایت نیستند، بلکه بر سرعت بارگذاری و کیفیت SEO نیز تأثیرگذارند. زنجیره‌های ریدایرکت طولانی، انتخاب‌های نابجا در canonical، نبود gzip یا brotli، فایل‌های لاگ حجیم و کش ناکارآمد می‌توانند سرعت سایت را پایین بیاورند. گوگل به تجربه کاربری اهمیت می‌دهد؛ سایت‌های سریع، امن و پایدار رتبه بهتری دارند.

ابتدا برای هر دامنه یک نسخه canonical مشخص کنید. ریدایرکت HTTP به HTTPS و www به غیرwww را در یک مرحله و با کد ۳۰۱ انجام دهید. زنجیره‌های پیچیده مانند http://site.com → http://www.site.com → https://www.site.com → https://site.com مناسب نیستند.

برای فایل‌های استاتیک مانند تصاویر، CSS و JS از Cache-Control استفاده کنید تا مرورگر آن‌ها را به مدت مشخصی ذخیره کند. برای فایل‌هایی که مرتب تغییر می‌کنند، از نسخه‌بندی نام فایل یا query string بهره ببرید. فشرده‌سازی gzip پهنای باند را کاهش می‌دهد و در سایت‌های پر ترافیک می‌توان از microcache، FastCGI cache یا CDN استفاده کرد. برای آشنایی با CDN به CDN چیست مراجعه کنید.

مدیریت لاگ و پایش سایت‌ها

در میزبانی چند سایت، مدیریت لاگ کلید حل مشکلات است. فایل‌های لاگ جداگانه نشان می‌دهند هر سایت چه خطاهایی دارد. access_log درخواست‌های بازدیدکنندگان و error_log مشکلات پیکربندی، مجوزها، فایل‌های مفقود یا ارتباط با سرورها را ثبت می‌کند. خطای ۵۰۲ معمولا مربوط به PHP-FPM یا اتصال به بک‌اند است، ۴۰۳ نشان‌دهنده مشکل مجوز یا نبود فایل index و ۴۰۴ می‌تواند ناشی از مسیر اشتباه یا تنظیمات rewrite یا DNS باشد.

برای جلوگیری از رشد بی‌رویه لاگ‌ها، تنظیمات logrotate را بررسی کنید. پروژه‌های کوچک می‌توانند روزانه یا هفتگی چرخش لاگ داشته باشند. سایت‌های پرترافیک به سیستم‌های مرکزی جمع‌آوری لاگ، مانیتورینگ و هشدار نیاز دارند. پر شدن دیسک ممکن است باعث عدم ثبت لاگ، توقف دیتابیس و از دسترس خارج شدن سایت شود؛ پس تعیین حد آستانه برای استفاده دیسک ضروری است.

خطاهای رایج و راهکارهای سریع

هنگام کار با بلوک‌های سرور Nginx، برخی مشکلات معمولاً پیش می‌آید که شناخت آن‌ها سرعت حل را زیاد می‌کند.

• دامنه اشتباهی باز می‌شود: server_nameهای تکراری و default server block را بررسی کنید.
• خطای ۴۰۳ Forbidden: مسیر root، مجوز فایل‌ها و وجود index را کنترل کنید.
• خطای ۴۰۴ Not Found: مسیر root و قواعد try_files را بازبینی کنید.
• خطای ۵۰۲ Bad Gateway: از اجرای سرویس PHP-FPM و مسیر سوکت مطمئن شوید.
• گواهی SSL به سایت اشتباه تعلق دارد: server_name در پورت ۴۴۳ و فایل‌های گواهی را بررسی کنید.
• ریدایرکت بی‌پایان ایجاد شده: قوانین ریدایرکت HTTP-HTTPS و www را ساده کنید.
• Nginx بارگذاری مجدد نمی‌شود: خطای syntax را با توجه به شماره خط در خروجی sudo nginx -t رفع کنید.

فهرست بررسی سریع مدیران باتجربه شامل: آیا DNS درست تنظیم شده؟ پیکربندی Nginx فعال است؟ پوشه root وجود دارد؟ مجوزها صحیح‌اند؟ سرویس تست شده؟ لاگ‌ها چه می‌گویند؟ این کار را مرحله به مرحله پیش ببرید تا بدون استرس مشکل را حل کنید.

فهرست کنترل نهایی برای محیط تولید

قبل از راه‌اندازی هر سایت، موارد زیر را چک کنید. مخصوصاً در پروژه‌های مشتری، ثبت این موارد استاندارد حرفه‌ای محسوب می‌شود.

• رکورد A یا AAAA دامنه به IP درست اشاره دارد.
• نسخه اصلی دامنه (www یا بدون www) مشخص و کانونیکال شده است.
• ترافیک HTTP به HTTPS با کد ۳۰۱ منتقل می‌شود.
• گواهی SSL معتبر و تمدید خودکار فعال است.
• برای هر سایت دایرکتوری root و فایل‌های لاگ جدا تعریف شده‌اند.
• پیکربندی Nginx با sudo nginx -t تأیید شده است.
• برنامه پشتیبان‌گیری تعریف و تست بازیابی انجام شده است.
• مجوزهای فایل‌ها مطابق اصل حداقل دسترسی تنظیم شده‌اند.
• فایروال فقط پورت‌های لازم را باز گذاشته است.
• لاگ خطا حداقل ۱۵ دقیقه پس از راه‌اندازی مانیتور شده است.

اگرچه این لیست کوتاه به نظر می‌رسد، اما در پروژه‌های واقعی تا حد زیادی ریسک قطعی و مشکل را کاهش می‌دهد. بخصوص کنترل تمدید SSL، وضعیت DNS و پایش لاگ‌ها اغلب خطاهای پنهان را زود آشکار می‌کنند.

نتیجه‌گیری

بلوک‌های سرور Nginx یکی از روش‌های کلیدی برای میزبانی چندین سایت به صورت منظم، امن و با کارایی بالا روی یک سرور واحد هستند. با ساختار دایرکتوری مناسب، فایل‌های پیکربندی مجزا، قوانین ریدایرکت شفاف، استفاده از HTTPS، تفکیک لاگ‌ها و فرایندهای تست منظم، مدیریت چند سایت بسیار بهینه خواهد شد. این اصول از یک سایت کوچک شخصی تا چندین پروژه مشتری قابل استفاده است.

اگر قصد راه‌اندازی پروژه جدیدی دارید، ابتدا نیازهای دامنه، منابع سرور و SSL خود را مشخص کنید سپس با استفاده از فهرست کنترل بالا پیکربندی Nginx را گام به گام اجرا نمایید. برای زیرساختی با مدیریت آسان‌تر می‌توانید راهکارهای بسته‌های هاستینگ، سرور VPS و گواهی‌نامه‌های SSL در Hostragons را بررسی کنید و نقطه شروع مناسبی انتخاب نمایید.

سؤالات متداول

با بلوک‌های سرور Nginx چند سایت می‌توان میزبانی کرد؟

از نظر فنی می‌توانید تعداد زیادی سایت روی یک سرور با Nginx میزبانی کنید؛ محدودیت اصلی به CPU، حافظه رم، فضای دیسک، ترافیک، بار دیتابیس و ظرفیت PHP-FPM بستگی دارد. در سایت‌های ایستا با ترافیک کم، می‌توان ده‌ها سایت داشت، اما در پروژه‌های وردپرس یا فروشگاهی پر ترافیک تعداد سایت‌ها باید کمتر باشد.

آیا برای هر سایت باید گواهی SSL جداگانه داشت؟

بله، هر دامنه یا زیر دامنه‌ای که با HTTPS منتشر می‌شود باید گواهی مربوطه را داشته باشد. می‌توانید گواهی‌های جداگانه یا گواهی‌های چند دامنه‌ای (SAN) و Wildcard استفاده کنید. مهم این است که در بلوک ۴۴۳ Nginx، فایل‌های گواهی به دامنه صحیح متصل شوند.

آیا می‌توان با بلوک سرور Nginx زیر دامنه منتشر کرد؟

بله، می‌توانید برای زیر دامنه‌هایی مانند blog.site.com یا panel.site.com server_name جدا تعریف کرده و آن‌ها را به دایرکتوری یا بک‌اند متفاوتی هدایت کنید. در DNS نیز باید رکورد A یا CNAME مربوطه ایجاد شود.

فرق sites-available و sites-enabled چیست؟

sites-available محل نگهداری فایل‌های پیکربندی موجود است و sites-enabled شامل پیکربندی‌های فعال می‌باشد. معمولاً در sites-enabled لینک سمبولیک به فایل‌های موجود در sites-available ایجاد می‌شود که مدیریت فعال و غیرفعال کردن سایت‌ها را آسان می‌کند.

اگر سایت اشتباهی باز می‌شود مشکل از کجاست؟

علت‌های رایج شامل تنظیم نادرست DNS به IP اشتباه، مقدار server_name اشتباه، فعال بودن بلوک پیش‌فرض Nginx که درخواست را می‌گیرد یا اجرای بلاک SSL اشتباه در پورت ۴۴۳ است. ابتدا رکوردهای DNS، خروجی sudo nginx -t، لینک‌های فعال در sites-enabled و فایل‌های access_log را بررسی کنید.