Nginx सर्वर ब्लॉक्स के साथ मल्टीसाइट

Nginx सर्वर ब्लॉक्स एक ऐसी तकनीक है जो आपको एक ही Nginx इंस्टॉलेशन पर कई डोमेन या वेबसाइट अलग-अलग सेटिंग्स के साथ होस्ट करने की सुविधा देती है। उदाहरण के लिए, एक ही VPS पर आप example.com, blog.example.com और dusri-site.com के लिए अलग-अलग रूट डायरेक्टरी, लॉग फाइल्स, SSL सर्टिफिकेट और PHP कॉन्फ़िगरेशन सेट कर सकते हैं। संक्षेप में, समाधान यह है कि हर वेबसाइट के लिए अलग डायरेक्टरी बनाएं, डोमेन के DNS रिकॉर्ड को सर्वर के IP से जोड़ें, /etc/nginx/sites-available में अलग सर्वर ब्लॉक बनाएं, उसे sites-enabled में लिंक करें, कॉन्फ़िगरेशन टेस्ट करें और फिर Nginx सर्विस को रीलोड करें।

इस गाइड में हम Nginx सर्वर ब्लॉक्स के जरिए एक से ज्यादा वेबसाइट को प्रोडक्शन स्तर पर होस्ट करने की प्रक्रिया को विस्तार से समझेंगे। लक्ष्य सिर्फ वेबसाइट चलाना नहीं है बल्कि एक ऐसा प्रबंधनीय, सुरक्षित, तेज, बैकअप योग्य और स्केलेबल सिस्टम बनाना है। खासकर एजेंसियां, डेवलपर्स, ई-कॉमर्स मालिक, मल्टी-ब्रांड कंपनियां और ऐसे सिस्टम एडमिन्स जो एक ही सर्वर पर कई प्रोजेक्ट्स चलाते हैं, उनके लिए उपयोगी टिप्स साझा करेंगे। यदि आपके पास अभी सर्वर नहीं है तो VPS सर्वर के लिए VPS सर्वर और डोमेन रजिस्ट्रेशन के लिए डोमेन पंजीकरण पेज देख सकते हैं।

Nginx सर्वर ब्लॉक्स क्या हैं?

Nginx सर्वर ब्लॉक्स, Nginx की कॉन्फ़िगरेशन में defined server blocks होते हैं जो यह तय करते हैं कि आने वाले HTTP या HTTPS रिक्वेस्ट किस वेबसाइट को भेजे जाएं। यह Apache के VirtualHost के समान है। जब कोई यूजर ब्राउजर में डोमेन नाम टाइप करता है, तो DNS उस नाम को सर्वर के IP एड्रेस पर रिज़ॉल्व करता है। इसके बाद Nginx Host हेडर चेक करता है और server_name से मेल खाते सर्वर ब्लॉक को एक्टिव करता है।

इस तरह एक ही IP एड्रेस और फिजिकल या वर्चुअल सर्वर पर कई अलग-अलग वेबसाइट्स होस्ट की जा सकती हैं। हर वेबसाइट के लिए अलग root directory, access log, error log, redirect rules, SSL सर्टिफिकेट, cache policy और security सेटिंग्स दी जा सकती हैं। उदाहरण के लिए, आपकी कंपनी की साइट /var/www/kurumsal/public में, ब्लॉग /var/www/blog/public में और टेस्ट एन्वायरनमेंट /var/www/staging/public में हो सकता है।

Nginx की यह व्यवस्था बहुत कुशल है क्योंकि इसकी इवेंट-ड्रिवन आर्किटेक्चर की वजह से यह बहुत कम रिसोर्स में ज्यादा कनेक्शंस मैनेज कर सकता है। इसलिए यह shared hosting, VPS, क्लाउड सर्वर और हाई ट्रैफिक एप्लिकेशन के लिए पसंदीदा होता है। परंतु मल्टी-साइट होस्टिंग के लिए फ़ाइल परमिशन्स, DNS रिकार्ड्स, SSL सेटअप और अलग-अलग लॉग फाइल्स का सही प्लानिंग बेहद जरूरी है।

Nginx सर्वर ब्लॉक्स कब इस्तेमाल करें?

