Konfigurowanie Nginx jako reverse proxy dla aplikacji backendowych | INTROSERV
EUR
european

EUR

usa

USD

Poland Pl
Ex. VAT Ex. VAT 0%

Konfigurowanie Nginx jako reverse proxy dla aplikacji backendowych

Wprowadzenie

We współczesnych konfiguracjach serwerowych aplikacje rzadko komunikują się bezpośrednio z internetem. Zamiast tego przed nimi znajduje się reverse proxy, które obsługuje przychodzące żądania klientów. Nginx jest jednym z najpopularniejszych narzędzi do tego zadania, ponieważ jest szybki, niezawodny i łatwy do skonfigurowania. W tym poradniku dowiesz się, jak skonfigurować Nginx jako reverse proxy dla aplikacji backendowej działającej na tym samym serwerze.

Co to jest reverse proxy?

Reverse proxy to serwer, który:

  • Akceptuje żądania od klientów (przeglądarki, API itp.)
  • Przekazuje te żądania do aplikacji backendowej
  • Wysyła odpowiedź z backendu z powrotem do klienta

Klient nigdy nie komunikuje się bezpośrednio z aplikacją backendową.

Reverse proxy vs bezpośredni dostęp

Bez reverse proxy:

Klient ---> Aplikacja backendowa (port 3000)

Z reverse proxy:

Klient ---> Nginx (port 80, 443) ---> Aplikacja backendowa (port 3000)

Dlaczego używać Nginx jako reverse proxy?

Użycie Nginx przed aplikacją pozwala na:

  • Wystawienie do internetu tylko portów 80/443
  • Ukrycie usług backendowych przed bezpośrednim dostępem
  • Terminację HTTPS (TLS) w jednym miejscu
  • Dodanie logowania, kontroli dostępu i ograniczeń szybkości
  • Uruchamianie wielu aplikacji na jednym serwerze

Dla administratorów systemów oznacza to lepsze bezpieczeństwo i łatwiejsze zarządzanie.

Scenariusz użyty w tym poradniku

Aby uprościć, użyjemy następującej konfiguracji:

  • Nginx nasłuchuje na porcie 80
  • Aplikacja backendowa nasłuchuje na 127.0.0.1:3000
  • Żądania do http://example.com są przekazywane do backendu

Diagram przepływu ruchu

[ Przeglądarka ] | v [ Nginx example.com:80,443 ] | v [ Aplikacja backendowa 127.0.0.1:3000 ]

Wymagania wstępne

Przed rozpoczęciem upewnij się, że masz:

  • Serwer Linux z najnowszym stabilnym Debianem
  • Dostęp root lub sudo
  • Już działającą aplikację backendową (np. aplikację Node.js, Python lub Java)
  • Podstawową znajomość terminala Linux

Instalacja Nginx

Zaktualizuj listy pakietów i zainstaluj Nginx oraz curl (do testowania konfiguracji):

sudo apt update

sudo apt install nginx curl

Sprawdź, czy Nginx działa:

systemctl status nginx

Powinieneś zobaczyć "active (running)" w wyniku.

Przetestuj Nginx lokalnie:

curl http://localhost

Jeśli Nginx działa, otrzymasz domyślną stronę powitalną.

Zrozumienie struktury konfiguracji Nginx

Pliki konfiguracyjne Nginx są zazwyczaj przechowywane w /etc/nginx/. Ważne katalogi:

  • /etc/nginx/nginx.conf — główny plik konfiguracyjny
  • /etc/nginx/sites-available/ — pliki konfiguracyjne witryn (nieaktywne)
  • /etc/nginx/sites-enabled/ — włączone konfiguracje witryn (linki symboliczne)

Nginx czyta pliki konfiguracyjne z folderu sites-enabled, a nie bezpośrednio z sites-available. Zaleca się tworzenie plików konfiguracyjnych witryn w sites-available, a następnie tworzenie do nich linków symbolicznych w sites-enabled.

Tworzenie konfiguracji reverse proxy

Utwórz nowy plik witryny

sudo nano /etc/nginx/sites-available/reverse-proxy.conf

Dodaj konfigurację reverse proxy

