Nginx സേർവർ ബ്ലോകുകൾ ഉപയോഗിച്ച് ഒരേ സെർവറിൽ പല വെബ്‌സൈറ്റുകൾ ഹോസ്റ്റ് ചെയ്യൽ

Nginx സേർവർ ബ്ലോകുകൾ (Virtual Hosts) എന്നത് ഒരേ Nginx സെർവർ ഇൻസ്റ്റാൾ ചെയ്തിരിക്കുന്നിടത്ത് പല ഡൊമെയ്‌നുകളും വെബ്‌സൈറ്റുകളും ഓരോതിനും വേർതിരിച്ചുള്ള സജ്ജീകരണങ്ങളോടെ ഹോസ്റ്റ് ചെയ്യാൻ സഹായിക്കുന്ന ഒരു സാങ്കേതിക സംവിധാനമാണ്. ഉദാഹരണത്തിന്, ഒരേ VPS-ൽ example.com, blog.example.com, രണ്ടാം-സൈറ്റ്.com എന്നീ ഡൊമെയ്‌നുകൾക്ക് വ്യത്യസ്ത റൂട്ടുകൾ, ലോഗ് ഫയലുകൾ, SSL സർട്ടിഫിക്കറ്റുകൾ, PHP ക്രമീകരണങ്ങൾ എന്നിവ നിർദ്ദേശിക്കാം. എന്നെല്ലാം സാരാംശത്തിൽ, ഓരോ സൈറ്റിനും വേർതിരിച്ചുള്ള ഡയറക്ടറി സൃഷ്ടിച്ച്, ഡൊമെയ്ൻ നെയിം സിസ്റ്റം (DNS) റെക്കോർഡുകൾ സെർവർ IP-യിലേക്ക് പോയിന്റ് ചെയ്ത്, /etc/nginx/sites-available എന്നിടത്ത് വേർതിരിച്ച സേർവർ ബ്ലോക്ക് ഫയൽ ഉണ്ടാക്കി, അതിനെ sites-enabled ഡയറക്ടറിയിലേക്ക് സിംബോളിക് ലിങ്ക് ചെയ്യുകയും, സജ്ജീകരണം ടെസ്റ്റ് ചെയ്ത് Nginx സർവീസ് റീലോഡ് ചെയ്യുകയുമാണ് ചെയ്യേണ്ടത്.

ഈ ഗൈഡിൽ Nginx സേർവർ ബ്ലോകുകൾ ഉപയോഗിച്ച് പല വെബ്‌സൈറ്റുകളും പ്രൊഡക്ഷൻ പരിസ്ഥിതിയിൽ എങ്ങനെ ഹോസ്റ്റ് ചെയ്യാമെന്ന് വിശദമായി പരിഗണിക്കും. ലക്ഷ്യം വെബ്‌സൈറ്റ് ഓൺലൈൻ ചെയ്യുക മാത്രമല്ല, അത് സുരക്ഷിതവും മാനേജുചെയ്യാനും എളുപ്പവുമാക്കുന്നതും വേഗതയേറിയതും ബാക്കപ്പ് എടുക്കാവുന്നതുമായതിനും തുല്യമായിരിക്കണം. പ്രത്യേകിച്ച് ഡിജിറ്റൽ ഏജൻസികൾ, ഡെവലപ്പർമാർ, ഇ-കൊമേഴ്സ് ഉടമകൾ, നിരവധി ബ്രാൻഡുകൾ കൈകാര്യം ചെയ്യുന്ന സ്ഥാപനങ്ങൾ, ഒറ്റ സെർവറിൽ പല പ്രോജക്റ്റുകളും പ്രവർത്തിപ്പിക്കുന്ന സിസ്റ്റം അഡ്മിനിസ്‌ട്രേറ്റർമാർക്ക് പ്രായോഗിക മാർഗങ്ങൾ പങ്കുവെക്കുന്നു. നിങ്ങൾക്ക് VPS അല്ലെങ്കിൽ ഡൊമെയ്ൻ ഇല്ലെങ്കിൽ VPS സർവർയും ഡൊമെയ്ൻ രജിസ്്ട്രേഷൻവുൾള പേജുകൾ പരിശോധിക്കാൻ കഴിയും.

