Strona WWW na VPS: Nginx i certyfikat Let's Encrypt (HTTPS)

Nginx to szybki serwer WWW. Użyjemy go do serwowania statycznej strony albo postawimy go przed aplikacją jako reverse proxy i włączymy HTTPS z certyfikatem Let's Encrypt, który odnawia się sam.

Jak to działa#

Przeglądarka łączy się z portem 80 (HTTP) lub 443 (HTTPS) Twojego VPS. Na podstawie domeny w żądaniu Nginx wybiera właściwy server block (konfigurację jednej strony) i albo wysyła plik z dysku (strona statyczna), albo przekazuje żądanie aplikacji działającej na innym porcie (reverse proxy).

Certyfikat HTTPS wystawia bezpłatnie Let's Encrypt. Program Certbot weryfikuje, że kontrolujesz domenę (Let's Encrypt łączy się z portem 80 i pobiera plik kontrolny), pobiera certyfikat, konfiguruje go w Nginx i potem sam go odnawia.

Wymagania wstępne: DNS i porty#

1. Sprawdź, czy domena wskazuje na VPS. Na VPS uruchom:

   getent hosts example.cz

   Zobaczysz adres IP swojego VPS (z zakładki Sieć). Jeśli nie, popraw DNS i poczekaj na propagację zmiany.

2. Otwórz porty 80 i 443:

   • Firewall w strefie klienta (jeśli używasz trybu Blokuj wszystko poza dozwolonym): reguła Przychodzący · Zezwól · TCP · port 80,443. Poradnik: Firewall w strefie klienta.
   • UFW na VPS (jeśli go używasz): ufw allow 80/tcp i ufw allow 443/tcp.

Instalacja Nginx#

Działa zarówno na Ubuntu 24.04, jak i na Debianie 13:

apt update
apt -y install nginx

• apt -y install nginx – instaluje Nginx. Usługa startuje od razu i jest włączona przy uruchomieniu VPS.

Kontrola: otwórz w przeglądarce http://<ADRES_IP_VPS>. Zamiast <ADRES_IP_VPS> wstaw adres IPv4 z zakładki Sieć (na przykład http://203.0.113.10). Zobaczysz stronę „Welcome to nginx!”.

Jak uporządkowana jest konfiguracja#

Stronę włączasz więc, tworząc plik w sites-available i dowiązanie do niego w sites-enabled. Wyłączasz ją, usuwając dowiązanie.

Strona statyczna#

Strona statyczna to zestaw gotowych plików HTML, CSS, JavaScript i obrazów.

1. Utwórz katalog strony i stronę testową:

   mkdir -p /var/www/example.cz/html
   echo '<h1>It works</h1>' > /var/www/example.cz/html/index.html

   • mkdir -p – tworzy katalog łącznie z nadrzędnymi.
   • echo '…' > …/index.html – zapisuje prostą stronę do index.html.

   Później prześlij do tego katalogu własne pliki strony przez SFTP (poradnik) albo w zakładce Pliki.

2. Utwórz konfigurację strony:

   nano /etc/nginx/sites-available/example.cz

   server {
       listen 80;
       listen [::]:80;
       server_name example.cz www.example.cz;
   
       root /var/www/example.cz/html;
       index index.html;
   
       location / {
           try_files $uri $uri/ =404;
       }
   }

3. Włącz stronę, wyłącz domyślną stronę powitalną, przetestuj konfigurację i ją wczytaj:

   ln -s /etc/nginx/sites-available/example.cz /etc/nginx/sites-enabled/
   rm /etc/nginx/sites-enabled/default
   nginx -t
   systemctl reload nginx

   • ln -s … /etc/nginx/sites-enabled/ – tworzy dowiązanie, więc Nginx zaczyna wczytywać stronę.
   • rm /etc/nginx/sites-enabled/default – wyłącza domyślną stronę (plik zostaje w sites-available).
   • nginx -t – sprawdza składnię wszystkich konfiguracji. Musi zakończyć się syntax is ok i test is successful.
   • systemctl reload nginx – wczytuje nową konfigurację bez zrywania połączeń.

Kontrola: http://example.cz pokazuje nagłówek „It works” ze strony testowej.

Reverse proxy dla aplikacji#

Aplikacja (Node.js, Python, Java, kontener Dockera) zwykle działa na własnym porcie, na przykład 3000. Stawiasz przed nią Nginx jako reverse proxy: przyjmuje żądania na porcie 80/443 i przekazuje je aplikacji. Korzyści: Nginx obsługuje HTTPS, aplikacja nie musi być widoczna z internetu, a na jednym VPS może działać kilka aplikacji pod różnymi domenami.

