Ghid pentru Găzduirea a Mai Multor Site-uri cu Blocuri de Server Nginx

Blocurile de server Nginx reprezintă o metodă de găzduire care vă permite să publicați mai multe domenii sau site-uri web cu configurații separate într-o singură instalare Nginx. De exemplu, pe același VPS, puteți defini directoare rădăcină diferite, fișiere de log, certificate SSL și setări PHP pentru example.com, blog.example.com și al doilea-site.com. Pe scurt, soluția constă în a crea un director separat pentru fiecare site, a direcționa înregistrările DNS ale domeniului către adresa IP a serverului, a scrie un bloc de server separatat sub /etc/nginx/sites-available, a-l conecta în directorul sites-enabled, a testa configurația și a reîncărca serviciul Nginx.

În acest ghid, vom aborda procesul de găzduire a mai multor site-uri folosind blocuri de server Nginx într-un mod potrivit pentru medii de producție. Scopul nu este doar de a crea o structură funcțională, ci de a construi un sistem gestionabil, sigur, rapid, scalabil și ușor de backup. Vom împărtăși pași practici, în special pentru agenții, dezvoltatori, proprietari de e-commerce, afaceri care gestionează multiple mărci și administratori de sistem care rulează mai multe proiecte pe un singur server. Dacă nu aveți un server, puteți consulta paginile pentru alegerea resursei server VPS și gestionarea domeniilor Înregistrarea Domeniului.

Ce sunt Blocurile de Server Nginx?

Blocurile de server Nginx sunt părți de configurație definite în configurarea Nginx, care determină către ce site este direcționată o cerere HTTP sau HTTPS primită. Acestea sunt similare cu conceptul de VirtualHost din Apache. Atunci când un vizitator scrie un domeniu în browser, DNS rezolvă acest domeniu în adresa IP a serverului. Apoi, Nginx examinează antetul Host din cerere și activează blocul de server corespunzător valorii server_name.

Astfel, zeci de site-uri web diferite pot fi publicate pe aceeași adresă IP și pe același server fizic sau virtual. Este posibil să definiți un director rădăcină, loguri de acces, loguri de eroare, reguli de redirecționare, certificate SSL, politici de cache și reguli de securitate separate pentru fiecare site. De exemplu, puteți păstra site-ul dvs. corporativ în /var/www/corporate/public, blogul în /var/www/blog/public și mediul de testare în /var/www/staging/public.

Nginx este foarte eficient în această structură deoarece, datorită arhitecturii sale bazate pe evenimente, poate gestiona conectivitatea simultană ridicată cu un consum redus de resurse. Din acest motiv, este adesea preferat în infrastructuri de hosting partajat, VPS, servere cloud și aplicații cu trafic ridicat. Pentru funcționarea sănătoasă a găzduirii multiple de site-uri, fiecare detaliu, de la permisiunile fișierelor la redirecționările DNS, de la instalarea SSL la separarea logurilor, trebuie să fie planificat corect.

Când Se Folosesc Blocurile de Server Nginx?

Blocurile de server Nginx sunt utilizate în special atunci când trebuie să gestionați mai multe entități web pe un singur server. Acest lucru poate fi uneori două site-uri corporative mici sau, în alte cazuri, zeci de proiecte de clienți, subdomenii sau microservicii. Punctul critic aici este separarea logică a fiecărui proiect.

• Dacă doriți să publicați mai multe domenii pe același VPS.
• Dacă doriți să redirecționați domeniile www și non-www către o singură adresă canonică.
• Dacă doriți să conectați subdomeni la directoare sau aplicații diferite.
• Dacă doriți să definiți certificate SSL și politici de securitate separate pentru fiecare site.
• Dacă doriți să urmăriți proiectele clienților cu fișiere de log separate.
• Dacă doriți să rulați aplicații diferite, cum ar fi Laravel, WordPress, HTML static și Node.js pe același server.