server { listen 80; server_name example.com; location / { proxy_pass http://127.0.0.1:3000; 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; } }

Zrozumienie konfiguracji

Blok serwera

server { listen 80; server_name example.com; }

  • listen 80; — Nginx nasłuchuje ruchu HTTP na porcie 80
  • server_name example.com; — nazwa domeny, na którą odpowiada ten blok serwera

Blok lokalizacji

location / { proxy_pass http://127.0.0.1:3000; 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; }

  • location / — pasuje do wszystkich przychodzących URL
  • proxy_pass — przekazuje żądania do aplikacji backendowej

Nagłówki proxy

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;

Te nagłówki zapewniają, że backend wie:

  • Oryginalną nazwę domeny
  • Prawdziwy adres IP klienta
  • Czy żądanie było HTTP czy HTTPS

Bez tych nagłówków aplikacje backendowe mogą logować nieprawidłowe informacje o kliencie.

Włączanie konfiguracji

Wyłącz domyślną witrynę Nginx, aby uniknąć konfliktów na porcie 80:

sudo rm /etc/nginx/sites-enabled/default

Utwórz link symboliczny, aby włączyć witrynę:

sudo ln -s /etc/nginx/sites-available/reverse-proxy.conf /etc/nginx/sites-enabled/

Przetestuj konfigurację pod kątem błędów składni:

sudo nginx -t

Jeśli test zakończy się sukcesem, przeładuj Nginx:

sudo systemctl reload nginx

Testowanie reverse proxy

Przetestuj z serwera:

curl http://example.com

Otwórz http://example.com w przeglądarce, aby przetestować. Powinieneś otrzymać odpowiedź z aplikacji backendowej, a nie z domyślnej strony Nginx. Jeśli wszystko jest poprawnie skonfigurowane, aplikacja backendowa się załaduje.

Jak przetwarzane jest żądanie

  1. Klient wysyła żądanie do example.com
  2. Nginx odbiera żądanie na porcie 80
  3. Nginx przekazuje żądanie do 127.0.0.1:3000
  4. Backend przetwarza żądanie
  5. Odpowiedź wraca przez Nginx
  6. Klient otrzymuje odpowiedź

Typowe błędy i rozwiązywanie problemów

Backend nie działa

  • Upewnij się, że aplikacja działa
  • Potwierdź poprawny port

ss -tuln | grep 3000

Niepoprawny adres proxy_pass

  • Zawsze dołączaj http://
  • Upewnij się, że IP i port są poprawne

Zapomnienie o przeładowaniu Nginx

Po każdej zmianie konfiguracji:

sudo systemctl reload nginx

Zapora blokuje dostęp

Upewnij się, że port 80 jest otwarty:

sudo ufw allow 80

Opcjonalne ulepszenia

Gdy reverse proxy działa, rozważ:

  • Włączenie HTTPS z Let's Encrypt
  • Uruchamianie wielu aplikacji backendowych
  • Dodanie logów dostępu i błędów
  • Konfigurację równoważenia obciążenia
  • Wsparcie dla połączeń WebSocket

Konfiguracja HTTPS

W środowiskach produkcyjnych zawsze powinieneś używać HTTPS zamiast HTTP. HTTPS szyfruje ruch między klientem a twoim serwerem, chroniąc hasła, tokeny API, ciasteczka i inne wrażliwe dane. Nginx obsługuje HTTPS za pomocą certyfikatów SSL/TLS. W tej sekcji dowiesz się:

  • Czym jest Certbot
  • Jak zainstalować Certbot
  • Jak Certbot automatycznie modyfikuje konfigurację Nginx
  • Jak ręcznie skonfigurować Nginx za pomocą zakupionego certyfikatu

Czym jest Certbot?

Certbot to narzędzie, które automatycznie uzyskuje i instaluje darmowe certyfikaty SSL/TLS od Let's Encrypt. Może:

  • Zażądać darmowego certyfikatu
  • Zweryfikować własność domeny
  • Automatycznie skonfigurować Nginx
  • Ustawić automatyczne odnawianie certyfikatu

Dla początkujących i większości środowisk produkcyjnych Certbot jest najłatwiejszym i najbezpieczniejszym sposobem na włączenie HTTPS.

Instalacja Certbot

Zaktualizuj listy pakietów:

sudo apt update

Zainstaluj Certbot i wtyczkę Nginx:

sudo apt install certbot python3-certbot-nginx

Pakiet python3-certbot-nginx pozwala Certbotowi automatycznie modyfikować konfigurację Nginx.

Uzyskiwanie i instalacja certyfikatu

Przed uruchomieniem Certbot upewnij się, że:

  • Twoja nazwa domeny wskazuje na publiczny adres IP twojego serwera
  • Nginx działa
  • Porty 80 i 443 są otwarte w zaporze

Uruchom:

sudo certbot --nginx

Certbot:

  1. Zapytaj, którą domenę chcesz zabezpieczyć
  2. Zweryfikuje własność domeny
  3. Automatycznie zaktualizuje konfigurację Nginx
  4. Przeładuje Nginx

Info

Certbot automatycznie modyfikuje konfigurację Nginx. Zazwyczaj dodaje nowy blok serwera dla portu 443 (HTTPS), dodaje ścieżki do certyfikatów SSL, konfiguruje przekierowanie z HTTP do HTTPS, jeśli wybierzesz tę opcję, i dodaje zalecane ustawienia SSL.

Przykładowa konfiguracja dodana przez Certbot:

server { listen 443 ssl; server_name example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; location / { proxy_pass http://127.0.0.1:3000; 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; } }

Certbot może również zmodyfikować blok HTTP, aby przekierować ruch:

server { listen 80; server_name example.com; return 301 https://$host$request_uri; }

Ponieważ Certbot edytuje pliki konfiguracyjne automatycznie, zaleca się:

  • Przechowywanie kopii zapasowych swojej konfiguracji
  • Zrozumienie, jakie zmiany zostały wprowadzone
  • Zawsze testowanie konfiguracji po zmianach

Testowanie konfiguracji:

sudo nginx -t

Automatyczne odnawianie certyfikatu

Certyfikaty Let's Encrypt są ważne przez 90 dni. Certbot automatycznie instaluje timer odnawiania. Możesz przetestować odnawianie za pomocą:

sudo certbot renew --dry-run

Jeśli jest poprawnie skonfigurowane, odnawianie będzie odbywać się automatycznie bez przestojów.

Używanie zakupionego certyfikatu SSL

Jeśli kupisz certyfikat SSL od urzędu certyfikacji (CA), musisz ręcznie skonfigurować Nginx. Po zakupie zazwyczaj otrzymujesz:

  • Plik certyfikatu (np. example.com.crt)
  • Klucz prywatny (example.com.key)
  • Plik pakietu CA (ca_bundle.crt)

Utwórz bezpieczny katalog:

sudo mkdir -p /etc/nginx/ssl

sudo chmod 700 /etc/nginx/ssl

Skopiuj swoje pliki certyfikatów do tego katalogu.

Przykładowa konfiguracja HTTPS z zakupionym certyfikatem:

server { listen 443 ssl; server_name example.com www.example.com; ssl_certificate /etc/nginx/ssl/example.com.crt; ssl_certificate_key /etc/nginx/ssl/example.com.key; ssl_trusted_certificate /etc/nginx/ssl/ca_bundle.crt; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; location / { proxy_pass http://127.0.0.1:3000; 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; } }

Dodaj przekierowanie z HTTP do HTTPS:

server { listen 80; server_name example.com www.example.com; return 301 https://$host$request_uri; }

Przeładuj Nginx po ręcznej konfiguracji:

sudo nginx -t

sudo systemctl reload nginx

Tip

Dla początkujących administratorów systemów Certbot jest zdecydowanie zalecany, chyba że twoja organizacja wymaga certyfikatów komercyjnych.

Podsumowanie

W tym poradniku nauczyłeś się:

  • Czym jest reverse proxy i dlaczego jest przydatne
  • Jak Nginx przekazuje żądania do aplikacji backendowych
  • Jak utworzyć i włączyć konfigurację reverse proxy
  • Jak testować i rozwiązywać typowe problemy
  • Jak skonfigurować HTTPS

Reverse proxy Nginx to podstawowa umiejętność dla administratorów systemów i jest szeroko stosowana w środowiskach produkcyjnych.

VAT

  • Other

    Ex. VAT

    0%
  • austria

    Austria

    20%
  • Belgium

    Belgium

    21%
  • Bulgaria

    Bulgaria

    20%
  • Croatia

    Croatia

    25%
  • Cyprus

    Cyprus

    19%
  • Czech Republic

    Czech Republic

    21%
  • Denmark

    Denmark

    25%
  • Estonia

    Estonia

    22%
  • France

    France

    20%
  • Finland

    Finland

    24%
  • Germany

    Germany

    19%
  • Greece

    Greece

    24%
  • Hungary

    Hungary

    27%
  • Ireland

    Ireland

    23%
  • Italy

    Italy

    22%
  • Latvia

    Latvia

    21%
  • Lithuania

    Lithuania

    21%
  • Luxembourg

    Luxembourg

    17%
  • Malta

    Malta

    18%
  • Netherlands

    Netherlands

    21%
  • Poland

    Poland

    23%
  • Portugal

    Portugal

    23%
  • Romania

    Romania

    19%
  • Slovakia

    Slovakia

    20%
  • Slovenia

    Slovenia

    22%
  • Spain

    Spain

    21%
  • Sweden

    Sweden

    25%
  • USA

    USA

    0%
european
states
  • germany
  • Español
  • Italiano
  • Poland
  • Русский
  • Slovenski
  • Türkçe
  • ukraine
  • kingdom
  • French
  • Hrvatska
  • Other
  • Austria
  • Belgium
  • Bulgaria
  • Croatia
  • Cyprus
  • Czech Republic
  • Denmark
  • Estonia
  • Finland
  • France
  • Germany
  • Greece
  • Hungary
  • Ireland
  • Italy
  • Latvia
  • Lithuania
  • Luxembourg
  • Malta
  • Netherlands
  • Poland
  • Portugal
  • Romania
  • Slovakia
  • Slovenia
  • Spain
  • Sweden
  • USA