Nginx سرور بلاکس (ورچوئل ہوسٹس) کے ذریعے متعدد ویب سائٹس کی ہوسٹنگ

Nginx سرور بلاکس ایک ورچوئل ہوسٹنگ کی منطق ہے جو آپ کو ایک ہی Nginx انسٹالیشن میں متعدد ڈومینز یا ویب سائٹس کو علیحدہ کنفیگریشن کے ساتھ ہاسٹ کرنے کی اجازت دیتا ہے۔ مثال کے طور پر، آپ ایک ہی VPS پر example.com، blog.example.com اور second-site.com کے لیے مختلف روٹ ڈائریکٹریز، لاگ فائلیں، SSL سرٹیفکیٹس، اور PHP سیٹنگز متعین کر سکتے ہیں۔ مختصراً یہ حل ہے کہ ہر سائٹ کے لیے علیحدہ ڈائریکٹری بنائیں، ڈومین کے DNS ریکارڈز کو سرور کے IP ایڈریس کی طرف ری ڈائریکٹ کریں، /etc/nginx/sites-available کے تحت ایک علیحدہ سرور بلاک لکھیں، اسے sites-enabled ڈائریکٹری میں لنک کریں، کنفیگریشن کی جانچ کریں، اور Nginx سروس کو دوبارہ لوڈ کریں۔

اس رہنما میں، ہم Nginx سرور بلاکس کے ساتھ متعدد سائٹس کی ہوسٹنگ کے عمل کو پیداواری ماحول کے لیے موزوں طریقے سے سمجھیں گے۔ مقصد صرف ایک کام کرنے والی ساخت بنانا نہیں ہے؛ بلکہ ایک منظم، محفوظ، تیز، بیک اپ کی جا سکنے والی اور اسکیل ایبل ترتیب بنانا ہے۔ خاص طور پر ایجنسیوں، ترقی دہندگان، ای کامرس مالکان، متعدد برانڈز کا انتظام کرنے والی کمپنیوں اور ایک سرور پر متعدد پروجیکٹس چلانے والے سسٹم ایڈمنز کے لیے عملی اقدامات شیئر کریں گے۔ اگر آپ کے پاس ابھی تک سرور نہیں ہے تو وسائل کے انتخاب کے لیے VPS سرور اور ڈومین کی انتظام کاری کے لیے ڈومین تصدیق صفحات کا جائزہ لے سکتے ہیں۔

Nginx سرور بلاکس کیا ہیں؟

Nginx سرور بلاکس وہ کنفیگریشن کے حصے ہیں جو Nginx کی کنفیگریشن میں سرور بلاک کے طور پر بیان کیے جاتے ہیں اور یہ طے کرتے ہیں کہ آنے والی HTTP یا HTTPS درخواست کس سائٹ کی طرف ری ڈائریکٹ کی جائے گی۔ یہ Apache کے VirtualHost کے تصور کے مشابہ ہے۔ جب ایک وزیٹر براؤزر میں ایک ڈومین نام ٹائپ کرتا ہے تو DNS اس ڈومین نام کو سرور کے IP ایڈریس میں حل کرتا ہے۔ اس کے بعد Nginx، درخواست میں آنے والے Host ہیڈر کو دیکھتا ہے اور server_name ویلیو کے مطابق میچ کرنے والا سرور بلاک چلاتا ہے۔

اس طرح، ایک ہی IP ایڈریس اور ایک ہی جسمانی یا ورچوئل سرور پر درجنوں مختلف ویب سائٹس کو ہاسٹ کیا جا سکتا ہے۔ ہر سائٹ کے لیے علیحدہ روٹ ڈائریکٹری، ایکسیس لاگ، ایرر لاگ، ری ڈائریکشن رول، SSL سرٹیفکیٹ، کیش پالیسی اور سیکیورٹی رول متعین کرنا ممکن ہے۔ مثال کے طور پر، آپ اپنی کمپنی کی ویب سائٹ کو /var/www/company/public میں، اپنے بلاگ کو /var/www/blog/public میں، اور اپنے ٹیسٹ ماحول کو /var/www/staging/public میں رکھ سکتے ہیں۔