Nginx सर्वर ब्लॉक्स खासतौर पर तब उपयोगी होते हैं जब आपको एक ही सर्वर पर कई वेबसाइट्स या वेब एप्लिकेशन मैनेज करनी हों। यह दो छोटे बिजनेस साइट्स से लेकर कई ग्राहक प्रोजेक्ट्स, सबडोमेन या माइक्रोसर्विसेज तक हो सकते हैं। महत्वपूर्ण यह है कि हर प्रोजेक्ट एक-दूसरे से तार्किक रूप से अलग हो।

अगर आप एक से ज्यादा डोमेन एक ही VPS पर होस्ट करना चाहते हैं।
www और non-www डोमेन को एक ही canonical URL पर रीडायरेक्ट करना हो।
सबडोमेन्स को अलग-अलग फोल्डर्स या एप्लिकेशन से लिंक करना हो।
हर वेबसाइट के लिए अलग SSL सर्टिफिकेट और सुरक्षा नीति लागू करनी हो।
क्लाइंट प्रोजेक्ट्स के लिए अलग-अलग लॉग फाइल्स रखना हो।
Laravel, WordPress, Static HTML या Node.js जैसी अलग तकनीकों को एक ही सर्वर पर चलाना हो।

उदाहरण के लिए, एक डिजिटल एजेंसी एक 4GB RAM वाले VPS पर 8 कम ट्रैफिक वाली कॉर्पोरेट साइट्स होस्ट कर सकती है। लेकिन हर साइट के ट्रैफिक, डिस्क यूसेज, PHP प्रोसेस, डेटाबेस लोड और बैकअप की जरूरतों को ध्यान में रखना जरूरी है। अगर ट्रैफिक ज्यादा हो या रिसोर्स आइसोलेशन महत्वपूर्ण हो तो बेहतर VPS, क्लाउड सर्वर या Managed Hosting समाधान लेना चाहिए। इस मामले में वेब होस्टिंग और कॉर्पोरेट होस्टिंग को भी देख सकते हैं।

शुरू करने से पहले आवश्यकताएँ

यह गाइड 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 में root डायरेक्टरी सीधे public फोल्डर को पॉइंट करनी चाहिए। इससे प्रोजेक्ट की फाइल्स, .env जैसे संवेदनशील डॉक्यूमेंट और बैकअप्स वेब से सीधे एक्सेस नहीं होंगे।

हर साइट फोल्डर में एक साधारण index.html टेस्ट पेज रखकर आप यह सुनिश्चित कर सकते हैं कि कौन सा सर्वर ब्लॉक एक्टिव है। प्रोडक्शन में इन फोल्डर्स का मालिकाना www-data यूजर या डिप्लॉयमेंट यूजर को देना चाहिए। फाइल परमिशन डायरेक्टरी के लिए 755 और फाइल्स के लिए 644 सेट करना सामान्यत: पर्याप्त होता है। WordPress जैसी ऐप्स के लिए uploads जैसी डायरेक्ट्री को अलग से हैंडल करना होगा।

स्टेप-बाय-स्टेप Nginx सर्वर ब्लॉक बनाना

नीचे दिए गए उदाहरण site1.com पर आधारित हैं। आप इसी प्रक्रिया को दूसरी और तीसरी साइट के लिए भी दोहरा सकते हैं। मुख्य बात यह है कि हर साइट के लिए unique server_name, root और log फाइल्स हों।

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 में आम प्रैक्टिस है कि inactive कॉन्फ़िग फाइलें /etc/nginx/sites-available में रखें और active कॉन्फ़िग के लिए symbolic link /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;
}
}

यह कॉन्फ़िग 80 पोर्ट पर HTTP ट्रैफिक सुनता है, server_name से डोमेन बताता है, root में वेब फाइल्स की जगह सेट करता है, index डिफ़ॉल्ट फाइल तय करता है और try_files से फाइल न मिलने पर 404 लौटाता है। स्टैटिक साइट्स के लिए यह पर्याप्त है।

3. साइट को सक्रिय करें

कॉन्फ़िग को सक्रिय करने के लिए symbolic लिंक बनाएं: 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 कमांड से syntax चेक करें। अगर टेस्ट सफल हो तो sudo systemctl reload nginx से Nginx को बिना डाउनटाइम के रीलोड करें। reload कमांड restart से बेहतर है क्योंकि यह चालू कनेक्शंस को प्रभावित नहीं करता।