Nginx സേർവർ ബ്ലോകുകൾ എന്താണ്?

Nginx സേർവർ ബ്ലോകുകൾ Nginx കോൺഫിഗറേഷനിലെ server ബ്ലോക്കുകളാണ്, HTTP/HTTPS അഭ്യർത്ഥനകൾ ഏത് സൈറ്റിലേക്ക് നയിക്കണമെന്ന് നിർണ്ണയിക്കുന്ന ഘടകങ്ങൾ. Apache-യിലെ VirtualHost-നെപ്പോലെ പ്രവർത്തിക്കുന്നു. ഒരു യൂസർ ബ്രൗസറിൽ ഡൊമെയ്ൻ നെയിം നൽകുമ്പോൾ DNS അത് സെർവറിന്റെ IP-യിലേക്ക് പരിഭാഷപ്പെടുത്തും. പിന്നീട് Nginx Host ഹെഡറിന്റെ അടിസ്ഥാനത്തിൽ server_name-ന് അനുയോജ്യമായ ബ്ലോക്ക് പ്രവർത്തിപ്പിക്കും.

ഇതുവഴി ഒരേ IP വിലാസത്തിലോ ഫിസിക്കൽ അല്ലെങ്കിൽ വിർച്വൽ സെർവറിലോ അനേകം വെബ്‌സൈറ്റുകൾ സജ്ജമാക്കാം. ഓരോ സൈറ്റിനും വ്യത്യസ്ത root ഡയറക്ടറി, access_log, error_log, റീഡൈറക്ഷൻ നിയമങ്ങൾ, SSL സർട്ടിഫിക്കറ്റ്, ക്യാഷെ നയം, സുരക്ഷാ നയം എന്നിവ നിർവഹിക്കാം. ഉദാഹരണത്തിന്, നിങ്ങളുടെ കോർപ്പറേറ്റ് സൈറ്റ് /var/www/kurumsal/public-ൽ, ബ്ലോഗ് /var/www/blog/public-ൽ, ടെസ്റ്റ് എൻവയ്റൺമെന്റ് /var/www/staging/public-ൽ സൂക്ഷിക്കാം.

Nginx ഈ ഘടനയിൽ വളരെ ഫലപ്രദമാണ്, കാരണം ഇത് event-driven ആർക്കിടെക്ചർ ഉപയോഗിച്ച് ഉയർന്ന സമകാലിക ബന്ധങ്ങൾ കുറഞ്ഞ റിസോഴ്‌സ് ഉപയോഗത്തോടെ കൈകാര്യം ചെയ്യുന്നു. അതിനാൽ ഷെയർഡ് ഹോസ്റ്റിംഗ്, 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-ലെ root പാത്ത് public ഡയറക്ടറിയെ സൂചിപ്പിക്കണം. ഇതുവഴി ആപ്ലിക്കേഷൻ ഫയലുകൾ, .env പോലുള്ള സെൻസിറ്റിവ് ഫയലുകൾ, ബാക്കപ്പ് ഫയലുകൾ വെബ് വഴി നേരിട്ട് ആക്‌സസ് ചെയ്യപ്പെടാതിരിക്കും.

ഒരു ലളിതമായ സ്റ്റാറ്റിക് ടെസ്റ്റ് പേജ് ആയി ഓരോ സൈറ്റിനും index.html ഫയൽ ചേർക്കാം. അതിൽ സൈറ്റ് നാമം എഴുതിയാൽ ഏത് സേർവർ ബ്ലോക്ക് പ്രവർത്തിക്കുന്നെന്ന് എളുപ്പം തിരിച്ചറിയാം. പ്രൊഡക്ഷൻ എൻവയിർമെന്റിൽ ഈ ഡയറക്ടറികളുടെ ഉടമസ്ഥത സാധാരണയായി www-data യൂസർ അല്ലെങ്കിൽ ഡിപ്ലോയ്മെന്റ് നടത്തുന്ന പ്രത്യേക യൂസർ ആയിരിക്കും. ഫയൽ അനുമതികൾ സാധാരണയായി 755 (ഡയറക്ടറികൾക്ക്) 644 (ഫയലുകൾക്ക്) മതിയാകും. WordPress പോലെയുള്ള എഴുതൽ ആവശ്യമായ ആപ്ലിക്കേഷനുകളിൽ uploads പോലുള്ള ഡയറക്ടറികൾക്ക് പ്രത്യേക പരിഗണന വേണം.