Nginx اس ساخت میں کافی موثر ہے کیونکہ ایونٹ پر مبنی معمار کی وجہ سے یہ اعلیٰ ہم وقتی کنکشنز کو کم وسائل کے استعمال کے ساتھ منظم کر سکتا ہے۔ اسی لیے مشترکہ ہوسٹنگ، VPS، کلاؤڈ سرور اور زیادہ ٹریفک والی ایپلیکیشن کی بنیادوں میں اسے اکثر ترجیح دی جاتی ہے۔ متعدد سائٹس کی ہوسٹنگ کے صحت مند طریقے سے کام کرنے کے لیے، فائل کی اجازتوں سے لے کر DNS ری ڈائریکشنز، SSL کی تنصیب سے لے کر لاگ کی تفریق تک ہر تفصیل کی درست منصوبہ بندی کی جانی چاہیے۔

Nginx سرور بلاکس کب استعمال ہوتے ہیں؟

Nginx سرور بلاکس خاص طور پر ایک ہی سرور پر متعدد ویب موجودگیوں کا انتظام کرنے کی ضرورت کے وقت استعمال ہوتے ہیں۔ یہ کبھی دو چھوٹی کاروباری ویب سائٹس ہو سکتی ہیں، اور کبھی درجنوں کلائنٹ پروجیکٹس، ذیلی ڈومینز یا مائیکرو سروسز ہو سکتی ہیں۔ یہاں اہم نکتہ یہ ہے کہ ہر پروجیکٹ کو منطقی طور پر ایک دوسرے سے الگ رکھا جائے۔

• اگر آپ ایک ہی VPS پر متعدد ڈومینز کو ہاسٹ کرنا چاہتے ہیں۔
• اگر آپ www اور بغیر www ڈومینز کو ایک ہی کینونیکل ایڈریس کی طرف ری ڈائریکٹ کرنا چاہتے ہیں۔
• اگر آپ ذیلی ڈومینز کو مختلف فولڈروں یا ایپلیکیشنز سے جوڑنا چاہتے ہیں۔
• اگر آپ ہر سائٹ کے لیے علیحدہ SSL سرٹیفکیٹ اور سیکیورٹی پالیسی متعین کرنا چاہتے ہیں۔
• اگر آپ کلائنٹ پروجیکٹس کو علیحدہ لاگ فائلوں کے ساتھ ٹریک کرنا چاہتے ہیں۔
• اگر آپ Laravel، WordPress، سٹیٹک HTML، اور Node.js جیسی مختلف ایپلیکیشنز کو ایک ہی سرور پر چلانا چاہتے ہیں۔

مثال کے طور پر، ایک ڈیجیٹل ایجنسی کے لیے ایک ہی 4 GB RAM VPS پر 8 کم ٹریفک والی کاروباری ویب سائٹس کو ہاسٹ کرنا تکنیکی طور پر ممکن ہے۔ تاہم، ہر سائٹ کے لیے ٹریفک، ڈسک کا استعمال، PHP پروسیس کی تعداد، ڈیٹا بیس کا بوجھ اور بیک اپ کی تعدد کا حساب لگانا ضروری ہے۔ اگر پروجیکٹس زیادہ ٹریفک حاصل کر رہے ہیں یا وسائل کی علیحدگی اہم ہے تو مزید طاقتور VPS، کلاؤڈ سرور یا منظم ہوسٹنگ کے حل کا انتخاب کیا جانا چاہیے۔ اس وقت ویب ہوسٹنگ اور کاروباری ہوسٹنگ کے اختیارات کا موازنہ کیا جا سکتا ہے۔

شروع کرنے سے پہلے کی ضروریات

اس رہنما میں، ہم فرض کریں گے کہ آپ کے پاس Ubuntu یا Debian پر مبنی ایک Linux سرور ہے۔ کمانڈز تقسیم کے لحاظ سے چھوٹی تبدیلیاں دکھا سکتی ہیں؛ لیکن منطق ایک ہی ہے۔ پیداواری ماحول میں عمل کرنے سے پہلے ہمیشہ بیک اپ لیں۔ Nginx کی غلط کنفیگریشن تمام سائٹس کو عارضی طور پر ناقابل رسائی بنا سکتی ہے۔