अगर टेस्ट फेल हो तो एरर में फाइल और लाइन नंबर मिलेगा। आम गलतियों में मिसिंग सेमीकोलन, गलत ब्रैकेट्स, फोल्डर पाथ की गलती या server_name के टकराव होते हैं। एरर सही किए बिना रीलोड न करें।

दूसरी और तीसरी साइट जोड़ना

एक से ज्यादा साइट होस्ट करने का फायदा यह है कि पहली बार सही सेटअप के बाद बाकी साइट्स के लिए प्रक्रिया दोहराना आसान हो जाता है। site2.com के लिए /var/www/site2.com/public फोल्डर बनाएं, /etc/nginx/sites-available/site2.com फाइल लिखें, root और लॉग फाइल के नाम बदलें, symbolic लिंक बनाएं और 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 सेटअप में आमतौर पर HTTP (port 80) ट्रैफिक को 443 पर रीडायरेक्ट कर दिया जाता है। 301 रीडायरेक्शन SEO के लिए स्थायी सिग्नल होता है। www के इस्तेमाल या न करने का निर्णय लें और सभी वैरिएंट्स को एक canonical URL पर कंसॉलिडेट करें। जैसे https://www.site1.com की जगह https://site1.com इस्तेमाल करना हो तो HTTP और HTTPS दोनों के www ट्रैफिक को non-www पर भेजें ताकि डुप्लीकेट कंटेंट का खतरा न रहे।

PHP और WordPress साइट्स के लिए Nginx सर्वर ब्लॉक

स्टैटिक HTML साइट्स की तुलना में WordPress, Laravel या कस्टम PHP ऐप्स के लिए PHP-FPM के साथ इंटीग्रेशन जरूरी होता है। इस स्थिति में index.php शामिल किया जाता है और PHP रिक्वेस्ट्स को PHP-FPM सॉकेट पर भेजा जाता है। उदाहरण के तौर पर 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 होस्टिंग के लिए WordPress होस्टिंग बेहतर विकल्प हो सकता है।

Nginx सर्वर ब्लॉक और Apache VirtualHost की तुलना

Nginx और Apache दोनों एक ही मकसद के लिए अलग आर्किटेक्चर का इस्तेमाल करते हैं। दोनों एक ही सर्वर पर बहु-साइट होस्ट कर सकते हैं। चुनाव एप्लिकेशन की जरूरत, प्रबंधन शैली और परफॉर्मेंस अपेक्षाओं पर निर्भर करता है।

Nginx सर्वर ब्लॉक और Apache VirtualHost की तुलना
मापदंड	Nginx सर्वर ब्लॉक्स	Apache VirtualHost
परफॉर्मेंस	हाई कनेक्शन पर कम संसाधन उपयोग के साथ बेहतर प्रदर्शन।	मॉड्यूल और प्रोसेस मॉडल के कारण ज्यादा संसाधन ले सकता है।
कॉन्फ़िगरेशन	सेंट्रलाइज्ड और सिंपल सेटअप।	.htaccess के जरिए डायरेक्टरी स्तर पर लचीलापन।
स्टैटिक फाइल सर्विंग	बहुत तेज़ और एफिशिएंट।	अच्छा प्रदर्शन लेकिन Nginx से हल्का नहीं।
PHP सपोर्ट	PHP-FPM के माध्यम से।	mod_php या PHP-FPM दोनों विकल्प।
उपयोग केस	रिवर्स प्रॉक्सी, स्टैटिक कंटेंट, हाई ट्रैफिक और आधुनिक एप्लिकेशन के लिए।	.htaccess पर निर्भर पुरानी एप्लिकेशन और शेयर होस्टिंग के लिए।

अगर आपकी एप्लिकेशन heavily .htaccess पर निर्भर है तो Apache बेहतर लग सकता है। पर हाई ट्रैफिक, रिवर्स प्रॉक्सी, कैशिंग और आधुनिक डिप्लॉयमेंट के लिए Nginx अधिकांश प्रोजेक्ट्स में बेहतर विकल्प है। कुछ सेटअप में Nginx रिवर्स प्रॉक्सी के रूप में और Apache बैकएंड एप्लिकेशन सर्वर के रूप में साथ में चलाए जाते हैं।

