Jak przekierować HTTP na HTTPS w systemie Linux za pomocą Nginx (Kompletny przewodnik)

Zabezpieczenie witryny za pomocą HTTPS nie jest już opcjonalne — jest to fundamentalne wymaganie ochrony danych użytkowników, utrzymania zaufania i osiągnięcia silnych pozycji w rankingach SEO. Wyszukiwarki takie jak Google aktywnie karają nieszyfrowane witryny HTTP, podczas gdy nowoczesne przeglądarki oznaczają je jako „Niezabezpieczone”. Przekierowanie całego ruchu HTTP na HTTPS zapewnia, że każdy odwiedzający automatycznie dociera do zaszyfrowanej wersji witryny bez żadnej ręcznej interwencji.

Ten kompleksowy przewodnik przeprowadzi Cię przez cały proces: zrozumienie różnicy między HTTP i HTTPS, instalacja bezpłatnego certyfikatu SSL za pośrednictwem Let’s Encrypt, konfiguracja stałego przekierowania 301 w Nginx i weryfikacja, że wszystko działa prawidłowo na serwerze Linux.

Spis treści

1. HTTP vs. HTTPS: Jaka jest różnica?
2. Wymagania wstępne
3. Krok 1: Instalacja certyfikatu SSL za pomocą Let’s Encrypt
4. Krok 2: Konfiguracja Nginx do przekierowania HTTP na HTTPS
5. Krok 3: Testowanie konfiguracji Nginx
6. Krok 4: Przeładowanie Nginx w celu zastosowania zmian
7. Krok 5: Weryfikacja działania przekierowania
8. Typowe problemy i rozwiązywanie problemów
9. Podsumowanie