പടി പടിയായി Nginx സേർവർ ബ്ലോക്ക് സജ്ജമാക്കൽ

താഴെ കൊടുത്തിരിക്കുന്ന ഘട്ടങ്ങൾ site1.com എന്ന സൈറ്റിന്റെ ഉദാഹരണത്തിലാണ്. ഇതേ രീതിയിൽ രണ്ടാമത്, മൂന്നാമത് മറ്റ് സൈറ്റുകൾക്കും ആവർത്തിക്കാം. പ്രധാനമാകുന്നത് ഓരോ സൈറ്റിനും വ്യത്യസ്തമായ 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-ൽ സാധാരണ പ്രാക്ടീസ് sites-available എന്നിടത്ത് കോൺഫിഗർ ഫയലുകൾ സൂക്ഷിച്ച്, 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 ബ്ലോക്ക് ചേർക്കുകയും ചെയ്യും. എന്നാൽ ഓട്ടോമാറ്റിക് മാറ്റങ്ങൾ പരിശോധിക്കുന്നതാണ് നല്ല ശീലമെന്ന് ശ്രദ്ധിക്കണം. തെറ്റായ റീഡൈരക്ഷണങ്ങളും ഡുപ്ലിക്കറ്റ് server ബ്ലോക്കുകളും ഉണ്ടാകാം.

HTTPS ക്രമീകരണത്തിൽ സാധാരണയായി 80 പോർട്ട് 443 പോർട്ടിലേക്ക് സ്ഥിരമായി റീഡൈരക്ട് ചെയ്യുന്നു. 301 റീഡൈരക്ഷൻ SEO-വിന് നല്ലതാണ്. www ഉള്ളതോ അല്ലാതെയോ ഒറ്റ കാനോണിക്കൽ വിലാസം തീരുമാനിച്ച് എല്ലാ ട്രാഫിക്കും അവിടെ കൊണ്ടുവരിക. ഉദാഹരണത്തിന് https://www.site1.com എന്നതിന് പകരം https://site1.com ഉപയോഗിക്കുകയാണെങ്കിൽ www ഉള്ള HTTP, HTTPS ട്രാഫിക്ക് 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 ഹോസ്റ്റിംഗ് പരിഹാരങ്ങളായി WordPress ഹോസ്റ്റിംഗ് പരിഗണിക്കാം.

Nginx സേർവർ ബ്ലോക്കുകൾ vs Apache VirtualHost

Nginx, Apache രണ്ടും ഒരേ ലക്ഷ്യത്തിനെത്തുന്നവയാണ്, പക്ഷേ വ്യത്യസ്ത ആർക്കിടെക്ചറുകളോടെ. ഒരേ സെർവറിൽ പല സൈറ്റുകളും ഹോസ്റ്റ് ചെയ്യാൻ ഇരുവരും കഴിയും. തിരഞ്ഞെടുപ്പ് ആപ്ലിക്കേഷൻ ആവശ്യകതകൾ, മാനേജ്മെന്റ് രീതികൾ, പ്രകടന പ്രതീക്ഷ എന്നിവ അനുസരിച്ചാണ്.

.htaccess നിബന്ധനകളിൽ ആശ്രിതമായ ആപ്ലിക്കേഷനുകൾ ഉള്ളവർക്ക് Apache കൂടുതൽ എളുപ്പമാകാം. എന്നാൽ ഉയർന്ന ട്രാഫിക്, റിവേഴ്സ് പ്രോക്സി, ക്യാഷിംഗ്, ആധുനിക ഡിപ്പ്ലോയ്മെന്റ് ഫ്ലോമുകൾക്കായി Nginx മിക്ക പ്രോജക്റ്റുകളിലും മികച്ചതാണ്. ചില സാഹചര്യങ്ങളിൽ Nginx റിവേഴ്സ് പ്രോക്സിയായി, Apache ബാക്ക്‌എൻഡ് ആപ്ലിക്കേഷൻ സർവറായി ചേർന്ന് പ്രവർത്തിക്കാം.

