Proxy vs reverse proxy - roznice wyjasnione na przykladach

Proxy (forward proxy) działa w imieniu klienta - pośredniczy w ruchu wychodzącym użytkownika do internetu i ukrywa jego tożsamość. Reverse proxy działa w imieniu serwera - przyjmuje ruch przychodzący i rozdziela go do serwerów zaplecza. Różnica sprowadza się do kierunku ruchu i tego, czyje interesy pośrednik reprezentuje.

W skrócie: forward proxy chroni i reprezentuje klientów, reverse proxy chroni i reprezentuje serwery. Oba siedzą w środku połączenia i pośredniczą, ale patrzą w przeciwne strony. Poniżej tabela-kotwica, a dalej po kolei: definicje, porównanie, kiedy czego używasz, konfiguracja nginx i najczęstsze wpadki.

Co to jest proxy, a co to jest reverse proxy

Forward proxy, potocznie nazywany po prostu "proxy", to pośrednik między użytkownikiem a internetem. Klient (przeglądarka, aplikacja, cała firmowa sieć) kieruje swój ruch przez proxy, a proxy wykonuje żądanie w jego imieniu i zwraca odpowiedź. Serwer docelowy widzi adres proxy, nie realny adres użytkownika. Stąd klasyczne zastosowania: anonimizacja, obejście blokad regionalnych, cache pobrań w sieci lokalnej i filtrowanie ruchu pracowników.

Reverse proxy stoi po drugiej stronie - przed serwerem albo grupą serwerów. Klient łączy się z reverse proxy, myśląc, że rozmawia z docelowym serwerem, a to reverse proxy decyduje, gdzie faktycznie przekazać żądanie. Dla świata zewnętrznego istnieje jeden adres i jedna brama, a za nią może siedzieć kilka aplikacji na różnych portach czy maszynach. Typowe zadania to load balancing, terminacja SSL, cache odpowiedzi, ochrona origin i routing po domenie lub ścieżce.

Konkret: oba narzędzia to "proxy", bo oba pośredniczą w połączeniu. Cała różnica to kierunek i to, czyje interesy reprezentują. Najprostszy obraz myślowy:

• forward proxy: klient -> forward proxy -> internet (pośrednik po stronie klienta),
• reverse proxy: internet -> reverse proxy -> serwery zaplecza (pośrednik po stronie serwera).

Kiedy pracujesz zdalnie na maszynie i konfigurujesz takiego pośrednika, robisz to zwykle przez połączenie SSH z serwerem,

• cache'ować pobrania wspólne dla wielu maszyn w sieci lokalnej.

Tu warto rozgraniczyć proxy od VPN. Zwykłe proxy HTTP kieruje ruch konkretnej aplikacji i często go nie szyfruje - pośrednik widzi treść. VPN to forma proxy działająca niżej, na poziomie całego połączenia, i szyfruje cały ruch urządzenia. Konkret: jeśli zależy Ci wyłącznie na zmianie widocznego adresu do jednego żądania, wystarczy proxy. Jeśli chcesz prywatności i szyfrowania całego ruchu w niezaufanej sieci, sięgasz po VPN (na rynku znane są usługi w rodzaju NordVPN czy Surfshark). To dwa różne poziomy ochrony, nie zamienniki.

Reverse proxy wybierasz, gdy stoisz po stronie serwera i chcesz:

• postawić nginx przed aplikacją Node.js, PHP lub Python i wystawić ją na świat pod jednym adresem,
• rozłożyć ruch między kilka instancji aplikacji (load balancing),
• terminować SSL w jednym miejscu zamiast konfigurować certyfikat w każdej aplikacji,
• hostować wiele aplikacji na jednym serwerze pod różnymi domenami,
• schować origin za warstwą pośredniczącą, np. Cloudflare jako reverse proxy z funkcją WAF.

Typowy polski scenariusz: masz jeden VPS, jeden publiczny adres IP i dwie aplikacje. Reverse proxy (nginx) słucha na porcie 443 i po nazwie domeny routuje ruch - app1.pl do aplikacji na porcie 3000, app2.pl do aplikacji na porcie 8080. Bez tego musiałbyś wystawiać aplikacje na różnych portach i podawać je w adresie, co jest brzydkie i trudne do zabezpieczenia. Reverse proxy wdrażasz właśnie na własnym serwerze, więc dobór sensownego VPS ma znaczenie - jeśli dopiero wybierasz maszynę, zajrzyj do zestawienia w porównaniu hostingu i VPS.

Przyklady praktyczne

Krok po kroku: najczęstsza konfiguracja to reverse proxy w nginx, który przyjmuje ruch i przekazuje go do aplikacji chodzącej lokalnie na porcie 3000.

