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 அமைப்பில் server குழு என அழைக்கப்படும் மற்றும் வரும் HTTP அல்லது HTTPS கோரிக்கையை எந்த தளத்திற்கு திருப்புவது என்பதை நிர்ணயிக்கும் அமைப்பு கூறுகள் ஆகும். Apache பக்கம் உள்ள VirtualHost கோட்பாட்டிற்கு ஒத்ததாகும். ஒரு பார்வையாளர் உலாவியில் ஒரு டொமைனை எழுதும் போது, DNS அந்த டொமைனை சேவையகத்தின் IP முகவரிக்கு தீர்க்கிறது. பின்னர் Nginx, கோரிக்கையில் வரும் Host தலைப்பை பார்க்கிறது மற்றும் server_name மதிப்பு பொருந்தும் சேவையக குழுவைப் செயல்படுத்துகிறது.

இதன் மூலம் ஒரே IP முகவரி மற்றும் ஒரே உடல் அல்லது மெய்நிகர் சேவையகத்தில் பல்வேறு வலைத்தளங்களை வெளியிட முடியும். ஒவ்வொரு தளத்திற்கும் தனித்தனி அடித்தளம், அணுகல் பதிவு, பிழை பதிவு, திருப்புமுனை விதி, 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 போன்ற வெவ்வேறு செயலிகளை ஒரே சேவையகத்தில் இயக்க விரும்பினால்.

எடுத்துக்காட்டாக, ஒரு டிஜிட்டல் முகாமையாளரின் ஒரே 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 மற்றும் பதிவு கோப்புகளைப் பயன்படுத்துவதுதான்.

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. இந்த முறை கோப்புகளை நகலெடுக்கவிடாதது மிகவும் நலமுள்ளது, ஏனெனில் நீங்கள் ஒரே முதன்மை அமைப்பு கோப்பில் செயல்படுகிறீர்கள். நீங்கள் மாற்றம் செய்தால், இணைக்கப்பட்ட கோப்பு சீர் செய்யப்பட்டுவிடும்.

உங்கள் சேவையக குழுவின் முன்னணி நிலை default அமைப்பை நிறுத்த விரும்பினால், default அமைப்பை முடக்கலாம். இதற்காக /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 ஹோஸ்டிங் மாற்றத்தைத் தேடும்வர்கள் 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 தவறாக செயல்படுத்தப்படும்போது, script மற்றும் style கோப்புகளைத் தடுக்கும்; எனவே முதலில் சோதனை சூழலில் சோதிக்க வேண்டும். பாதுகாப்பு தொடர்பான மேலும் உள்ளடக்கம் வலைத்தளத்தின் பாதுகாப்பு பதிவுகளுக்கான இணைப்பினை வழங்கலாம்.

செயல்திறன் மற்றும் SEO க்கான கவனிக்க வேண்டியவை

Nginx சேவையக குழுக்கள் வெள்ளிக்கான மட்டுமல்ல; செயல்திறன் மற்றும் SEO தரத்தையும் பாதிக்கின்றன. தவறான திருப்பக் களங்கள், தவறான canonical விருப்பங்கள், குறைவான 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 கோப்புகள் குறிப்பிட்ட காலத்திற்கு உலாவியில் காப்பாற்றப்படலாம். ஆனால் அடிக்கடி மாறும் கோப்புகளில் கோப்பு பெயர் பதிப்பீடு அல்லது 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 என்பது அனுமதி அல்லது index கோப்பின் சிக்கலாக இருக்கலாம். 404 Not Found என்பது கோப்பு பாதை, மறுபெயரிடுதல் அல்லது DNS பிறகு தவறான root பிரச்சினையை குறிப்பிடலாம்.

பதிவு கோப்புகள் அளவற்ற அளவுக்கு அதிகரிக்காமல் இருக்க logrotate அமைப்பைச் சரிபார்க்க வேண்டும். சிறிய திட்டங்களில், தினசரி அல்லது வாராந்திர சுழற்சி போதுமானதாக இருக்கலாம். அதிக வணிகத்தைக் கொண்ட தளங்களில் மைய பதிவு சேகரிப்பு, அளவீட்டு கண்காணிப்பு மற்றும் எச்சரிக்கை அமைப்புகள் பயன்படுத்தப்பட வேண்டும். டிஸ்க் நிரம்பி Nginx க்கு பதிவு எழுத முடியாது, தரவுத்தளத்தை நிறுத்தி வைக்க மற்றும் தளங்களுக்கு அணுக முடியாமல் இருக்கக் காரணமாக இருக்கலாம். எனவே, டிஸ்க் பயன்பாட்டிற்கான மைய மதிப்பீடுகளை நிதானமாகக் கணக்கிடுவது பயனுள்ள முன்னெடுக்கலாகும்.