تکنیکی تیاریوں کی ضرورت

• Root یا sudo کی اجازت کے ساتھ Linux صارف کا اکاؤنٹ۔
• انسٹال اور چل رہا Nginx سروس۔
• سرور IP ایڈریس کی طرف ری ڈائریکٹ کردہ کم از کم ایک ڈومین نام۔
• 80 اور 443 پورٹس کی فائر وال میں کھلی ہونا۔
• سائٹ کی فائلوں کے لیے منظم ڈائریکٹری کی ساخت۔
• SSL کے لیے درست سرٹیفکیٹ یا مفت Let’s Encrypt کا استعمال۔
• PHP پر مبنی ایپلیکیشنز کے لیے PHP-FPM کی تنصیب۔

DNS کی طرف A ریکارڈ کو بنیادی ڈومین کو IPv4 ایڈریس کی طرف ری ڈائریکٹ کرتا ہے، اور اگر AAAA ریکارڈ ہو تو IPv6 ایڈریس کی طرف۔ www جیسے ذیلی ڈومینز کے لیے CNAME یا A ریکارڈ استعمال کیا جا سکتا ہے۔ 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۔ Nginx کا روٹ ویلیو براہ راست public ڈائریکٹری کی طرف اشارہ کرنا چاہیے۔ اس طرح ایپلیکیشن کی فائلیں، .env جیسے حساس فائلیں اور بیک اپ انٹرنیٹ کے ذریعے براہ راست قابل رسائی نہیں ہوں گے۔

مثال کے طور پر ایک سٹیٹک ٹیسٹ پیج کے لیے ہر سائٹ کے فولڈر میں ایک سادہ index.html فائل رکھ سکتے ہیں۔ اس کے اندر سائٹ کا نام لکھ کر آپ یہ جلدی سے تصدیق کر سکتے ہیں کہ کون سا سرور بلاک چل رہا ہے۔ پیداواری ماحول میں، یہ فولڈرز کی ملکیت عام طور پر www-data صارف یا ڈیپلائی کرنے والے مخصوص صارف کے ساتھ ترتیب دی جاتی ہے۔ فائل کی اجازتوں میں، فولڈرز کے لیے 755، اور فائلز کے لیے 644 زیادہ تر سٹیٹک منظر ناموں کے لیے کافی ہیں۔ WordPress جیسے لکھنے کی ضرورت والے ایپلیکیشنز میں 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 کمانڈ استعمال کی جا سکتی ہے۔ اگر آپ مختلف صارف کے ساتھ ڈیپلائمنٹ کے عمل کرتے ہیں تو گروپ کی اجازتیں اس کے مطابق ترتیب دیں۔ پیداواری ماحول میں، 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 صفحہ آپ کی سائٹ پر فوقیت حاصل کرے تو آپ ڈیفالٹ کنفیگریشن کو غیر فعال کر سکتے ہیں۔ اس کے لیے /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 اور log کی ویلیو کو 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 کی کنفیگریشن

2026 کی SEO معیارات کے تحت HTTPS اب صرف ایک حفاظتی خصوصیت نہیں ہے، بلکہ صارف کے اعتماد اور تکنیکی معیار کی علامت ہے۔ براؤزر HTTP سائٹس کو غیر محفوظ کے طور پر نشان زد کرتے ہیں؛ ادائیگی، رکنیت، فارم یا انتظامی پینل پر مشتمل پروجیکٹس میں SSL کی ضرورت ہے۔ متعدد سائٹس کی ہوسٹنگ کے دوران ہر ڈومین کے لیے صحیح سرٹیفکیٹ کی شناخت ہونا ضروری ہے۔ Hostragons کے ذریعے SSL کی ضروریات کے لیے SSL سرٹیفکیٹس صفحے پر جا سکتے ہیں۔