Konfiguracja (zamiast strony statycznej albo jako kolejny plik dla innej domeny, na przykład app.example.cz):

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    listen [::]:80;
    server_name app.example.cz;

    client_max_body_size 20m;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_read_timeout 300s;
    }
}

Włączenie działa tak samo jak przy stronie statycznej:

ln -s /etc/nginx/sites-available/app.example.cz /etc/nginx/sites-enabled/
nginx -t
systemctl reload nginx

Aby aplikacja działała stale i startowała automatycznie po restarcie VPS, skonfiguruj ją jako usługę: Aplikacja 24/7 z systemd.

HTTPS przez Certbot#

Instalacja Certbota#

apt -y install certbot python3-certbot-nginx

• certbot – klient Let's Encrypt.
• python3-certbot-nginx – wtyczka, która potrafi zweryfikować domenę przez Nginx i sama edytować jego konfigurację.

Uzyskanie certyfikatu#

certbot --nginx -d example.cz -d www.example.cz

• --nginx – weryfikacja przez Nginx i automatyczna edycja jego konfiguracji.
• -d example.cz -d www.example.cz – domeny, dla których chcesz certyfikat. Każda musi mieć rekord DNS wskazujący na VPS i być wymieniona w server_name jakiejś strony.

Przy pierwszym uruchomieniu Certbot zadaje te pytania:

Wynik: Successfully deployed certificate for example.cz to /etc/nginx/sites-enabled/example.cz i Congratulations! You have successfully enabled HTTPS….

Co Certbot zmienił w konfiguracji#

Otwórz konfigurację strony (nano /etc/nginx/sites-available/example.cz). Linie oznaczone # managed by Certbot dodał Certbot:

Nie edytuj tych linii ręcznie, chyba że dokładnie wiesz dlaczego. Certbot opiera się na nich przy odnawianiu.

Automatyczne odnawianie#

Certyfikat Let's Encrypt jest ważny 90 dni (stan na październik 2026; Let's Encrypt stopniowo skraca ważność). Pakiet Certbota zainstalował timer, który dwa razy dziennie sprawdza certyfikaty i odnawia te, którym została mniej więcej jedna trzecia ważności. Wtyczka Nginx sama przeładowuje Nginx po odnowieniu.

Sprawdź, czy timer istnieje i czy odnawianie działa:

systemctl list-timers | grep certbot
certbot renew --dry-run

• systemctl list-timers | grep certbot – wypisuje linię z certbot.timer i czasem następnego uruchomienia.
• certbot renew --dry-run – próbuje odnowienia na serwerze testowym bez dotykania prawdziwych certyfikatów. Musi zakończyć się Congratulations, all simulated renewals succeeded.

certbot certificates wypisuje Twoje certyfikaty i ich ważność.

Cloudflare i tryby SSL#

Jeśli strona działa przez proxy Cloudflare (pomarańczowa chmurka), szyfrowane są dwa połączenia: między odwiedzającym a Cloudflare oraz między Cloudflare a Twoim VPS. Drugim steruje tryb SSL/TLS w Cloudflare:

Po przełączeniu na Proxied uruchom certbot renew --dry-run i sprawdź, czy odnawianie działa także przez proxy Cloudflare. Jeśli się nie powiedzie, upewnij się, że nie blokujesz portu 80 własnymi regułami w Cloudflare. Trwałe rozwiązanie dla zaawansowanych to weryfikacja domeny przez DNS wtyczką python3-certbot-dns-cloudflare (zobacz dokumentację Certbota (otwiera się w nowym oknie)).

Podstawowe zabezpieczenie#

1. Ukryj wersję Nginx. Na Debianie 13 /etc/nginx/nginx.conf zawiera już domyślnie server_tokens off;. Na Ubuntu 24.04 otwórz plik (nano /etc/nginx/nginx.conf) i w bloku http usuń # przed # server_tokens off;. Nginx nie zdradza wtedy swojej wersji w nagłówkach ani na stronach błędów.

2. Nagłówki bezpieczeństwa. Możesz dodać je do bloku server z portem 443:

   add_header X-Content-Type-Options nosniff always;
   add_header X-Frame-Options SAMEORIGIN always;
   add_header Referrer-Policy strict-origin-when-cross-origin always;

   • X-Content-Type-Options nosniff – przeglądarka nie zgaduje typu pliku (ochrona przed zamaskowanymi skryptami).
   • X-Frame-Options SAMEORIGIN – strony nie da się osadzić w cudzej stronie w ramce (ochrona przed clickjackingiem).
   • Referrer-Policy strict-origin-when-cross-origin – inne strony dostają tylko domenę, nie pełny URL strony.
   • always – nagłówek jest wysyłany także z odpowiedziami błędów.