பொதுவான பிழைகள் மற்றும் விரைவான தீர்வுகள்

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 reload செய்யவில்லை: sudo nginx -t வெளியீட்டில் உள்ள வரிசை எண்ணின்படி சொற்பொழிவுப் பிழையைச் சரிசெய்யவும்.

அனுபவமிக்க நிர்வாகிகள் பயன்படுத்தும் எளிய கட்டுப்பாட்டு பட்டியல் உள்ளது: DNS சரியாக இருக்கிறதா, Nginx அமைப்பு செயல்பாட்டில் இருக்கிறதா, root கோப்புறை இருக்கிறதா, அனுமதிகள் சரியாக உள்ளதா, சேவை சோதனையை கடந்து வந்ததா, பதிவு என்ன சொல்லுகிறது? இந்த வரிசையில் முன்னேறுவது, பயந்துவிடாமல் விரைவான தீர்வுகளை உருவாக்குவதற்கு உதவுகிறது.

உற்பத்தி சூழலுக்கு நடைமுறை கட்டுப்பாட்டு பட்டியல்

நீங்கள் இழுப்பதற்கு முன்பு, கீழ்காணும் கட்டுப்பாட்டு பட்டியலுடன் ஒவ்வொரு தளத்தையும் உறுதிசெய்யவும். குறிப்பாக, வாடிக்கையாளர் திட்டங்களில், ஒப்படைக்கும் முன்பு இந்த உருப்படிகளை ஆவணமாக்குவது ஒரு தொழில்முறை பணிய standards உருவாக்குகிறது.

• டொமைன் A அல்லது AAAA பதிவேடு சரியான IP முகவரிக்கு திருப்பப்படுகிறது.
• www மற்றும் www இல்லாத பதிப்புகளில் ஒன்று கானொனிகல் ஆக தேர்ந்தெடுக்கப்பட்டுள்ளது.
• HTTP உள்ளீடு HTTPS க்கு 301 மூலம் திருப்பப்படுகிறது.
• SSL சான்றிதழ் செல்லுபடியாகும் மற்றும் தானாகவே புதுப்பிப்பு செயல்படுத்தப்பட்டுள்ளது.
• ஒவ்வொரு தளத்திற்கும் தனித்தனி root மற்றும் பதிவு கோப்புகள் வரையறுக்கப்பட்டுள்ளன.
• Nginx அமைப்பு sudo nginx -t மூலம் உறுதிப்படுத்தப்பட்டது.
• பின்வாங்கல் திட்டம் மேற்கொள்ளப்பட்டது மற்றும் மீண்டும் ஏற்றுதல் சோதனை செய்யப்பட்டது.
• கோப்பு அனுமதிகள் குறைந்த அனுமதி கொள்கைக்கு ஏற்ப உள்ளன.
• பாதுகாப்பு சுவரில் தேவையான போர்டுகள் மட்டும் திறக்கப்பட்டுள்ளன.
• பிழை பதிவுகள் நேரடியாக ஏற்றுமதி செய்யப்படும் பிறகு குறைந்தது 15 நிமிடங்கள் கண்காணிக்கப்பட்டன.

இந்த பட்டியல் சிறியதாக தோன்றினாலும், உண்மையான திட்டங்களில் இடைநிறுத்தம் ஏற்படும் ஆபத்தைக் மிகக் குறைக்கிறது. குறிப்பாக SSL புதுப்பிப்பு, DNS சரிபார்ப்பு மற்றும் பதிவு கண்காணிப்பு படிகள் பல மறைவு பிழைகளை முன்னதாகவே கண்டுபிடிக்க உதவுகின்றன.

முடிவு

Nginx சேவையக குழுக்கள், ஒரே சேவையகத்தில் பல தளங்களை ஒழுங்காக, பாதுகாப்பாக மற்றும் செயல்திறனான முறையில் பராமரிக்கும் அடிப்படையான முறைகளுள் ஒன்றாகும். சரியான அடித்தள அமைப்பு, தனித்தனி அமைப்பு கோப்புகள், தெளிவான திருப்ப விதிகள், HTTPS பயன்பாடு, பதிவு பிரிப்பு மற்றும் ஒழுங்கான சோதனை செயல்முறை மூலம் பல தள மேலாண்மை மிகவும் பயனுள்ளதாக மாறுகிறது. சிறிய போர்ட்போலியோ தளத்திலிருந்து பல வாடிக்கையாளர் திட்டங்களுக்கு, ஒரே மாதிரியான கோட்பாடுகள் செயல்படும்.

