Nginx Bloki Serwera (Virtual Hosts) – Jak Hostować Wiele Stron na Jednym Serwerze

Bloki serwera Nginx to mechanizm pozwalający na uruchomienie wielu domen lub stron internetowych na pojedynczej instalacji Nginx, każda z własną, odrębną konfiguracją. Przykładowo na tym samym VPS możesz mieć różne katalogi root, pliki logów, certyfikaty SSL czy ustawienia PHP dla example.com, blog.example.com czy drugiej-strony.pl. W skrócie: tworzymy osobne katalogi dla każdej strony, kierujemy rekordy DNS domen na IP serwera, tworzymy osobny blok serwera w /etc/nginx/sites-available, aktywujemy go przez symlink w sites-enabled, testujemy konfigurację i przeładowujemy Nginx.

W tym przewodniku omówimy, jak profesjonalnie i bezpiecznie skonfigurować hostowanie wielu stron w Nginx. Nie chodzi tylko o działającą konfigurację, lecz o skalowalny, bezpieczny i łatwy w utrzymaniu system. Szczególnie przydatny będzie dla agencji, developerów, właścicieli sklepów e-commerce, firm zarządzających wieloma markami oraz administratorów, którzy na jednym serwerze obsługują wiele projektów. Jeśli nie masz jeszcze serwera, warto najpierw zapoznać się z Serwer VPS oraz Rejestracja Domeny przed dalszą konfiguracją.

Co to są bloki serwera Nginx?

Bloki serwera Nginx to fragmenty konfiguracji oznaczone jako server, które definiują, jak serwer reaguje na przychodzące żądania HTTP lub HTTPS i do której strony je kieruje. Można je porównać do koncepcji VirtualHost w Apache. Gdy użytkownik wpisuje domenę w przeglądarce, DNS tłumaczy ją na adres IP serwera. Nginx odczytuje nagłówek Host i wybiera odpowiedni blok serwera na podstawie wartości server_name.

Dzięki temu na jednym adresie IP i serwerze (fizycznym lub wirtualnym) można hostować dziesiątki różnych stron. Każda z nich może mieć osobny katalog root, osobne pliki logów, własne reguły przekierowań, certyfikaty SSL, polityki cache czy ustawienia bezpieczeństwa. Na przykład firmową stronę możesz umieścić w /var/www/firma/public, blog w /var/www/blog/public, a środowisko testowe w /var/www/test/public.

Nginx jest bardzo wydajny dzięki architekturze zdarzeniowej, co pozwala obsługiwać dużą liczbę równoczesnych połączeń przy niskim zużyciu zasobów. Dlatego często jest wybierany na hosting współdzielony, VPS, serwery chmurowe czy aplikacje o dużym ruchu. Aby wszystko działało stabilnie, ważne jest prawidłowe planowanie praw dostępu, rekordów DNS, instalacji SSL i rozdzielenia logów.

Kiedy używać bloków serwera Nginx?

Bloki serwera Nginx są niezastąpione, gdy na jednym serwerze trzeba zarządzać wieloma stronami internetowymi. To może być kilka małych firmowych stron lub dziesiątki projektów klientów, subdomen czy mikroserwisów. Kluczowe jest, by każdy projekt był logicznie odseparowany.

• Gdy chcesz hostować wiele domen na jednym VPS.
• Gdy chcesz przekierować wersje www i bez www na jedną kanoniczną domenę.
• Gdy subdomeny mają wskazywać na różne katalogi lub aplikacje.
• Gdy każda strona ma mieć osobny certyfikat SSL i politykę bezpieczeństwa.
• Gdy chcesz monitorować projekty klientów na osobnych plikach logów.
• Gdy na jednym serwerze uruchamiasz różne aplikacje: Laravel, WordPress, statyczne strony czy Node.js.

Na przykład agencja może na jednym VPS z 4 GB RAM hostować 8 niskoruchliwych stron firmowych. Trzeba jednak wtedy dobrze oszacować ruch, wykorzystanie dysku, liczbę procesów PHP, obciążenie baz danych i częstotliwość backupów. Przy większym ruchu lub konieczności izolacji zasobów lepiej wybrać mocniejszy VPS, serwer w chmurze lub hosting zarządzany. W takim wypadku warto przeanalizować opcje Hosting WWW i Hosting dla firm.

Wymagania przed rozpoczęciem

Zakładamy, że korzystasz z serwera Linux opartego na Ubuntu lub Debianie. Polecenia mogą się różnić w innych dystrybucjach, ale zasada pozostaje ta sama. Przed wprowadzeniem zmian na produkcji zawsze wykonaj kopię zapasową. Błędna konfiguracja Nginx może spowodować chwilową niedostępność wszystkich stron.