സുരക്ഷക്കുള്ള മികച്ച പ്രാക്ടീസുകൾ

ഒറ്റ സെർവറിൽ പല സൈറ്റുകളും ഹോസ്റ്റ് ചെയ്യുന്നത് ചെലവ് കുറയ്ക്കുന്നു, പക്ഷേ സുരക്ഷാ ബാധ്യത വർധിപ്പിക്കുന്നു. ഒരു സൈറ്റിലെ സുരക്ഷാ ദുർബലതകൾ മറ്റെല്ലാ സൈറ്റുകളെയും ബാധിക്കാതിരിക്കാൻ ഐസൊലേഷൻ, കുറഞ്ഞ അധികാരമാറ്റം എന്ന തത്ത്വങ്ങൾ പാലിക്കണം.

• ഓരോ സൈറ്റിനും വ്യത്യസ്ത ഡാറ്റാബേസ്, വ്യത്യസ്ത ഡാറ്റാബേസ് യൂസർ സൃഷ്ടിക്കുക.
• വെബ് റൂട്ട് ഡയറക്ടറി പബ്ലിക് ഫോൾഡറിലേക്കു മാത്രം പരിമിതപ്പെടുത്തുക.
• ബാക്കപ്പ്, .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 നിലവാരത്തെയും സ്വാധീനിക്കുന്നു. തെറ്റായ റീഡൈരക്ഷണങ്ങൾ, canonical URL തെറ്റുകൾ, gzip അല്ലെങ്കിൽ brotli സങ്കുചിതമാക്കൽ ഇല്ലായ്മ, വലുതായ ലോഗ് ഫയലുകൾ, അപര്യാപ്ത ക്യാഷെ ക്രമീകരണങ്ങൾ സൈറ്റ് വേഗത കുറയ്ക്കും. Google പേജ് അനുഭവം ഉപയോക്തൃകേന്ദ്രിതമാണ്; വേഗത്തിൽ പ്രതികരിക്കുന്ന, സുരക്ഷിതവും സ്ഥിരതയുള്ള സൈറ്റുകൾ മികച്ച റാങ്ക് നേടും.

പ്രത്യേകിച്ച് ഓരോ ഡൊമെയ്‌നിനും ഒറ്റ കാനോണിക്കൽ പതിപ്പ് തീരുമാനിക്കുക. HTTP-ൽ നിന്നു HTTPS-യിലേക്ക്, www ഉള്ളതിൽ നിന്നു www ഇല്ലാത്തതിലേക്കോ അതിന്റെ മറുവശത്തേക്കോ ഒരുപടി 301 റീഡൈരക്ഷണം നടപ്പിലാക്കുക. റീഡൈരക്ഷണ ചങ്ങലകൾ ഒഴിവാക്കുക; ഉദാഹരണത്തിന് http://site.com → http://www.site.com → https://www.site.com → https://site.com എന്നത് പകരം നേരിട്ട് 301-നു ശേഷം https://site.com-ലേക്ക് പോകുക.

സ്റ്റാറ്റിക് ഫയലുകൾക്ക് cache-control ഹെഡറുകൾ ഉപയോഗിക്കാം. ചിത്രങ്ങൾ, CSS, JS ഫയലുകൾ ചില സമയം ബ്രൗസറിൽ സൂക്ഷിക്കാം. മുറുക്കിയ മാറ്റങ്ങൾ ഉള്ള ഫയലുകൾക്ക് വെർഷൻ നമ്പർ ചേർക്കുക അല്ലെങ്കിൽ query string ഉപയോഗിക്കുക. gzip സങ്കുചിതീകരണം HTML, CSS, JS, JSON പോലുള്ള ടെക്സ്റ്റ് ഫയലുകളിൽ ബാൻഡ്‌വിഡ്ത്ത് കുറയ്ക്കും. ഉയർന്ന ട്രാഫിക് സൈറ്റുകൾക്ക് Nginx microcache, FastCGI cache, CDN എന്നിവ ഉപയോഗിക്കാൻ കഴിയും. ലോകവ്യാപക ആക്‌സസ് ആവശ്യങ്ങൾക്ക് CDN എന്താണ് സന്ദർശിക്കാം.