De exemplu, este tehnic posibil ca o agenție digitală să publice 8 site-uri corporative cu trafic redus pe un singur VPS de 4 GB RAM. Totuși, pentru fiecare site, trebuie să se calculeze traficul, utilizarea discului, numărul de procese PHP, sarcina bazei de date și frecvența backup-urilor. Dacă proiectele primesc trafic intens sau dacă izolarea resurselor este critică, ar trebui să se opteze pentru VPS-uri mai puternice, servere cloud sau soluții de hosting gestionabil. În acest context, opțiunile Hostragons Web Hosting și Hosting Corporate pot fi comparate.

Cerințe înainte de a începe

În acest ghid, vom presupune că utilizați un server Linux bazat pe Ubuntu sau Debian. Comenzile pot varia ușor în funcție de distribuție; totuși, logica rămâne aceeași. Asigurați-vă că faceți backup înainte de a efectua modificări în mediu de producție. O configurație Nginx greșită poate face toate site-urile temporar inaccesibile.

Pregătiri tehnice necesare

• Un cont de utilizator Linux cu privilegii root sau sudo.
• Serviciul Nginx instalat și funcțional.
• Cel puțin un domeniu direcționat către adresa IP a serverului.
• Porturile 80 și 443 deschise în firewall.
• O structură de directoare organizată pentru fișierele site-ului.
• Un certificat valid pentru SSL sau utilizarea gratuită a Let’s Encrypt.
• Instalarea PHP-FPM pentru aplicațiile bazate pe PHP.

Pe partea de DNS, înregistrarea A direcționează domeniul principal către adresa IPv4, iar înregistrarea AAAA, dacă există, către adresa IPv6. Inregistrările CNAME sau A pot fi utilizate pentru subdomenii precum www. Propagarea DNS durează de obicei între câteva minute și 24 de ore. Când faceți o nouă instalare, este mai eficient să pregătiți mai întâi înregistrările DNS și apoi să treceți la configurarea blocurilor de server Nginx.

Structura recomandată a directoarelor

Una dintre cele mai frecvente greșeli în găzduirea mai multor site-uri este păstrarea tuturor fișierelor într-un singur director într-un mod haotic. Această abordare poate părea ușoară pe termen scurt, dar va duce la pierderi semnificative de timp în procesele de întreținere, backup și depanare. O metodă mai bună este de a utiliza un director principal separat pentru fiecare domeniu, cu subdirectoare precum public, logs, backups.

O structură exemplară poate fi planificată astfel: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public și /var/www/site2.com/logs. Valoarea root Nginx ar trebui să indice direct către directorul public. Astfel, fișierele aplicației, fișierele sensibile, cum ar fi .env și backup-urile nu vor fi accesibile direct pe web.

Pentru fiecare folder de site, puteți plasa un fișier simplu index.html pentru o pagină de testare statică. Scriind numele site-ului în conținut, veți putea verifica rapid care bloc de server funcționează. În medii de producție, proprietatea acestor foldere este de obicei gestionată de utilizatorul www-data sau de un utilizator special care se ocupă de desfășurare. În majoritatea scenariilor statice, permisiunile fișierelor pentru foldere ar trebui să fie 755, iar pentru fișiere 644. În aplicații precum WordPress, care necesită scriere, directoarele precum uploads ar trebui evaluate suplimentar.

Crearea unui Bloc de Server Nginx Pas cu Pas

Următorii pași sunt descriși prin exemplul domeniului site1.com. Puteți repeta aceeași metodă pentru un al doilea, al treilea sau mai multe site-uri. Punctul critic este utilizarea unui server_name, root și fișier de log unice pentru fiecare site.

1. Creați folderul site-ului

Primul pas este să creați directorul în care vor fi stocate fișierele web. Exemplu: sudo mkdir -p /var/www/site1.com/public. Apoi, pentru testare, puteți crea fișierul /var/www/site1.com/public/index.html și să scrieți un text ușor de recunoscut, cum ar fi Aceasta este pagina de testare site1.com.

Pentru a seta corect proprietatea fișierului, poate fi folosită comanda sudo chown -R www-data:www-data /var/www/site1.com. Dacă efectuați operațiuni de desfășurare cu un alt utilizator, ajustați permisiunile grupului în consecință. În medii de producție, evitați permisiunile 777, care permit tuturor să scrie, deoarece acestea pot permite atacatorilor să abuzeze de directoarele de încărcare.