3. Po każdej zmianie uruchom nginx -t i systemctl reload nginx.

Weryfikacja#

curl -I http://example.cz
curl -I https://example.cz

• curl -I – pobiera tylko nagłówki odpowiedzi.

Pierwsze polecenie zwraca HTTP/1.1 301 Moved Permanently z nagłówkiem Location: https://example.cz/, drugie HTTP/1.1 200 OK (lub HTTP/2 200). W przeglądarce zobaczysz kłódkę obok adresu.

Rozwiązywanie problemów#

nginx -t zgłasza błąd#

Wyjście zawiera plik i numer linii, na przykład unexpected "}" in /etc/nginx/sites-enabled/example.cz:12. Najczęściej brakuje średnika na końcu dyrektywy albo jest zbędny lub brakujący nawias klamrowy. Popraw linię i uruchom test ponownie. Nie restartuj Nginx z zepsutą konfiguracją; nie wystartowałby.

502 Bad Gateway#

Nginx działa, ale aplikacja za nim nie odpowiada. Sprawdź, czy aplikacja działa i nasłuchuje na porcie z proxy_pass:

ss -tlnp | grep 3000

• ss -tlnp – nasłuchujące porty TCP z nazwami programów.

Jeśli nic się nie wypisuje, aplikacja nie działa albo nasłuchuje gdzie indziej. Szczegóły są w /var/log/nginx/error.log (linia z connect() failed (111: Connection refused)).

504 Gateway Time-out#

Aplikacja odpowiedziała za późno. Zwiększ proxy_read_timeout albo ustal, dlaczego aplikacja jest wolna.

413 Request Entity Too Large#

Przesyłany plik jest większy niż client_max_body_size (domyślnie 1 MB). Zwiększ wartość w bloku server i przeładuj konfigurację.

Zamiast strony wyświetla się „Welcome to nginx!”#

Domyślna strona jest nadal aktywna albo domena w server_name nie zgadza się z adresem w przeglądarce. Usuń /etc/nginx/sites-enabled/default i sprawdź server_name.

Nginx nie startuje: Address already in use#

Port 80 lub 443 zajmuje inny program, zwykle Apache. Ustal który: ss -tlnp | grep -E ':80 |:443 '. Zatrzymaj i wyłącz Apache (systemctl disable --now apache2) albo go odinstaluj.

Certbot: Could not automatically find a matching server block#

Żadna strona nie ma w server_name domeny, dla której żądasz certyfikatu. Dodaj ją do server_name, uruchom nginx -t, systemctl reload nginx i ponownie Certbota.

Certbot: Timeout during connect (likely firewall problem) lub Connection refused#

Let's Encrypt nie mógł dotrzeć do portu 80. Sprawdź DNS (getent hosts example.cz), firewall w strefie klienta i UFW. Jeśli domena ma rekord AAAA, musi wskazywać na adres IPv6 tego VPS, a strona musi nasłuchiwać także na IPv6 (listen [::]:80;).

Cloudflare: błąd 521, 522, 525 lub 526#

• 521 – VPS odrzucił połączenie: Nginx nie działa albo firewall blokuje port 443.
• 522 – przekroczony czas połączenia: VPS jest nieosiągalny albo firewall odrzuca pakiety.
• 525 – nie powiódł się handshake TLS: Nginx nie ma poprawnej konfiguracji HTTPS na porcie 443.
• 526 – certyfikat na VPS jest nieprawidłowy lub wygasł, w trybie Full (strict). Sprawdź certbot certificates.

ERR_TOO_MANY_REDIRECTS#

Zwykle Cloudflare w trybie Flexible w połączeniu z przekierowaniem HTTPS. Przełącz Cloudflare na Full (strict).

Dalsza lektura#

• nginx: Beginner's Guide (otwiera się w nowym oknie)
• nginx: WebSocket proxying (otwiera się w nowym oknie)
• nginx: ngx_http_proxy_module (otwiera się w nowym oknie)
• Certbot: User Guide (otwiera się w nowym oknie)
• Let's Encrypt: Rate Limits (otwiera się w nowym oknie)
• Cloudflare: tryby szyfrowania SSL/TLS (otwiera się w nowym oknie)