सुरक्षा के लिए बेहतरीन प्रैक्टिस

एक ही सर्वर पर कई साइट होस्ट करना लागत कम करता है लेकिन सुरक्षा जिम्मेदारी बढ़ाता है। किसी एक साइट की कमजोरी दूसरे साइट्स को नुकसान न पहुंचाए इसके लिए आइसोलेशन और न्यूनतम अधिकार नीति जरूरी है।

हर साइट के लिए अलग डेटाबेस और यूजर बनाएं।
वेब रूट डायरेक्टरी को सिर्फ public फोल्डर तक सीमित करें।
बैकअप, .env, .git, config और SQL फाइल्स को वेब एक्सेस से बाहर रखें।
SSL सर्टिफिकेट्स को नियमित रूप से रिन्यू करें और HTTPS रीडायरेक्शन अनिवार्य करें।
सर्वर पर UFW या अन्य फ़ायरवॉल लगाएं; केवल जरूरी पोर्ट खोलें।
Nginx और OS अपडेट्स समय-समय पर करें।
हर साइट के लिए अलग access_log और error_log रखें।
एडमिन पैनल्स पर IP बेस्ड एक्सेस कंट्रोल या दोहरी प्रमाणीकरण लगाएं।
फाइल परमिशन में 777 जैसी व्यापक अनुमतियों से बचें।

साथ ही X-Frame-Options, X-Content-Type-Options, Referrer-Policy और Content-Security-Policy जैसे सुरक्षा हेडर जोड़ना फायदेमंद होता है। हालांकि Content-Security-Policy गलत सेट करने पर जावास्क्रिप्ट और CSS फाइल्स ब्लॉक हो सकती हैं, इसलिए पहले टेस्ट एन्वायरनमेंट में आज़माएं। सुरक्षा से जुड़ी और जानकारी के लिए वेब साइट सुरक्षा पढ़ें।

परफॉर्मेंस और SEO के लिए ध्यान देने वाली बातें

Nginx सर्वर ब्लॉक्स केवल वेबसाइट होस्टिंग ही नहीं बल्कि परफॉर्मेंस और SEO क्वालिटी को भी प्रभावित करते हैं। गलत रीडायरेक्शन चेन, canonical टैग्स की गलती, gzip या brotli कम्प्रेशन का अभाव, भारी लॉग फाइल्स और खराब कैश सेटिंग्स वेबसाइट की स्पीड धीमी कर सकते हैं। Google का पेज एक्सपीरियंस यूजर-फ्रेंडली, तेज और सुरक्षित साइट्स को बढ़ावा देता है।

सबसे पहले हर डोमेन के लिए एक ही canonical URL निर्धारित करें। HTTP से HTTPS और www से non-www (या इसके विपरीत) एक स्टेप में 301 रीडायरेक्शन करें। रीडायरेक्शन चेन जैसे http://site.com → http://www.site.com → https://www.site.com → https://site.com से बचें।

स्टैटिक फाइल्स के लिए cache-control हेडर लगाएं। इमेजेस, CSS और JS को ब्राउज़र में कुछ समय के लिए स्टोर करें। बार-बार बदलने वाली फाइल्स में वर्जनिंग या query string रणनीति अपनाएं। gzip कम्प्रेशन HTML, CSS, JS और JSON फाइल्स की बैंडविड्थ बचाता है। हाई ट्रैफिक साइट्स के लिए Nginx microcache, FastCGI cache या CDN का इस्तेमाल लाभदायक होता है। CDN और ग्लोबल एक्सेस के लिए CDN क्या है पढ़ें।

लॉग प्रबंधन और मॉनिटरिंग

मल्टी-साइट होस्टिंग में लॉग्स का सही प्रबंधन समस्या समाधान की कुंजी है। अलग-अलग लॉग फाइल्स से पता चलता है कि किस साइट पर क्या समस्या है। access_log यूजर रिक्वेस्ट रिकॉर्ड करता है और error_log कॉन्फ़िग, परमिशन, फाइल न मिलना या PHP-FPM त्रुटियों को दर्शाता है। 502 Bad Gateway एरर अक्सर PHP-FPM या बैकएंड कनेक्शन से जुड़ा होता है। 403 Forbidden आमतौर पर परमिशन या इंडेक्स फाइल की कमी से होता है। 404 Not Found फाइल पाथ, रीराइट या DNS के बाद गलत root सेटिंग की ओर इशारा करता है।