2. Creați fișierul blocului de server

Practicile comune în Nginx sugerează păstrarea configurațiilor inactive în /etc/nginx/sites-available și conectarea celor active în /etc/nginx/sites-enabled printr-o legătură simbolică. Exemplu de fișier: /etc/nginx/sites-available/site1.com.

Un bloc de server HTTP simplu este scris astfel: 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; } }

În această configurație, listen 80 ascultă traficul HTTP, server_name specifică ce domenii aparțin acestui bloc, root indică directorul în care se află fișierele web, iar index definește fișierul implicit. try_files va returna 404 dacă nu găsește fișierul sau directorul solicitat. Această structură este suficientă pentru site-uri statice.

3. Activați site-ul

Pentru a activa configurația, se creează o legătură simbolică: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. Această metodă este mai sănătoasă decât copierea fișierelor, deoarece lucrați pe un singur fișier de configurare principal. Când faceți modificări, fișierul conectat rămâne actualizat.

Dacă nu doriți ca pagina implicită Nginx să apară înaintea site-ului dvs., puteți dezactiva configurația default. Pentru aceasta, legătura /etc/nginx/sites-enabled/default poate fi eliminată. Totuși, asigurați-vă mai întâi că propriul bloc de server funcționează corect.

4. Testați configurația și reîncărcați Nginx

După fiecare modificare, trebuie să rulați comanda sudo nginx -t pentru a verifica sintaxa. Dacă testul este reușit, comanda sudo systemctl reload nginx va reîncărca serviciul fără întreruperi. Comanda reload este de obicei mai sigură decât restartul, deoarece gestionează conexiunile active mai delicat.

Dacă testul eșuează, mesajul de eroare va arăta de obicei numele fișierului și numărul liniei. Lipsa unui punct și virgulă, paranteze greșite, calea greșită a directorului sau valori server_name conflictuale sunt cele mai frecvente probleme. Nginx nu ar trebui să fie reîncărcat până când problema nu este rezolvată.

Adăugarea celui de-al Doilea și al Treilea Site

Frumusețea găzduirii mai multor site-uri constă în faptul că, după prima instalare corectă, procesul devine repetabil. Creați directorul /var/www/site2.com/public, scrieți fișierul /etc/nginx/sites-available/site2.com, schimbați valorile root și log pentru site2.com, creați o legătură simbolică și rulați testul Nginx.

Structura simplă pentru cel de-al doilea site este scrisă astfel: 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; } }

Utilizarea logurilor separate pentru fiecare site este extrem de valoroasă în viața reală. De exemplu, în timp ce un site poate avea un număr crescut de erori 404, altul poate funcționa fără probleme. Datorită structurii separate a logurilor, puteți găsi sursa erorii în câteva secunde. În mod similar, analiza traficului, atacurile de bot, linkurile rupte și problemele de performanță pot fi monitorizate la nivel de site.

Configurarea SSL și HTTPS

Conform standardelor SEO din 2026, HTTPS nu mai este doar o caracteristică de securitate, ci un indicator al încrederii utilizatorului și al calității tehnice. Browserele marchează site-urile HTTP ca fiind nesigure; SSL este obligatoriu pentru proiectele care includ plăți, înscriere, formulare sau panouri de administrare. Atunci când găzduiți mai multe site-uri, trebuie să definiți certificatele corecte pentru fiecare domeniu. Puteți vizita pagina certificate SSL de pe Hostragons pentru nevoile dvs. de SSL.

Dacă utilizați Let’s Encrypt, puteți obține certificate pentru fiecare domeniu cu Certbot. În procesul exemplificat, comanda certbot --nginx -d site1.com -d www.site1.com va detecta configurația Nginx și poate adăuga automat blocul HTTPS. Totuși, este o bună practică să verificați fișierul după modificările automate. Probleme de redirecționare greșită sau blocuri de server repetate pot apărea.

