Reverse proxy - co to jest i jak działa (nginx, Caddy, Cloudflare)

Reverse proxy to serwer pośredniczący stojący przed aplikacjami: odbiera żądania z internetu i przekazuje je do właściwego backendu, a odpowiedź oddaje użytkownikowi. Daje jeden adres wejścia, HTTPS, ukrycie portów, cache i równoważenie obciążenia. Najpopularniejsze to nginx, Caddy i Cloudflare.

Co to jest reverse proxy

Reverse proxy to warstwa, która siedzi między internetem a Twoimi serwerami aplikacji i występuje wobec klienta jako jedyny widoczny adres. Klient wysyła żądanie na jeden host (np. twojadomena.pl na porcie 443), a proxy decyduje, do którego backendu je skierować - do aplikacji Node.js na porcie 8080, do WordPressa na 8081 albo do panelu na 3000. Backend nazywamy origin server albo upstream, a pulę backendów - backend pool.

Dobra analogia to recepcjonista w biurowcu. Wchodzisz jednymi drzwiami i mówisz, w jakiej sprawie przychodzisz. To recepcja kieruje Cię do właściwego pokoju - nie musisz znać numerów pięter ani wewnętrznych numerów telefonów. Reverse proxy działa tak samo: klient zna tylko adres frontowy, a wewnętrzna topologia serwerów pozostaje ukryta.

Skąd "reverse", czyli odwrotny? Bo klasyczny (forward) proxy reprezentuje i chroni klienta - stoi po stronie osoby wychodzącej do internetu, jak firmowy proxy filtrujący ruch pracowników. Reverse proxy jest lustrzanym odbiciem: reprezentuje i chroni serwery, stoi po stronie usługi, do której użytkownik się łączy. Ten sam mechanizm pośrednika, przeciwny kierunek działania.

Konkret: samo pośredniczenie to nie wszystko. Po drodze proxy terminuje TLS (rozszyfrowuje HTTPS), dopisuje nagłówki takie jak X-Forwarded-For i X-Real-IP, żeby backend wiedział, kto naprawdę pyta, i może cache'ować odpowiedzi. Serwer aplikacji dostaje czysty ruch HTTP z jednego, zaufanego źródła.

Jak działa reverse proxy - krok po kroku

Prześledźmy jedno żądanie od kliknięcia w przeglądarce do odpowiedzi. Krok po kroku:

1. Klient wpisuje adres. DNS zamienia domenę na adres IP - a ten IP należy do reverse proxy, nie do serwera aplikacji.
2. Żądanie trafia na proxy, zwykle na port 443 (HTTPS). Proxy terminuje TLS, czyli rozszyfrowuje połączenie i dalej rozmawia z backendem po zwykłym HTTP w sieci lokalnej.
3. Proxy patrzy na nagłówek Host i na ścieżkę URL, po czym decyduje, do którego upstreamu skierować ruch - na przykład na 127.0.0.1:8080.
4. Zanim przekaże żądanie, dopisuje nagłówki: X-Forwarded-For (prawdziwy IP klienta), X-Real-IP i X-Forwarded-Proto (czy klient szedł po HTTPS).
5. Backend przetwarza żądanie i zwraca odpowiedź do proxy. Proxy może ją skompresować, dołożyć do cache i dopiero wtedy oddaje ją klientowi po zaszyfrowanym kanale.

Schematycznie przepływ wygląda tak:

Klient (HTTPS/443)
   -> DNS -> Reverse proxy (terminacja TLS, routing, cache)
      -> Upstream 127.0.0.1:8080 (aplikacja, czysty HTTP)
      <- odpowiedz
   <- odpowiedz do klienta (HTTPS)

Nagłówki przekazywane do backendu

To miejsce, w którym najczęściej boli. Skoro całość ruchu wchodzi przez proxy, backend widzi jako źródło połączenia zawsze ten sam adres - IP proxy, czyli często 127.0.0.1. Gdyby aplikacja logowała ten adres jako IP użytkownika, wszystkie wpisy w logach byłyby identyczne, a limity po IP czy geolokalizacja przestałyby działać.

Rozwiązaniem jest nagłówek X-Forwarded-For, w którym proxy wpisuje prawdziwy adres klienta. Ale jest haczyk: aplikacja musi być skonfigurowana tak, żeby ufać temu nagłówkowi - i to wyłącznie od swojego proxy. Jeśli backend jest wystawiony bezpośrednio do sieci, ktoś może podrobić X-Forwarded-For i podszyć się pod dowolny IP. Dlatego backend powinien słuchać tylko na interfejsie lokalnym, a nie na publicznym.

Reverse proxy vs forward proxy vs load balancer

Trzy pojęcia, które łatwo pomylić, bo wszystkie pośredniczą w ruchu. Różni je to, kogo chronią i co dokładnie robią.

Forward proxy vs reverse proxy

Najprostsze rozróżnienie to kierunek i strona, którą pośrednik reprezentuje.