اگر آپ Let’s Encrypt استعمال کر رہے ہیں تو Certbot کے ذریعے ہر ڈومین کے لیے سرٹیفکیٹ حاصل کیے جا سکتے ہیں۔ مثال کے طور پر، certbot --nginx -d site1.com -d www.site1.com کا حکم Nginx کی کنفیگریشن کو محسوس کرتا ہے اور خودکار طور پر HTTPS بلاک شامل کر دیتا ہے۔ تاہم، خودکار ترمیم کے بعد فائل کی جانچ کرنا ایک اچھی عادت ہے۔ غلط ری ڈائریکشن یا دہرانے والے سرور بلاک کے مسائل پیدا ہو سکتے ہیں۔

HTTPS کی کنفیگریشن میں عام طور پر 80 پورٹ کی ٹریفک کو 443 پورٹ کی طرف مستقل طور پر ری ڈائریکٹ کیا جاتا ہے۔ 301 ری ڈائریکشن SEO کے لحاظ سے مستقل ترجیحات کا اشارہ دیتی ہے۔ یہ طے کریں کہ آیا آپ www استعمال کریں گے یا نہیں اور تمام مختلف ورژنز کو ایک ہی کینونیکل ایڈریس پر جمع کریں۔ مثال کے طور پر، اگر آپ https://www.site1.com کے بجائے https://site1.com استعمال کریں گے تو دونوں HTTP اور HTTPS www ٹریفک کو بغیر www ایڈریس کی طرف ری ڈائریکٹ کریں۔ یہ کاپی مواد کے خطرے کو کم کرتا ہے۔

PHP اور WordPress سائٹس کے لیے Nginx سرور بلاکس

سٹیٹک HTML سائٹس میں کنفیگریشن سادہ ہوتی ہے؛ لیکن WordPress، Laravel یا خصوصی PHP ایپلیکیشنز میں PHP-FPM کے ساتھ انضمام کی ضرورت ہوتی ہے۔ اس صورت میں، index.php فائل کی تعریف کی جاتی ہے اور PHP کی درخواستیں متعلقہ سوکٹ کی طرف ری ڈائریکٹ کی جاتی ہیں۔ مثال کے طور پر، Ubuntu میں 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; } }

WordPress کے لیے مستقل روابط کے کام کرنے کے لیے try_files $uri $uri/ /index.php?$args کی ساخت اہم ہے۔ اس کے علاوہ xmlrpc.php کی رسائی، wp-login.php کی شرح کی حد، uploads ڈائریکٹری میں PHP کو چلانے سے روکنے جیسے حفاظتی اقدامات پر غور کیا جانا چاہیے۔ اگر آپ ایک ہی 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 کمپریشن، بڑے لاگ فائلیں اور ناکافی کیش کی ترتیبات سائٹ کی رفتار کو کم کر سکتی ہیں۔ گوگل کے صفحے کے تجربے کے اشارے صارف کے مرکوز ہیں؛ تیز جواب دینے والے، محفوظ اور مستحکم سائٹس بہتر کارکردگی کا مظاہرہ کرنے کا رجحان رکھتی ہیں۔

سب سے پہلے، ہر ڈومین کے لیے ایک ہی کینونیکل ورژن متعین کریں۔ HTTP سے HTTPS تک، www سے بغیر www یا اس کے برعکس ایک ہی اقدام میں ری ڈائریکشن کریں۔ زنجیر اس طرح نہیں ہونی چاہیے: http://site.com پہلے http://www.site.com، پھر https://www.site.com، پھر https://site.com۔ اس کے بجائے ایک ہی 301 کے ساتھ ہدف پر جانا زیادہ درست ہے۔

سٹیٹک فائلوں کے لیے cache-control ہیڈرز استعمال کیے جا سکتے ہیں۔ تصاویر، CSS اور JS فائلیں ایک مخصوص مدت تک براؤزر میں محفوظ کی جا سکتی ہیں۔ تاہم، بار بار تبدیل ہونے والی فائلوں میں فائل کے نام کی ورژننگ یا query string حکمت عملی استعمال کی جانی چاہیے۔ gzip کمپریشن HTML، CSS، JS، اور JSON جیسے متنی فائلوں میں بینڈوڈتھ کو کم کرتی ہے۔ زیادہ ٹریفک والی سائٹس کے لیے Nginx microcache، FastCGI cache، یا CDN کے استعمال پر غور کیا جا سکتا ہے۔ CDN اور عالمی رسائی کی ضروریات کے لیے CDN کیا ہے جیسے مواد کی طرف اشارہ کیا جا سکتا ہے۔