1. HTTP vs. HTTPS: Jaka jest różnica? {#http-vs-https}

Przed przystąpieniem do konfiguracji ważne jest zrozumienie, dlaczego to przekierowanie ma znaczenie.

HTTP (Hypertext Transfer Protocol)

HTTP to podstawowy protokół używany do przesyłania danych między przeglądarką internetową a serwerem. Jednak przesyła wszystkie dane w zwykłym tekście, co oznacza, że każde informacje — dane logowania, szczegóły płatności, dane osobowe — mogą być przechwycone przez atakujących przy użyciu ataku man-in-the-middle (MITM). HTTP nie oferuje szyfrowania, uwierzytelniania ani gwarancji integralności danych.

HTTPS (HTTP Secure)

HTTPS to bezpieczne rozszerzenie HTTP. Opakowuje standardowy protokół HTTP w szyfrowanie SSL/TLS, tworząc zaszyfrowany tunel między klientem a serwerem. Zapewnia to:

• Poufność — Dane nie mogą być odczytane przez strony trzecie podczas transmisji.
• Integralność — Dane nie mogą być zmieniane podczas transmisji.
• Uwierzytelnianie — Użytkownicy mogą zweryfikować, że komunikują się z legalnym serwerem.
• Przewaga SEO — Google używa HTTPS jako sygnału rankingowego, dając bezpiecznym witrynom mierzalną przewagę.
• Zaufanie przeglądarki — Chrome, Firefox i Edge wyświetlają ikonę kłódki dla witryn HTTPS i ostrzeżenie „Niezabezpieczone” dla witryn HTTP.

Podsumowanie: uruchamianie witryny bez HTTPS w dzisiejszym środowisku stanowi poważne zagrożenie bezpieczeństwa i biznesu.

2. Wymagania wstępne {#prerequisites}

Przed wykonaniem tego przewodnika upewnij się, że masz na miejscu:

• Serwer Linux (Ubuntu 20.04/22.04, Debian 11/12 lub podobny) z uruchomionym Nginx
• Zarejestrowaną nazwę domeny wskazującą na adres IP serwera
• Dostęp root lub sudo do serwera
• Podstawową znajomość wiersza poleceń Linux

Jeśli szukasz niezawodnego środowiska serwera do hostowania witryny, VPS Hosting od AlexHost zapewnia w pełni zarządzane i niezarządzane plany Linux VPS zoptymalizowane dla aplikacji internetowych, z magazynem SSD i siecią o wysokiej dostępności.

Będziesz również potrzebować ważnego certyfikatu SSL. Ten przewodnik używa bezpłatnego certyfikatu Let’s Encrypt za pośrednictwem Certbot. Jeśli potrzebujesz certyfikatu z rozszerzoną walidacją (EV) lub walidacją organizacyjną (OV) do użytku biznesowego, rozważ zapoznanie się z Certyfikatami SSL od AlexHost.

3. Krok 1: Instalacja certyfikatu SSL za pomocą Let’s Encrypt {#install-ssl}

Let’s Encrypt to bezpłatny, zautomatyzowany i otwarty urząd certyfikacji. Certbot to oficjalny klient, który automatyzuje proces uzyskiwania i odnawiania certyfikatów SSL/TLS od Let’s Encrypt i konfigurowania serwera internetowego.

Instalacja Certbot i wtyczki Nginx

Zaktualizuj indeks pakietów i zainstaluj Certbot wraz z wtyczką Nginx:

sudo apt update
sudo apt install certbot python3-certbot-nginx -y

Uzyskaj i zainstaluj certyfikat SSL

Uruchom Certbot z flagą --nginx aby automatycznie uzyskać certyfikat i skonfigurować Nginx do jego użycia:

sudo certbot --nginx -d example.com -d www.example.com

Zastąp example.com rzeczywistą nazwą domeny. Certbot będzie:

1. Weryfikować własność domeny za pośrednictwem wyzwania ACME
2. Uzyskać podpisany certyfikat od Let’s Encrypt
3. Automatycznie zmodyfikować konfigurację Nginx w celu włączenia HTTPS na porcie 443
4. Opcjonalnie skonfigurować automatyczne przekierowanie HTTP na HTTPS (możesz pominąć ten krok w Certbot i skonfigurować go ręcznie jak pokazano poniżej dla pełnej kontroli)

Włącz automatyczne odnawianie certyfikatu

Certyfikaty Let’s Encrypt wygasają co 90 dni. Certbot instaluje czasomierz systemd lub zadanie cron do automatycznego obsługiwania odnowień. Sprawdź, czy jest aktywny:

sudo systemctl status certbot.timer

Możesz również wykonać test suchego przebiegu odnowienia:

sudo certbot renew --dry-run

4. Krok 2: Konfiguracja Nginx do przekierowania HTTP na HTTPS {#configure-nginx}

Po zainstalowaniu certyfikatu SSL musisz teraz skonfigurować Nginx do stałego przekierowania całego ruchu HTTP (port 80) na HTTPS (port 443). Odbywa się to za pomocą 301 Moved Permanently przekierowania, które jest prawidłowym typem przekierowania dla SEO — przekazuje wartość linku do wersji HTTPS stron.

Otwórz plik konfiguracji bloku serwera Nginx

Konfiguracje witryn Nginx są zwykle przechowywane w /etc/nginx/sites-available/. Otwórz plik konfiguracji dla domeny:

sudo nano /etc/nginx/sites-available/example.com

Skonfiguruj blok przekierowania HTTP na HTTPS

Plik konfiguracji będzie zawierać jeden lub więcej bloków server. Zlokalizuj blok nasłuchujący na porcie 80 (HTTP) i zastąp lub zaktualizuj go następującą regułą przekierowania:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    # Permanently redirect all HTTP requests to HTTPS
    return 301 https://$host$request_uri;
}

Blok serwera HTTPS (port 443), który Certbot prawdopodobnie skonfigurował automatycznie, powinien wyglądać podobnie do tego:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    root /var/www/example.com/html;
    index index.html index.php;

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

> Dlaczego używać return 301 zamiast rewrite?

> Dyrektywa return 301 jest szybsza i bardziej wydajna niż reguła rewrite. Natychmiast zwraca odpowiedź przekierowania bez konieczności przetwarzania przez Nginx dodatkowych bloków lokalizacji, zmniejszając obciążenie serwera i poprawiając czas odpowiedzi.

Zrozumienie dyrektywy przekierowania

5. Krok 3: Testowanie konfiguracji Nginx {#test-nginx}

Nigdy nie przeładowuj ani nie uruchamiaj ponownie Nginx bez wcześniejszego testowania konfiguracji. Błąd składni w pliku konfiguracji spowoduje, że Nginx nie uruchomi się, biorąc witrynę w tryb offline.

Uruchom wbudowany test konfiguracji Nginx:

sudo nginx -t

Pomyślny test daje następujące dane wyjściowe:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Jeśli widzisz jakiekolwiek błędy, dokładnie przejrzyj dane wyjściowe. Nginx wskaże plik i numer wiersza, w którym problem został wykryty. Typowe problemy to:

• Brakujące średniki na końcu dyrektyw
• Niezamknięte nawiasy klamrowe {}
• Nieprawidłowe ścieżki plików dla certyfikatów SSL
• Zduplikowane wpisy server_name

Napraw wszelkie zgłoszone błędy przed kontynuowaniem.

6. Krok 4: Przeładowanie Nginx w celu zastosowania zmian {#reload-nginx}

Po pomyślnym przejściu testu konfiguracji przeładuj Nginx, aby zastosować zmiany. Użycie reload zamiast restart jest preferowane, ponieważ stosuje nową konfigurację bezpiecznie bez przerywania aktywnych połączeń:

sudo systemctl reload nginx

Aby potwierdzić, że Nginx działa prawidłowo po przeładowaniu:

sudo systemctl status nginx

Powinieneś zobaczyć active (running) w danych wyjściowych.

7. Krok 5: Weryfikacja działania przekierowania {#verify-redirect}

Po przeładowaniu Nginx czas potwierdzić, że przekierowanie działa prawidłowo.

Metoda 1: Test przeglądarki

1. Otwórz przeglądarkę internetową.
2. Przejdź do http://example.com (używając HTTP, nie HTTPS).
3. Obserwuj, że przeglądarka automatycznie przekierowuje Cię na https://example.com.
4. Potwierdź, że ikona kłódki pojawia się na pasku adresu, wskazując prawidłowe połączenie SSL.

Metoda 2: Test wiersza poleceń z curl

Użyj curl z flagą -I aby pobrać tylko nagłówki odpowiedzi HTTP bez pobierania treści strony:

curl -I http://example.com

Prawidłowo skonfigurowane przekierowanie daje następującą odpowiedź:

HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Mon, 01 Jan 2025 12:00:00 GMT
Content-Type: text/html
Location: https://example.com/
Connection: keep-alive

Kluczowe wskaźniki do weryfikacji:

• Kod stanu 301 Moved Permanently — Potwierdza, że stałe przekierowanie jest na miejscu.
• Location: https://example.com/ — Potwierdza, że ruch jest przekierowywany do wersji HTTPS.

Metoda 3: Narzędzie do sprawdzania przekierowań online

Możesz również użyć bezpłatnych narzędzi online, takich jak redirect-checker.org lub httpstatus.io, aby śledzić pełny łańcuch przekierowań i potwierdzić, że nie ma pętli przekierowań ani niepotrzebnych przeskoków.

8. Typowe problemy i rozwiązywanie problemów {#troubleshooting}

Pętla przekierowania

Symptom: Przeglądarka wyświetla błąd „Zbyt wiele przekierowań”.

Przyczyna: Blok serwera HTTPS również wyzwala przekierowanie z powrotem do HTTP, tworząc nieskończoną pętlę.

Rozwiązanie: Upewnij się, że dyrektywa return 301 istnieje tylko w bloku HTTP (port 80), a nie w bloku HTTPS (port 443).

Ostrzeżenia dotyczące mieszanej zawartości

Symptom: Ikona kłódki pokazuje ostrzeżenie nawet po działającym przekierowaniu.

Przyczyna: Strony HTML nadal odwołują się do zasobów HTTP (obrazów, skryptów, arkuszy stylów) przy użyciu adresów URL http://.

Rozwiązanie: Zaktualizuj wszystkie wewnętrzne adresy URL zasobów, aby używały https:// lub adresów URL niezależnych od protokołu (//). Użyj wtyczki takiej jak Really Simple SSL dla witryn WordPress.

Certyfikat SSL nie znaleziony

Symptom: Nginx nie uruchamia się z błędem dotyczącym brakujących plików certyfikatu.

Przyczyna: Ścieżki określone w ssl_certificate i ssl_certificate_key nie odpowiadają rzeczywistym lokalizacjom plików certyfikatu.

Rozwiązanie: Sprawdź ścieżki certyfikatu za pomocą:

###PPT_NO