Nieodzowne przygotowania techniczne

• Konto użytkownika z uprawnieniami root lub sudo.
• Zainstalowany i działający serwer Nginx.
• Co najmniej jedna domena skierowana na IP serwera.
• Porty 80 i 443 otwarte w zaporze.
• Ustrukturyzowany katalog na pliki stron.
• Certyfikat SSL – ważny lub bezpłatny z Let’s Encrypt.
• Dla aplikacji PHP – zainstalowany PHP-FPM.

W DNS rekord A wskazuje na IPv4, a AAAA na IPv6, jeśli jest dostępny. Subdomeny jak www można przypisać przez CNAME lub A. Propagacja DNS trwa od kilku minut do 24 godzin. Przy konfiguracji zaczynaj od przygotowania rekordów DNS, potem przechodź do bloków serwera Nginx – to przyspieszy proces.

Rekomendowana struktura katalogów

Jednym z najczęstszych błędów przy hostowaniu wielu stron jest trzymanie wszystkich plików w jednym, nieuporządkowanym katalogu. Choć na początku wydaje się to proste, utrudnia późniejszą konserwację, backup i debugowanie. Lepszym rozwiązaniem jest stworzenie osobnego katalogu nadrzędnego dla każdej domeny z podkatalogami na publiczne pliki, logi i kopie zapasowe.

Przykład struktury: /var/www/site1.pl/public, /var/www/site1.pl/logs, /var/www/site2.pl/public, /var/www/site2.pl/logs. Wartość root w konfiguracji Nginx zawsze powinna wskazywać bezpośrednio na katalog publiczny, by chronić pliki konfiguracyjne, .env czy backupy przed dostępem z poziomu przeglądarki.

Możesz też w każdym katalogu umieścić prosty plik index.html z nazwą strony, by szybko zweryfikować, który blok serwera jest aktywny. Na produkcji właścicielem plików zwykle jest użytkownik www-data lub dedykowany użytkownik deploymentu. Standardowe uprawnienia to 755 dla katalogów i 644 dla plików – w przypadku WordPressa katalog uploads i inne zapisywalne foldery wymagają dodatkowych ustawień.

Jak krok po kroku stworzyć blok serwera Nginx

Poniższe kroki opisują konfigurację dla domeny site1.pl. Analogicznie powtarzasz je dla kolejnych stron. Kluczowe jest, aby każda strona miała unikalne wartości server_name, root oraz osobne pliki logów.

1. Utwórz katalog strony

Na początek tworzysz katalog, gdzie będą pliki www: sudo mkdir -p /var/www/site1.pl/public. Następnie dla testu możesz dodać plik index.html z tekstem np. „To jest strona testowa site1.pl”.

Aby poprawnie ustawić właściciela, wykonaj: sudo chown -R www-data:www-data /var/www/site1.pl. Jeśli deployment jest realizowany przez innego użytkownika, dostosuj grupę i uprawnienia. Unikaj nadawania uprawnień 777, które mogą ułatwić ataki i nadużycia.

2. Stwórz plik bloku serwera

W Nginx powszechną praktyką jest przechowywanie konfiguracji nieaktywnych w /etc/nginx/sites-available oraz aktywnych poprzez link symboliczny w /etc/nginx/sites-enabled. Przykładowy plik to /etc/nginx/sites-available/site1.pl.

Prosta konfiguracja HTTP wygląda tak:

server {
    listen 80;
    server_name site1.pl www.site1.pl;
    root /var/www/site1.pl/public;
    index index.html index.htm;

    access_log /var/log/nginx/site1.pl.access.log;
    error_log /var/log/nginx/site1.pl.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

Parametr listen 80 nasłuchuje na ruch HTTP, server_name definiuje domeny przypisane do tego bloku, root wskazuje katalog ze stroną, index definiuje domyślny plik. Dyrektywa try_files sprawdza, czy plik lub katalog istnieje, a jeśli nie, zwraca błąd 404. Taka konfiguracja jest wystarczająca dla statycznych stron.

3. Aktywuj blok serwera

Aktywacja polega na utworzeniu linku symbolicznego:

sudo ln -s /etc/nginx/sites-available/site1.pl /etc/nginx/sites-enabled/site1.pl

Ta metoda jest bezpieczniejsza niż kopiowanie plików, bo zmiany w oryginale od razu mają wpływ na aktywną konfigurację.

Jeśli nie chcesz, aby domyślna strona Nginx blokowała dostęp do Twojej, możesz wyłączyć domyślną konfigurację usuwając link /etc/nginx/sites-enabled/default. Pamiętaj jednak, aby najpierw zweryfikować działanie własnego bloku.

4. Sprawdź konfigurację i przeładuj Nginx

Po każdej zmianie warto wykonać test składni poleceniem:

sudo nginx -t

Jeśli test przejdzie pomyślnie, przeładuj usługę bez przerw w działaniu:

sudo systemctl reload nginx

Komenda reload jest bezpieczniejsza od restartu, bo łagodnie obsługuje aktywne połączenia.

Jeśli test się nie powiedzie, komunikat wskaże plik i linię z błędem – najczęściej jest to brak średnika, błąd nawiasów, błędna ścieżka lub konflikt w server_name. Nginx nie załaduje konfiguracji, dopóki nie poprawisz błędów.

Dodawanie drugiej i trzeciej strony

Największą zaletą wielu bloków serwera jest powtarzalność procesu. Dla site2.pl tworzysz katalog /var/www/site2.pl/public, plik konfiguracyjny /etc/nginx/sites-available/site2.pl, dostosowujesz root i pliki logów, tworzysz link symboliczny i testujesz konfigurację.

Przykładowa konfiguracja dla drugiej strony:

server {
    listen 80;
    server_name site2.pl www.site2.pl;
    root /var/www/site2.pl/public;
    index index.html;

    access_log /var/log/nginx/site2.pl.access.log;
    error_log /var/log/nginx/site2.pl.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

Posiadanie osobnych logów dla każdej strony to ogromna zaleta. Pozwala szybko zidentyfikować źródło błędów, np. gdy jedna witryna generuje dużo 404, a inne działają poprawnie. Możesz też analizować ruch, ataki botów czy problemy wydajnościowe indywidualnie dla każdej domeny.

Konfiguracja SSL i HTTPS

W 2026 roku HTTPS to już nie tylko kwestia bezpieczeństwa, lecz także kluczowy czynnik SEO i zaufania użytkowników. Przeglądarki oznaczają strony bez SSL jako niezabezpieczone – jest to krytyczne zwłaszcza w projektach z płatnościami, rejestracjami czy panelami administracyjnymi. Każda domena powinna mieć poprawnie skonfigurowany certyfikat SSL. W Hostragons znajdziesz Certyfikaty SSL, które ułatwią Ci ten proces.

Jeśli korzystasz z Let’s Encrypt, możesz automatycznie wygenerować certyfikat dla każdej domeny za pomocą Certbota. Polecenie:

certbot --nginx -d site1.pl -d www.site1.pl

zaktualizuje konfigurację Nginx, dodając blok HTTPS. Po automatycznej modyfikacji warto sprawdzić plik konfiguracyjny, ponieważ mogą pojawić się błędy typu duplikacja bloków lub niepoprawne przekierowania.

Standardowo ruch na porcie 80 przekierowuje się na 443 z kodem 301, co jest korzystne dla SEO. Wybierz, czy chcesz używać www czy nie, i skieruj cały ruch na tę jedną wersję kanoniczną. Na przykład, jeśli preferujesz https://site1.pl, to przekieruj zarówno http://www.site1.pl, jak i https://www.site1.pl na wersję bez www – zmniejszysz w ten sposób ryzyko duplikatów treści.

Bloki serwera Nginx dla PHP i WordPress

Statyczne strony są najprostsze do konfiguracji, ale jeśli używasz WordPressa, Laravel czy innej aplikacji PHP, konieczna jest integracja z PHP-FPM. W takim przypadku w bloku serwera dodajesz obsługę plików .php oraz wskazujesz socket PHP-FPM (np. /run/php/php8.3-fpm.sock w Ubuntu). Oto przykład konfiguracji dla WordPressa:

server {
    listen 80;
    server_name wordpress-site.pl www.wordpress-site.pl;
    root /var/www/wordpress-site.pl/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;
    }
}

Struktura try_files $uri $uri/ /index.php?$args; jest niezbędna, aby permalinki WordPressa działały poprawnie. Zadbaj też o zabezpieczenia, takie jak ograniczenia dostępu do xmlrpc.php, blokowanie uruchamiania PHP w katalogu uploads czy limitowanie prób logowania do wp-login.php. Jeśli hostujesz wiele WordPressów, każda strona powinna mieć osobną bazę danych, użytkownika oraz regularne aktualizacje. Dla wygody możesz rozważyć też Hosting WordPress, który oferuje dodatkowe narzędzia ułatwiające zarządzanie.

Porównanie bloków serwera Nginx i VirtualHost Apache

Nginx i Apache realizują podobne cele, ale w różny sposób. Oba potrafią hostować wiele stron na jednym serwerze. Wybór zależy od wymagań aplikacji, preferencji administratora i oczekiwanej wydajności.

Jeśli Twoja aplikacja mocno korzysta z reguł w .htaccess, Apache może być wygodniejszy. Przy dużym ruchu, proxy czy cache Nginx jest często lepszym wyborem. Często Nginx jest stosowany jako reverse proxy, a Apache jako backend.

Najlepsze praktyki bezpieczeństwa

Hostowanie wielu stron na jednym serwerze zmniejsza koszty, ale zwiększa odpowiedzialność za bezpieczeństwo. Luka w jednej stronie nie powinna wpływać na pozostałe. Stosuj zasady minimalnych uprawnień i izolacji.

• Każda strona z osobną bazą danych i użytkownikiem DB.
• Ogranicz katalog root do folderu public.
• Trzymaj backupy, pliki .env, .git, konfiguracje i dumpy baz poza dostępem WWW.
• Regularnie odnawiaj certyfikaty SSL i wymuszaj HTTPS.
• Używaj zapory (np. UFW), otwierając tylko niezbędne porty.
• Systematycznie aktualizuj Nginx i system operacyjny.
• Każda strona z osobnymi plikami access_log i error_log.
• Dodaj ograniczenia IP i dodatkowe uwierzytelnianie do paneli admina.
• Unikaj uprawnień 777 na plikach i katalogach.

Dobrze jest też dodać nagłówki bezpieczeństwa: X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Content-Security-Policy. Ten ostatni wymaga testów, by nie blokował skryptów i stylów. Więcej o zabezpieczeniach przeczytasz w Bezpieczeństwo strony internetowej.

Wydajność i SEO – na co zwrócić uwagę

Bloki serwera Nginx wpływają nie tylko na dostępność, ale i szybkość oraz widoczność w wyszukiwarkach. Niepoprawne przekierowania, błędne kanoniczne adresy, brak gzip lub brotli, duże pliki logów czy brak cache mogą spowolnić stronę. Google faworyzuje szybkie, bezpieczne i stabilne witryny.

Ustal jedną kanoniczną wersję domeny (np. https://site1.pl) i stosuj jednoetapowe przekierowania 301. Nie twórz łańcuchów jak http://site.pl → http://www.site.pl → https://www.site.pl → https://site.pl. Dla statycznych zasobów stosuj nagłówki cache-control z rozsądnym czasem ważności. Dla często zmienianych plików stosuj wersjonowanie nazw lub query stringi. Kompresja gzip zmniejsza transfer HTML, CSS, JS i JSON. W witrynach z dużym ruchem warto rozważyć Nginx microcache, FastCGI cache lub CDN. O CDN przeczytasz więcej w Czym jest CDN.

Zarządzanie logami i monitoring

W przypadku wielu stron logi to klucz do szybkiego rozwiązywania problemów. Pliki access_log rejestrują żądania użytkowników, error_log błędy konfiguracji, uprawnień, brak plików czy problemy z backendem. Błędy 502 zwykle dotyczą PHP-FPM lub połączeń z backendem, 403 to najczęściej problem uprawnień, a 404 wskazuje na błędną ścieżkę lub konfigurację try_files.

Kontroluj rotację logów za pomocą logrotate, aby uniknąć zapchania dysku. W małych projektach wystarczy dzienna lub tygodniowa rotacja. Duże serwisy korzystają z centralnego zbierania logów, monitoringu metryk i systemów alertów. Pełny dysk może spowodować zatrzymanie zapisu logów i awarię serwisu, dlatego ustal progi ostrzegawcze dla wykorzystania miejsca na dysku.

Typowe błędy i szybkie rozwiązania

Podczas pracy z blokami serwera Nginx często spotkasz poniższe problemy. Znajomość ich przyspiesza diagnozę i naprawę.

• Niepoprawna strona ładuje się pod domeną – sprawdź konflikty server_name i ustawienia domyślnego bloku.
• Błąd 403 Forbidden – zweryfikuj katalog root, uprawnienia i obecność pliku index.
• Błąd 404 Not Found – sprawdź ścieżkę root i reguły try_files.
• Błąd 502 Bad Gateway – upewnij się, że PHP-FPM działa i ścieżka do socketa jest poprawna.
• Certyfikat SSL na niewłaściwą domenę – sprawdź pliki certyfikatów i konfigurację portu 443.
• Przekierowania w pętli – uprość reguły przekierowań HTTP/HTTPS i www.
• Nie można przeładować Nginx – popraw błędy składni wskazane przez nginx -t.

Doświadczeni administratorzy korzystają z prostej listy kontrolnej: czy DNS jest poprawny, czy konfiguracja jest aktywna, czy katalog root istnieje, czy uprawnienia są prawidłowe, czy testy przeszły pomyślnie i co mówią logi? Takie podejście pomaga szybko i bez paniki rozwiązywać problemy.

Praktyczna lista kontrolna przed uruchomieniem na produkcji

Zanim oddasz stronę klientowi, sprawdź poniższe punkty. W projektach komercyjnych dokumentowanie ich podnosi standard pracy.

• Rekordy A lub AAAA domeny wskazują na właściwy adres IP.
• Wybrano i ustawiono wersję kanoniczną domeny (z www lub bez).
• Ruch HTTP jest przekierowany na HTTPS kodem 301.
• Certyfikat SSL jest ważny i odnowienia działają automatycznie.
• Dla każdej strony zdefiniowano osobne katalogi root i pliki logów.
• Konfiguracja Nginx przeszła pomyślnie test sudo nginx -t.
• Plan backupów jest ustalony i przeprowadzono test przywracania.
• Uprawnienia plików są zgodne z zasadą najmniejszych uprawnień.
• Zapora ma otwarte tylko niezbędne porty.
• Logi błędów monitorowano co najmniej przez 15 minut po wdrożeniu.

Choć lista wydaje się prosta, jej stosowanie znacząco zmniejsza ryzyko awarii. Szczególnie ważne są regularna kontrola certyfikatów, DNS i logów.

Podsumowanie

Bloki serwera Nginx to podstawowy sposób na wygodne, bezpieczne i wydajne hostowanie wielu stron na jednym serwerze. Dzięki dobrze przemyślanej strukturze katalogów, osobnym plikom konfiguracji, jasnym regułom przekierowań, HTTPS, rozdzieleniu logów i regularnym testom zarządzanie wieloma witrynami staje się proste i efektywne. Zasady te sprawdzą się zarówno w małych portfolio, jak i przy dużych projektach klientów.

Planując nowy projekt, najpierw ustal domenę, zasoby serwera i potrzeby SSL, a potem krok po kroku wdrażaj konfigurację według powyższej listy kontrolnej. Jeśli chcesz mieć bardziej wygodne środowisko, sprawdź ofertę Hostragons, gdzie znajdziesz Pakiety hostingu, Serwer VPS i Certyfikaty SSL, które ułatwią Ci start.

Najczęściej zadawane pytania

Ile stron można hostować w blokach serwera Nginx?

Technicznie nie ma ograniczenia na liczbę stron na jednym serwerze Nginx; ograniczenia wynikają z zasobów CPU, RAM, dysku, ruchu sieciowego, obciążenia bazy danych i PHP-FPM. Przy niskim ruchu nawet kilkadziesiąt statycznych stron jest możliwe, ale przy intensywnych projektach WordPress czy e-commerce lepiej ograniczyć liczbę stron.

Czy każda strona wymaga osobnego certyfikatu SSL?

Tak, każda domena lub subdomena publikowana przez HTTPS musi mieć odpowiedni certyfikat. Możesz użyć pojedynczych certyfikatów, certyfikatów SAN (Subject Alternative Name) lub wildcard (dzikich kart). Ważne, by pliki certyfikatów były poprawnie przypisane do domen w bloku serwera 443.

Czy można hostować subdomeny za pomocą bloków serwera Nginx?

Oczywiście. Możesz przypisać subdomeny, takie jak blog.site.pl albo panel.site.pl, jako osobne server_name, wskazać inne katalogi root lub przekierować na inne backendy. W DNS musisz dodać odpowiedni rekord A lub CNAME dla subdomeny.

Jaka jest różnica między sites-available a sites-enabled?

sites-available to katalog z wszystkimi możliwymi plikami konfiguracyjnymi, a sites-enabled zawiera linki symboliczne do aktywnych konfiguracji. Dzięki temu możesz łatwo włączać i wyłączać witryny bez usuwania plików.

Dlaczego ładuje się niewłaściwa strona?

Najczęstsze powody to błędne rekordy DNS wskazujące na złe IP, błędny wpis server_name, aktywny domyślny blok serwera Nginx przechwytujący żądania lub błędna konfiguracja certyfikatów SSL na porcie 443. Sprawdź najpierw DNS, potem wynik nginx -t, aktywne symlinki w sites-enabled i pliki access_log dla diagnostyki.