Forward proxy stoi przy kliencie: pracownik wychodzi do internetu przez firmowy serwer, który filtruje strony i ukrywa jego adres. Reverse proxy stoi przy usłudze: użytkownik z internetu łączy się z Twoim serwerem, a proxy przyjmuje go w imieniu backendu i pilnuje, żeby nie sięgnął głębiej, niż powinien.

Reverse proxy vs load balancer

Tu nie ma sztywnej granicy i stąd całe zamieszanie. Load balancer to wyspecjalizowana funkcja - rozkłada ruch na pulę identycznych serwerów, żeby żaden się nie zapchał. Reverse proxy to pojęcie szersze: robi routing, terminację TLS, cache, kompresję i ochronę, a równoważenie obciążenia jest jedną z jego możliwości.

W praktyce to zależy od narzędzia: nginx potrafi pełnić obie role naraz - kieruje ruch po domenie i jednocześnie rozdziela go na kilka kopii aplikacji. Trade-off: dedykowany load balancer (jak HAProxy czy usługa chmurowa) bywa wydajniejszy przy ogromnym ruchu i ma bogatsze mechanizmy zdrowia backendów, ale dla małego i średniego setupu jeden dobrze ustawiony reverse proxy załatwia wszystko.

Do czego służy reverse proxy - zastosowania

W skrócie: reverse proxy przydaje się wtedy, gdy masz więcej niż jedną usługę albo chcesz oddzielić to, co widoczne z internetu, od tego, co działa w środku. Najczęstsze zastosowania:

• Jeden adres i HTTPS dla wielu aplikacji - kilka usług (aplikacja, API, panel, blog) chowasz za jedną domeną i jednym certyfikatem. Idealne przy mikroserwisach, homelab i kontenerach Docker, gdzie każda usługa siedzi na innym porcie.
• Terminacja SSL/TLS w jednym miejscu - certyfikat konfigurujesz i odnawiasz raz, na proxy, zamiast w każdej aplikacji z osobna. Backendy rozmawiają po zwykłym HTTP w sieci lokalnej.
• Ukrycie i ochrona backendu - wewnętrzne porty nie są widoczne z zewnątrz, a proxy może dokładać WAF (web application firewall), rate limiting i ochronę przed atakami DoS oraz DDoS.
• Cache, kompresja i równoważenie obciążenia - proxy odciąża serwer aplikacji, oddając powtarzalne odpowiedzi z pamięci, kompresując treść i rozkładając ruch na pulę backendów. To bezpośrednio poprawia skalowalność i wydajność.

Reverse proxy stawia się na własnym serwerze - VPS albo maszynie w homelab. Jeśli dopiero dobierasz maszynę pod taki setup, pomocne będzie porównanie w zestawieniu VPS pod nginx, Caddy i Docker, bo wymagania proxy są skromne, ale liczy się stabilność i kontrola nad portami.

nginx jako reverse proxy - minimalna konfiguracja

nginx to najczęstszy wybór na produkcji: dojrzały, szybki, świetnie udokumentowany. Konfigurację reverse proxy sprowadza się do bloku server z jedną lokalizacją i dyrektywą proxy_pass, która wskazuje upstream.

server {
    listen 443 ssl;
    server_name twojadomena.pl;

    # certyfikat TLS - terminacja SSL na proxy
    ssl_certificate     /etc/letsencrypt/live/twojadomena.pl/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/twojadomena.pl/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;   # backend, czysty HTTP w sieci lokalnej

        # przekazanie prawdziwego klienta do aplikacji
        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;
    }
}

Kluczowe są cztery linie proxy_set_header. Bez nich aplikacja zobaczy jako źródło ruchu adres proxy i nie dowie się, czy klient szedł po HTTPS. Sprawdź: po każdej zmianie testuj konfigurację poleceniem nginx -t i dopiero wtedy przeładuj usługę.

Ten sam wzorzec działa, gdy backendem jest kontener - przy docker nginx reverse proxy proxy_pass wskazujesz na nazwę usługi w sieci Dockera zamiast na 127.0.0.1. A jeśli wahasz się między nginx a Apache pod rolę serwera i proxy, rozstrzyga to porównanie nginx kontra Apache - dla czystego reverse proxy nginx zwykle wygrywa lekkością.

Caddy jako reverse proxy - HTTPS automatyczny

Caddy to nowszy serwer, który zdobywa popularność jednym argumentem: HTTPS działa od razu, bez ręcznej konfiguracji certyfikatów. Cała definicja reverse proxy mieści się w dwóch liniach Caddyfile:

twojadomena.pl {
    reverse_proxy 127.0.0.1:8080
}

To wszystko. Caddy sam pobierze i odnowi certyfikat z Let's Encrypt, wymusi HTTPS i dopisze standardowe nagłówki forwardingu. Dla początkującego, który stawia pierwszy serwer, to ogromne uproszczenie - nie ma osobnego kroku z certyfikatem, nie ma zapomnianego auto-renew.

Trade-off: nginx daje więcej drobnej kontroli i ma większą bazę gotowych przepisów na nietypowe scenariusze, a w bardzo dużych wdrożeniach bywa wydajniejszy. Caddy wybieraj, gdy zależy Ci na prostocie i szybkim starcie z poprawnym HTTPS, a nie na dłubaniu w każdym parametrze. To zależy od tego, ile czasu chcesz spędzić przy konfiguracji.