server {
    listen 80;
    server_name app.example.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;
    }
}

Co robi każdy nagłówek: Host przekazuje aplikacji nazwę domeny, po której przyszedł klient (bez tego aplikacja może budować złe linki). X-Real-IP i X-Forwarded-For niosą prawdziwy adres klienta, żeby aplikacja nie logowała adresu proxy. X-Forwarded-Proto mówi aplikacji, że klient przyszedł po HTTPS, nawet jeśli do backendu ruch idzie po HTTP.

Terminacja SSL to jeden z głównych powodów, dla których stawia się reverse proxy. Certyfikat instalujesz na proxy, ono odszyfrowuje ruch, a do aplikacji w sieci lokalnej przekazuje już zwykły HTTP. Dzięki temu certyfikat jest w jednym miejscu, a aplikacja nie musi wiedzieć nic o SSL. Reverse proxy słucha na 443, aplikacja nasłuchuje tylko na 127.0.0.1:3000 i nie jest wystawiona bezpośrednio.

Reverse proxy jako load balancer rozkłada ruch między kilka backendów. W nginx robi to blok upstream:

upstream app_backend {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
}

server {
    listen 80;
    location / {
        proxy_pass http://app_backend;
    }
}

Domyślnie nginx rozdziela zapytania metodą round-robin - kolejne połączenia trafiają na przemian do obu instancji. Gdy jedna padnie, ruch idzie do drugiej. To najprostsza droga do większej odporności bez przepisywania aplikacji.

Po stronie forward proxy konfiguracja wygląda inaczej - ustawiasz ją u klienta. W terminalu Linux robisz to zmiennymi środowiskowymi albo przełącznikiem narzędzia:

export http_proxy="http://proxy.firma.local:8080"
export https_proxy="http://proxy.firma.local:8080"
curl -x http://proxy.firma.local:8080 https://example.pl

Tu widać różnicę w praktyce: przy reverse proxy to serwer decyduje o pośredniku, przy forward proxy - klient. Więcej o samych narzędziach do takich zadań znajdziesz w porównaniu wget i curl.

Czeste bledy i pulapki

Sprawdź te punkty, zanim uznasz, że reverse proxy działa poprawnie - większość realnych problemów siedzi właśnie tutaj.

• Mylenie forward i reverse. To najczęstsze nieporozumienie. Zawsze wracaj do pytania "czyje interesy reprezentuje pośrednik": klienta czy serwera. To rozstrzyga w każdym przypadku.
• Brak proxy_set_header Host. Aplikacja widzi wtedy 127.0.0.1 zamiast realnej domeny i generuje złe przekierowania oraz błędne linki bezwzględne. Objaw: dziwne redirecty i psujące się ścieżki.
• Brak X-Forwarded-For. Aplikacja loguje adres proxy zamiast realnego klienta. Wszystkie statystyki i limity oparte na IP przestają mieć sens.
• Pętla przekierowań przy terminacji SSL. Proxy kończy SSL i wysyła ruch do backendu po HTTP, a backend wymusza HTTPS i odbija klienta z powrotem. Rozwiązanie: przekaż X-Forwarded-Proto https i skonfiguruj aplikację tak, by ufała temu nagłówkowi.
• Mylenie reverse proxy z load balancerem i z VPN. Reverse proxy może pełnić rolę load balancera, ale load balancer to węższe pojęcie skupione na rozkładaniu ruchu. VPN to z kolei forward proxy całego połączenia. Są pokrewne, nie tożsame.
• Forward proxy a bezpieczeństwo. Proxy HTTP samo w sobie nie szyfruje ruchu tak jak VPN - jeśli potrzebujesz prywatności, samo proxy nie wystarczy. A gdy przy terminacji SSL na reverse proxy zobaczysz błąd certyfikatu, zacznij od sprawdzenia łańcucha certyfikatów i zgodności nazwy domeny.

Pro tip admina: po każdej zmianie w konfiguracji nginx uruchom nginx -t przed przeładowaniem. Test składni wyłapie literówkę, zanim położysz działającą usługę.

Reverse proxy a load balancer, API gateway i port forwarding

Wokół reverse proxy krąży kilka pojęć, które łatwo pomylić, bo częściowo się pokrywają. Konkret: to nie są synonimy, choć ten sam nginx potrafi udawać każde z nich.

Load balancer to urządzenie lub oprogramowanie skupione na jednym zadaniu - równym rozkładaniu ruchu między serwery. Reverse proxy może to robić (jak w bloku upstream wyżej), ale dokłada terminację SSL, cache i routing. W praktyce load balancer bywa osobną warstwą przed kilkoma reverse proxy, gdy skala jest naprawdę duża. Dla jednego czy dwóch VPS-ów reverse proxy z wbudowanym round-robin wystarcza w zupełności.