În configurarea HTTPS, traficul de pe portul 80 este de obicei redirecționat permanent către portul 443. Redirecționarea 301 oferă un semnal de preferință permanent din punct de vedere SEO. Decideți dacă doriți să utilizați www sau nu și să centralizați toate variațiile către o singură adresă canonică. De exemplu, dacă alegeți https://site1.com în loc de https://www.site1.com, redirecționați atât traficul HTTP cât și HTTPS www către adresa fără www. Acest lucru reduce riscul de conținut duplicat.

Blocurile de Server Nginx pentru Site-uri PHP și WordPress

Configurarea pentru site-urile HTML statice este simplă; totuși, pentru WordPress, Laravel sau aplicațiile PHP personalizate, este necesară integrarea cu PHP-FPM. În acest caz, fișierul index.php este definit, iar cererile PHP sunt direcționate către socketul corespunzător. De exemplu, pe Ubuntu, calea socketului pentru PHP 8.3 poate fi /run/php/php8.3-fpm.sock. Versiunea variază în funcție de server.

Exemplul de logică bazat pe PHP este: 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; } }

Pentru a funcționa corect permalinks în WordPress, structura try_files $uri $uri/ /index.php?$args este esențială. De asemenea, ar trebui să luați în considerare măsuri de securitate, cum ar fi limitarea accesului la xmlrpc.php, limitarea ratei pentru wp-login.php și interzicerea executării PHP în directorul uploads. Dacă găzduiți numeroase site-uri WordPress pe același VPS, utilizați baze de date separate, utilizatori separați și o politică de actualizare regulată. Cei care caută alternative de hosting pentru WordPress pot lua în considerare hosting WordPress, care poate fi o opțiune mai gestionabilă.

Compararea Blocurilor de Server Nginx cu VirtualHost Apache

Nginx și Apache ating același obiectiv prin arhitecturi diferite. Ambele pot găzdui mai multe site-uri pe un singur server. Alegerea depinde de nevoile aplicației, obiceiurile de gestionare și așteptările de performanță.

Dacă aplicația dvs. depinde intensiv de regulile .htaccess, Apache poate părea mai ușor de utilizat. Cu toate acestea, pentru trafic ridicat, proxy invers, cache și fluxuri moderne de distribuție, Nginx este o alegere puternică pentru majoritatea proiectelor. În unele infrastructuri, Nginx poate fi utilizat ca proxy invers, iar Apache ca server de aplicație din spate.

Practici Recomandate pentru Securitate

Găzduirea mai multor site-uri pe același server oferă avantaje financiare, dar crește și responsabilitatea securității. Trebuie aplicată o separare logică și principiul minimului privilegiu pentru a preveni ca o vulnerabilitate pe un site să afecteze celelalte.

• Creați baze de date separate și utilizatori de baze de date separați pentru fiecare site.
• Restricționați directorul rădăcină web doar la folderul public.
• Mențineți backup-urile, .env, .git, fișierele de configurare și SQL în afara accesului web.
• Reînnoiți regulat certificatele SSL și impuneți redirecționarea HTTPS.
• Utilizați un firewall de securitate precum UFW pe server; deschideți doar porturile necesare.
• Aplicați actualizări regulate pentru Nginx și sistemul de operare.
• Păstrați loguri separate de access_log și error_log pentru fiecare site.
• Adăugați restricții IP sau autentificare suplimentară pentru panourile de administrare.
• Evitați permisiunile largi, cum ar fi 777, în permisiunile fișierelor.

De asemenea, este util să adăugați antete de securitate de bază. Antetele precum X-Frame-Options, X-Content-Type-Options, Referrer-Policy și Content-Security-Policy pot fi evaluate în proiectele adecvate. Totuși, în special Content-Security-Policy, dacă este implementat greșit, poate bloca scripturile și fișierele de stil; de aceea, trebuie testat mai întâi în medii de testare. Pentru mai multe informații despre securitate, puteți consulta articolele Securitatea site-ului web.

Aspecte de Luat în Considerare pentru Performanță și SEO