لاگ کی انتظامیہ اور نگرانی

متعدد سائٹس کی ہوسٹنگ میں لاگ کی انتظامیہ مسئلہ حل کرنے کی کلید ہے۔ علیحدہ لاگ فائلیں یہ واضح طور پر دکھاتی ہیں کہ کس سائٹ پر کیا خرابی پیش آئی۔ access_log وزیٹر کی درخواستوں کو ریکارڈ کرتا ہے، جبکہ error_log کنفیگریشن، اجازت، فائل نہ ملنے اور upstream غلطیوں کو ریکارڈ کرتا ہے۔ 502 Bad Gateway کی خرابی عموماً PHP-FPM یا بیک اینڈ سروس کے کنکشن سے متعلق ہوتی ہے۔ 403 Forbidden کی خرابی اجازت یا انڈیکس فائل کے مسئلے کی علامت ہو سکتی ہے۔ 404 Not Found کا مطلب ہے کہ فائل کا راستہ، ری رائٹ یا DNS کے بعد غلط روٹ مسئلہ ہو سکتا ہے۔

لاگ فائلوں کے بے حد بڑھنے سے روکنے کے لیے logrotate کی کنفیگریشن کو چیک کیا جانا چاہیے۔ چھوٹے پروجیکٹس کے لیے روزانہ یا ہفتہ وار گردش کافی ہو سکتی ہے۔ زیادہ ٹریفک والی سائٹس کے لیے مرکزی لاگ جمع کرنے، میٹرک ٹریکنگ، اور الرٹ سسٹمز کا استعمال کیا جانا چاہیے۔ ڈسک کا بھرا ہوا ہونا Nginx کو لاگ کرنے سے روک سکتا ہے، ڈیٹا بیس کو روک سکتا ہے، اور سائٹس کو ناقابل رسائی بنا سکتا ہے۔ اس لیے، ڈسک کے استعمال کے لیے حد کی قدریں متعین کرنا ایک عملی احتیاط ہے۔

عام غلطیاں اور فوری حل

Nginx سرور بلاکس کے ساتھ کام کرتے وقت کچھ غلطیاں تقریباً ہر پروجیکٹ میں پیش آ سکتی ہیں۔ ان کو جاننا انسٹالیشن کے وقت کو نمایاں طور پر کم کر سکتا ہے۔

• ڈومین غلط سائٹ کھول رہا ہے: server_name کے تصادم اور ڈیفالٹ سرور بلاک کی جانچ کریں۔
• 403 Forbidden کی خرابی: روٹ ڈائریکٹری، فائل کی اجازتیں، اور انڈیکس فائل کی موجودگی کو چیک کریں۔
• 404 Not Found کی خرابی: روٹ کے راستے اور try_files کے قاعدے کا جائزہ لیں۔
• 502 Bad Gateway کی خرابی: اس بات کی تصدیق کریں کہ PHP-FPM سروس چل رہی ہے اور سوکٹ کا راستہ درست ہے۔
• SSL سرٹیفکیٹ غلط سائٹ سے متعلق لگتا ہے: 443 پورٹ میں server_name اور سرٹیفکیٹ کی فائلوں کی جانچ کریں۔
• ری ڈائریکشن کا ایک چکر ہے: 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 سرور بلاک کے ذریعے ذیلی ڈومین کی نشریات ممکن ہیں؟

جی ہاں۔ 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 بلاک کا درخواست کو پکڑنا، یا 443 پر غلط SSL بلاک کا چلنا شامل ہیں۔ پہلے DNS ریکارڈز، پھر nginx -t آؤٹ پٹ، فعال sites-enabled لنکس اور متعلقہ access_log فائل کو چیک کریں۔