API gateway to reverse proxy wyspecjalizowany pod API - dokłada uwierzytelnianie, limity zapytań, wersjonowanie i transformację odpowiedzi. Trade-off: daje więcej funkcji dla mikroserwisów, ale wprowadza dodatkową złożoność. Dla klasycznej strony czy pojedynczej aplikacji zwykły reverse proxy załatwia sprawę, a API gateway to przerost formy.

Port forwarding (przekierowanie portów) działa niżej, na poziomie sieci - przepuszcza ruch z jednego portu na drugi bez rozumienia protokołu HTTP. Reverse proxy patrzy w treść żądania (nagłówek Host, ścieżkę) i na tej podstawie decyduje, dokąd je skierować. Port forwarding nie potrafi rozdzielić dwóch domen na jednym adresie IP, reverse proxy tak.

To zależy od ruchu: dla większości polskich firm z jedną lub kilkoma aplikacjami na VPS reverse proxy w nginx pokrywa wszystkie te potrzeby naraz, bez dokładania osobnego load balancera czy API gateway.

Nginx czy Apache w roli reverse proxy

Oba serwery pełnią rolę reverse proxy, więc pytanie "nginx czy Apache" pojawia się przy niemal każdym wdrożeniu. W skrócie: nginx projektowano jako serwer zdarzeniowy, lekki przy tysiącach równoległych połączeń, i to on stał się domyślnym wyborem do reverse proxy oraz load balancingu. Apache z modułem mod_proxy też to potrafi i bywa naturalny tam, gdzie już stoi (np. hosting z .htaccess), ale przy dużej liczbie jednoczesnych połączeń zjada więcej pamięci.

Konkret: jeśli budujesz warstwę pośredniczącą od zera, zacznij od nginx - mniejszy ślad pamięciowy, prostsza składnia bloku upstream, ogrom gotowych przykładów. Warto znać też lżejsze alternatywy: Caddy z automatycznym HTTPS z Let's Encrypt (świetny do szybkiego startu) oraz Traefik, który sam wykrywa kontenery Docker i buduje routing dynamicznie. Wybór zależy od tego, co już masz w infrastrukturze, nie od tego, który serwer jest "najlepszy" w oderwaniu od kontekstu.

FAQ

Jaka jest główna różnica między proxy a reverse proxy? Forward proxy działa w imieniu klienta i pośredniczy w ruchu wychodzącym do internetu, ukrywając tożsamość użytkownika. Reverse proxy działa w imieniu serwera i przyjmuje ruch przychodzący, rozdzielając go do serwerów zaplecza. Różnica to kierunek ruchu oraz to, czyje interesy pośrednik reprezentuje.

Czy reverse proxy to to samo co load balancer? Nie do końca. Reverse proxy może rozkładać ruch między backendy i wtedy pełni rolę load balancera, ale robi też więcej: terminuje SSL, cache'uje odpowiedzi i routuje po domenie. Load balancer to węższe pojęcie skupione wyłącznie na równomiernym rozkładaniu ruchu między serwery.

Czy reverse proxy to VPN? Nie. VPN to forward proxy działający na poziomie całego połączenia urządzenia, który szyfruje cały ruch i reprezentuje klienta. Reverse proxy stoi po stronie serwera, przyjmuje ruch przychodzący i nie służy do anonimizacji użytkownika. To dwa różne narzędzia patrzące w przeciwne strony połączenia.

Po co stosuje się reverse proxy? Reverse proxy centralizuje kilka zadań przed aplikacją: terminuje SSL w jednym miejscu, rozkłada ruch między instancje, cache'uje odpowiedzi, routuje wiele domen na jednym adresie IP i chroni origin przed bezpośrednim ruchem z internetu. Upraszcza to konfigurację i zwiększa odporność oraz bezpieczeństwo.

Czy nginx to forward czy reverse proxy? Nginx może pełnić obie role. Najczęściej występuje jako reverse proxy przed aplikacjami i jako load balancer, ale potrafi też działać jako forward proxy dla ruchu wychodzącego. O jego roli decyduje konfiguracja, nie samo narzędzie - ten sam serwer obsłuży oba scenariusze.

Czy reverse proxy zwiększa bezpieczeństwo serwera? Tak, pośrednio. Ukrywa strukturę zaplecza, zostawia aplikację na adresie lokalnym zamiast wystawiać ją bezpośrednio, centralizuje certyfikaty SSL i może filtrować ruch (np. Cloudflare z WAF). Nie zastąpi jednak firewalla ani aktualizacji aplikacji - to jedna z warstw ochrony, nie całość.