Blocurile de server Nginx influențează nu doar publicarea, ci și calitatea performanței și SEO. Lanțurile de redirecționare greșite, alegerile canonice incorecte, lipsa comprimării gzip sau brotli, fișierele de log mari și setările de cache insuficiente pot reduce viteza site-ului. Semnalele de experiență a paginii de la Google sunt centrate pe utilizator; site-urile care răspund rapid, sunt sigure și stabile tind să performeze mai bine.

În primul rând, stabiliți o singură versiune canonică pentru fiecare domeniu. Redirecționați de la HTTP la HTTPS, de la www la non-www sau invers într-un singur pas. Lanțul nu ar trebui să fie: http://site.com la http://www.site.com, apoi la https://www.site.com, apoi la https://site.com. În schimb, este mai corect să mergeți direct la destinație cu un singur 301.

Pentru fișierele statice, se pot utiliza antete cache-control. Imaginile, fișierele CSS și JS pot fi păstrate în browser pentru o perioadă definită. Totuși, pentru fișierele care se schimbă frecvent, se pot utiliza strategii de versionare a numelui fișierului sau query string. Comprimarea gzip reduce lățimea de bandă pentru fișierele bazate pe text, cum ar fi HTML, CSS, JS și JSON. Pentru site-urile cu trafic ridicat, se poate evalua utilizarea microcache-ului Nginx, FastCGI cache sau CDN. Pentru nevoile de CDN și acces global, puteți consulta un conținut precum Ce este CDN.

Gestionarea Logurilor și Monitorizarea

Gestionarea logurilor este cheia rezolvării problemelor în găzduirea mai multor site-uri. Fișierele de log separate indică clar pe care site s-a întâmplat o eroare. access_log înregistrează cererile vizitatorilor, iar error_log înregistrează probleme de configurație, permisiuni, fișiere lipsă și erori upstream. Eroarea 502 Bad Gateway este de obicei legată de serviciul PHP-FPM sau de conexiunea cu serviciul backend. Eroarea 403 Forbidden poate indica o problemă cu permisiunile sau cu fișierul index. Eroarea 404 Not Found poate semnala o problemă cu calea fișierului, regulile de rewrite sau o eroare de root după DNS.

Pentru a preveni creșterea nelimitată a fișierelor de log, ar trebui să verificați configurația logrotate. Pentru proiectele mici, rotirea zilnică sau săptămânală poate fi suficientă. Pe site-urile cu trafic ridicat, ar trebui utilizate sisteme centrale de colectare a logurilor, monitorizare metrică și sisteme de alertă. Umplerea discului poate împiedica scrierea logurilor de către Nginx, oprirea bazei de date și inaccesibilitatea site-urilor. Prin urmare, stabilirea valorilor prag pentru utilizarea discului este o măsură practică.

Greșeli Frecvente și Soluții Rapide

Când lucrați cu blocuri de server Nginx, unele erori pot apărea aproape în fiecare proiect. A cunoaște aceste erori poate reduce semnificativ timpul de instalare.

• Domeniul deschide site-ul greșit: verificați conflictele server_name și blocul de server default.
• Eroare 403 Forbidden: verificați directorul root, permisiunile fișierelor și existența fișierului index.
• Eroare 404 Not Found: verificați calea root și regula try_files.
• Eroare 502 Bad Gateway: verificați dacă serviciul PHP-FPM rulează și că calea socketului este corectă.
• Certificatul SSL pare a fi pentru un site greșit: verificați server_name pe portul 443 și fișierele certificate.
• A apărut un ciclu de redirecționare: simplificați regulile de redirecționare HTTP-HTTPS și www.
• Nginx nu se reîncărca: corectați eroarea de sintaxă conform numărului liniei din ieșirea sudo nginx -t.

Administratorii experimentați aplică o listă de verificare simplă: DNS este corect? Configurația Nginx este activă? Directorul root există? Permisiunile sunt corecte? Serviciul a trecut testul? Ce spune logul? Urmând această ordine, veți putea găsi rapid soluții fără panică.

Lista de Verificare Practică pentru Mediul de Producție