ലോഗ് മാനേജ്മെന്റ് & മോണിറ്ററിംഗ്

പല സൈറ്റുകൾ ഒരേ സെർവറിൽ ഹോസ്റ്റ് ചെയ്യുമ്പോൾ ലോഗ് മാനേജ്മെൻറ് പ്രശ്‌ന പരിഹാരത്തിൽ മുഖ്യമാണ്. വ്യത്യസ്ത ലോഗ് ഫയലുകൾ ഏത് സൈറ്റിൽ പിഴവ് സംഭവിക്കുന്നു എന്ന് വ്യക്തമായി കാണിക്കും. access_log സന്ദർശക അഭ്യർത്ഥനകൾ രേഖപ്പെടുത്തുന്നു, error_log കോൺഫിഗറേഷൻ, അനുമതി, ഫയൽ ഇല്ലായ്മ, അപ്പ്‌സ്റ്റ്രീം പിശകുകൾ രേഖപ്പെടുത്തുന്നു. 502 Bad Gateway പിശക് സാധാരണയായി PHP-FPM അല്ലെങ്കിൽ ബാക്ക്‌എൻഡ് സർവീസ് കണക്ഷൻ പ്രശ്‌നങ്ങളാണ്. 403 Forbidden അനുമതി പ്രശ്‌നങ്ങൾക്കാണ്, 404 Not Found റൂട്ട് പാത്ത് അല്ലെങ്കിൽ റ്റ്രൈ ഫയൽ നിയമം തെറ്റായിരിക്കാം.

ലോഗ് ഫയലുകൾ അനിയന്ത്രിതമായി വലുതാകുന്നത് തടയാൻ logrotate ക്രമീകരണം പരിശോധിക്കണം. ചെറിയ പ്രോജക്റ്റുകളിൽ ദിവസവും അല്ലെങ്കിൽ ആഴ്ചവാരമായി റൊട്ടേഷൻ മതിയാകും. ഉയർന്ന ട്രാഫിക് സൈറ്റുകൾക്ക് സെൻട്രലൈസ്ഡ് ലോഗ് ശേഖരണം, മെട്രിക്‌സ് നിരീക്ഷണം, അലേർട്ട് സംവിധാനം എന്നിവ ഉപയോഗിക്കാം. ഡിസ്ക് നിറഞ്ഞാൽ Nginx ലോഗുകൾ എഴുതാൻ കഴിയാതെ പോകും, ഡാറ്റാബേസ് നിൽക്കും, സൈറ്റുകൾ അപ്രാപ്യമായാകും. അതിനാൽ ഡിസ്ക് ഉപയോഗത്തിനായി പരിധി നിശ്ചയിച്ച് മുൻകരുതൽ എടുക്കുക.

സാധാരണ പിഴവുകളും എളുപ്പം പരിഹരിക്കുന്ന വഴികളും

Nginx സേർവർ ബ്ലോക് ഉപയോഗിക്കുമ്പോൾ പല പ്രോജക്റ്റുകളിലും സാധാരണ കാണുന്ന ചില പിഴവുകൾ അറിയുന്നത് ഇൻസ്റ്റാളേഷൻ സമയവും പ്രശ്‌ന പരിഹാരവും വേഗത്തിലും എളുപ്പത്തിലും നടത്താൻ സഹായിക്കും.

• തെറ്റായ സൈറ്റ് തുറക്കുന്നു: server_name കൂട്ടിച്ചേർക്കലുകളോ ഡീഫോൾട്ട് സെർവർ ബ്ലോക്ക് പരിശോധിക്കുക.
• 403 Forbidden പിശക്: റൂട്ടിന്റെ പാത, ഫയൽ അനുമതികൾ, ഇൻഡക്സ് ഫയൽ നിലവാരം പരിശോധിക്കുക.
• 404 Not Found പിശക്: റൂട്ടിന്റെ പാതയും try_files നിബന്ധനകളും പരിശോധിക്കുക.
• 502 Bad Gateway പിശക്: PHP-FPM സർവീസ് ഓണായിട്ടുണ്ടോ, സോക്കറ്റ് പാത ശരിയാണോ എന്ന് ഉറപ്പാക്കുക.
• SSL സർട്ടിഫിക്കറ്റ് തെറ്റായ സൈറ്റിനോട് ബന്ധിപ്പിച്ചിരിക്കുന്നു: 443 പോർട്ടിലെ server_name, സർട്ടിഫിക്കറ്റ് ഫയലുകൾ പരിശോധിക്കുക.
• റീഡൈരക്ഷണ ചക്രം ഉണ്ടാകുന്നു: HTTP-HTTPS, www-നോ-www റീഡൈരക്ഷണ നിയമങ്ങൾ ലളിതമാക്കുക.
• Nginx റീലോഡ് സാധ്യമല്ല: sudo nginx -t ഔട്ട്പുട്ടിൽ വരിയനുസരിച്ച് സിന്റാക്സ് പിഴവ് തിരുത്തുക.

