Generator Nginx reverse proxy

Generator Nginx reverse proxy

Reverse proxy przyjmuje ruch z internetu i przekazuje go do aplikacji działającej lokalnie (np. na porcie 3000). Nginx pełni tu rolę bramy z SSL i nagłówkami.

Kluczowe dyrektywy

WebSocket

Aplikacje real-time (czaty, aplikacje na żywo) wymagają przekazania nagłówków Upgrade i Connection. Bez nich połączenie WebSocket nie zadziała.

Wdrożenie

nginx -t
systemctl reload nginx

Zawsze sprawdź składnię przed przeładowaniem — błąd w konfiguracji może zatrzymać serwer.

Jak działa generator bloku server dla reverse proxy

Generator zbiera z formularza kilka niezależnych informacji: domenę, adres aplikacji docelowej, port, sposób obsługi HTTPS, opcję WebSocket oraz dodatkowe nagłówki. Na tej podstawie buduje tekst bloku server, który można wkleić do konfiguracji Nginx. Nie uruchamia serwera ani nie sprawdza, czy aplikacja faktycznie nasłuchuje pod podanym adresem. Tworzy jedynie poprawną składniowo deklarację, która po wdrożeniu ma kierować ruch z zewnątrz do wskazanego procesu.

Mechanizm działania opiera się na dopasowaniu żądania przez Nginx. Najpierw wybierany jest blok server na podstawie server_name i portu, na którym przyszło połączenie. Następnie lokalizacja location / przechwytuje żądanie i przekazuje je dalej przez proxy_pass. Nagłówki takie jak Host, X-Forwarded-Proto czy X-Forwarded-For informują aplikację, z jakiej domeny, protokołu i adresu IP przyszło żądanie. Dzięki temu aplikacja może generować poprawne linki, logować ruch i podejmować decyzje bezpieczeństwa.

Wynik zależy wyłącznie od ustawień wprowadzonych w formularzu, ponieważ narzędzie nie korzysta ze sztywnych tablic wartości. Jeśli zmienisz port aplikacji, wyłączysz HTTPS albo dodasz obsługę WebSocket, wygenerowany blok server zmieni się odpowiednio. To czyni generator wygodnym punktem startowym, ale nadal wymaga zrozumienia, jak Nginx przetwarza ruch i jak wygląda topologia Twojej infrastruktury.

Przykład krok po kroku dla aplikacji na porcie 3000

1. W polu domeny wpisz app.example.com. To trafi do dyrektywy server_name i sprawi, że blok będzie obsługiwał ruch właśnie dla tej subdomeny.
2. Jako adres aplikacji podaj 127.0.0.1:3000. Taki wpis oznacza, że Nginx ma przekazywać żądania do procesu działającego lokalnie na porcie 3000.
3. Zaznacz opcję HTTPS oraz przekierowanie z HTTP na HTTPS. Generator przygotuje dwa bloki server: pierwszy na porcie 80 z przekierowaniem 301, drugi na porcie 443 z konfiguracją SSL i właściwym proxy_pass.
4. Włącz obsługę WebSocket, jeśli aplikacja korzysta z połączeń dwukierunkowych. W wygenerowanym pliku pojawią się nagłówki Upgrade i Connection ustawione na wartości wymagane przez protokół.
5. Wygeneruj konfigurację i sprawdź, czy aplikacja odpowiada bezpośrednio pod adresem 127.0.0.1:3000. Dopiero potem wdrażaj blok server, aby uniknąć sytuacji, w której Nginx kieruje ruch do niedziałającego procesu.
6. Po wdrożeniu przetestuj adres https://app.example.com. Oczekiwany wynik to odpowiedź aplikacji z portu 3000, ale widoczna pod domeną z certyfikatem SSL. Ruch z portu 80 powinien zostać przekierowany na 443, a nagłówki przekazane do aplikacji powinny zawierać informację o oryginalnym protokole HTTPS.

Zależność między ustawieniem a wygenerowanym fragmentem

Praktyczne wskazówki przed wdrożeniem

• Trzymaj osobny plik dla każdej domeny — łatwiej wtedy wycofać zmianę, uniknąć konfliktów server_name i porównać konfiguracje między środowiskami.
• Sprawdź, na jakim interfejsie nasłuchuje aplikacja — jeśli proces jest dostępny tylko lokalnie, użyj adresu pętli zwrotnej. Jeśli działa w kontenerze, wskaż nazwę usługi lub adres sieciowy zamiast ślepo kopiować 127.0.0.1.
• Dostosuj timeouts do charakteru ruchu — krótkie żądania API nie potrzebują długich czasów oczekiwania, ale aplikacje real-time mogą wymagać większych wartości proxy_read_timeout.
• Przekazuj oryginalne IP i protokół — dzięki temu logi i mechanizmy ograniczania ruchu w aplikacji będą opierać się na danych klienta, a nie na adresie proxy.
• Testuj na kopii konfiguracji — przed przeładowaniem produkcyjnego Nginxa użyj środowiska staging lub tymczasowego portu, aby sprawdzić, czy ruch faktycznie trafia do właściwej aplikacji.

Ograniczenia generatora

• Nie zastępuje hardeningu TLS — generator tworzy podstawowe dyrektywy SSL, ale nie dobiera polityk szyfrów, OCSP stapling ani parametrów wymaganych w audycie bezpieczeństwa.
• Nie zna topologii sieci — nie wie, czy aplikacja działa w Dockerze, Kubernetesie, za load balancerem albo CDN. Adres upstream trzeba podać ręcznie i zweryfikować po stronie infrastruktury.
• Nie konfiguruje zdrowia upstreamu — brak health checków, kolejkowania i automatycznego wyłączania błędnych instancji. Do tego potrzebny jest pełny blok upstream oraz mechanizmy zewnętrzne.
• Nie uwzględnia limitów aplikacji — wygenerowane bufory, timeouts i limit ciała żądania są ogólne. Wysokie uploady lub długotrwałe połączenia wymagają dostrojenia zarówno w Nginx, jak i w samej aplikacji.

Najczęstsze pytania