Înainte de a lansa, verificați fiecare site cu lista de verificare de mai jos. În special pentru proiectele clienților, documentarea acestor puncte înainte de predare creează un standard profesional de lucru.

• Inregistrarea A sau AAAA a domeniului se direcționează către adresa IP corectă.
• Una dintre versiunile cu www și fără www a fost aleasă ca versiune canonică.
• Traficul HTTP este redirecționat cu 301 către HTTPS.
• Certificatul SSL este valid și reînnoirea automată este activă.
• Fiecare site are definite directoare root și fișiere de log separate.
• Configurarea Nginx a fost validată cu sudo nginx -t.
• Planul de backup a fost stabilit și testat pentru restaurare.
• Pernisiunile fișierelor respectă principiul minimului privilegiu.
• În firewall sunt deschise doar porturile necesare.
• Logurile de eroare au fost monitorizate timp de cel puțin 15 minute după lansare.

Această listă poate părea mică, dar în proiectele reale reduce semnificativ riscul de întreruperi. În special, pașii de reînnoire a SSL, verificare DNS și monitorizare a logurilor pot detecta devreme majoritatea erorilor invizibile.

Concluzie

Blocurile de server Nginx sunt una dintre metodele fundamentale pentru a găzdui mai multe site-uri într-un mod organizat, sigur și performant pe un singur server. O structură de directoare corectă, fișiere de configurare separate, reguli clare de redirecționare, utilizarea HTTPS, separarea logurilor și un proces regulat de testare fac gestionarea mai multor site-uri extrem de eficientă. Aceleași principii se pot aplica de la un site de portofoliu mic până la proiecte multiple pentru clienți.

Dacă intenționați să publicați un nou proiect, mai întâi clarificați nevoile dvs. de domeniu, resursele serverului și SSL; apoi, utilizați lista de verificare de mai sus pentru a construi pas cu pas configurația Nginx. Dacă căutați o infrastructură mai gestionabilă, puteți explora soluțiile Pachete de hosting, server VPS și certificate SSL de la Hostragons pentru a alege punctul de pornire potrivit pentru proiectul dvs.

Întrebări Frecvente

Cu câte site-uri pot găzdui folosind blocurile de server Nginx?

Tehnic, puteți găzdui un număr mare de site-uri pe același server Nginx; limita depinde de obicei de CPU, RAM, disc, trafic, sarcina bazei de date și capacitatea PHP-FPM. Pe site-urile statice cu trafic redus, este posibil să aveți zeci de site-uri, în timp ce pentru proiecte complexe WordPress sau de e-commerce, este mai sănătos să găzduiți mai puține site-uri.

Este necesar un certificat SSL separat pentru fiecare site?

Da, fiecare domeniu sau subdomeniu care va fi publicat pe HTTPS trebuie inclus în domeniul certificatului. Este posibil să utilizați certificate separate, precum și certificate SAN sau wildcard. Ceea ce este important este ca fișierele corecte ale certificatului să fie asociate cu domeniile corespunzătoare în blocul de server Nginx pe portul 443.

Pot publica subdomenii folosind un bloc de server Nginx?

Da. Puteți defini un server_name separat pentru subdomenii precum blog.site.com sau panel.site.com și le puteți direcționa către un director root diferit sau către o aplicație backend diferită. Pe partea de DNS, trebuie să creați o înregistrare A sau CNAME pentru subdomeniul respectiv.

Care este diferența dintre site-available și sites-enabled?

sites-available este locul în care sunt păstrate fișierele de configurare disponibile; sites-enabled conține configurațiile active. De obicei, în sites-enabled se creează o legătură simbolică către fișierul din sites-available. Această metodă face activarea și dezactivarea site-urilor mai organizată.

Dacă se deschide un site greșit, de unde provine problema?

Cele mai frecvente cauze sunt că DNS se direcționează către o IP greșită, valoarea server_name este greșită, blocul de server implicit Nginx captează cererea sau blocul SSL de pe partea de 443 funcționează greșit. Verificați mai întâi înregistrările DNS, apoi ieșirea nginx -t, legăturile active din sites-enabled și fișierul access_log corespunzător.