Cloudflare jako reverse proxy - warstwa w chmurze

nginx i Caddy uruchamiasz na własnym serwerze. Cloudflare działa inaczej - to reverse proxy jako usługa, siedzące w chmurze przed Twoim serwerem. Włączasz je, ustawiając rekord DNS w trybie proxied (pomarańczowa chmurka w panelu). Od tego momentu cały ruch do domeny idzie najpierw przez sieć Cloudflare, a dopiero potem do Twojego origin.

Co to daje: WAF filtrujący złośliwe żądania, ochronę przed DDoS w skali sieci brzegowej, cache statycznych zasobów blisko użytkownika i ukrycie prawdziwego adresu IP serwera - z zewnątrz widać tylko adresy Cloudflare. Konkret: to nie zastępuje proxy na serwerze, tylko je uzupełnia. Typowy układ to Cloudflare jako warstwa brzegowa plus nginx albo Caddy lokalnie, które terminuje TLS i rozdziela ruch między usługi. Dwa reverse proxy w łańcuchu, każdy w swojej roli.

Częste błędy i pułapki

Reverse proxy potrafi zadziałać w pięć minut, ale te same kilka problemów wraca u każdego. Krok po kroku, co sprawdzić najpierw:

• 502 Bad Gateway - proxy nie dostało poprawnej odpowiedzi od backendu. Najczęściej aplikacja nie działa, słucha na innym porcie niż proxy_pass albo tylko na innym interfejsie. Sprawdź, czy backend faktycznie odpowiada lokalnie, choćby przez test endpointu curlem lub wgetem proxy reprezentuje klienta - stoi po jego stronie, ukrywa jego adres i pośredniczy w ruchu wychodzącym do internetu. Reverse proxy reprezentuje serwer: przyjmuje ruch przychodzący z internetu w imieniu backendu, ukrywa jego wewnętrzną strukturę i chroni go. Ten sam mechanizm pośrednika, przeciwna strona i kierunek.

Reverse proxy czy load balancer - co wybrać? Load balancer to jedna z funkcji reverse proxy, a nie osobna alternatywa. Jeśli chcesz tylko rozłożyć ruch na kilka identycznych serwerów, wystarczy load balancing. Jeśli potrzebujesz też HTTPS, routingu po domenie, cache i ochrony, wybierz reverse proxy - narzędzia takie jak nginx pełnią obie role naraz.

Czy reverse proxy spowalnia stronę? W praktyce najczęściej ją przyspiesza. Dodatkowy przeskok kosztuje ułamki milisekundy w sieci lokalnej, ale proxy oddaje powtarzalne odpowiedzi z cache, kompresuje treść i odciąża backend. Zysk z buforowania i kompresji zwykle wielokrotnie przewyższa mikroskopijne opóźnienie samego pośredniczenia.

Czy potrzebuję reverse proxy do jednej aplikacji? Nawet przy jednej usłudze bywa opłacalne. Daje wygodną terminację TLS w jednym miejscu, ukrywa port aplikacji, pozwala dołożyć rate limiting i cache oraz ułatwia późniejsze dodanie kolejnych usług bez przebudowy. Dla prostego, pojedynczego serwisu nie jest obowiązkowe, ale porządkuje setup.

nginx, Caddy czy Cloudflare - co dla początkującego? Na start Caddy, bo HTTPS działa od razu bez konfiguracji certyfikatów. nginx wybierz, gdy potrzebujesz drobnej kontroli i gotowych przepisów na nietypowe scenariusze. Cloudflare dołóż jako warstwę w chmurze przed serwerem - dla ochrony DDoS, WAF i cache brzegowego. Najczęściej łączy się Cloudflare z lokalnym nginx albo Caddy.

Czy reverse proxy daje HTTPS za darmo? Tak, w połączeniu z Let's Encrypt. Caddy pobiera i odnawia darmowy certyfikat automatycznie, nginx wymaga jednorazowej konfiguracji certbota z auto-renew, a Cloudflare zapewnia HTTPS na warstwie brzegowej. W każdym z tych scenariuszy certyfikat nic nie kosztuje, a terminacja TLS dzieje się na proxy.

Podsumowanie

W skrócie: reverse proxy to jeden punkt wejścia, który przyjmuje ruch z internetu, terminuje HTTPS, ukrywa i chroni backendy oraz rozdziela żądania między usługi. nginx daje pełną kontrolę, Caddy - najprostszy start z automatycznym HTTPS, a Cloudflare dokłada ochronę i cache w chmurze; najlepsze setupy często łączą warstwę brzegową z lokalnym proxy. Reverse proxy zaczyna się od własnego serwera, więc gdy będziesz dobierać maszynę pod nginx, Caddy czy Docker, punktem wyjścia jest porównanie VPS pod takie wdrożenie. Samą maszyną administrujesz najczęściej przez połączenie SSH z serwerem - to tam edytujesz konfigurację proxy i przeładowujesz usługę.