लॉग फाइल्स के अनियंत्रित बढ़ने से बचने के लिए logrotate कॉन्फ़िगरेशन जरूरी है। छोटे प्रोजेक्ट्स में डायली या वीकली रोटेशन पर्याप्त होता है। हाई ट्रैफिक साइट्स के लिए केंद्रीकृत लॉग कलेक्शन, मेट्रिक्स मॉनिटरिंग और अलर्ट सिस्टम लगाना चाहिए। डिस्क फुल होने से Nginx लॉग नहीं लिख पाता, DB रुक जाता है और साइट डाउन हो सकती है। इसलिए डिस्क स्पेस मॉनिटरिंग के लिए थ्रेशोल्ड सेट करें।

आम गलतियां और त्वरित समाधान

Nginx सर्वर ब्लॉक्स के साथ काम करते वक्त कुछ सामान्य त्रुटियां अक्सर सामने आती हैं। इन्हें जानना इंस्टॉलेशन का समय बचाता है।

गलत साइट खुल रही है: server_name टकराव और default सर्वर ब्लॉक चेक करें।
403 Forbidden एरर: root डायरेक्टरी, फाइल परमिशन और index फाइल मौजूदगी जांचें।
404 Not Found: root पाथ और try_files रूल की समीक्षा करें।
502 Bad Gateway: PHP-FPM सर्विस स्टेटस और सॉकेट पाथ सही है या नहीं देखें।
SSL सर्टिफिकेट गलत साइट पर दिख रहा है: 443 पोर्ट के server_name और सर्टिफिकेट फाइल्स जांचें।
रीडायरेक्शन लूप: HTTP-HTTPS और www रीडायरेक्शन नियम सरल बनाएं।
Nginx रीलोड न हो: sudo nginx -t आउटपुट में लाइन नंबर के अनुसार सिंटैक्स त्रुटि ठीक करें।

अनुभवी एडमिन्स की एक चेकलिस्ट होती है: DNS सही है? Nginx कॉन्फ़िग एक्टिव है? root फोल्डर मौजूद है? परमिशन ठीक हैं? सर्विस टेस्ट पास हो गई? लॉग क्या बता रहे हैं? इस क्रम में जांचने से बिना घबराए तेज समाधान निकलता है।

प्रोडक्शन के लिए प्रैक्टिकल चेकलिस्ट

लाइव करने से पहले नीचे दिए गए पॉइंट्स से हर साइट की जांच करें। खासकर क्लाइंट प्रोजेक्ट्स में डिलीवरी से पहले इन्हें डॉक्यूमेंट करना प्रोफेशनलिज्म दिखाता है।

डोमेन का A या AAAA रिकॉर्ड सही IP पर पॉइंट कर रहा है।
www और non-www में से किसी एक को canonical चुना गया है।
HTTP ट्रैफिक HTTPS पर 301 से रीडायरेक्ट हो रहा है।
SSL सर्टिफिकेट वैध है और ऑटो रिन्यूअल चालू है।
हर साइट के लिए अलग root और लॉग फाइल्स डिफाइन की गई हैं।
sudo nginx -t से कॉन्फ़िगरेशन टेस्ट हो चुका है।
बैकअप प्लान बना है और रिस्टोर टेस्ट किया गया है।
फाइल परमिशन न्यूनतम अधिकार नीति के अनुसार हैं।
फ़ायरवॉल में सिर्फ जरूरत के पोर्ट खुले हैं।
एरर लॉग कम से कम 15 मिनट तक लाइव मॉनिटर किए गए हैं।

यह सूची छोटी लग सकती है लेकिन असल में यह डाउनटाइम के जोखिम को काफी कम कर देती है। खासकर SSL रिन्यूअल, DNS चेक और लॉग मॉनिटरिंग कई अनदेखी गलतियों को जल्दी पकड़ लेती हैं।

निष्कर्ष

