Nginx jako reverse proxy na VPS

Reverse proxy to serwer, który przyjmuje cały ruch z internetu i przekazuje go do właściwej aplikacji działającej na serwerze. Nginx świetnie się do tego nadaje, gdy na jednym VPS uruchamiasz aplikacje Node.js, Python czy Go albo usługi w kontenerach: Obsłużysz wiele domen, podłączysz certyfikaty SSL w jednym miejscu i ukryjesz aplikacje przed bezpośrednim dostępem. Ten poradnik pokazuje, jak to skonfigurować.

Czym jest reverse proxy i po co go używać

Aplikacje webowe (np. w Node.js) zwykle nasłuchują na lokalnym porcie, takim jak 3000 czy 8000. Wystawianie ich wprost do internetu jest niewygodne i mniej bezpieczne. Reverse proxy rozwiązuje to, dając jeden wspólny punkt wejścia:

• Obsługa wielu aplikacji i domen na jednym serwerze, każda kierowana do swojej usługi.
• Terminacja SSL, czyli szyfrowanie obsługiwane w jednym miejscu, a nie osobno w każdej aplikacji.
• Ukrycie aplikacji, która odpowiada tylko lokalnie, a do internetu wystawiony jest wyłącznie Nginx na portach 80 i 443.
• Wspólne funkcje (kompresja, nagłówki) ustawione raz dla wszystkiego.

To dlatego reverse proxy stawia się przed aplikacjami Node.js, Python i Go oraz przed kontenerami Docker.

Krok 1: Zainstaluj Nginx

Jeśli Nginx nie działa jeszcze na serwerze, zainstaluj go zgodnie z artykułem o LEMP/LAMP. Upewnij się też, że serwer jest wstępnie zabezpieczony, jak opisujemy w artykule o pierwszych krokach na VPS.

Krok 2: Skonfiguruj przekazywanie do aplikacji

Utwórz konfigurację dla swojej domeny i wskaż w niej, dokąd Nginx ma przekazywać ruch. Najprostszy reverse proxy do aplikacji nasłuchującej lokalnie na porcie 3000 wygląda tak:

server {
    listen 80;
    server_name twojadomena.pl;

    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;
    }
}

Nagłówki X-Real-IP i X-Forwarded-For przekazują aplikacji prawdziwy adres odwiedzającego, a X-Forwarded-Proto informuje ją, czy połączenie przyszło po HTTPS. Bez nich aplikacja widziałaby tylko adres samego serwera. Po zapisaniu konfiguracji przeładuj Nginx.

Obsługa wielu domen i aplikacji

Aby obsłużyć kilka aplikacji, utwórz osobny blok server dla każdej domeny i skieruj go do innego portu lokalnego:

server {
    listen 80;
    server_name aplikacja-a.pl;
    location / { proxy_pass http://127.0.0.1:3000; }
}

server {
    listen 80;
    server_name aplikacja-b.pl;
    location / { proxy_pass http://127.0.0.1:8000; }
}

Nginx kieruje ruch do właściwej aplikacji na podstawie domeny, z którą łączy się odwiedzający. W ten sposób jeden serwer obsługuje wiele niezależnych usług.

Obsługa WebSocketów

Aplikacje czasu rzeczywistego (czaty, powiadomienia, część aplikacji Node.js) korzystają z WebSocketów, które wymagają dodatkowych nagłówków. Bez nich połączenie zostanie zerwane:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
}

Terminacja SSL

Najwygodniej dodać HTTPS Certbotem, który sam dopisze konfigurację SSL do Twoich bloków server i ustawi przekierowanie z http na https. Proces opisujemy w poradniku o darmowym SSL na VPS. Po jego wykonaniu Nginx szyfruje połączenia z odwiedzającymi, a do aplikacji przekazuje ruch lokalnie. To właśnie terminacja SSL: Szyfrowanie kończy się na Nginx, więc nie musisz konfigurować certyfikatów w każdej aplikacji osobno.

Krok 3: Firewall

Skoro cały ruch WWW wchodzi przez Nginx, z internetu udostępnij porty 80 i 443 oraz port SSH (domyślnie 22), żeby nie odciąć sobie dostępu do serwera, a porty samych aplikacji zostaw dostępne wyłącznie lokalnie. Konfigurację zapory opisujemy w artykule o firewallu na VPS.

Najczęstsze problemy

• 502 Bad Gateway: Nginx działa, ale nie może połączyć się z aplikacją. Najczęściej aplikacja nie jest uruchomiona albo nasłuchuje na innym porcie niż podany w proxy_pass. Sprawdź, czy aplikacja działa i na jakim porcie.
• Aplikacja widzi adres serwera zamiast odwiedzającego: brakuje nagłówków X-Real-IP i X-Forwarded-For w konfiguracji proxy.
• Zerwane połączenia w aplikacji czasu rzeczywistego: brak nagłówków WebSocket (Upgrade i Connection).

Najczęstsze pytania

Czym reverse proxy różni się od zwykłego serwera WWW?

Zwykły serwer WWW sam serwuje pliki strony. Reverse proxy nie obsługuje treści bezpośrednio, tylko przekazuje żądania do aplikacji działających w tle i odsyła ich odpowiedzi. Nginx potrafi pełnić obie role naraz.

Czy potrzebuję reverse proxy do aplikacji w kontenerze?

To zalecany układ. Kontenery uruchamiasz na portach lokalnych, a Nginx przed nimi obsługuje domeny i SSL, dzięki czemu nie wystawiasz kontenerów wprost do internetu. Docker opisujemy w osobnym artykule.

Czy jeden certyfikat wystarczy dla wszystkich aplikacji?

To zależy od domen, nie od samych aplikacji. Jeśli każda aplikacja działa pod własną domeną, każda domena potrzebuje swojego certyfikatu; jeśli kilka aplikacji dzieli jedną domenę (różne ścieżki), wystarczy jeden. Tak czy inaczej, obsługujesz je w jednym miejscu, w Nginx, a Certbot wystawia i odnawia certyfikaty, więc nie konfigurujesz SSL w samych aplikacjach.

Dostaję błąd 502 Bad Gateway, co robić?

Oznacza, że Nginx nie może połączyć się z aplikacją w tle. Sprawdź, czy aplikacja jest uruchomiona i czy nasłuchuje dokładnie na porcie wskazanym w proxy_pass. Pomaga w tym menedżer procesów opisany w artykule o deploymencie aplikacji.