അനുഭവസമ്പന്നരായ അഡ്മിന്മാർ ഒരു ലളിതമായ ചെക്ക്‌ലിസ്റ്റ് പാലിക്കുന്നു: DNS ശരിയാണോ, Nginx കോൺഫിഗറേഷൻ സജീവമാണോ, root ഡയറക്ടറി ഉണ്ടോ, അനുമതികൾ ശരിയാണോ, സർവീസ് ടെസ്റ്റ് പൂർത്തിയാക്കിയിട്ടുണ്ടോ, ലോഗുകൾ എന്താണെന്ന് നോക്കുക? ഈ ക്രമം പാലിച്ചാൽ അനാവശ്യ പാനിക് കൂടാതെ വേഗം പരിഹാരം കാണാം.

പ്രൊഡക്ഷൻ എൻവയിർമെന്റിനുള്ള പ്രായോഗിക ചെക്ക്‌ലിസ്റ്റ്

ലൈവ് ആക്കുന്നതിന് മുമ്പ് താഴെ കൊടുത്തിരിക്കുന്നവ പരിശോധിച്ച് ഓരോ സൈറ്റും ശരിയാണെന്ന് ഉറപ്പാക്കുക. പ്രത്യേകിച്ച് ക്ലയന്റ് പ്രോജക്റ്റുകളിൽ ഡെലിവറി മുൻപ് ഈ പട്ടിക രേഖപ്പെടുത്തുന്നത് പ്രൊഫഷണൽ രീതിയാണ്.

• ഡൊമെയ്ൻ A/AAAA റെക്കോർഡ് ശരിയായ IP-യ്ക്ക് പോയിന്റ് ചെയ്യുന്നു.
• www ഉള്ളതോ അല്ലാതെയോ ഒന്ന് കാനോണിക്കൽ ആയി തിരഞ്ഞെടുക്കപ്പെട്ടിട്ടുണ്ട്.
• HTTP-ൽ നിന്നു HTTPS-യിലേക്ക് 301 റീഡൈരക്ട് ചെയ്യും.
• SSL സർട്ടിഫിക്കറ്റ് സാധുവും ഓട്ടോമാറ്റിക് പുതുക്കലും സജ്ജമാണ്.
• ഓരോ സൈറ്റിനും വ്യത്യസ്ത root, log ഫയലുകൾ നിർദ്ദേശിച്ചിരിക്കുന്നു.
• sudo nginx -t ഉപയോഗിച്ച് Nginx കോൺഫിഗറേഷൻ പരിശോധന പൂർത്തിയായി.
• ബാക്കപ്പ് പദ്ധതി ഉണ്ടാക്കി റീസ്ടോറും പരിശോധിച്ചു.
• ഫയൽ അനുമതികൾ കുറഞ്ഞ അധികാര തത്ത്വം പാലിക്കുന്നു.
• സെക്യൂരിറ്റി ഫയർവാളിൽ അനിവാര്യ പോർട്ടുകൾ മാത്രമേ തുറന്നിട്ടുള്ളൂ.
• ലൈവ് ശേഷം കുറഞ്ഞത് 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 പോർട്ടിലെ സെർവർ ബ്ലോക്കിൽ ശരിയായ സർട്ടിഫിക്കറ്റ് ഫയലുകൾ ശരിയായ ഡൊമെയ്‌നിനോട് ബന്ധിപ്പിക്കുന്നതാണ്.

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 ഫയലുകൾ പരിശോധിക്കുക.