Nginx सर्वर ब्लॉक्स एक ही सर्वर पर कई वेबसाइट्स को व्यवस्थित, सुरक्षित और बेहतर प्रदर्शन के साथ होस्ट करने का एक प्रभावी तरीका है। सही डायरेक्टरी स्ट्रक्चर, अलग-अलग कॉन्फ़िग फाइल्स, स्पष्ट रीडायरेक्शन नियम, HTTPS का उपयोग, लॉग अलग रखना और नियमित टेस्टिंग से मल्टी-साइट मैनेजमेंट बेहद कुशल बन जाता है। छोटे पोर्टफोलियो से लेकर बड़े मल्टी-क्लाइंट प्रोजेक्ट्स तक ये सिद्धांत लागू होते हैं।

अगर आप नई वेबसाइट लॉन्च कर रहे हैं तो पहले डोमेन, सर्वर रिसोर्स और SSL जरूरतों को स्पष्ट करें। फिर ऊपर दी गई चेकलिस्ट के अनुसार Nginx सेटअप करें। और अगर आप ज्यादा मैनेजेबल सेटअप चाहते हैं तो Hostragons के होस्टिंग पैकेज, VPS सर्वर और SSL प्रमाणपत्र विकल्प देखें और अपनी जरूरत के अनुसार शुरुआत करें।

अक्सर पूछे जाने वाले प्रश्न

Nginx सर्वर ब्लॉक्स के साथ कितनी वेबसाइट होस्ट की जा सकती हैं?

तकनीकी रूप से Nginx के जरिए एक ही सर्वर पर कई वेबसाइट्स होस्ट की जा सकती हैं; सीमा मुख्यतः CPU, RAM, डिस्क, ट्रैफिक, डेटाबेस लोड और PHP-FPM क्षमता पर निर्भर करती है। कम ट्रैफिक वाली स्टैटिक साइट्स के लिए कई साइट्स संभव हैं, लेकिन भारी ट्रैफिक वाली WordPress या ई-कॉमर्स साइट्स के लिए कम संख्या बेहतर होती है।

क्या हर साइट के लिए अलग SSL सर्टिफिकेट जरूरी है?

हाँ, यदि हर डोमेन या सबडोमेन HTTPS पर चलाना है तो उसे सर्टिफिकेट में शामिल करना होगा। आप अलग-अलग सर्टिफिकेट इस्तेमाल कर सकते हैं या SAN (Subject Alternative Name) या wildcard सर्टिफिकेट भी चुन सकते हैं। मुख्य बात यह है कि Nginx के 443 पोर्ट वाले सर्वर ब्लॉक में सही सर्टिफिकेट फाइल सही डोमेन के लिए सेट हो।

Kya Nginx server block ke saath subdomain bhi host kar sakte hain?

हाँ, blog.site.com या panel.site.com जैसे सबडोमेन के लिए अलग server_name सेट कर सकते हैं और अलग root डायरेक्टरी या बैकएंड एप्लिकेशन पर रीडायरेक्ट कर सकते हैं। DNS में संबंधित सबडोमेन के लिए A या CNAME रिकॉर्ड बनाना जरूरी है।

sites-available और sites-enabled में क्या फर्क है?

sites-available वह डायरेक्टरी है जहां सभी उपलब्ध कॉन्फ़िगरेशन फाइल्स रखी जाती हैं; sites-enabled में वे कॉन्फ़िगरेशन होते हैं जो सक्रिय हैं। आमतौर पर sites-enabled में sites-available की फाइल का symbolic लिंक होता है। इससे साइट्स को एक्टिव या डीएक्टिव करना आसान होता है।

गलत साइट खुल रही है तो समस्या कहां हो सकती है?

सबसे आम कारण हैं DNS का गलत IP पर पॉइंट होना, server_name सेटिंग में गलती, default Nginx ब्लॉक का रिक्वेस्ट पकड़ लेना, या 443 पोर्ट पर गलत SSL ब्लॉक का एक्टिव होना। पहले DNS रिकॉर्ड, फिर nginx -t आउटपुट, सक्रिय sites-enabled लिंक और संबंधित access_log फाइल जांचें।

Nginx सर्वर ब्लॉक्स के साथ एक ही सर्वर पर कई वेबसाइट होस्ट करें