நீங்கள் புதிய திட்டத்தை வெளியிட விரும்பினால், முதலில் டொமைன், சேவையக ஆதாரம் மற்றும் SSL தேவைகளை தெளிவாகக் கூறுங்கள்; பின்னர் மேலே உள்ள கட்டுப்பாட்டு பட்டியலுடன் Nginx அமைப்பை படி படியாக அமைக்கவும். மேலாண்மைக்கேற்ப ஒரு அடிப்படையை தேடுகிறீர்களானால், Hostragons இன் விற்பனை தொகுப்புகள், VPS சர்வர் மற்றும் SSL சான்றிதழ்கள் தீர்வுகளைப் பார்க்கலாம், உங்கள் திட்டத்திற்கு ஏற்ப ஆரம்ப இடத்தைத் தேர்ந்தெடுக்கலாம்.

அதிக frequentemente கேட்கப்படும் கேள்விகள்

Nginx சேவையக குழுக்களுடன் எவ்வளவு தளங்களை பராமரிக்கலாம்?

தொழில்நுட்ப ரீதியாக Nginx உடன் ஒரே சேவையகத்தில் பல தளங்களை பராமரிக்கலாம்; எல்லை பொதுவாக CPU, RAM, டிஸ்க், வணிகம், தரவுத்தளம் சுமை மற்றும் PHP-FPM திறனுக்கு அடிப்படையாக இருக்கும். குறைந்த வணிகத்திற்கான நிலையான தளங்களில், பத்துமணிக்குப் பல தளங்கள் சாத்தியமாக இருக்கலாம், ஆனால் அதிக வணிகத்திற்கான WordPress அல்லது மின்னணு வர்த்தக திட்டங்களில் குறைந்த தளங்களை பராமரிக்கவும் அதிக சுகாதாரமானது.

ஒவ்வொரு தளத்திற்கும் தனித்தனி SSL சான்றிதழ் தேவைதா?

ஆம், ஒவ்வொரு டொமைன் அல்லது துணை டொமைன் HTTPS மூலம் வெளியிடப்பட வேண்டும் என்றால், சான்றிதழ் வரம்புக்குள் சேர்க்கப்பட வேண்டும். தனித்தனி சான்றிதழ்களை பயன்படுத்தலாம், அல்லது SAN அல்லது wildcard சான்றிதழ்களைப் பயன்படுத்தலாம். முக்கியமானது Nginx 443 சேவையக குழுவில் சரியான சான்றிதழ் கோப்புகளை சரியான டொமைனுக்கு இணைக்க வேண்டும்.

Nginx சேவையக குழுவுடன் துணை டொமைன் வெளியிட முடியுமா?

ஆம். blog.site.com அல்லது panel.site.com போன்ற துணை டொமைன்களுக்கு தனித்தனி server_name வரையறுக்கலாம் மற்றும் வெவ்வேறு root அடித்தளத்திற்கோ அல்லது வெவ்வேறு பின்னணி செயலிக்கு திருப்பலாம். DNS பக்கம் தொடர்புடைய துணை டொமைனுக்கு A அல்லது CNAME பதிவுகளை உருவாக்க வேண்டும்.

site-available மற்றும் sites-enabled இடையே என்ன வேறுபாடு உள்ளது?

sites-available என்பது பயன்படுத்தக்கூடிய அமைப்பு கோப்புகளை வைத்திருக்கும் இடமாகும்; sites-enabled என்பது செயல்படுத்தப்பட்ட அமைப்புகளை உள்ளடக்கியது. பொதுவாக sites-enabled இல், sites-available கோப்புக்கு சின்ன இணைப்பு உருவாக்கப்படுகிறது. இந்த முறை தளங்களை செயல்படுத்துவது மற்றும் செயலிழக்க வைத்திருப்பது மிகவும் ஒழுங்காக இருக்கும்.

தவறான தளம் திறக்கப்படுகிறதா எனில், சிக்கல் எங்கு இருந்து வருகிறது?

மிகவும் பொதுவான காரணங்கள் DNS தவறான IP க்கு திருப்புவதன் மூலம், server_name மதிப்பின் தவறு, default Nginx குழுவால் கோரிக்கையை பிடிப்பது அல்லது 443 பக்கம் தவறான SSL குழுவின் செயல்பாடு ஆகியவை இருக்கலாம். முதலில் DNS பதிவுகளை, பின்னர் nginx -t வெளியீட்டைப், செயல்படுத்தப்பட்ட sites-enabled இணைப்புகளை மற்றும் தொடர்புடைய access_log கோப்புகளை சரிபார்க்கவும்.